This post was originally published here by Matthew Hosburgh.
Introduction
By now the world has learned about the massive breach that Equifax reported in early September. The Cyber Kill Chain would classify the final stages of this attack as the actions on objective. Unfortunately, Equifax did not detect this activity in time to contain or prevent the data loss. No organization is above the law, especially in terms of a breach; however, failing to learn from this example only paves the way for the next catastrophic breach to occur.
With the b-word fresh on everyone’s mind, the following two-part post will dive into hunting for data exfiltration, where PowerShell is the exfiltration tool of choice. In this first post, we will hunt for network indicators. In the second post, the focus will be on the host.
Why PowerShell?
PowerShell is fast becoming the defacto tool for adversaries in nearly every phase of an attack. With Windows holding nearly 75% of the market share, it’s no wonder why PowerShell is leveraged so heavily. When time is of the essence, why bring your own tools to the game when you have ready access to them all? As of version 5, the features and capabilities are incredible from both an administrator’s and attacker’s perspective. One Technique leveraged by known adversaries is the automated exfiltration of data. With PowerShell in play, scripting this type of exfiltration is easy money; however, where is the starting point to begin hunting for something like this?
Formulating the Hunt
Begin by leveraging observed techniques to form your hypothesis. MITRE has an excellent resource, known as the Adversarial Tactics Techniques & Common Knowledge (ATT&CK for short). Contained in this matrix of tactics is a series of techniques that attackers leverage to obtain their objectives. Within each category is an explanation, examples, mitigation and detection recommendations. Look no further for an outstanding resource to start formulating hunt hypotheses!
For this discussion, table 1 is an example of a hypothesis that we will use to start our hunt:
| Automated Data Exfiltration (Windows Environment) | |
| 1. What are you looking for? (Hypothesis) | Hypothesis:
PowerShell is being leveraged in my environment for automated data exfiltration Look for: · Anomalies in HTTP user agent strings, such as PowerShell · Consistent and reoccurring HTTP PUT methods Cyber Kill Chain Phase: Actions on Objectives MITRE ATT&CK: Automated exfiltration Example Malware: TINYTYPHON |
| 2. Investigation (Data) | Datasets:
For identifying mis-behaving PowerShell over the network, look at (some easier to examine than others):
· Netflow (“flow” data in general) · Frequency and any patterns of PUT methods · Packet Captures · Proxy Logs · Firewall Logs (if logging HTTP headers) · EDR Logs · Sysmon · Windows Event Logs for PowerShell · PowerShell Transcript Logs |
| 3. Uncover Patterns and IOCs (Techniques) |
same? |
| 4. Inform and Enrich Analytics (Takeaways) | The destination IP addresses and user agent string containing PowerShell can be used to help identify other hosts that may be exfiltrating data within environment.
Feed these IOCs into the Risk Trigger in Sqrrl, your IDS, SIEM, or EDR system to automate future detection or response. |
Table 1. Forming the Hypothesis
Based on one-part hunch, one-part MITRE reference, a viable hypothesis has been created. Similar to the preparation phase of the six-step incident handling process, establishing the resources available to the hunter is a time saver. Now it’s time to go hunting!
Network Data: The Broad Brush
Network data is one of the easiest places to start hunting for oddities within an environment; however, encryption or lack of visibility can frustrate your network based hunt. All network traffic has a source. Put another way, there is a process executing on a host at the other end of the traffic you might be seeing. In most cases the network is a great way to get an idea of where to focus more attention, or what hosts might need to be examined. This is especially true in the case of exfiltration.
PowerShell User Agent Strings
Certain PowerShell actions should stand out among others. One less-than-normal behavior is to see PowerShell making web requests, or even worse, uploading data via HTTP. As an easy starting point, the first technique that can be leveraged is a search for user-agent (UA) strings that line up to the default PowerShell UA. The default can be observed in Figure 1. A good start, but not foolproof. Since version 3.0, there is an option to easily change the default UA to camouflage its identity.
Figure 1. The default UA string for PowerShell
Frequency Analysis
Since the user-agent is not a reliable indicator alone, Frequency Analysis (FA) can be used to help visualize automated data leakage. In its simplest form, Frequency Analysis illustrates how often a particular set of methods show up and if they seem to be recurring. In this case, the consistent and periodic use of the HTTP PUT method is the primary indicator that will narrow the focus of the hunt.
POST vs PUT
So why not search for POST data, professor? There lies a distinguishing factor between the two. According to the RESTFul API, “POST can be used to add a child resource under a resources collection.” PUT is used “to modify a singular resource which is already a part of resources collection.” Confusing, yes, but in my simplistic mind, PUT is more synonymous with uploading an entire file (think cloud file hosting provider).
Got One!
Taking this knowledge and applying it to the hunt can reveal some interesting results. In this case, we can begin our hunt with a suspect PowerShell user-agent, figure 2, at which point we can pivot into connections and detections as can be seen in figure 3. Leveraging FA in combination with the beacon and exfiltration alerts narrows down the misbehaving traffic easily. Figure 4 illustrates the consistent traffic.
Figure 2. The PowerShell UA Found in HTTP Traffic
Figure 3. Connections and Detections from Initial UA Discovery
Figure 4. FA Showing a Consistent Beacon Every Two Hours.
An observation based off of the links and alerts: the beacon might also be the same traffic used to exfiltrate data from the environment. Now it’s time to take a look at the host!
Conclusion
Whether your organization is responding to the fallout of a news worthy breach, or simply formulating a hypothesis, a little direction and thought can yield a viable means to start hunting. Each environment is different, so it takes knowledge of what is normal and what is not. Additionally, knowing the lay of the land can help give a hunter the variables that might be in play. For this example, PowerShell was suspected as behaving oddly as compared to the other traffic in the environment. In part II of this blog installment, we will dive into the source of this traffic to see what might be happening at the host level.
Photo:Stiki
