Endpoint Detection & Response (EDR) is frequently used by organizations as the first line of defense against cyber attacks. EDR platforms monitor organizations’ endpoints (servers, employee laptops, etc) and detect and contain malicious activity running where possible. In this blog, we will be exploring a ransomware attack in a lab environment, using payloads inspired from real attacks.
For this experiment, we set up an up-to-date Windows machine, with a mainstream EDR tool installed. We simulated a ClickFix attack against the user, which relies on socially engineering the user into running malicious commands.
During the first stage of the attack, our fake end user receives a phishing email with a clickfix attachment:
As this is a test, we kept the email fairly short. However, an attacker in a real-world setting would make the email far more convincing to view. In the real world, we often see this type of attack being used with fake invoices being sent to finance staff.
After opening up the HTML, our end user is presented with the following page:
The ClickFix HTML the user is presented with as part of our simulated attack
This is taken from a real attack seen in the wild where a word online page is mimicked, prompting the user to interact with it. The user needs to interact with the button, as most browsers will block clipboard writes unless the user has interacted with an element. Clicking the button copies a command to the user’s clipboard, and updates the instructions to tell them to press Win + R, Ctrl + V, and then Enter. If the user does this, it will open the run dialog, paste in the command, and execute it. This relies on the average user not understanding or blindly following the instructions, which has proven itself effective in actual cyberattacks.
It is worth noting that the EDR tool flagged this stage during our initial testing. However, adding a layer of obfuscation to the HTML enabled us to bypass detection. We were able to encode the page, and then decode it and write it to the document using reflection to access methods that would normally be flagged.
Once the command is executed, Powershell is invoked to download and run an exe file from an attacker-controlled server.
The payload is a custom C++ binary that was developed for the purpose of this test. The binary spawns a reverse shell, as well as encrypting all of the files in the Documents folder for ransom. We iteratively tested this binary against the EDR tool, and were able to tweak functionality each time to bypass elements that were getting detected. Bypassing the EDR tool did not require any fancy techniques. Simply using a different Windows API to accomplish a goal that was previously flagged by the EDR tool, or altering the behavior, timing, and ordering of activities performed was sufficient to evade detection. This may seem surprising that sophisticated techniques aren’t strictly required to be undetected.
We can see the aftermath of the attack in the below images, with a ransom note being written, and our important documents no longer being readable.
The ransom note
The aftermath of our handiwork when trying to open one of the PDFs
With no alerts to investigate from the EDR tool - how could a blue team uncover this attack chain after the fact for incident response? That’s where Cado comes in.
Using Cado, we can import the affected VM directly with just a few clicks.
The ransom note is a good starting point for our investigation. Using the timeline search feature, we can quickly find an entry showing us what process made the readme.txt file.
We can see that the ransom note was created by the process fix.exe, which we can use to pivot off of and build a better understanding of what else the malware did, and how it got onto the system.
Reviewing events relating to the fix.exe payload, we observe an event showing it established a connection to a server, in this case, an attacker-controlled C2 server. It also spawned a command prompt instance, which provides a remote shell to the attacker.
Looking at the event information, we can also easily spot the ransom attacks against the files. For example, we can see it modifying the internal_draft_important.pdf document, which as we saw before can no longer be opened.
Finally reaching the start of the log trail relating to the payload, we can see it initially being executed by Powershell.
However, this doesn’t tell us what caused the malware to run in the first place - so we can use the pivot feature to find related events.
Pivoting off the event allows us to quickly figure out this was precipitated by a visit to obfuscated.html, which was downloaded from an email in Outlook online:
The Cado Platform also allows us to directly jump to the file in the file browser so we can conduct further analysis:
An EDR platform usually only gives you an alert, process snapshot, and event details for a singular moment in time, missing the vital context needed to successfully understand the attack. Cado provides the vital context needed to successfully understand the full scope of the attack, not just its entry point.
We’ve covered how Cado can enable you to forensically analyze systems to fully understand how attacks have occurred and unfolded. Defense-in-depth is a core component of cybersecurity, and being entirely reliant on an EDR platform as your only line of defense and insight into attacks can leave you without full context.
This was an example only, and a finely tuned EDR platform would likely detect an attack similar to this. However, many organizations may overlook the forensics side of Digital Forensics and Incident Response (DFIR), and remediate incidents solely using their EDR platform. This can result in organizations missing out on the complete picture of an attack, potentially leaving them open to re-infection. A DFIR platform such as Cado is vital to respond quickly to incidents across Cloud, SaaS, and on-prem.