One of the most easily resolved scenarios an analyst can face is when an alert is triggered regarding an abnormality on an endpoint, whereupon initial investigation reveals right off that an abnormal process is running in memory. The process is immediately checked on virustotal or in a sandbox service, where it is identified as malicious and there are clear online KBs indicating how to clean it up. Piece of cake. Case closed.
This is the kind of incident that analysts’ dreams are made of: A monitoring system triggers alerts that indicate events like network scans, brute force attempts and C&C communications. This is the kind of low-hanging fruit that can be easily identified, verified and remediated. But sometimes dreams can turn into nightmares... Alerts that may initially seem to be open-and-shut cases can be misleading. Because in fact, they are not low-hanging fruit at all. In reality, the fruit may be so high up in the tree that it isn’t even visible.
But how is this possible? As attackers get more and more sophisticated, classic persistence, becomes less critical to a successful invasion. In fact, the most recent stealthy attacks rely on agility, i.e., the ability to penetrate, complete objectives and quickly disappear undetected. The attacker evaporates like a ghost without a trace, while keeping attack channels available for future mayhem.
The fraudster can achieve this goal using malware that employs self-deletion capabilities like time scheduling of tasks or keys in the registry that delete themselves after doing their dastardly damage. The same principle applies for attacks that are in memory only. Or attacks that use an OS built-in scripting mechanism like PowerShell, cmd, python, bash, js or vbs.
So, even if an analyst uncovers flimsy evidence like ‘wscript.exe’ or ‘cscript.exe’ as the process responsible for certain abnormal patterns, since these are legitimate Windows processes, the attack may have come and gone before any incident response can be initiated. The same applies to ‘rundll32.exe’. It is a perfectly valid Windows process, but it can be used to execute malicious DLL files. Or ‘wscript.exe’ that can execute malicious vbs/js instructions. And that’s just the tip of the iceberg. A case in point is PowerShell, probably the most popular culprit nowadays. You can find many tutorials and online instructions on how to control a remote machine using nothing but PowerShell commands, then learn how to wipe away any trace of malicious activities once the attack is complete.
Another example is thread injection, which is a form of attack that can trick an analyst into misinterpreting the data shown on a screen. The cause of an alert could be from legitimate processes like the browser, ‘svchost.exe’ or ‘explorer.exe’, but, the devil is in the details. A single, solitary thread in an otherwise legitimate process could be deceiving when that thread is not native to the process. It might have been created remotely by another, illegitimate process. But which one? See what we mean about the fruit actually being high up in the tree? The fruit can be higher still. In more extreme scenarios, rather than just deleting themselves upon exit, attackers may wipe clean the local eventlog or syslog as well as other repositories that would later be used for forensics, effectively erasing any evidence of their presence
Employing these cunning methods, attackers can conduct their malicious business and then simply fade back into the anonymity of the web, never to be nabbed. And the door remains wide open for when they want to return and get their hands on still more sensitive data and IP. But to the analyst on the hunt, it looks like nothing happened. An alert may have been triggered because of an anomaly, but when the analyst searches for evidence, there’s nothing there. Gone without a trace, because the fruit was too high to see. The analyst closes the case and quickly moves on to the next alert in the queue, hoping to find easy pickings like low-hanging fruit.
Meanwhile, a whole slew of questions arises: Was the case really a false positive? Or was it a stealthy attack that left no trace after it was executed? Could the attack actually still be in process without any ability to understand the evidence? Did the attacker leave open a door for a future intrusion?
Answering these questions after the fact, especially when dealing with volatile memory, is extremely challenging even for the most seasoned of forensic specialists. This is undoubtedly one of the many contributors to protracted dwell times. Providing answers at all, let alone in reasonable timeframes, necessitates a change of concept. It requires preemptive forensics.
Preemptive forensics ensures every component is collected from all endpoints and servers, 24/7/365, and stored remotely and securely. Every process, every thread, every file operation, every registry modification, every network activity, every USB drive connection, every command running in memory, every argument. Literally everything. A complete, permanent log of everything that ever happened.
With this forensic evidence at the ready and using accurate forensic tools, the analyst can quickly get clear answers to every question to determine exactly what happened. No guesswork, no assumptions. Real, actual facts that provide a precise picture of the actual events as they occurred.
About Secdo:SECDO’s Preemptive Incident Response platform delivers preemptive forensics that ensures complete system visibility. By automating the investigation process and furnishing a visual investigation report, it empowers analysts to respond correctly and enables them to implement lessons learned in order to improve future protection.