6 - Reestablishing Access #

Out of the blue, it seems that the actor has had issues accessing the network. Were they kicked out for good?

Somewhere along the way the actors lost access to their webshell. So in this section we need to take a look at what happened to the webshell and then how they got themselves back into the network.

TA003 - Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code. See also T1505.003: Server Software Component: Web Shell

To complete this section I have used the following tools:

• MFT output spreadsheet.
• Splunk for the IIS logs.
• Autopsy - ParseEVTX Python Ingest Module.
• MFTECmd with some different output options.

Note: See this page for tool set up and explanations.

RA-1 #

First, let’s revisit what we’ve already collected about the two malware samples.

Sample 2 we know was dropped on corp-webdev so we will need to go back and revisit our evidence items here.

We know they gained access and were using a GET request to /submit.aspx. So lets narrow down to their access attempts in Splunk to find out when they stopped being successful.

index="acsc_ir_challenge_2021" 
| where sourcetype = "iis" 
| where cs_uri_stem= "/submit.aspx"
| sort _time 
| table _time, c_ip, cs_uri_stem, cs_method, sc_status

Breaking down what we see in the logs in terms of requests to the server and the responses.

So we are looking for when they started to have trouble accessing, which would be the 404 response. Narrowing it down again:

index="acsc_ir_challenge_2021" 
| where sourcetype = "iis" 
| where cs_uri_stem= "/submit.aspx"
| where sc_status= "404"
| sort _time 
| table _time, c_ip, cs_uri_stem, cs_method, sc_status

RA-2 #

There are two events: corp-webdev.alien.local

2021-04-05 22:01:21.622398	 
ALIEN 
dev_agardner 
S-1-5-21-3316040739-64797688-1164660000-1118 
Backdoor:MSIL/Chopper.F!dha
https://go.microsoft.com/fwlink/?linkid=37020&name=Backdoor:MSIL/Chopper.F!dha&threatid=2147776854&enterprise=0 
file:_C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\a056c683\f67bca3c\App_Web_euav215z.dll 
Severe
Backdoor 
AV: 1.333.1660.0, AS: 1.333.1660.0 
1.1.17900.7	

dmz-webpub.alien.local

2021-04-05 22:55:41.744503	
DMZ-WEBPUB 
Administrator 
S-1-5-21-4089384500-2623859888-3969791207-500 
Backdoor:MSIL/Chopper.F!dha
https://go.microsoft.com/fwlink/?linkid=37020&name=Backdoor:MSIL/Chopper.F!dha&threatid=2147776854&enterprise=0 
file:_C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\a056c683\f67bca3c\App_Web_aa0aecbt.dll 
Severe
Backdoor 
AV: 1.333.1660.0, AS: 1.333.1660.0 
1.1.17900.7	

I am very familiar with this webshell backdoor and know it as ChinaChopper.

For some insights into ChinaChopper, check out this blog from Mandiant.

RA-3 #

DFS Replication.evtx is likely where we will find this evidence. on dmz-webpub there are 7 events at 2021-04-01 08:38:00.344700 with the following event codes:

%2 in this case is dfsrtest which matches our previous discoveries.

RA-4 #

To get an idea of the timeframe i went back to splunk and took a look at the actor activities since they stopped being successful.

index="acsc_ir_challenge_2021"
| where sourcetype = "iis"
| where c_ip="13.54.35.87"
| sort _time
| table _time, c_ip, cs_uri_stem, cs_method, sc_status

with the date filter set to “Since 04/05/2021 21:40:00.000”

Sometimes this data can tell a bit of a story. In this case, what it looks like to me is that the actor lost access to their webshell via submit.aspx. To check whether the webserver was still up they browsed to default.aspx and could access, tried their webshell again and failed, then roughly an hour and a bit later they exploited the telerik vulnerability again to load another webshell and regain access. The new webshell was /global.aspx.

So they have no reestablished external access at 2021-04-05 23:16:07 when they regained access via global.aspx.

So we are then looking for events after this time for when they may have transferred files from dmz-webpub to corp-webdev over SMB as they did in the past.

RA-5 #

There are a few tools that we can do this with. Since we have already exported the MFT to a csv, we can find the file information:

• Entry number: 302095
• Sequence number: 28

Running MFTECmd.exe again and focusing on this specific file will show us what is in the $DATA field:

F:\EZTools\Get-ZimmermanTools\MFTECmd.exe -f "(location)\ACSC\ACSC_IR_Challenge_2021\artefacts\corp-webdev.alien.local\C\`$MFT" --de 302095-28

Right at the bottom when we scroll down we see the data and the webshell.

(Request.Item[“tinfoil”]

M-6 #

Running MFTECmd.exe again and focusing on this specific file will show us what is in the $DATA field:

F:\EZTools\Get-ZimmermanTools\MFTECmd.exe -f "(location)\ACSC\ACSC_IR_Challenge_2021\artefacts\corp-webdev.alien.local\C\`$MFT" --de 638-58

The flag answer they gave was 8a0ff044f892d72dbfb8fe9d6a395d47 which I cannot replicate. If anyone can point me in the right direction I’d appreciate it!

UPDATE #

With some assistance we went back to the ACSC for clarification and there was actually a new line character at the end of the webshell code that when I copied the ASCII output was not obvious. To replicate and get the answer I took the HEX into cyberchef and then took the MD5.