This CTF is a threat-hunting practice scenario. We’ll have to investigate malicious activity on a computer that’s been the victim of a phishing attack, from initial access all the way to stealing confidential data.

This challenge is part of the Threat Hunting module on TryHackMe, and I felt it was a solid way to practice what was learned. You can find the link to Hunt Me I: Payment Collectors here.

We’re given an ELK Stack to perform our investigation, so open the Discover tab, set the date to the date of the incident (September 15, 2023), and let’s get to it! Answers in this guide will be hidden as usual.

Questions#

What was the name of the ZIP attachment that Michael downloaded?#

Let’s query Elasticsearch for any .zip files that appeared in the logs that day:

  • *.zip

Sort the results in ascending order, and expand the first document. In the file.name field, the original invoice that Michael downloaded is there:

The original ZIP attachment downloaded at around 6:41 PM.

The original ZIP attachment downloaded at around 6:41 PM.

What was the contained file that Michael extracted from the attachment?#

Now let’s search for records containing this file name, because it’s likely that the zip was extracted into a folder of the same name:

  • << zip-from-question-1 >>

There are only a few records, and some of them turned up in the last query, so they can be ignored. Opening up one of the more recent records, we see there is indeed a folder of the same name, and a path to a file contained within it:

The file contained in the ZIP.

The file contained in the ZIP.

What was the name of the command-line process that spawned from the extracted file attachment?#

The previous event was created when the explorer.exe process opened the file, and so this event has its own process.id, which is 3180.

The PID generated by opening the file.

The PID generated by opening the file.

We can query for other processes which have this PID matching their parent process ID:

  • process.parent.pid : 3180

There are two records, though we can ignore the older one as it is benign and occurred before the incident. The other record contains the answer.

The spawned process name.

The spawned process name.

What URL did the attacker use to download a tool to establish a reverse shell connection?#

Expand the details of this record, and look at the process.command_line field. Here we see the URL to the tool, and the usage of the same tool to set up a reverse shell connection.

The command, URL, and port used to set up a reverse shell.

The command, URL, and port used to set up a reverse shell.

What port did the workstation connect to the attacker on?#

The port used is also in the command executed above.

What was the first native Windows binary the attacker ran for system enumeration after obtaining remote access?#

The command in the previous question opens a PowerShell process with its own process.id of 9060. We can look for records whose parent process matches it with this query:

  • process.parent.pid : 9060

Here we can see some Windows binaries run from this session, and the answer is the oldest command.

Windows binaries executed from the launched PowerShell session.

Windows binaries executed from the launched PowerShell session.

What is the URL of the script that the attacker downloads to enumerate the domain?#

I initially couldn’t figure this out chronologically like all the other questions, so I’ll return to it at the end (Q7.b).

What was the name of the file share that the attacker mapped to Michael’s workstation?#

From the list of processes obtained in Q4, the latest one opens up yet another PowerShell session, with a PID of 3728. Again, we search for events with matching parent PIDs:

  • process.parent.pid : 3728

The oldest command shows a drive being mapped using net.exe, and this is the answer.

Processes initiated by a different PowerShell session.

Processes initiated by a different PowerShell session.

What directory did the attacker copy the contents of the file share to?#

The very next command with Robocopy.exe shows where the files were copied to.

What was the name of the Excel file the attacker extracted from the file share?#

When Robocopy.exe was invoked, Sysmon logged FileCreate events for each file copied over. So we can look at the surrounding documents of the initial Robocopy command, and see an event for each file.

Subsequent Robocopy events logged by Sysmon.

Subsequent Robocopy events logged by Sysmon.

Sifting through the file.path fields of the subsequent Robocopy processes, we find a .xslx file, which is our answer.

The target Excel file copied over.

The target Excel file copied over.

What was the name of the archive file that the attacker created to prepare for exfiltration?#

Since we know the location of where the attacker copied the files to (from Q9), let’s query for records containing that directory, since the command that created the archive should contain it:

  • << answer-from-question-9 >>

When looking at the PowerShell executions just after the Robocopy processes, we see the name of the archive file to be created.

The archive file being prepared for exfiltration.

The archive file being prepared for exfiltration.

What is the MITRE ID of the technique that the attacker used to exfiltrate the data?#

This answer is found by going back through the results of the search we did in Q8:

  • process.parent.pid : 3728
Processes initiated by a different PowerShell session.

Processes initiated by a different PowerShell session.

There are several requests to a suspicious domain with seemingly randomized subdomains, starting at around 6:41:03 PM. These events are actually the product of data exfiltration to a domain owned by the attacker, but masked as innocent DNS requests.

This tactic maps to MITRE ID T1048: Exfiltration Over Alternative Protocol1. The attacker is sending data through DNS, which is different from their established command and control channel.

What was the domain of the attacker’s server that retrieved the exfiltrated data?#

The domain is listed in the records seen previously.

The attacker exfiltrated an additional file from the victim’s workstation. What is the flag you receive after reconstructing the file?#

Another exfiltration action seems to start at 6:46:19 PM, with two events close in time. Just based on the final subdomain, it looks like the data is encoded in base64. We can just combine the two subdomains, and put the result in any base64 decoding tool, such as https://www.base64decode.org/.

Decoding the exfiltrated data.

Decoding the exfiltrated data.

Discovery (Revisited)#

What is the URL of the script that the attacker downloads to enumerate the domain?#

I did this write-up while doing the CTF for the first time, and wanted to document my thought process exactly as it came to mind. So, I punted on this question intially, and tried again afterward with the context of my total investigation.

Going back to the search we did for the ZIP attachment in Q2, if we looked at the message field of the most recent record, we’ll notice an interesting tool being used in the script block.

An interesting PowerShell tool somehow related to the original ZIP attachment.

An interesting PowerShell tool somehow related to the original ZIP attachment.

This tool is a well-known PowerShell tool for enumerating domains, and since we now have a name, we can query Elasticsearch to possibly find out how it was downloaded:

  • << interesting-tool-here >>

There are 259 hits, but we should sort from oldest to newest, since we’re concerned with how the tool first got onto the computer. The first few entries contain our answer, the URL that was used to download the tool.

The command used to download the tool.

The command used to download the tool.

Conclusion#

And now we’ve finished our investigation! To recap:

  • Michael downloaded an attachment from a phishing email which looked like an invoice, but upon opening the fake document, it launched a reverse PowerShell session on his computer that was controlled by attackers.
  • The attackers then did some reconaissance of the network and files accessible by the machine, and discovered valuable data.
  • Finally, the data was then exfiltrated in pieces over DNS to help avoid detection.

  1. Exfiltration Over Alternative Protocol. https://attack.mitre.org/techniques/T1048/ ↩︎