Adversaries use persistence mechanisms to maintain access to their target environments. However, by persisting, they’re also granting security operations centers (SOCs) an opportunity to detect a threat that might have slipped by other controls that are designed to stop it earlier in the attack lifecycle.
As we’ve been saying in the lead-up to our quarterly webinar with Carbon Black and MITRE ATT&CK™ next week: “Persistence is just another opportunity for detection.”
Ultimately, many persistence mechanisms generate telemetry that SOCs can use to build high-fidelity alerts. Of course, persistence isn’t always observable with endpoint detection and response (EDR) and other tools. Even if it were, detection isn’t always viable and there are too many techniques to achieve full coverage. However, by familiarizing ourselves with as many persistence methods as possible, we can slowly remove the number of unknown techniques to help our overall detection capabilities.
This article will walk through an obscure but effective persistence mechanism and offer some strategies that security teams can use to detect adversaries using this technique.
When automation turns ugly
System administrators and information technology (IT) teams increasingly utilize automation to make their jobs easier, and that automation consists largely of custom scripts. Some of these scripts are configured to execute from scheduled tasks or cron jobs, which security teams typically monitor. However, more often than not, they assume the events associated with their custom scripts are benign and ignore or filter them out.
With this in mind, adversaries can modify these scripts, adding malicious functionalities to them. For example, an adversary can update a script that would normally deploy Sysmon so that, in addition to deploying Sysmon, it establishes a network connection to a command and control server (C2). It’s important for all teams within an organization to communicate when these types of scripts are being configured so that the correct security controls can be implemented to help identify when this type of activity is occurring.
Think like a sysadmin
Back when I was a sysadmin, I loved using PowerShell jobs or batch scripts to help deploy products like Sysmon within an environment. In retrospect, a lot of these scripts had a glaring security flaw: you could manipulate them pretty easily, and no one was really watching them to make sure they weren’t manipulated.
From an offensive perspective, it’s not hard to find these scripts within an environment. In fact, they are often deployed through Group Policy Objects (GPO), and an adversary can readily find them on a network share or by enumerating windows event logs.
This same concept applies to scripting profiles that are commonly used by internal IT teams. These profiles are essentially scripts that are executed anytime a user launches an instance of bash or PowerShell—depending on the preconfigured execution policies. Most system administrators or organizations do not go through the trouble of signing these scripts or applying other security controls to them. As such, there aren’t a lot of barriers preventing these changes from being made—much less, any form of alerting within an organization when changes are made to these profiles.
This following script is from a previous blog post about testing your ability to detect prevalent MITRE ATT&CK techniques. If you do utilize PowerShell profiles within your environment, would you be able to identify a change like this one appended to the end of your profile—much less identify the execution of this script within a profile?
Servers and persistence mechanisms
Web servers are also susceptible to these types of changes, although they typically have more security surrounding them in the form of firewalls and proxies capable of detecting on suspicious web requests. The concern is that if an adversary manages to bypass these controls and gain access to a web server, they can alter it to deliver malicious code directly to the source, completely bypassing the web application firewall. This is especially worrisome for internal servers, which don’t always receive the same level of security attention as their external counterparts. Depending on how often these internal sites get used, they can be a great place to implement persistence.
No… they wouldn’t abuse macros!
Not to beat a dead horse, but another method we’ve seen implemented within an environment (by a penetration tester) involved changing the existing default templates for Microsoft Office documents. The pen-tester overwrote the default Word template file (normal.dotm), effectively injecting a malicious macro into every Word document using the template, thereby having the user spread the adversary’s means of persistence.
While advanced knowledge of an environment is typically required to implement this type of persistence, the barrier to entry for implementation is actually quite low. Perhaps worse yet, remediation can be a nightmare due to the amount of visibility required to detect on these types of changes.
As adversaries learn how security teams operate, it is critical to continue evolving our detection capabilities.
If you do plan on implementing security controls to help combat this type of persistence, some kind of file integrity monitoring tool could help alert internal teams to when changes are made to these high value targets. You can never assume what level of access an adversary has, so it’s not a great idea to purely rely on permission-based controls in this instance.
In a perfect world, having a dedicated endpoint within the environment that monitors these changes on a regular basis would be ideal to avoid anyone altering how these security controls work on the dedicated server. It’s worth noting that the above examples aren’t your run-of-the-mill persistence mechanisms, and if you are seeing this type of activity within your environment, then you’re probably either facing an advanced adversary or (more likely) a penetration tester.
Additionally, not all EDR platforms have full visibility into the code that may reside in these scripts, so deploying a solution like Sysmon or PowerShell ScriptBlock logging is always recommended. Here is a great example of a recommended implementation of Sysmon that’s worked like a charm when I’ve previously used it. Of course, unless we’ve learned nothing today, don’t forget to monitor changes made to this batch script either!