There are plenty of articles and cheat sheets advising defenders how to monitor, hunt and detect the adversary in their environment. But sometimes, it feels like there are fewer posts advising us what to do once we catch the adversary.

We’ve all been there during an incident: you’ve caught the adversary red-handed, in the middle of their campaign and before they have caused serious damage. Now, you’re tasked with denying the adversary any further opportunities. It’s the defender’s turn to cause the attacker some pain!

Googling “how to kick out an attacker from my active directory” or “how to kill hacker shell from Windows computer” doesn’t really offer us much advice. And the real kicker is this is the type of advice we defenders could all benefit from.

In this blog, I’ll sketch out a number of things that’ll help the next time you catch an attacker. We’ll look at…

• What the attack looks like from the perspectives of the defender and the attacker
• How to dig deeper and find data that illuminates the adversaries’ activities 
• Some commands that will allow you to evict the adversary

Scenario

Note: None of the usernames or screenshots in this article come from our partners or clients! All fictional details, but real security techniques. 

Picture it: It’s 2am. You get an alert that three users are up to something suspicious on a key server. You jump on the machine and begin to dig into exactly what’s going on here. 

You know the users: AFairfax, BMason and ERochester. They have medium privileges in your Active Directory, but they definitely wouldn’t be working at 2am! You can dig further with some PowerShell to find out what they are currently doing on this server:

This PowerShell one-liner gives us insight into the process being run in the first column, the user account associated with the process in the middle column as well as the underlying executable and commands that initiated the process to begin with in the final column.

Some of these processes don’t look particularly malicious, as they are legitimate programs (like rdpclip and wsmprovhost.exe), whereas other processes look really bad (sharphound.exe has a strange re-directed relationship with a local SMB share). 

You could just kill the individual processes, but that would not evict the adversary from your environment. This would be a mild inconvenience to the adversary, since they likely have compromised credentials and gained remote access to the machine, allowing them to just remote in and restart the process you just killed. Moreover, this would let them know the defenders are on to them (more at the end on why this is problematic).

So what should you do?

Well, let’s eject these three puppeted accounts from your Active Directory—and stop the adversary from leveraging them permanently. 

PowerShell Remoting (WinRM)

Monitoring

We’ll tackle the user AFairfax first. In our first examination, AFairfax’s only running process on the server was wsmprovhost.exe. If we take a look at our Elastic instance, which collects our logs, we see that it has detected that wsmprovhost has spawned a ‘whoami’.

Wsmprovhost is an executable that supports PowerShell remoting and Windows Remote Management. It is a legitimate, built-in functionality that allows a user to securely sign in to other machines and run commands (think of it as an alternative to SSH if you want). But for our scenario, this is definitely bad. We know the user AFairfax is in bed snoozing away, so someone malicious has hijacked their account. 

From the adversary’s point of view, they can leverage WinRM to access our server from their attacking machine by providing the user's credentials.

Digging Deeper

The adversary signed in and ran whoami. Because we had monitoring in place, we caught this malarkey easily!

However, if your logging solution has yet to be rolled out, or you need to verify server-side, I have an awesome bit of PowerShell code for you.

‍

At the red arrow, we’re told that the shell is still connected and alive. The pink arrow lets us know that AFairfax is the user currently remoting, and the ShellRunTime by the blue arrow lets us know AFairfax has been using WinRM for the last 26 minutes!

Ejecting AFairfax's PowerShell Remote Shell

Enough of this. Let's kick the attacker out! To eject a mid-session PowerShell remote shell, we can disable that user account from the Active Directory altogether.

From the adversary’s perspective, they will be unauthorized from the remote session partway through. Moreover, when they try to re-authenticate, they will be disappointed to know we have entirely disabled the account.

Impacket's WMIexec

Earlier, we noted processes belonging to the user ERochester had strange underlying commands. These commands, such as redirecting output into a localhost share, are indicative of Impacket’s toolkit—specifically WMIexec in our case. WMIexec leverages Windows Management Instrumentation to have a powerful and quiet impact on a victim machine.

Monitoring

Whilst Impacket is a stealthy toolkit, a mature logging solution will catch enough relics of activity to warrant a defender’s suspicion. 

In the pink box, we see the process that executes ERochester’s `net time`, and in the green box, we see the beginnings of the process that executes ‘whoami’. This is what Impacket’s WMIexec looks like on the receiving side. Notice the redirection into ADMIN$—a telltale sign. 

For the attacker to execute commands on our server, it’s a relatively simple one-liner that again relies on having credentials for the target user. 

As an extra special spoiler, here’s a small peek at how the Huntress ThreatOps team would see this same process activity, whilst the threat actor masquerades as ERochester.

Digging (Even) Deeper

If you do not have a logging solution, I can assure you all is not lost. If you need to sift through more data to determine malicious activity of Impacket or other tools, I have written elsewhere about how to leverage digital forensics and incident response techniques in a log-less investigation. 

One place we can quickly look is in the prefetch directory—available on Windows endpoints and not servers. 

‍

Ejecting ERochester's Impacket-WMIexec

Well, we’ve all seen enough of the data to conclude that this is malicious activity. Let’s sort it out. 

First, we twice rotate ERochester’s compromised password. 

This is not the ultimate solution. Password caching may present a complication that benefits the adversary. Rotating the password twice can ensure we don’t gift the adversary persistent access with the old password or hash that is still usable for authentication.

To be safe, we could and should disable the account altogether for now, like we did for the AFairfax account. 

As an additional final layer of eviction, we can also kick ERochester out of the administrators group, denying the adversary the privileges they previously required to run Impacket effectively. 

From the adversary’s perspective, they go from being able to run commands (in the green box) to losing their shell and no longer being able to re-authenticate again as ERochester (red box).

Remote Desktop Protocol (RDP)

If you cast your mind back to our first evaluation of the server’s processes, BMason was associated with a simple ‘rdpclip’. However, given we know that the real BMason is asleep at 2am, we know to investigate this further to deduce what the adversary has done.

Monitoring

RDP is a legitimate service like WinRM that can be leveraged by adversaries. As it is a legitimate, built-in functionality, its usage may not trigger an alert if you do not set up specific tripwires. Moreover, many RDP detections rely on port 3389, despite the fact it can be changed from this default port. 

From the defender’s perspective, we can see Elastic has captured all the relics of an RDP session spawned by BMason. But notice the ‘source.domain’ column, which betrays that the BMason user is interacting from the ‘kali’ machine. But in real life, you may not have an attacker’s machine so obviously named. This kind of telemetry can be useful in helping you determine if the RDP session you are watching is malicious or legitimate.

From the adversary’s perspective, it’s a relatively simple one line to leverage BMason’s stolen credentials to gain an RDP session into our server! 😱

Digging (Even) Deeper

But perhaps you did not have your SIEM set up, and your logs are just sitting there on the server, unparsed and unloved!

Don’t worry—I’ve got a cool one-liner for you. It will query the RDP log and ask for the times that a user remoted into the server and will snitch on their username and source IP address. 

Ejecting BMason's RDP

Now we have accurately determined that BMason’s account is being abused by the adversary to RDP in, let’s evict them! This is one of the easier methods of ejection:

BMason is forced to sign out, and we have terminated the RDP GUI that the adversary was previously enjoying. Now, we can repeat the password change/account disabling for BMason that we did for previous users.

Is the Adversary Anywhere Else?

Perhaps the adversary has other accounts they have compromised. Maybe they are signed in elsewhere across your Active Directory domain.

To dig deeper into this, I’d recommend YossiSassi's Get-UserSession.ps1 and Get-RemotePSSession.ps1. 

These will show which user accounts are currently signed in, and which machines they are signed in to, across your whole domain. This will generate a LOT of data in a real-world Active Directory though.

Alerting the Adversary

Incidents have an interesting relationship with time. When the adversary is discovered, defenders must simultaneously retread what happened in the past via logs and artifacts, work at break-neck speed in the present to deny the adversary and then deliver upgraded defenses in the immediate future. In other words, we defenders are being pulled in many directions.

If you follow the guidance in this article, you’ll evict the adversary with ease. But before you fly out and ruin the attackers’ day, consider that the minute you start to engage and interrupt their campaign, you are tipping off the adversary; they now know that you know. A pressured, rushed adversary may prioritize covering their tracks (making it difficult to identify their initial access methods) or execute something devastating as a final farewell (ransomware on the machines they do still have access to).

Prioritize your time by following these steps:

• Someone on the defender’s team needs to pour through the logs. They need to find the method of initial access, and then identify and undo any persistence mechanisms the attacker gifted themselves. 
• A present-focused defender can battle the attacker, but it’s better to do this once you have a confident understanding of the adversary’s initial access and persistence. Of course, if you see the adversary make it to key machines or start devastating activities, intervene. 
• Post-incident IT and security teams need to work together to immediately enact the tech and cultural changes necessary to prevent similar re-compromise. 

And that’s it! 

We looked at the tools adversaries can leverage to pivot across an environment, we focused on what these tools look like on impact, and then—most importantly—we had a granular conversation about the defensive commands and techniques to evict the adversary from your network. 

Check out the Blue Team Notes for some more cool commands for defenders. Drop me a line on Twitter if you recognized the classic literature referenced throughout this article.

Want to explore how managed detection and response can help you find and evict hackers? Download our eBook below.