Improving Your Simple Windows Domain for Offensive Testing: Sysmon

by Justin Palk

A couple of years ago, I put together a series on standing up a simple Windows AD domain in a lab environment. This article is part of a new series on adding additional capabilities to make the lab an even more useful environment for practicing tradecraft.

EDR isn’t the only detective tool defenders have on their endpoints. Sysmon is one of the tools in Microsoft’s SysInternals Suite, consisting of a service and a device driver that logs information on process creation, network connections, disk access and DLL and driver loading, among other data. Running Sysmon on one (or more) of your systems can help you get a better idea as to what defenders are seeing and alerting on when you’re executing attacks.

To get the most out of Sysmon, we’ll need to also get a configuration file. Several years ago SwiftOnSecurity wrote a good one, which you can get here. SOS’s config file is monolithic. If you’d like something more modular, Olaf Hartong has you covered here. My lab environment is fairly small, and doesn’t have a ton of services, so I’m going to use SwiftOnSecurity’s config. I’d encourage you to look through the config file to try and understand what it actually captures.

You can review Sysmon events in the built-in Windows Event Viewer, but since I recently added Elastic to my lab, I’m going to install it on rsl-wks-2, which has an Elastic Agent so I can ingest those logs into Elastic and view them in Kibana. I described setting up Elastic Defend and the supporting infrastructure in this blog post, in case you want to check that out.

Once you’ve got Sysmon downloaded and the archive unpacked, download the Sysmon config file from Github, put it in the Sysmon directory, then open an admin shell and run the following command to install Sysmon and apply the config file:

.\Sysmon64.exe -i <path to config file> -accepteula

The following screenshot shows me installing Sysmon on rsl-wks-2.rslabs.lan.

 

 

With Sysmon installed, open up Windows Event Viewer as an administrator, and navigate to Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.

Here is where we will find Sysmon events. The screenshot below shows a sample of the process creation event generated when I executed ping www.arstechnica.com. If you look at the line above the one highlighted in blue, you’ll see the DSN query event generated when the host had to look up the IP address for www.arstechnica.com.

Reviewing events in the Event Viewer is OK, but we can do better. As I said above, I chose to install Sysmon on rsl-wks-2, which already has an Elastic Agent on it. Elastic has a Windows integration that allows it to ingest regular Windows log data, including ETW sources, PowerShell and Sysmon (it will also ingest Windows Defender data, if you want to put an Elastic Agent on a host that is running Windows Defender rather than Elastic Defend).

 

In your browser, go into Kibana, and search for Windows in the main search bar, then click on the Windows integration when it comes up.

 

On the Windows integration page, hit the Add Windows button. On the configuration page give the integration a unique name and description if you want, then scroll down under Collect events from the following Windows event log channels: and make sure Sysmon Operational is active.

 

At the bottom, choose which policy to add the integration to. I’m going to chose to apply this policy to existing agents using the Elastic Defend Agents policy. Set your policy then choose Save and continue.

 

Now, after waiting a minute or two for things to propagate, if we go to the sidebar and select Discover, we’ll have access to the Sysmon logs for the host you’ve got Elastic Agent and Sysmon running on. To look specifically at Sysmon logs, filter the logs by where data_stream.dataset is windows.sysmon_operational, as shown below.

 

Now, if I filter on events with a file.name field of *exe, I’ll get a list of all events tied to .EXE files. You can also search for fields in the sidebar and add them as columns to the results, as shown below.

Now, when practicing techniques in our lab, or using it to test our payloads and tooling, we can get a better sense of what defenders are actually (or potentially) seeing in their logs.

---

About Justin Palk, Senior Security Consultant:

Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.

Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA