Post Incident Response - I like to - Sherlock by HTB

Attackers workflow mapped

Attacker's Summary

This summary will cover the attackers workflow as discovered from my point of view. I believe the attack first started with nmap port scanning. While looking through web request logs I discovered the use of the nmap scripting engine. From here, there were several webshells uploaded, and several failed. The attacker took advantage of CVE-2023-34362, an exploit found in a file system known as MoveIT.

Triaging Summary

We are provided a summary of logs extracted by the Kroll artifact parser and extractor and a memory dump which is corrupted and cannot be loaded with a memory analysis tool such as volatility. Unfortunately I couldn't get the KAPE tool to load the logs I was provided. I believe the KAPE tool is used once you have access to a host. This was a new tool for me, and my understanding below;

Imagine you have a messy room filled with different types of objects, and you need to organize and document everything in an efficient manner. KAPE is like a specialized toolset that helps you systematically go through the room, identify specific types of objects (digital artifacts in the case of forensics), and neatly categorize and document them.

In this analogy:

1. Messy Room: Represents a digital device or storage medium containing a variety of data.

2. Objects in the Room: Correspond to digital artifacts, such as files, logs, registry entries, and other pieces of information that are relevant for forensic analysis.

3. KAPE Toolset: Acts as your organized approach to sorting through the mess. It has specific tools for identifying, collecting, and processing different types of digital artifacts. It streamlines the investigative process and ensures that you can efficiently gather the necessary evidence without missing anything important.

In essence, KAPE is like having a specialized organizer for your digital investigation, helping forensic analysts efficiently sift through and document digital evidence in a methodical and systematic way.

Workflow

References

• MoveIT Secure Data Transfer Software

  1. https://www.ipswitch.com/moveit-transfer

• MoveIT CVE

  1. https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023

• Kroll Artifact Parser and Extractor

  1. https://www.kroll.com/en/insights/publications/cyber/kroll-artifact-parser-extractor-kape

• MFT Parser

  1. https://www.sans.org/tools/mftecmd/

Sherlock Questions

1. Name of the ASPX webshell uploaded by the attacker?

Location the webshell involved investigation http GET/POST requests to the webserver. To find the evidence of a webshell we browse to the following web directory.

\\HTB\\iliketo\\Triage\\Triage\\uploads\\auto\\C%3A\\inetpub\\logs\\LogFiles\\W3SVC2

1. The inetpub folder is evidence of the use of Microsoft IIS.

2. The log file contains many post requests of ASPX file

2. What was the attacker's IP address?

This was a quick win by referencing the same line item as above for the attackers IP address.

3. What user agent was used to perform the initial attack?

The initial attack appears to be attempt from the the default CVE. We were able to determine this as the MoveIT CVE by default tries to upload a webshell called guestaccess.aspx. We also see the user agent is ruby which is often indicative of Metasploit usage.

4. When was the ASPX webshell uploaded by the attacker?

This was rather tricky as I first narrowed in on the move.aspx POST time in the log file. However, I later learned this is the time the request was sent, not the time the webshell was successfully downloaded and written to the disk. I had to redirect my investigative efforts to the MFT file which first required parsing via MFTCMD, a tool by Zack zimmermen which can be found in the references above.

5. The attacker uploaded an ASP webshell which didn't work, what is its filesize in bytes?

For this question, we have existing context to do with the webshell attempts prior to webshell.aspx. We know there were several odd post requests including moveit.aspx as per our log file. However, we again have to check the MFT file system to determine the size that was written to disk. One reason for the failure of this webshell is the .asp extension. ASP is a legacy version.

7. Which tool did the attacker use to initially enumerate the vulnerable server?

This question brings us back to the log file, were we initially noticed the Nmap + Scripting Engine user agent during the initial scanning phase.

8. We suspect the attacker may have changed the password for our service account. Please confirm the time this occurred (UTC)

9. Which protocol did the attacker utilize to remote into the compromised machine?

I hate to say it, but I guessed RDP......

10. Please confirm the date and time the attacker remotely accessed the compromised machine?

11. What was the useragent that the attacker used to access the webshell?

I noticed in the log file that there was an HTTP smuggling like request, with a call to the attackers host. The user agent was easy, but I wanted to point out this interesting request down below.

12. What is the inst ID of the attacker?

For this one I just checked the metasploit script and it defines inst ID 1234

13. What command was run by the attacker to retrieve the webshell?

For this challenge I checked out the parsed MFT (Master file table) and looked for wget http:// calls. Sure enough we found it.

14. What was the string within the title header of the webshell deployed by the TA?

This one was very labor intensive as I searched for key words through out the file.

15. What did the TA change the our moveitsvc account password to?

This one took me to the parsed MFT file where I looked for a common command to reset a users password.