Tag: SIEM

Better Windows Security Logging Using Sysmon

Published on by Dave BranscomeLeave a comment

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:

https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

 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 103.119.92.112 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:

https://github.com/SwiftOnSecurity/sysmon-config

https://github.com/olafhartong/sysmon-modular

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.

https://attack.mitre.org/techniques/T1037/002/

https://attack.mitre.org/techniques/T1484/

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!

Using DeTTECT and the MITRE ATT&CK Framework to Assess Your Security Posture

Published on by Dave BranscomeLeave a comment

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

– – – – – – – – – – – – – – – – – –

One of the things I’ve become very interested in lately is the MITRE ATT&CK Framework, which can be found at https://attack.mitre.org. The great thing about this tool is that it provides a real world, standardized method for understanding how adversaries attack specific platform types, including the tactics and techniques they typically leverage, the methods used by specific threat groups and so on.

This is valuable information for understanding the threat landscape and for understanding the way that attackers think. ATT&CK also gives you information about the data sources where you would typically need to look for indicators of compromise related to the types of attacks being carried out. For example, in the screenshot below, you can see that the indicators of compromise (IoC’s) for the “Phishing for Information” technique might be found in logs on your email gateway, your network intrusion detection system, or a packet capture (among other data sources).

This is really good information for understanding what data sources might be useful to look through during an incident, but it leaves one important question unanswered for SOC analysts: am I pulling the right logs into my SIEM (such as Azure Sentinel) in order to detect an adversary that is using a specific tactic?

Using DeTTECT

This is where a tool like DeTTECT, in conjunction with ATT&CK, comes into play.

DeTTECT is an open-source tool, located on GitHub (https://github.com/rabobank-cdc/DeTTECT). Its intent is to help SOC teams compare the quality of their data logging sources to the MITRE ATT&CK matrices in such a way that they can easily see if they have the proper logging coverage to allow them to detect adversaries, based upon the tactics they may be using. What makes DeTTECT so valuable is that it does this in a way that is easily understandable since it is very visual. This can help you understand where you can shore up your organization’s logging for specific types of threats that you may be facing. For example, in the screenshot above, maybe you’re logging traffic on your web proxy, but you aren’t capturing any logging on your email gateway. You could be missing a very valuable source of intelligence in your threat detection by not ingesting those logs into Azure Sentinel. DeTTECT can help you analyze your logging and find those weaknesses. Let’s see how.

The DeTTECT framework uses a Python tool, YAML administration files, the DeTTECT editor and several scoring tables to help you score your environment. The following steps were performed on a Ubuntu VM with the DeTTECT image running inside a Docker container. The instructions for setting up a container running DeTTECT are listed here:

https://github.com/rabobank-cdc/DeTTECT/wiki/Installation-and-requirements

As you see in the following screenshot, I’ve started up the DeTTECT Editor running in the container.

As the last line shows, I can now open the DeTTECT Editor in a URL and begin interacting with the editor. After I bring up the web page, my first step is to add Data Sources. This allows me to define for DeTTECT the logs I am capturing and ingesting into Azure Sentinel so that I can qualitatively measure the visibility I have across my logging sources.

Click on “New File”.

In this case, I want to tell DeTTECT how I’m capturing logs for Windows endpoints, so I click on “Add data source”.

Next, I define the data source as Windows event logs. Notice that the tool provides options for you to choose from as you type. For example, you could select AWS CloudTrail logs, Azure activity logs, Office 365 audit logs and numerous other sources. These options correspond to the logging sources referenced in the MITRE ATT&CK matrices, as we saw earlier.

I add the date the data source was registered and connected, define whether it is available for data analytics and whether it’s been enabled.

Know Thy Data!

Now comes the part where you must know your data. In the next section, I am defining the quality of the data that I’m getting from my Windows event logging configuration. For example, maybe I’m only capturing Windows System logs (reducing my overall visibility). In my example, I’m going to assume that I’m regularly logging data using Sysmon on all my devices, and I ingest it into Azure Sentinel on a regular basis. This gives me great visibility due to the completeness of the data that Sysmon can generate (that’s going to be another blog). I move the bars accordingly.

I go through the same process for all of my data sources, and I end up with something like what you see below.

In a production environment, the list would (hopefully) be much longer, assuming you have more than just a couple logging sources. Note that the quality and coverage of the logging is going to vary according to the system or tool you are evaluating. You may get lots of detailed information from one type of networking device, while another gives fairly limited logging information. Make sure that you reflect that difference in the data sources you add.

Once you’ve added all the data sources for your environment, click on “Save YAML file”.

File Conversion

The next step involves converting the YAML file into JSON, so it can be used in the ATT&CK Navigator tool. Back in the terminal window on my Ubuntu VM, I convert the YAML file into JSON.

The result is shown below:

Layering DeTTECT Data over the ATT&CK Matrix  

Now comes the fun part – seeing how your organization’s data logging sources match up to the ATT&CK Framework. This will give you a visual indicator of how much coverage and visibility you potentially have into different techniques and tactics used by adversaries.

We will be layering our data_sources_example_1.json file (created in the previous section) on top of the MITRE ATT&CK Navigator. First, let’s browse to the MITRE ATT&CK Navigator, located here: https://mitre-attack.github.io/attack-navigator/

I click on Open Existing Layer – – > Upload from Local, and then I browse to the location where I’ve stored my data_sources_example_1.json file.

And *whammo! * – look at the visualization I get!

What Does This Tell Me?

So how do I use this? Think of this as a heat map for logging coverage. The darkest purple boxes reflect the attack techniques that your organization would have the greatest visibility into, based on the quality of the logs you’re ingesting into Sentinel. The lighter the box, the less visibility your organization would have into an attacker using that technique, based on the current logging strategy.

This can be a great way to illustrate to management where you have gaps in your security logging, as it is very easy to understand the color-coding.

More importantly, perhaps, it gives you a starting point for developing a strategy for improving logging capabilities in your organization. As an example, I could look at this and immediately see that my fictional Contoso organization may have a significant amount of exposure, based on the fact that Initial Access – – > Supply Chain Compromise has no logging coverage at all.  

Therefore, I may want to increase my logging in that area of the environment. On the other hand, maybe that’s not an area where Contoso feels they have much of a vulnerability (although I think recent security events should lead Contoso to rethink that position!).

In reality, we are always going to have parts of our environment where the logging is healthy and robust, and we will also have areas where the logging isn’t quite what we would like it to be.

By using a tool like DeTTECT in conjunction with the ATT&CK Navigator, you can begin to prioritize where to increase your logging and continue to improve the security of your organization.