in Powershell, RedTeam

Offensive Event Parsing – Bringing Home Trophies

Once Upon a time…

…Deep, Deep in the wild jungle of domain trusts, the illustrious user hides among the clutter and noise of a Windows network. Success Audit here, Failure Audit there. The hunter, who has already compromised the domain, wonders how they can track their prey and if they will bring home the trophy for their wall. The hunter fires up Veil-Powerview and queries all the things, but as luck would have it, the evasive user eludes detection. Where oh where could this user be?!

But Seriously… I recently found myself wondering how I would go about searching for a very specific user on a very large network. The challenge presented itself like the classic needle in a hay stack… thousands of systems spread internationally with my fixation on only a couple of those users.

Why do this?

To justify my craze, it is important to note that there are legitimate reasons for this:

  • Fulfilling a specific objective provided by a customer
  • Gaining access to certain sensitive network resources you know only a specific user can access
  • Targeting incident response or SOC ranges by targeting their personnel – Counter Network Defense
  • Targeting executives, engineers, or whatever group of users you are interested in

The list could go on to fill many pages if you polled the average Red Teamer. In my case, I knew of a specific functional team that would provide a wealth of information and awareness. In my mind, they were a critical target and so I spent the time going through all of the different methods to hunt down users.

User Hunting


Hackers and Red Teamers have always had to go hunting for the high value user and there are many solutions on the market. @harmj0y and @davidpmcguire talked about it in their Derbycon talk (slides). This will rehash a bunch of what they talked about but I find it important to identify what things I tried before moving on. Quick review:

Old School – Utilize net commands and network enumeration to locate a file server on the network. Run “net sessions” to get all user sessions on the file share and hopefully the target user has the share mounted.

New school – Utilize netview.exe written by @mubix to query domain and session information in a slightly automated fashion. This feature has the benefit of utilizing API calls instead of the standard windows net commands. Check out his github for more info.

Newish school – Give into your inner POSH junkie and import the latest module of Veil-Powerview. Written by @harmjoy and inspired by many people, this implements and extends the functionality originally written into netview.exe. Hunting for the illustrious user can truely be as simple as “Invoke-UserHunter”. For more info on this… visit here.

These three techniques utilize a similar back end method of finding users. I also discovered during some recent work that email can be a very useful method for locating users:

Oddball solution – Email headers FTW! It turns out that users tend to be quite chatty on corporate email. In my recent case, it was as simple as compromising credentials with mimikatz, logging into the enterprise web interface for email and spending some time digging through a random user’s inbox looking for email chains to/from the target user. Once found, I could search the email headers for my information of interest. For those who don’t know, an email header sometimes contains an entry labeled “X-Originating-IP” which represents the network address of client who originally sent the email. There are tons of resources out there on email headers.

Event Logs for You AND Me

So obviously I wouldn’t be writing this if it was truly that easy. The above tricks did not work for the specific user I was looking for. Fun fact: Organizations sometimes use Linux servers with Samba for user home directories. In this situation where the only share the user has mounted is a Samba server, a ton of the typical tricks do not work. When I came to the realization that I would have to look elsewhere, I thought about traditional admin or forensic techniques and how they could be applied offensively.

Event logs can be an extremely useful tool and a jackpot of information for network administrators, investigators, incident responders, users and even hackers. For a Windows domain, the domain controller will log many of the actions of clients joined to the domain. Specifically for the situation I encountered, the Security log is the location for event auditing of Kerberos authentication, account management, process privileges, and many more things. Most importantly, the Security log is the place that will store account logon events for domain users. Knowing this bit of information and reading this blog post, I got inspired to go hunting through the event logs for my target organization.

The Event ID for an account logon event on a Windows 2008 Server is 4624. All of the other interesting information for Security Events exists inside a generic “Message” field. This field is simply an ASCII blob. Reading through references, I broke out the various fields involved with the logon event and message that I would want:

  • Logon Type
    • 2 – Interactive Logon
    • 3 – Network Logon (File Shares)
  • Account Name
  • Source Network Address
  • Time/Date of Event

Armed with my basic requirements, I could fire up Event Viewer and connect to the domain controller to start hunting… or not. What if I was pivoting through 3 or 4 different hosts? It was time to wield a weapon of choice in Windows domains, Powershell!


Powershell provides a fairly simple capability to interface with the Windows event logs. There are actually two different Cmdlets to accomplish what is needed: ‘Get-EventLog’ and ‘Get-WinEvent’. Check this out for more information regarding the differences between the two. Basically, Get-WinEvent allows you to provide a filter that will actually process on the remote host being queried. This results in a drastically quicker transaction since it does not have to pull down the entire event log to perform processing. Based on this article, I was able to throw together a quick Cmdlet to dump all Logon Events from the Domain Controller after a certain time.

Get-WinEvent -ComputerName $CompName -FilterHashTable @{ LogName = "Security"; ID=4624; StartTime=$DateStart}

Powershell purists would probably prefer I stop here and let the user handle the returned objects. Instead, I continued to filter and parse useful information from the massive description. Since I was in a little bit of a time crunch, I utilized a little trick from a friend to perform regex matching and splitting on the resulting “Message” field. With the matches, I could then split the lines and isolate the resulting data field that I wanted to store. Below is an example of how this was done.

if($e.message -match '(?s)(?<=Logon Type:).*?(?=New Logon:)') {
    foreach($match in $Matches){

After using this technique to parse all required information, I could simply verify some of the fields and return the events in the form of an array to the user.

#only add if there was account information
if ($account -ne "")
	$out = New-Object psobject 
	$out | Add-Member NoteProperty 'Username' $account
	$out | Add-Member NoteProperty 'Address' $addr 
	$out | Add-Member NoteProperty 'Time' $etime

Putting this all together in a script allowed me to import it on my remote pivot points and quickly parse events looking for my specific user. Nothing in this script is revolutionary or ground breaking. There are also some downsides to this technique:

  • Requires elevated access to query event logs
  • Have to find the Domain Controller handling logon events for your users (easy in small networks)
  • Tested only on Windows 2008. The event logs have changed slightly across versions

If you think it would be useful,  go get the complete script here! I have started a new repository for random Powershell scripts that I develop.


If you have any other user hunting techniques or have questions about the ones mentioned, please feel free to comment or email! Happy Hacking!

Write a Comment