Better Windows Security Logging Using Sysmon

NOTE: Justin Henderson delivers some INCREDIBLE training on SIEM tactical Analysis through SANS. This article is based on some points I learned during that course.

SIEM Training | SIEM with Tactical Analysis | SANS SEC555

As with any SIEM, when it comes to ingesting networking, system or service logs into Azure Sentinel, you have to do more than simply send a large quantity of logs to Sentinel. Pushing gigabytes, terabytes or even petabytes of data into Sentinel creates two challenges:

  • it creates a lot of potential noise for threat hunters to sift through, and
  • storing all that data in Log Analytics can get very expensive, very quickly.

The key then, is to ingest quality logs – logs that will give you the information you need for threat hunting and that will be useful in identifying indicators of compromise. The question we need to address is – how can we do that effectively? There are several excellent strategies for ingesting useful logs from network devices, Linux systems and cloud services, but in this article, I’m only going to address the challenge of logging “interesting” Windows events and sending them to your SIEM.

You Can’t Log Everything

Okay, let’s get something out of the way right now.

If a vendor tells you that their log collection tool or strategy captures ALL the events in Windows, they are…ummm…”stretching the boundaries of believability”. Here’s why.

A given Windows 10 machine, contrary to many people’s expectations, is not an infinitely scalable resource, with no constraints on its processing power or storage capacity. As a result, there are built-in boundaries set on what it can, or is allowed to do. As one simple example, you can’t connect 100 monitors to your laptop and get them all to work.

Those same types of constraints exist for things like event logging. If you go into your Event Viewer tool in Windows 10 and start expanding all the different types of logs, you’ll see that there are more than your standard “System”, “Security” and “Application” logs. For example, on my laptop, I have literally HUNDREDS of things being logged in addition to the 3 major event logs.

Obviously not all of them are logging the same amount of data, but there’s still a lot of logging going on.

So, if you are trying to pull ALL of those logs from a Windows machine, it would require the machine to open up hundreds of individual channels to accommodate all the logs – and that just isn’t going to happen. You will hit your maximum number of 255 channels, and then Windows will politely tell you to take a flying leap…. or Windows may take its own flying leap for you.

So, if we can’t capture ALL the logs in Windows – and we probably don’t need to anyway – how do we capture the stuff that’s important when it comes to threat hunting?

Enter Sysmon…

Sysmon is a free tool, originally developed by the amazing Mark Russinovich and Thomas Garnier, for the Sysinternals suite. You can download sysmon here:

 What makes Sysmon so valuable for threat hunters is that, in contrast to your standard Windows logging in Event Viewer, Sysmon was specifically designed to log activity that is typically associated with abnormal or threat activity. That includes things like:

  • Process creation and access
  • Tracking of network connections
  • Registry additions or modifications
  • Drivers and DLL loading
  • WMI monitoring
  • Modification of file creation times
  • File hashes

…And lots of other similar data.

What’s cool is that Sysmon also generates its own set of event logs and you can configure exactly what gets captured in those logs! Let’s take a look…

Logging Before Sysmon

In the example below, I’ll show you what gets logged on a machine without Sysmon.

Let’s take an example that is a fairly common vector for compromise – an attacker using remote WMI to launch a process on a victim’s machine.

In the screenshot, I’m attacking the machine named VICTIM1721, and the user account is named VICTIM. (I mean really…with a name like that, he was asking for it.) The basic idea is that I run the command below to launch the calculator executable on the victim’s machine.

And as we see from the calculator executable on the VICTIM1721 machine, I was successful.

How very exciting. I can run calculator on the victim machine. What a coup for my team.

Obviously, launching calculator in a visible manner on the victim’s machine isn’t terribly useful for me as an attacker, but it’s illustrating the point that I could launch ANYTHING I WANT on the victim’s machine using WMI if I’ve got the right access. And if I was an attacker, I wouldn’t be launching calculator, and I definitely wouldn’t be launching anything visibly.

As an example, here I’m using WMI to enumerate the groups on my VICTIM machine. That’s information that is VERY interesting to me as an attacker.

So, the question is, what kind of information is provided by Windows for this type of event?

If we look at the Windows Security event logs on the VICTIM1721 machine, we see event ID’s 4624 and 4688, as you see below. There’s some useful information there, such as the fact that a process was created, the time and date of its creation and the fact that it was initiated by NETWORK SERVICE.

Event ID 4624

Event ID 4688

This is reasonably useful information, but there are two problems:

  • the information is contained in two separate events, and
  • there is other information that could help me identify this as anything more than a harmless process being created.

For example, as an attacker, I might choose to launch my malware as a process named svchost.exe. That would rarely even be noticed on a single machine because there’s usually a dozen or more instances of svchost.exe running on a machine at any given time. It would be hard to pick one of them out as being malicious without having some additional context. Additionally, if I look at the “New Process ID” and “Creator Process ID” lines, I see 0x1fe8 and 0xfa4, which isn’t readily usable.

As an aside, during my testing, my machine was being actively attacked externally, as you can see in this event entry. The attacker at IP address tried a number of usernames and passwords against my VICTIM machine, even though it was only publicly accessible for about 4 minutes.

What a world.

Anyway, moving on….

Sysmon-ify Your Logging!

Now let’s add sysmon to the picture. On my VICTIM machine, I’ve downloaded sysmon and installed it according to the default install parameters. That gives me some decent logging capabilities, but I want to enhance the logging. There are a couple great GitHub projects where people have developed comprehensive sysmon configuration files that you can use to customize your logging.

A couple custom logging configs that I like are:

What’s very useful about these config files is that they were built with the express intent of logging the actions of known threat actors. They accomplish this by aligning the logging capabilities with the MITRE ATT&CK Framework, in that they look for specific TTP’s (Techniques. Tactics and Procedures) identified in that framework. In the screenshot below, we see a logging configuration defined that is intended to identify actions consistent with T1037 and T1484 from the ATT&CK Framework.

In the repository, there are .XML files that you can download and apply to your own machines to enhance the logging on those machines and dump useful events into the sysmon event logs.

Simply download the XML and run this command (if it’s the first time you’re configuring sysmon):

sysmon.exe -accepteula -i sysmonconfig.xml

If you already have a configuration file for sysmon and want to update that file, run this command:

sysmon.exe -c sysmonconfig.xml

As you see below, I updated the sysmon configuration file on my VICTIM1721 machine.

Once sysmon is installed and starts logging actions, you can find the event log by opening Event Viewer and going to:

Applications and Services Logs – -> Microsoft – – >Sysmon

The Operational Log is where you’ll find the relevant logging for sysmon.

Now if we run the same type of remote WMI command against my VICTIM machine, I can go to my sysmon event logging and see what shows up. In this case, I see something like this in the event:

Notice that the information shown in this event is a little easier to sort through.

  • Time is shown in UTC format – always a valuable data point when investigating issues and trying to correlate events across multiple devices.
  • The Process ID and Parent Process ID are in a human-readable format (8168 and 4004). This will make it a little bit easier to identify the process on the affected machine.
  • Information is provided about the file version of calc.exe and associated hash so I can tell if a file has been modified from its original state.

Additionally, it’s all in a very structured format, which means I can create rules in my SIEM to parse data very easily out of the event.

Now, I can start pulling sysmon information from that Operational log into the SIEM and use that for triggering alerts and incidents.

To be clear, the sysmon Operational log isn’t intended to REPLACE specific logs you may be pulling from machines, such as the security logs or system logs. Those logs still have a value and may capture information not found in sysmon entries.

However, because sysmon was designed to help identify and point a flashlight at anomalies and unexpected behaviors, it can help you to be more efficient in your logging, reduce the overall number of log sources you pull off each machine and help your security team more quickly identify issues that impact the security of your network.

Check out sysmon today!

Setting Up a Kali Linux Machine in Azure

A Quick Overview of Kali

One of the tools that many security professionals use on a regular basis is the Kali Linux penetration testing platform. This tool is built and maintained by Offensive Security (, an organization that also provides extensive training on the platform and a variety of other security and penetration testing topics.


The Kali Linux platform is based on Debian GNU/Linux distro and contains hundreds of open source penetration-testing, forensic analysis, and security auditing tools. However, it isn’t exclusively used by traditional “red teams” and “blue teams”. In fact, it can also be used by IT admins to monitor their networks effectively (whether wired or wireless), perform analysis of data, and a variety of other tasks.

It’s important to remember that Kali Linux is NOT a static tool. Rather, you’ll likely have updates to the Kali distro on a daily basis, so make sure you perform updates before use the tool every time. (I’ll show you how in a few minutes)

Kali Linux can run on laptops, desktops or servers. You can download the ISO for Kali from, and create a bootable USB drive if you want to. But what we are doing today is running it on Azure, and this is one of the easiest ways to get started.

Let’s take a look.

Provisioning Kali on Azure

The Kali Linux distro is available without cost on Azure, but it might not be obvious where to find it. If you log in to your Azure subscription and try to provision a Kali box, you simply won’t find it in the list of operating systems or images you can deploy.

What you actually need to do is request it from the Azure Marketplace. To do this, go to . There, you’ll see a page similar to the one shown below. Click on the “Get It Now” button to request the Kali Linux distro.


After you request the Kali Linux machine, you’ll be asked which account you use to sign in when you request apps from the Azure Marketplace. Enter the login ID that you use for your Azure subscription.


Once you request the machine as described above, you’ll be able to provision the Kali box just like you would any other virtual machine or appliance. There are a couple points that should be highlighted in the description provided when you provision the box.

First, the Installation Defaults section tells us that, by default, the only way to log in to your Kali instance is by using SSH over port 22 and using either a set of SSH keys or a user-provided password. This is because the default configuration for the installation does not include a graphical user interface (GUI). The majority of the tools in Kali work just fine without a GUI, so this is the preferred way to use it, but if you are just getting started, you may want the benefit of a GUI while you figure out how the tools work and how Linux itself is set up. I’ll show you how to install the GUI later in this article. For this article, I’ll be using a username/password to log in, but again, SSH keys are more secure and would be preferred in a production environment.

Additionally, we see that it is recommended that you update the packages on your Kali machine after you deploy it. I’ll walk you through how to do that as well.


After you’ve provisioned your Kali Linux machine (using username and password during the initial configuration in the Azure portal), you’ll want to connect to the machine.

To do so, download and install PuTTY, or a similar SSH/telnet tool. PuTTY can be downloaded here:

When PuTTY is installed, it will require you to enter the IP address of your Kali machine in order to connect. You can get the public IP address of the Kali machine from the Azure portal, as shown below.


Next, open your PuTTY client and connect to the IP address and port 22 of your Kali machine.


One thing that’s unusual about the install is that the username and password that you defined for the Kali machine when you provisioned it does NOT have root access to the machine. This means you cant make any updates or modify the install with the set of credentials you are logging in with.

Let’s fix that.

As you can see below, I’m logged in to my machine KALI-001 as the user named KALIADMIN. I now need to set a password for the root (administrator) account.

To do this, I type:

sudo passwd root

Then I define the password I want to use. That’s all there is to it!

Now I can log in as root using the command

su root


Now that I’m logged in with root permissions, I need to update my Kali machine.

To do this, simply type:

apt update && apt dist-upgrade

Type y to confirm the updates. Depending upon how many updates are available, this could take a while. For example, when I ran this command after provisioning my machine, it took about 20 minutes to get all the updates.


At this point, you have logged in over SSH, set a password for the root account and updated the machine. However, you still are doing everything from the command line. You may want to install GUI. Basically, there are three tasks you have to perform to be able to able to manage the Kali instance the same way you’d manage a Windows server:

1. Install a GUI
2. Install RDP
3. Configure networking to allow connection over RDP

Install a GUI

Kali comes by default with the GNOME desktop package, but you need to install it.
To do so, use the command below:

apt-get install -f gdm3

Install RDP

Next, you’ll need to install an RDP package and enable the services using the commands below.

apt-get install xrdp
systemctl enable xrdp
echo xfce4-session >~/.xsession
service xrdp restart

Configure Networking to Allow Connection over RDP

Lastly, you’ll need to configure your Azure Network Security Group (NSG) to allow TCP port 3389 inbound (RDP) to your Kali machine. In the Networking section of your machine’s configuration, configure an inbound port rule for TCP 3389. Again, this is a penetration testing tool, so in a production environment, you would likely lock down the source IP addresses that can connect to this machine, but for this demonstration, we are leaving it at Any/Any.


Now that you have this set up, you should be able to connect to your Kali box using RDP, just as you would connect to a typical Windows machine. The interface for GNOME will look something like this, but it can be customized.


What Can I Do With It?

In the past, Microsoft required you to submit an Azure Service Penetration Testing Notification form to let Microsoft know that it was not an actual attack against a tenant. However, as per the documentation noted here,, this is no longer a requirement.

“As of June 15, 2017, Microsoft no longer requires pre-approval to conduct penetration tests against Azure resources. Customers who wish to formally document upcoming penetration testing engagements against Microsoft Azure are encouraged to fill out the Azure Service Penetration Testing Notification form. This process is only related to Microsoft Azure, and not applicable to any other Microsoft Cloud Service.”

In other words, there is no strict requirement to notify Microsoft when you perform a penetration test against your Azure resources. This means that you can perform many of the standard penetration tests against your Azure tenant, such as :

  • Tests on your endpoints to uncover the Open Web Application Security Project (OWASP) top 10 vulnerabilities
  • Fuzz testing of your endpoints
  • Port scanning of your endpoints

However, one type of test that you can’t perform is any kind of Denial of Service (DoS) attack. This includes initiating a DoS attack itself, or performing related tests that might determine, demonstrate or simulate any type of DoS attack.

Thanks, Captain Obvious……

It should be obvious, but just to be clear: DON’T use your Kali machine to attack anybody else’s stuff.

You would most definitely find yourself in a legal pickle if you decided to attack resources that didn’t belong to you (or one of your customers) without explicit permission in writing. Please, just don’t run the risk.

Practice using the 600+ tools available in the Kali Linux distro and learn how to better secure your environment!