Thursday, November 18, 2021

MITRE ATT&CK technique coverage with Sysmon for Linux

 Thanks to Kevin Sheldrake, Roberto Rodriguez, Jessen Kurien and Ofer Shezaf for making this blog possible.


For many years, people have been using Sysmon on their Windows systems to gain clarity on what is happening on their machines and, for the security community, to highlight when suspicious or malicious activity occurs. Collecting events from individual hosts is crucial to ensuring you have the visibility needed to identify and respond to malicious events and Sysmon provides a way to do just that. With the introduction of Sysmon for Linux, that same clarity is available for many Linux distros.  While we won’t be detailing all the available Sysmon for Linux capabilities in this post, you can find the Sysmon documentation here, read about how to deploy Sysmon in conjunction with Azure Sentinel, look at a quick guide on how you can use Sysmon in conjunction with Azure Sentinel, or look through our GitHub repository where we’ve been experimenting with Sysmon configs for Linux.


To frame the conversation around how Sysmon for Linux (shortened to Sysmon from here on out) can be used to create clarity for security teams, we will walk through how Sysmon events can be used to spot a specific MITRE ATT&CK technique. The MITRE ATT&CK Matrix (Linux focused version here) is a well-known and respected framework that many organizations use to think about adversary techniques and assess detection coverage. Just like on the Windows side, Sysmon can be used to highlight tactics and techniques across the matrix. In this blog, we will focus in on the Ingress Tool Transfer technique (ID T1105) and highlight a couple of the Sysmon events that can be used to see it. We observe this technique being used against Linux systems and sensor networks regularly, and while we have tools to alert on this activity, it is still a good idea to ensure you have visibility into the host so you can investigate attacks. To look at this technique, we will show how to enable collection of three useful events, what those events look like when they fire, and how they can help you understand what happened. Additionally, we will show what those events look like in Azure Sentinel.


Ingress Tool Transfer (T1105)

It is common to see attackers taking advantage of initial access to a machine by downloading a script or piece of malware. While “living off the land” is still something to watch for, in attacks on our customers and against our sensor network we see attempts to download tools very frequently.  In fact, the MITRE ATT&CK page for Ingress Tool Transfer shows 290 different pieces of malware and activity groups that use this technique, so it is a good place to start showing how Sysmon can help add coverage to different ATT&CK techniques.


For this example, we will focus on the five most commonly used tools for downloading scripts and malware that we’ve seen run on our sensor networks. We will look for wget, curl, ftpget, tftp, and lwp-download. You may want to customize this list for your environment, but this will cover the majority of what we see.


Create your Sysmon configuration file

Just like Sysmon for Windows, you will want to create configuration files based on the system you are wanting to collect logs for based on the role of the system, your environment, and your collection requirements. The basics of how to write and run a configuration can be found on the Sysmon documentation page and you can see some examples in the MSTIC-Sysmon repo so we'll just focus on what we need for this specific technique. One thing to note is that the Event IDs are consistent between Windows and Linux so Event ID 1 represents process creation events in both environments.


We are interested in seeing when an attacker tries to download files to our computer. There are a few ways we can see that behavior reflected. To begin, we know that a process will have to get created to start the download. We also know that a network connection will have to be made and, if the attacker is successful, a file will be written. Lucky for us, Sysmon has us covered for all three of these with ProcessCreate, NetworkConnect, and FileCreate events.


Below is a basic configuration that we can use to create those events based on our list of the commonly used tools (it is available in our repo here). You can see we have separate sections for each of the events we want and have said we want to include the listed matches.  The tool name will be in the “Image” field, and we’ve used “end with” because we generally expect to see file paths there (ex. /bin/wget).


<!-- Created: 10/15/2021 Modified: 10/17/2021 Technique: Ingress Tool Transfer References: - --> <Sysmon schemaversion="4.81"> <EventFiltering> <RuleGroup name="" groupRelation="or"> <ProcessCreate onmatch="include"> <Rule name="TechniqueID=T1105,TechniqueName=Ingress Tool Transfer" groupRelation="or"> <Image condition="end with">wget</Image> <Image condition="end with">curl</Image> <Image condition="end with">ftpget</Image> <Image condition="end with">tftp</Image> <Image condition="end with">lwp-download</Image> </Rule> </ProcessCreate> </RuleGroup> <RuleGroup name="" groupRelation="or"> <NetworkConnect onmatch="include"> <Rule name="TechniqueID=T1105,TechniqueName=Ingress Tool Transfer" groupRelation="or"> <Image condition="end with">wget</Image> <Image condition="end with">curl</Image> <Image condition="end with">ftpget</Image> <Image condition="end with">tftp</Image> <Image condition="end with">lwp-download</Image> </Rule> </NetworkConnect> </RuleGroup> <RuleGroup name="" groupRelation="or"> <FileCreate onmatch="include"> <Rule name="TechniqueID=T1105,TechniqueName=Ingress Tool Transfer" groupRelation="or"> <Image condition="end with">wget</Image> <Image condition="end with">curl</Image> <Image condition="end with">ftpget</Image> <Image condition="end with">tftp</Image> <Image condition="end with">lwp-download</Image> </Rule> </FileCreate> </RuleGroup> </EventFiltering> </Sysmon>


One thing to note is that both ProcessCreate and ProcessTerminate are enabled by default.  If you don't want to collect one of those, you'll need an empty "include" statement. Once you have your configuration created and enabled, you’ll start seeing events.


Raw Sysmon events

The Sysmon logs can be found in /var/log/syslog. While you could just look at the raw events there, we have the SysmonLogView tool which can make it easier. This tool will take the Sysmon events and display them in the more human readable format that you can see below. You can use the below command to push new events from syslog into the sysmonLogView using the following command:


sudo tail -f /var/log/syslog | sudo /opt/sysmon/sysmonLogView


This gives us a running view of what events are being created. We can then run the below command to trigger the rules.

wget -O

This command will use wget to call out to a server at port 7000, download the script, and save it as the script is an internal testing script that I used for this demo.


ProcessCreate (Event ID 1):

You can see we get quite a lot of information from the ProcessCreate event. We can see wget in the Image field, the full Command Line, the Current Directory, and the user. You also get Parent Process information although it isn’t as interesting in this example.


Event SYSMONEVENT_CREATE_PROCESS RuleName: - UtcTime: 2021-09-28 21:53:22.533 ProcessGuid: {23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image: /usr/bin/wget FileVersion: - Description: - Product: - Company: - OriginalFileName: - CommandLine: wget -O CurrentDirectory: /home/testUser User: testUser LogonGuid: {23b1b3a6-0000-0000-e903-000000000000} LogonId: 1001 TerminalSessionId: 38 IntegrityLevel: no level Hashes: - ParentProcessGuid: {23b1b3a6-8ed2-6153-0824-7cafd1550000} ParentProcessId: 13408 ParentImage: /bin/bash ParentCommandLine: bash


NetworkConnect (Event ID 3):

In the NetworkConnect event, we again see wget in the Image field and the user. We also see the protocol, source and destination IP addresses, and the ports involved. Our example command line has the IP listed already so it isn’t new information, but it could be useful in tying the different logs together. You’ll notice the Process IDs also match up as expected.


Event SYSMONEVENT_NETWORK_CONNECT RuleName: - UtcTime: 2021-09-28 21:53:22.543 ProcessGuid: {23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image: /usr/bin/wget User: testUser Protocol: tcp Initiated: true SourceIsIpv6: false SourceIp: SourceHostname: - SourcePort: 40680 SourcePortName: - DestinationIsIpv6: false DestinationIp: DestinationHostname: - DestinationPort: 7000 DestinationPortName: -


FileCreate (Event ID 11):

Here we can again see the wget tool and the process Id. We also have the name of the file that was created and its file path.


Event SYSMONEVENT_FILE_CREATE RuleName: - UtcTime: 2021-09-28 21:53:22.536 ProcessGuid: {23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image: /usr/bin/wget TargetFilename: /home/testUser/ CreationUtcTime: 2021-09-28 21:53:22.536


Viewing in Azure Sentinel

Sysmon events are pushed to Syslog so if you are collecting Syslog events from your Linux machine into Azure Sentinel, you will get the Sysmon events.  For more details on how to make that connection, check out the documentation here.  Also, as the Sysmon events come through with most of the data in the Syslog Message field, you’ll need to parse out the fields you are interested in.  Fortunately, the Azure Sentinel Information Model parsers have you covered. You can install the Parsers from the link here. Once you do, you’ll have access to functions that have taken the guesswork out of parsing.


The parsing functions are available under Functions-> Workspace functions. In the below, you can see the Linux Sysmon functions we currently have.



Using the function vimProcessCreateLinuxSysmon, we can see our event reflected. We have narrowed the query to just the event in the example above and chosen to project only a couple of the columns of data.


From here you can start to include Sysmon as a data source for your hunting queries and analytics.


Sysmon for Linux and MITRE ATT&CK

While we didn’t dig into all the possible Sysmon events or ATT&CK techniques, hopefully you can see how you can use Sysmon to collect data that will highlight adversary techniques. Sysmon

is open source and available in the Sysinternals GitHub.  If you have requests or find bugs, check out the Sysmon for Linux project page for the best ways to contact the team. MSTIC has been working with different configs and have started a repo here to share with the community. If you want to see other configs based on MITRE ATT&CK techniques, check them out here and feel free to add suggestions of your own. If you want a config that has all the techniques we've mapped so far, you can find it here. We will continue to come up with new ways to utilize the logs in Azure Sentinel and we look forward to seeing what the community develops. If the amazing work around the Windows version is any indication, we expect that the future of Linux logging is bright.



Original  Post here