Chapter 9: The Reverse Card: Weaponizing IOCs and OSINT for Defense
In every previous chapter of this book, we've looked at analyzing malware from both static and dynamic perspectives. The entire point of the analysis of adversarial software is to gather intelligence on an adversary's operations and find the fingerprints they may leave on a network, machine, or file.
However, simply gathering the information is not enough if we do not endeavor to make use of information our hard-fought analysis has uncovered. While, as analysts, we may not often be responsible for the implementation of these defenses, having the knowledge of how they may be implemented may assist us with knowing what will be of value to uncover during our analysis.
Let's take a look at some of the common uses of the Indicators of Compromise (IOCs) we have already been able to uncover, and how they may be of use to prevent further instances of attack by the same adversary. In this chapter, we'll examine the following:
- Hashing prevention
- Behavioral prevention
- Network IOCs – blocking at the perimeter
- Common tooling for IOC-based prevention
You'll also have an opportunity to collect some useful IOCs in a real-world sample of malware at the end of the chapter that may be useful for network defense!
Technical requirements
The following is the only technical requirement for this chapter:
- An internet connection
Hashing prevention
Perhaps the most common IOC collected by malware analysts, file hashes in MD5, SHA256, and SSDEEP are the fingerprints of files we've previously discussed during static analysis.
While even one bit being changed will alter the entirety of a standard, static cryptographic hash, oftentimes a single hash or small subset of hashes is utilized in any given attack, and being able to quickly blacklist and prevent the execution of these can greatly hinder an attack and buy necessary time to implement better preventative controls, or enable the IR team to find the point of ingress and close it off.
Thankfully, there are several ways we can implement hash-based blocking very quickly and efficaciously across an environment.
Blocking hash execution with Group Policy
Previously in the world of Windows, the primary way to block the execution of files was only via their filename. Within the world of adversarial tools such as Cobalt Strike and Metasploit, however, payload names are often randomly generated – even in tools that simply rely on passing the hash to execute a file, making this a poor choice.
However, Group Policy Objects (GPOs), introduced in Windows Server 2008, allow blocking by SHA256 hash, Zone, Path, or Certificate! Let's walk through the process of blacklisting a hash via GPO on Windows Server 2019.
The first step we need to take is to open the Group Policy Management Console on our Windows Server instance:
Figure 9.1 – The default page for Group Policy editing
Once opened, we can create a new Group Policy by right-clicking our domain and selecting Create a GPO in this domain, and Link it here…:
Figure 9.2 – Creating a new GPO within our domain
From here, we can name our new GPO, and selecting OK within the UI will create the new Group Policy object as we have specified:
Figure 9.3 – Naming our new GPO
Once the object is created, right-clicking the new object and selecting Edit will open the Settings pane – where we can select what we'd like to enforce via the new Group Policy object:
Figure 9.4 – Configuring the Group Policy object
From here, we'll navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Software Restrictions > Additional Rules. From this point, we can right-click within the window and select New Hash Rule:
Figure 9.5 – Creating a new, hash-based rule for our GPO
You'll need a copy of the file on disk to browse to, and select utilizing the menu. You can also select whether you'd like to explicitly disallow or allow the hash of the binary in question:
Figure 9.6 – Applying the hash rule by browsing to the offending file
Analysis tip
While we're focused on hash-based blocking here, that's certainly not the only good option within this Group Policy object. Blocking on a certificate or file path is also a valid option, and using each one in combination with the others may be the best bet if you're utilizing the GPO to this end.
With this applied, after the GPO is applied to the correct groups (this will differ based on each implementation of Active Directory and your specific situation) and they receive the requisite Group Policy update, the hash will be disallowed from executing by Windows, and will present the end user with a message indicating this!
Figure 9.7 – The message presented to end users when execution is denied
Windows GPO is great, but it is not the only option. Let's take a look at a few more methodologies that may be utilized.
Other methodologies
While Windows GPO is free and built into most environments that we will be defending as an analyst, it certainly is not the only option, and is not even the best option.
Generally speaking, the best options are going to be built into enterprise Endpoint Detection and Response (EDR) software such as CrowdStrike Falcon, Microsoft Defender ATP, and any other EDR solution worth its salt.
Feature parity varies greatly between solutions, however, blocking by SHA256 is certainly the most common feature that is present within these solutions, though some even allow blocking by similarity to SSDEEP fuzzy hashes – an incredibly useful technique to have access to give the prevalence of hashbusting malware samples in recent years.
However, hashing – be it static or otherwise – is not the only way to prevent execution. Let's take a look at how files may be prevented from executing from a behavioral standpoint.
Behavioral prevention
Behavioral or heuristic protection is often the stuff of EDR or AV platforms. Most platforms of this nature operate on a heuristic basis and utilize key MITRE ATT&CK tactics and techniques leveraged by real-world adversaries in order to prevent the execution of malicious commands, files, or techniques. For the sake of this discussion, we'll focus on command-line style behaviors for the sake of simplicity – things such as calling mshta.exe to open malicious HTA files or calling binaries from SMB shares.
Frequently, a well-built EDR solution is going to be irreplaceable in correctly and properly blocking behavioral-based techniques utilized by adversaries. However, this is not the only methodology available to us at a pinch.
Binary and shell-based blocking
In the Unix world, the proper way to achieve something of this nature is via the use of something like rsh – a restricted shell that allows us to basically "jail" our users and only allow the user to run a pre-determined set of commands, preventing the enumeration or execution of binaries that haven't been explicitly previously allowed. For further reading on the subject, an excellent article on restricted shells exists on Wikipedia at https://en.wikipedia.org/wiki/Restricted_shell.
Within the *nix world, this is likely the best way to achieve the prevention of unauthorized behaviors, by utilizing a loosely restricted shell from default, and then restricting as is necessary based on either job role, or IOCs that we have collected or have been identified by ourselves or other analysts.
However, most threats are not, in fact, within the *nix world, and exist within the wide world of Windows. To create the same sort of efficacy within Windows, we can utilize the same GPOs that we've previously utilized. First, let's clarify a couple of points about the Command Prompt in Windows.
Within the command prompt, there are two kinds of commands:
- Internal commands
- External commands
Internal commands are commands that are built directly into Command Prompt – such as cd. These do not call an external executable to perform their functions. The vast majority of commands within Command Prompt, however, fall into the second category – these DO call an external executable to perform their actions. These are things such as nslookup, mshta, robocopy, and so on.
Figure 9.8 – Blocking execution based on filename
While we cannot block internal commands, thankfully, most adversarial behavior relies on external commands. Utilizing the same GPOs that we've utilized before, only utilizing file pathing, we can block the execution of commonly utilized executables for malicious behavior, such as mshta.exe or even powershell.exe (though the latter may not be a great idea):
Figure 9.9 – Blocking execution with wildcards to limit SMB execution
We can also do some clever wildcarding here, and block something such as \*, which will disallow all binaries from executing from network shares – a common adversarial technique in order to execute payloads on hosts remotely. While this will not stop a determined attacker, it is certainly well within bounds to create a rule such as this to slow adversarial behavior within an environment:
Figure 9.10 – Blocked execution within Command Prompt
Additionally, we can utilize network zones to prevent execution in similar ways – though any adversary worth contending with will be sure to strip network zone information from their payload.
Network-based behaviors
Obviously, blocking the execution of binaries isn't the only control we have that can help control the flow of an adversary and turn the tide in our favor. We can also utilize Windows Firewall rules to help prevent lateral movement within our environment.
Some of the most common methodologies for lateral movement involve utilizing the abilities of Window's implementation of Server Message Block. Utilizing something such as Windows Firewall GPOs to limit the ability of workstations to talk to each other utilizing this protocol will severely hinder an adversary's ability to move laterally within a network.
Figure 9.11 – Blocking internal, inbound SMB traffic to workstations
To do so, we can navigate to Computer Configuration > Windows Settings > Security Settings > Windows Firewall and create a rule that blocks TCP on ports 139 and 445 inbound to our hosts and apply this to the requisite workstations group.
Certainly, within a domain, operation considerations apply, and SMB is used for legitimate purposes just as much as it is used for adversarial behavior.
A precursor to applying any of these rules is having well-defined and maintained groups within Active Directory and a clear understanding of the environment being administered – often a separate discipline from our role as analysts.
The endpoint is not the only place that network-based IOCs can be blocked, however. Let's take a look at perhaps the best place to block malicious network traffic: the perimeter.
Network IOCs – blocking at the perimeter
Some of the most powerful IOCs we uncover as analysts are those that are network-based. FQDNs, IPs, and other network-bound indicators are often utilized to control malware, attack machines, or download secondary stages that often contain the code meant to perform actions on objectives on our network – be that ransomware or otherwise.
The best solution we have to acting on these IOCs is certainly to block them at the network perimeter – at the egress point where the workstation attempts to call out to the known malicious IP, drop the packet, and pass the event to the SIEM stack to log and alert the SOC accordingly.
However, there are also considerations that we can take on workstations themselves via Group Policy or server configuration.
One of the ways we could go about this is to manually block outbound connections to the IP via the same firewall configuration tool that we utilized in the previous section. However, to do this is fairly flimsy, as it's often a negligible amount of work for a threat actor to change the IP to which their FQDN points, rendering your firewall rule entirely pointless once it's discovered.
Figure 9.12 – Leveraging DNS to block malicious sites with DNAME records
Another way we could go about this is manually creating DNS DNAME entries for known-malicious domains within our internal DNS servers that simply point back to a known-good site – and also disallowing our internal machines from sending DNS traffic outbound to any other DNS servers but those under our purview.
Common tooling for IOC-based blocking
In this section, we'll discuss and list out some of the common tooling we've used. While this book also endeavors to be vendor-agnostic and to not recommend specific EDR products, we'll also list out a few of those that are in common use and include the ability to block custom indicators of compromise.
File-based IOCs:
- Group Policy
- EDR tooling
Network-based IOCs:
- Firewalls (Cisco, Juniper, SonicWALL, Fortigate, and so on; host-based firewalls)
- DNS server configurations
- IPSec rules (inbound traffic – RDP, specifically)
- EDR tooling
- Group Policy
EDR tooling:
- CrowdStrike Falcon
- Microsoft Defender ATP
- VMWare Carbon Black
- Qualys Vulnerability Management Platform
- Many more…
Obviously, in authoring this book I have biases, and it is important to do one's due diligence and select the platform that is the best fit for the organization and will provide the optimal level of security that balances with operational needs.
However, each of the EDR platforms named does, to some degree, offer the implementation of custom indicators of compromise collected by internal or external analysts in order to attempt to slow or stop a currently ongoing incident.
There are in-built ways in which we may manage and control an active threat-actor within our environment, but largely, these tools will be the best long-term solution for ensuring the security of the environment and actively learning based on past incidents or compromises.
Challenge
For this challenge, we'll see if we can collect some IOCs for an increasingly common piece of malware – a CoinMiner. Utilizing your own research, attempt to answer the following:
Recently, a security firm (Intezer) identified a Monero-mining campaign utilizing exposed Oracle WebLogic (amongst other vulnerabilities) to install coin-mining software on Linux and Windows machines.
- What file-based IOCs can you identify?
a. What controls would you put in place for a Windows host to prevent this execution?
b. What controls would you put in place for Linux servers?
- What network-based IOCs can you identify?
a. Which is going to be more effective to block? FQDNs or IPs?
b. What controls would you implement for Windows? What about Linux?
Summary
In this chapter, we've discussed several ways that we may put the IOCs we have painstakingly collected in previous chapters to use, and leverage these to prevent further incidents within our environment – or simply create chokepoints for the adversary and address them as the Spartans did to the Persians at the gates of Thermopylae, though hopefully with a modicum more success.
We've reviewed ways we can utilize the power of in-built Windows tools such as Group Policy or Active Directory's in-built DNS mechanisms in order to limit the adversary's reach to download secondary payloads, execute files, or move laterally within the network.
We have also established that while these methodologies exist, perhaps the best methodology possible for implementing IOCs in the most effective way possible is to utilize a purpose-built piece of software, as is often the case with tools of one's trade.
In the next chapter, we'll take a look at taking the IOCs we've uncovered and implemented these changes for in a bit more depth. We'll learn how to map them to MITRE's ATT&CK framework, and how to build an effective report utilizing them.