2 - Initial Access #
ALIEN are adamant that the most likely place for a malicious actor to get into their network is their public web server hosting the main website, and have seen some odd activity recently. They have provided some data from this server in zip dmz-webpub.alien.local.zip. We’ll start by looking there.
There are 5 questions in this section that are primarily focused on external facing systems and their log files. There are a few options to review the logs provided as part of the zip file, but I opted to set up Splunk and do the challenge using Splunk.
Log parser is another great option to parse IIS logs.
TA001 - Initial Access consists of techniques that use various entry vectors to gain their initial foothold within a network. Techniques used to gain a foothold include targeted spearphishing and exploiting weaknesses on public-facing web servers. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited-use due to changing passwords.
IA-1 #
- Start by removing the local IP of 10.1.0.80 from the results:
index="acsc_ir_challenge_2021" | sort _time | where NOT c_ip="10.1.0.80"
- In general, GET requests are what we’ll see for normal traffic to a website, so I filtered on POST requests to see what came back:
index="acsc_ir_challenge_2021" | sort _time | where NOT c_ip="10.1.0.80" | where cs_method="POST"
- Traffic originating from 13.54.35.87 sticks out in the listing with multiple POST requests to /Telerik.Web.UI.WebResource.axd. So ill filter on that IP now:
index="acsc_ir_challenge_2021" | sort _time | where c_ip="13.54.35.87"
- There was a clue in the question so the following event was the one related:
2021-04-01 02:35:41 10.1.0.80 GET /Install/InstallWizard.aspx __VIEWSTATE=&culture=en-US&executeinstall 80 - 13.54.35.87 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:54.0)+Gecko/20100101+Firefox/54.0 - 404 0 0 42
Their malicious ‘wizardry’ that failed (404 status)
IA-2 #
The first indication in the log files that they were successful in gain access (status 500) is the log entry:
2021-04-01 02:49:08 10.1.0.80 POST /Telerik.Web.UI.WebResource.axd type=rau 80 - 13.54.35.87 python-urllib3/1.26.2 - 500 0 0 52 c_ip = 13.54.35.87host = dmz-webpubsource = u_ex210401.logsourcetype = iis
Googling
/Telerik.Web.UI.WebResource.axd
and CVE makes it pretty clear that there are a few CVEs bouncing about, but they have asked for the most recent.Coincidentally (or not) an advisory was put out by the ACSC in 2020 that has the interesting details in it.
on a side note and maybe for later, the advisory talked about evidence of the exploit in application event logs, so I jumped in to the eventlogs to correlate.
IOCs from the advisory
Item | Info |
---|---|
Advisories and CVEs | CVE-2019-18935, ACSC 2020-004 & ACSC 2019-126 |
Review web server request logs | POST /Telerik.Web.UI.WebResource.axd type=rau 443 – 192.0.2.1 - - 500 0 0 457 - These POST requests may be larger in size than legitimate requests due to the malicious actor uploading malicious files for the purposes of uploading a reverse shell binary. |
Review Windows event logs | Event ID: 1309 Source: ASP.NET <version_number>Message: Contains the following strings in addition to other error message content:An unhandled exception has occurred.Unable to cast object of type ‘System.Configuration.Install.AssemblyInstaller’ to type ‘Telerik.Web.UI.IAsyncUploadConfiguration Organisations should review the application event logs on vulnerable or previously vulnerable hosts for indications of Telerik exploitation. This analysis can be combined looking for associated HTTP 500 responses as identified above. |
IA-3 #
- Given we are looking for a file created I will parse the MFT and look for files created on the file system that corresponding to the timeline from the IIS log analysis:
- around 2021-04-01 02:50 UTC
- EZTools - MFTECmd.exe will do the trick to parse the $MFT file provided in the artefacts folder (root of C drive). I’ll run this from a PowerShell window.
EvtxExplorer - MFTECmd #
C:\Users\fancy_4n6\Desktop\EZTools\MFTECmd.exe --csv "c:\temp\out" --csvf dmz-webpub-mft-c.csv
- Open the CSV, you will need to set the format for the date/time columns. I set the format for columns T -> AA as yyyy-mm-dd hh:mm:ss.000.
- NOTE: ensuring that you have the milliseconds represented will stop any rounding which will change your answers.
- I then set a filter on the top row and sorted by column T “Created0x10”
- Looking at around 2021-04-01, something immediately caught my eye in Column F “.\Windows\Temp and two files 1617245542.475716.dll (2021-04-01 02:52:10) and 1617245455.5314393.dll (2021-04-01 02:50:43) created after we know the attacker was able to successfully exploit the CVE. We are looking for the first file filename.
This wasn’t specifically called out as required for a challenge, but during a normal investigation I’d likely do some OSINT on these files names. The files are no longer on disk, or we don’t have copies of that folder, so it will just be based on what I know so far.
File Name | Location | Size | MD5 | Created Date on C | Info |
---|---|---|---|---|---|
1617245455.5314393.dll | C:\Windows\Temp | 91648 | 2021-04-01 02:50:43 | ||
1617245542.475716.dll | C:\Windows\Temp | 118784 | 2021-04-01 02:52:10 |
It was a long shot and in this instance I came back with nothing from Google + VirusTotal.
IA-4 #
From the MFT we know that the attacker dropped some files starting at 2021-04-01 02:50:43 (IA-3), when we look below those entries there are a few more curious entries that look like updates being pushed to the site.
Correlating the logs we can expect that the attacker was able to use their tool via submit.aspx so the correct date time they are after relates to the time in the IIS logs and the attacker action and the first use.
This is where starting to build a timeline is very handy. I usually do this as a dashboard in my excel worksheet for the particular engagement.
Memory and TrufflePig Forensics #
Wanted to have a look at network connections and things going on related to this IP address in memory and found the following netconns:
We will be looking at those further I’m sure in subsequent questions.