Last year, ParaFlare’s Managed Detection and Response (MDR) team received an alert that caused some concern, especially at 2.30am. One of our customers had a server that was beaconing out to a known Command and Control (C2) server, conducted by one of their network engineers.

ParaFlare and the client quickly agreed to escalate this alert and engage our Digital Forensics and Incident Response team. We were tasked with the forensic analysis of four systems: one IIS server where the beacon had originated from, two Citrix servers, and the compromised user’s laptop.

NOISE OR PREPARATION?

A couple of days into the forensic investigation we were seeing the threat actor deploy and execute every tool under the sun to achieve their goal. Many of the tools identified below were indicative of the Ryuk ransomware group being involved. The pressure was on to make sure ransomware malware wouldn’t be deployed, but first we wanted to confirm it was Ryuk within the environment.

Enumeration:

• AdFind
• ARestore
• SharpHound
• SharpShares
• Netscan
• net, whoami, ping, tasklist

Credential Access:

• Rubeus; https://github.com/GhostPack/Rubeus
• Kerberoasting; Kerberoast.exe and Kerberos_Invoke_Kerberoast.ps1
• SharpRoast

Privilege Escalation:

• ZeroLogon (zer0dump.exe, CVE-2020-1472)
• Print Spooler (1.ps1, CVE-2022-21999)

WEBSHELL INTERACTIONS VIA INETCACHE

Among all this activity, there was still the initial beaconing to a C2 server that we needed to get on top of. Maybe that’s why the threat actor was so noisy?

Following a fast forensic triage of the IIS server, we discovered three webshells:

1. C:\inetpub\wwwroot\PMS\PMS\PMS\CYPRCS\1.asp
2. C:\inetpub\wwwroot\PMS\PMS\PMS\CYPRCS\1.aspx
3. C:\inetpub\wwwroot\PMS\PMS\PMS\CYPRCS\123.aspx

One of the main artefacts used throughout the analysis, Windows Event Logs, showed the threat actor was interacting with this webshell.

The ‘whoami’ command is used to display the user’s id, or name.

• EID 1116 Windows Defender has detected malware. Path: \10.32.20[.]155\pms\PMS\PMS\CYPRCS\1.asp. Process Name: notepad.exe. Name: Ace.T, PHP/Dirtelti.UB!MTB, ASP/AspxSpy.A, Backdoor:ASP/WebShell.C!MTB (aggregate of threat names)
• hxxps:///pms/CYPRCS/1.asp?cmd=whoami
• hxxp://Visited:%20@https///pms/CYPRCS/1.asp
• hxxps:///pms/CYPRCS/1.asp?cmd=cmd+%2Fc+whoami
• hxxp://Visited:%20@https///pms/CYPRCS/1.asp

The IIS logs also showed several similar commands being run, both successfully and unsuccessfully:

• GET /pms/CYPRCS/1.asp cmd=whoami|21|800a0046|Permission_denied 443 – Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko hxxps:///pms/CYPRCS/1.asp 500 0 64 47217

Generally, when analysing webshell activity, we defenders are only privy to the results of threat actor actions – from when accesses were made, to what commands were run, what files were manipulated, and the list goes on. What was interesting and somehow unique in this case was that we were able to see this interaction from the threat actor’s perspective.

Usually, you would have to seize a threat actor’s device to view the output of a webshell first-hand. Here, however, the threat actor installed webshells on the IIS server and was interacting with them from within the same compromised network.

The threat actor interacted with the IIS server webshell from a compromised Citrix server. By analysing the INetCache forensic artefact from this Citrix server, the threat actor’s base of malicious activity, ParaFlare was able to see what commands were entered and the output of these commands within these logs. The commands shown below were successfully run by an ‘awen’ asp.net webshell (https://github.com/SecWiki/WebShell-2/blob/master/Aspx/awen%20asp.net%20webshell.aspx) named 1.aspx.

The following screenshot shows an example of a log file within directory C:\Users\\AppData\Local\Microsoft\Windows\INetCache. We can see that the threat actor executed two commands via the webshell, and even captures a light-weight interface:

• Enumeration: “/c whoami”
• Command Output: “iis apppool\pmsapppool”

• File Discovery: “dir C:\TEMP”
• Command Output: a directory listing of C:\TEMP\

ParaFlare also identified other log files that showed when errors were made by the threat actor when interacting with these webshells:

From X-Ways export functionality, ParaFlare was able to pull out these logs into a PDF. This was a neat way to quickly discover:

• file path and filename of the webshell being accessed
• ‘title’ and therefore type of webshell being accessed
• timestamp of the activity
• what commands were being run by the threat actor, via this webshell.

The screenshot below is just a sample of this exported log.

Why did the threat actor choose to interact with a webshell using another compromised machine, instead of via the public Internet? ParaFlare can only assume one of two things. As the threat actor already gained initial access, the use of the webshell internally provided an opportunity for privileged escalation, instead of through exploitation. Or, the threat actor wanted to avoid detection, which is the least likely justification given the activity we had already uncovered.

CONCLUSION

We often stick with the same forensic artefacts during our analysis – such as IIS logs, Windows Event Logs, registry hives, and others that indicate program execution. In an investigation where the threat actor has chosen to deploy and interact with webshells within the same compromised environment, as opposed to using their own infrastructure, be sure to check out the INetCache logs to determine attacker activity.