CTF Walkthrough
Using Sysinternals to investigate an Endpoint | TryHackme Investigating Windows 3.x
This is a walk-through of the Tryhackme Room, Investigating Windows 3.x. A compromised machine was setup and we were supplied with the task to investigate, report and figure out what exactly happened on the machine. This was a fun exercise, as it gave us an opportunity to look at various artifacts left behind by the attacker and try to make sense of the situation.
Information Sources
There are various sources on the machine you will need to pull information from to get the answers needed:
- Autoruns log on Desktop
- Procmon logs on Desktop
- Sysmon (Event viewer or powershell whichever you prefer)
- Powershell command history in Documents
Q1: What is the registry key with the encoded payload? (full path)
A good first place to is going to be Autoruns to check for any suspicious entries that are not by a verified publisher. Here we can we see one named “updater” that mentions a key called “debug”:
If we right-click and jump to the entry in Regedit, we can move up directories in here until we see the “debug” value. Here we can find an encoded payload. However the question asked us for the path to this will be the answer:
NOTE: You will have to add a “\” after currentVersion and before debug to get the correct answer.
Q2: What is the rule name for this run key generated by Sysmon?
This one can be found in the sysmon logs in event viewer by using “find”. We can search for the powershell command we saw in autoruns in the previous question. The answer can found in the entry under “RuleName:”
Q3: What tactics is classified with this MITRE ATT&CK ID?
This can be found by searching the rule name from the previous question in MITRE ATT&CK. It will be found in the “tactics” field here: https://attack.mitre.org/techniques/T1547/001/
Q4: What was UTC time for the Sysmon event?
Can be found in the entry under “utctime:” from Q2.
Q5: What was the Sysmon Event ID? Event Type? (answer, answer)
This one can be found also in the entry from question 2. Check the Event ID in the column and the Type should be in the details.
Q6: Decode the payload. What service will the payload attempt start?
We saw this in the “debug” value in Regedit in question 1.
Decode the value data in a tool such as CyberChef. You may need to remove null bytes to make it more readable after decoding. There is a recipe for this in CyberChef itself:
Here you will find a service being started.
Q7: The payload attempts to open a local port. What is the port number
This is simple enough. You will find this in the decoded payload from above.
Q8:What process does the payload attempt to terminate?
If we look at the decoded payload from Q6, we can see another encoded payload under the $commands variable. If we decode this using the same recipe from earlier, our answer will be here. Look for the kill command.
Q9: What DLL file does the payload attempt to remove? (full path)
Found in the decoded payload from Q8. Look for a reference to a DLL file. You find it easily by searching for a DLL file extension: .dll .
Q10: What is the Windows Event ID associated with this service?
This one may take some research. If we google the process from Q8, we may find a mention to both “Fax Service” and “Print Service”. If we check the logs in event viewer under Windows > PrintService we will find our answer:
Q11: What is listed as the New Default Printer?
This can be found in the same place as above question. Read the description of the entry.
Q12: What process is associated with this event?
If we use find and enter the name of the new printer as a keyword in procmon, we will find our answer here under the process name.
Q13: What is the parent PID for the above process?
We can Right-click anywhere in procmon to add columns. If we do this and look at the entry from the previous two questions we will find the answer.
Q14: Examine the other processes. What is the PID of the process running the encoded payload?
This can be found in either sysmon logs or process monitor. We will need to search for the flag in powershell that encodes payloads that we saw earlier, which is -enc .
Q15: Decode the payload. What is the a visible partial path?
We have already decoded the payload earlier so if we take a look here we are looking for a mention of a path that would be part of a URL. This will be our answer.
Q16: This is the default communication profile the agent used to connect to the attack machine. What attack framework was used? What is the name of the variable? (**answer, answer**)
If we take a look in the powershell logs in the documents folder on the machine, we can see a mention of a command known as invoke-psinject . If we google this, it should bring us to the framework we are looking for. A quick look through the documentation or a google search of the default profiles in this framework, we will see a profile that mentions the URL path from the previous question. This will be our answer.
Q17: What other file paths are you likely to find in the logs? (answer, answer)
This answer will be found in the same place we found our profile in the previous question. This will be in the “value” column we will see our URL path from Q15 and other paths mentioned. This will be our answer.
Q18: What is the MITRE ATT&CK URI for the attack framework?
Search the name of the framework in MITRE and copy the URL. That is our answer.
Q19: What was the FQDN of the attacker machine that the suspicious process connected to?
In the previously decoded payloads we will see a encoded string declared as variable $t , if we decode this we will get a ip address and port from earlier. Use dig or nslookup tools to find the FQDN of the ip.
Q20: What other process connected to the attacker machine?
The way to find the answer is hinted in the question. If it’s a process that connected to the attacker machine, then it must’ve used the same IP. A quick search in sysmon will bring us to an answer, and we can then view the process name. This can also be done in procmon.
Q21: What is the PID for this process?
Simple enough. Can be found in procmon by looking for the process above.
Q22: What was the path for the first image loaded for the process identified in Q’s 19 & 20?
We can use procmon filters here to find this. If we filter for the PID in above question and then filter for an operation that loads an image. The operation itself is known as “LoadImage”:
The answer will be the path of the first entry.
Q23: What Sysmon event was generated between these 2 processes? What is its associated Event ID #? (answer, answer)
We will need to filter in event viewer between the time the two payloads we found in event viewer (the one from question 2 and question 14 ). We can do this by searching for “-enc” or “enc” again. We need to then look for an event tied to sysmon which talks about 2 processes accessing each other. This can be found in the sysmon docs: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon . Add a event ID filter to the already existing filter to confirm the answer. Here we will see the two processes accessing each other. This method is commonly known as process injection, which is used commonly by legitimate processes but can also be used to hide malicious activity on a machine.
Q24: What is the UTC time for the first event between these 2 processes?
Using the same filter from above, look for the earliest entry between the 2 processes, and then answer will be the UTC time for this entry.
Q25: What is the value under Date and Time? (MM/DD/YYYY H:MM:SS [AM/PM])
From the same entry above, look at the columns and the date and time column will have your answer
Q26: What is the first operation listed by the 2nd process starting with the Date and Time from Q25?
Here we can filter for the PID from the entries from the above questions. Our answer will be one of the first entries in the list
Q27: What is the full registry path that was queried by the attacker to get information about the victim?
This may take some time, but we are looking for a registry key that is used commonly for information gathering, here is a link to where we may find registry keys for gathering system info: https://techdirectarchive.com/2020/03/18/how-to-display-windows-system-information-via-the-windows-registry/. We can use the path filter on some of the keys in prcomon to confirm the full path of which one was used:
Q28: What is the name of the last module in the stack from this event which had a successful result?
We can find this by right-clicking the entry we found in the above question in procmon and going to properties > stack and looking at the last module.
Q29: Most likely what module within the attack framework was used between the 2 processes?
We saw this in the powershell command history in documents folder from earlier. You could also dig through the docs of the framework that was used and cross-reference the artifacts found on the machine, but it would be a lot easier to find in looking at the powershell history.
Q30: What is the MITRE ID for this technique?
A simple google search for the module name above in MITRE attack will get you the ID needed.
