LetsDefend.io Event ID 76 — Malicious File/Script Download Attempt
LetsDefend — Blue Team Training Platform is an online Blue-Team focused training platform that I recent dove into and I absolutely love it. LetsDefend focuses on core SOC and Incident Response skillsets with beginner to advanced challenges that ‘analysts’ must solve.
After discussing the different challenges with LetsDefend staff, specifically Gunal, on their Discord server, I’ve decided to post some write-ups as I work through cases. And so, here is the very first one! I will start off with a brief introduction to LetsDefend to set the stage, for lack of a better term, so that no one is confused (I will not be doing this for every single writeup).
Introduction to LetsDefend
Each case in LetsDefend starts out with an Alert. Every Alert has a specific ‘Rule Name’ that describes the reasoning for the alert. Alerts are also assigned a Severity level, Event ID, and Type.
Upon expanding an alert analyst are given a breakdown of critical information that pertains to this alert.
To start working an event an analyst must first take ownership of it, then run through a ‘playbook’ that asks them questions about the event. Analysts must work through the normal Incident Response steps to be able to answer all the questions, however not all alerts require every step in the Incident Response plan, many stop after the Analysis stage, while others involve deeper containment/eradication.
After answering all questions pertaining to an alert and writing a quick synopsis analysts close the alert and are given a score on their performance.
Event ID 76
Now that we have introductions out of the way, let’s walk through Event ID 76 — Malicious File/Script Download Attempt. Here is the alert information we have been given:
EventID: 76
Event Time: March 14, 2021, 7:15 p.m.
Rule: SOC137 — Malicious File/Script Download Attempt
Source Address 172.16.17.37
Source Hostname NicolasPRD
File Name INVOICE PACKAGE LINK TO DOWNLOAD.docm
File Hash f2d0c66b801244c059f636d08a474079
File Size 16.66 Kb
Device Action Blocked
Download (Password:infected): https://app.letsdefend.io/download/downloadfile/XXXXXXX[.]zip/
OSINT
So, first things first, let's pop that hash into VirusTotal and Checkout the results.
30/65…definitely a bad file. But I want to be more hands-on and aware of what exactly we have here. Downloading the .zip and uploading it into a AnyRun session gives us that opportunity. When we open the document in AnyRun we will immediately see WINWORD.EXE spawn a PowerShell process:
Zooming into that PowerShell process we see a basic, albeit obfuscated, PS Download Cradle reaching out to a filetransfer[.]io link:
In the connections request we can also see the IP addresses that are being requested:
Knowing these three pieces of information gives us a good idea of what maliciousness is attempting to transpire. I say attempting as we do not have definitive proof that this malicious file + download cradle ran successfully. Which is actually our next step. If you remember from the details of this event the “Device Action” is listed as “Blocked” but we need to verify this.
Log Analysis
LetsDefend has a few different sources of logs that analysts can look at. Network Logs, Endpoint Logs, and Mailbox Logs. For this event we are sticking with the network + endpoint logs.
Network Logs
The network logs can be found in the Log Managment tab. Here we will look for any call outs to the two bad IPs that we found using AnyRun. When searching for these IPs we are returned no hits.
Now, within the LetsDefend platform we have to put a lot of faith in the different logging tabs. Obviously in the real world there are multiple cross-checks that need to be done to verify there are no holes in the logs, and that the logs that are there are actually accurate. However, this is a training platform and needs to be assumed that there is no purposefully missing data.
Endpoint Logs
That being said, we can cross-check the network logs with the endpoint logs. This can be done on the Endpoint Security tab. On this tab we can find valuable information concerning different endpoints logs including browser history, command history, network connections, and processes running.
Annoyingly enough, there are no Network Connections listed for the NicolasPRD endpoint, instead we are met with “AGENT ERROR.”
While this is annoying, we can still check out the command history to look for any odd commands — especially the download cradle we have already identified. Which, when evaluated, we do not see the download cradle. However, we do find something much more interesting! Multiple encoded PowerShell commands followed by a rundll32.exe command to execute a .dll file from a user’s Temp folder?!
So, what does this mean? Well for starters, we will believe that the attempt to run the original alert-popping document was indeed blocked. We do not have any proof of it successfully running. Which is good! But now we have proof of something else malicious going on. Giant blocks of obfuscated, Base64-encoded PowerShell are not normal, and the immediate following of a .dll file being executed out of a user’s Temp folder is even less normal.
In the case of Event ID 76 specifically, we have the answers we need to close the alert. However, now we have more questions that — if this was the real world — we would need to pivot into answering. For now, however, we will request the containment of this box to be safe:
Closing the Alert
When closing an alert in LetsDefend, analysts have to answer all questions in the case’s playbook and add any/all artifacts they might have found. In the case of Event ID 76, we will answer as so:
When asked to define the threat actor we will select “Unknown or unexpected outgoing internet traffic” as the PowerShell download cradle was attempting to make an internet download request:
When asked if the malware was quarantined/cleaned we will select that it was in fact quarantined as it was successfully blocked — thus we have to assume LetsDefend quarantined it:
When asked if the malware is malicious, we know firsthand that it is:
And when asked if anyone requested the C2 IP address we will select “Not Accessed” as the network logs showed no communication (again we must trust LetsDefend to not intentionally hide data):
Finally we will input all the artifacts that we found:
Original File MD5 — f2d0c66b801244c059f636d08a474079
Filetransfer.io IP Addresses — 172.67.200{.}96, 104.21.13{.}139
PowerShell Download Cradle URL — https{:}//filetransfer{.}io/data-package/XXXXXX/download
This should finish this alert’s playbook and give us a score.
Verdict
As we can see we hit all four marks on this alert and got all answers correct:
All in all, this alert was a super quick and easy way to refresh on basic OSINT/sandbox skills and very basic log analysis. However, this barely touches the surface of LetsDefend and its incredible platform.
I’ve seen other alerts involving full-fledged ransomware detonations that require RDP/SSH connections to the infected machine to do live system analysis as well as in-depth Windows log analysis and deep-dive file analysis.
As I work further through LetsDefend I will periodically submit more write ups and hopefully shine more light on the great platform, while learning as well!
Thank you for reading!
