Ascending to Godmode - Analyzing Privilege Escalation Tactics
If you thought that we were done pwning the network you were wrong. We are going to hit the throttle, skyrocket our privileges, and dominate the network. If you thought I would skip a chance to throw a picture of the Thunderbirds ascending into the heavens on my blog, you would also be wrong. You may be thinking to yourself, we’ve already hax0red the network, why do anything else? Write the report, send it to the team lead, and enjoy the rest of the 4-week paid vacation. Wrong, we are here to crush our enemies, see their servers driven before us, and to hear the lamentations of their sysadmins!!!
The goal of this phase is to escalate our privileges on the network to enable the effects phase. We are going to leverage our established footholds to target local administrative access, domain administrator access, and privileged application access. Once we have achieved these goals we will be able to plunder and pillage as we please throughout the network and there is not a thing the blue team can do to stop us.
Status of Forces
We left off in the last phase with an unprivileged local user account on a web application server and a privileged local system account on the network’s external DNS server. During our reconnaissance phase we established that the organization runs a standard network topology with a DMZ set up that both our servers are sitting inside. From the DMZ we are able to pivot and gain access to the internal network. Our attempts to phish our way into the internal network ended in ruin and the local defenders pulling their hair out in fistfuls. We received callbacks, but all were quickly picked up and eliminated by the blue forces. In each phase we narrow down our targets and hone in our efforts. Fewer and fewer opportunities to move on are present.
Initial Tactical Engagement
Our initial tactical engagement focuses on escalating our privileges on the web application server and dumping credentials on the DNS server. Additionally, we will take a look at the internal network and complete a full scan, honing in on the internal DNS server which we trust has the same flaws as the external server.
Working on the DNS server we already have system privileges. Using any one of a number of password dumping tools (i.e. john the ripper or Cain and Able) we are able to dump the hashes of the local user and administrator accounts. We take these hashes and dump them into john the ripper and start cracking. We immediately come back with a keyboard pattern password to the local administrator account. Here is hoping that all local administrator accounts share the same password across the network (Hint: They generally are).
The web application server is a busy place and we might be able to leverage our access into privileged access based on the configuration of the server. As we explore the server we leverage several privilege escalation search scripts such as sherlock.ps1 and windows exploit suggester we are able to find a local privilege escalation exploit that will net us local administrator. We load up the exploit and fire it off, bingo, we’ve got local administrator. We migrate our meterpreter session to lsass and dump some credentials and get several user accounts and a domain administrator account. The hashes go into john the ripper immediately to decipher the plaintext passwords but the complexity requirements for the passwords could mean this will take some time.
The internal network is our prime target. Scanning commences, and we start leapfrogging with remote desktop into machines to check if the local administrator account yields access to any computers. As we get failed attempt after failed attempt, a thought crosses our mind. This is the local administrator account from an ancient time long forgotten. Based on the age of the server we got it from several equipment refreshes should have gone by. With that in mind, we narrow our search to older operating systems on the network. A few minutes later and we have local administrative access to an internal host. From here we implement the same procedures of uploading password dumping tools and dumping credentials, but WAIT! A massive upset occurs and the files we upload are immediately quarantined. A few seconds later we lose access to the host. The host based anti-malware solution has detected our tools and quarantined the host, it can’t be reasoned with, it can’t be bargained with...it doesn’t feel pity or remorse or fear and it absolutely will not stop. Ever.
As we try to figure out what went wrong on the host we see that our connection to the web application server has been disconnected. The team lead and operators are shouting, there are erasers and markers being thrown against the wall, somewhere a baby is crying. There is a chance we might be able to use some of the user credentials we’ve gained to get access again to the web application again, but for now we place all our eggs in domain administrator has we got off the web application server.
At this point we use our last ditch effort to pass the hash of the domain administrator account. We target the domain controller with a meterpreter session. This yields a connection and we use the safe password dump post module to dump passwords instead of the tools that seemed to burn our last connection. With all of the hashes of all the users on the network we target the administrator accounts and add them to our password cracking list. Lucky enough one of the domain administrator accounts yields a password immediately and we are able to freely remote around the network using legitimate credentials. As a bonus, we add our own domain administrator account to the network just in case the admins do a password reset to try to counter us.
Adversary Counter Tactics
Fresh off an 18 hour shift the previous day our blue team comes into work at a delayed time and weary from the previous day cleaning up the phishing mess we left for them. They are pissed off, malnourished, and slightly thankful they didn’t have to see their ungrateful wife or kids yesterday. Today has to be easier, for their sake.
As the day goes by the blue team is monitoring the network and does not see anything out of the ordinary. Thankfully, the rules on the firewall are configured such that our scanning traffic is not flagged from the DMZ to the internal network. However, it is not long before some of the users send in tickets complaining of slow internet (it wouldn’t matter but Gary needs to watch his youtube in 720p and you bet your ass he’s gonna win that fight). These tickets will take some time to get through the system, but eventually a network engineer will begin to investigate why the connection is so slow, escalate the ticket to the web application server sysadmin, and it will then get escalated to incident response. After this mutli-hour process concludes, incident response will clean the web server of our presence, bounce the server to be sure, and monitor for persistence. Lucky for us we already have everything we need from it and our pivot on the DNS server is safe.
Elsewhere, an older host on the network has been quarantined by the host based anti-malware solution the company employs. A notification goes off in the security operations center but is low priority because the host is quarantined and can’t cause much trouble in isolation. A user ticket will eventually press the blue team into doing their job. As they investigate, they see the cause for quarantine was password dumping tools being uploaded by the local administrator account. The box is cleaned and some blue team smart guy has the gall to order that all local administrator passwords are changed to ensure we cannot use this vector again. This is tedious work for the local helpdesk technicians that don’t know how to automate tasks and the resentment against the red team spreads wider.
Everything else we do on the network goes by the wayside as the weary network defenders head home for the day. Managers continually rebuff requests for overtime pay noting that their employees are on salary and are essentially slaves. After a day of taking two solid counter actions against the red team they are happy with their efforts and think they have won the day. Little do they know that we’ve established persistence on the network with our own domain administrator account and we are gaining more credentials as our password cracker chugs on.
The red team begins the debrief with a round of high fives and beers. They own the network and there is naught to do but hunt down critical information and write the report. However, as we sit down to reflect we should have realized that the host based anti-malware program we identified during the reconnaissance phase had file creation scanning and would detect our tool. At a minimum we should have known this would create an alert and could have had the possibility of quarantining the host. We make updates to our operating procedures to stay file-less when possible as we did on the web application server and domain controller. The debrief drags on for an hour as we explore what went wrong on the web application server and why we lost our access. The team is unable to pinpoint what tipped off incident response but many ideas are thrown around. Eventually, they give up and leave it to the end of scenario brief to ask the blue team.
The planning begins for the persistence phase. How are we going to embed ourselves in this network like a blood sucking tick? How are we going to make ourselves impossible to remove? By the end of this assessment the blue team should only be able to remove us by nuking their network from orbit... it’s the only way to be sure.