Registry Run Key Persistence - Defender Edition

2024-06-04 1689 words 8 minutes

Contents

Note: If you need to zoom in, you can click on the image.

Warning

Everything shown here is carried out in a virtualized environment that is hosted on my local machine.

Attacker Mindset

As an defender, we have to think from attacker point of view what they’re going to do. Form a hypothesis and find any clues that support these hypothesis. There has to be series of steps that the attacker have to achieve before they can “encrypt” or “exfiltration” sensitive data.

Think of it like eating your favorite food. You need to cook or make your favorite food before you can eat it. It doesn’t suddenly appear.

One useful framework that we can use to tell the story of what the attacker did is using the “Cyber Kill Chain” by Lockheed martin.

For reference, Attacker_IP is 192.168.109.6 and Victim_IP is 192.168.109.5.

Starting with Delivery Phase

In this phase, we are going to see if our victim machine reach out to an unknown IP and download an unknown application. Let’s pretend we didn’t know that the attacker_ip was 192.168.109.6.

We can start by filtering traffic based on our source_ip. This is the query we can use: source_ip: "192.168.109.5"

This is will give me logs that came from IP address 192.168.109.5

As we can see from the picture above, 192.168.109.5 reached to two IP address: 192.168.109.6 and 192.168.109.2. Let's filter the result even more based on destination ip address.

Query:

source.ip : 192.168.109.5 and destination.ip: 192.168.109.6

The field we’re going to focus is “Process.name”, “event.action”

Looking at the picture above, we see that msedge.exe was being used to connect to 192.168.109.6. We then can move into the event log to see more in depth what msedge.exe was doing. Our goal is to see what msedge.exe download. To accomplish this, we can use Sysmon event id 15: FilleCreateStreamHash using the query:

process.name: "msedge.exe" and event.code: "15"

Referring to the picture above, we can see that msedge.exe was used to download a file called svch0st.exe. The downloaded file/application is stored under: C:\Users\Administrator\Downloads\svch0st.exe.

Diving deeper into the other logs, under winlog.event_data.contents -> We see that the victim machine download an application at hxxp[://]192[.]168[.]109[.]6:9000/

Additionally, we wanted to quickly verify if this program was malicious, we can grab the hash of the program and plug it into virus total.

Now, as a defender, we want note these information down such as the process that was downloaded, where the application was stored, and the IP address that victim machine reach out to. These information can help us discover more activity the attacker has carried out.

Installation Phase

Let’s see what artifacts are generated when an malware is executed on the victim machine. What we can do is filter our result based on the malicious process (svch0st.exe) that we saw.

Query: process.name: "svch0st.exe"

Event ID: 4688 - A new process has been created

The activity we first see being generated is Event ID: 4688. What is 4688?

Event 4688 documents each program that is executed, who the program ran as and the process that started this process. Think of “created” as running.

Here’s the event log. Let’s break it down.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


A new process has been created.

Creator Subject:
	Security ID:		S-1-5-21-518224448-692797076-3762862117-500
	Account Name:		Administrator
	Account Domain:		TESTDUMMY
	Logon ID:		0x1758CD

Target Subject:
	Security ID:		S-1-0-0
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x28f8
	New Process Name:	C:\Users\Administrator\Downloads\svch0st.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		S-1-16-12288
	Creator Process ID:	0x2878
	Creator Process Name:	C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
	Process Command Line:	"C:\Users\Administrator\Downloads\svch0st.exe" 

Focusing on the process Information section, we can see that msedge.exe was trying to start up svch0st.exe. This would make msedge.exe a parent process of svch0st.exe. As a SOC analyst, this should be a red flag for us because msedge downloading an random application is a bad sign.

At this point, we identify the suspicious malicious process. The most important thing we can write down right now is the process id of svch0st.exe. This will be helpful for tracking the activity generated by svch0st.exe.

Sysmon Equivalent

Sysmon equivalent to event code: 4688 is Sysmon 1. Same type of information but overall the structure is different.
Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


Process Create:
RuleName: technique_id=T1036,technique_name=Masquerading
UtcTime: 2024-07-11 09:59:45.693
ProcessGuid: {e58af071-ad11-668f-4001-000000004b00}
ProcessId: 10488
Image: C:\Users\Administrator\Downloads\svch0st.exe
FileVersion: 2.2.14
Description: ApacheBench command line utility
Product: Apache HTTP Server
Company: Apache Software Foundation
OriginalFileName: ab.exe
CommandLine: "C:\Users\Administrator\Downloads\svch0st.exe" 
CurrentDirectory: C:\Users\Administrator\Downloads\
User: TESTDUMMY\Administrator
LogonGuid: {e58af071-a9d7-668f-cd58-170000000000}
LogonId: 0x1758CD
TerminalSessionId: 1
IntegrityLevel: High
Hashes: SHA1=A5D0EBC16A1FDFC518E74C76600F444BF08A2B80,MD5=562A240FAF051DAB58C309DB165B13C8,SHA256=D7374152BF977F3465DC50C886D4C053E95F06F8B7691FE9E98E16CDC1B17B26,IMPHASH=481F47BBB2C9C21E108D65F52B04C448
ParentProcessGuid: {e58af071-aa1c-668f-e000-000000004b00}
ParentProcessId: 10360
ParentImage: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
ParentCommandLine: "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --no-startup-window
ParentUser: TESTDUMMY\Administrator

As you can see there are no sections such as Creator Subject, Target Subject, Process Information.

Command & Control

Once the attacker was able to set up his malware. What he want the malware to do is to radio back home and wait for further commands. We are going to find artifacts of this type of activity.

For this type of activity, we want to go to the network log. This allow us to eliminate the noise and only focus on network activity.

Now, we can carry out a search using the process name or process id. Either one works.

Query: process.name: "svch0st.exe" and process.pid: "10488"

Looking at a glance, we can see that svch0st.exe made a connection attempt! This is really bad news for us. I’m shaking in my boots right now.

Looking into the detail, we see that it made a connection with 192.168.109.6 (destination.ip) from 192.168.109.5.

Now, if an environment is running sysmon, we can use sysmon id: 3. This id log TCP/UDP connections.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Network connection detected:
RuleName: technique_id=T1036,technique_name=Masquerading
UtcTime: 2024-07-11 09:59:50.256
ProcessGuid: {e58af071-ad11-668f-4001-000000004b00}
ProcessId: 10488
Image: C:\Users\Administrator\Downloads\svch0st.exe
User: TESTDUMMY\Administrator
Protocol: tcp
Initiated: true
SourceIsIpv6: false
SourceIp: 192.168.109.5
SourceHostname: -
SourcePort: 50824
SourcePortName: -
DestinationIsIpv6: false
DestinationIp: 192.168.109.6
DestinationHostname: -
DestinationPort: 6777
DestinationPortName: -

Since we know that there’s ongoing communication with 192.168.109.6. We need to see what activity were ran under svch0st.exe. We can do this by seeing the relationship between the parent (svch0st.exe) process and child process. The child process being the command.

As shown in the picture below, we see that there is no result found.

Look like our trail has gone cold. This is weird because there's no activity of svch0st.exe executing any commands. At this point, we may suspect that the attacker have carried out a process injection attack, in simpler term, move into a legitimate window process to further carry out their attack.

Some other thing we can check is if the legitimate window process drop a suspicious application. This could be a sign of establishing persistence. One way we can check for this is using Sysmon. The event id we going hone in is 11.

Query:

event.code:"11" and process.name:"*"

This query allow us to see if a process drop an application. We are looking for suspicious application. As shown below, Runtimebroker.exe was seen creating a file called “evilLink.exe” which is located in C:\Windows\Temp\evilLink.exe.

This proves our hypothesis that the attacker used process injection to disguise his traffic. We can add to our notes that RunTimeBroker.exe was seen being used in a malicious way and it's important to note the process id which is 8308 so that we can keep track of the process activity.
If we really want to prove if that the case, we can use this query: `event.code:"10" and process.name: "svch0st.exe" and winlog.event_data.TargetImage: C:\Windows\System32\RuntimeBroker.exe"

This query allow us to see if svch0st.exe was trying to inject to RunetimeBroker.exe.

Now, that we know that RuntimeBroker.exe was used in a malicious manner, we can keep track of the activity generated from this process. For now, the query we going to use is:

process.name:"RuntimeBroker.exe" and process.id:"8308"

Since, we don’t have the time to look at all of these logs, we can get a general idea of what the logs are. To do that, we can go to the top left corner of the elastic siem and filter it by event.code.

As from the picture above, we see that 61% of these logs contain information about Process Creation. 19% of these logs contain information about Sysmon 13 which is about Registry and so on. I'm going to choose event.code 13 because that's what stick out for me.

Looking at the result, we didn't get anything useful. Well, Back to the drawing board. The next thing we can look for is what commands was run by Runtimebroker especially with process id "8308".

Query:

process.parent.pid:"8308"
As we can see from the result below, we see that multiple of command line were generated by RuntimeBroker.exe.

The next thing we can do is use the process id of the command line to see what command were run.
Visual example:

As we can see from the picture below, RuntimeBroker.exe (8308) was seen invoking cmd.exe (6232) which is equivalent of opening command line. Then, we see cmd.exe (6232) invoking reg.exe (6184). This is what I called a chain of execution.

Let's further investigate what reg.exe was used for. According to the SIEM, reg.exe executed the following command: `reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v backdoor /t REG_SZ /d "C:\Windows\Temp\evilLink.exe" /f`. Let's debunk this command.

The first part of the command is "reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run ", we can conclude that this command is adding a value to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion which is in charge of system startup. We see that the command created a value called "backdoor" and it point to an application called evilLink.exe.

In summary, evilLink.exe will execute every time whenever a system start up. This allow the attacker to have persistence access to the victim computer.

This is the end of the walkthrough. Even though this walkthrough is a bit hindsight and the attack were easily spotted. It allow SOC analyst to see how different process interact with each other and what logs are generated from the following attack.