Defending Security Infrastructure Against Wild Weasels

In the 1960s the United States came up with a plan to deal with advanced anti-aircraft Surface to Air Missiles (SAMs) present in Vietnam: They'd equip a jet with anti-radiation missiles, then have them fly into defended airspace to deliberately try to get shot down. The hope was that the plane would be able to fire their missiles to destroy the SAM radar stations before they were hit. The crews that performed this feat were called Wild Weasels.

Today, we are seeing Wild Weasel tactics being used against security infrastructure.

Weasels Targeting Security Infrastructure

The military strategy of Wild Weasels, which involves probing and then destroying enemy defenses, mirrors modern cyberattack techniques. Historically, this activity has been against Windows-based security tools, but today the spotlight is shifting to Linux in various ways:

• Deploying malware packages that uninstall Linux anti-virus.

• Disabling security measures like SELinux, firewalls, and auditd.

• Disabling or using stealth rootkits to evade Linux EDR agents.

• Attacking embedded Linux edge devices that can't use traditional monitoring.

Moreover, attackers don’t just stop at disabling security tools. They test the waters, seeking reactions from incident responders to inform their broader assault on infrastructure.

Security Infrastructure Disabling Attacks are Common

Contrary to belief, neutralizing security tools isn't just the domain of elite hackers. Such practices have surfaced in ordinary cryptominers, and even our open-source tools have been targeted. One prominent example from a few years back is a Docker-enabled malware sample that targeted security controls on Linux. This kind of activity is very common today.

This provides a textbook example of automated malware targeting Linux as it attempted to:

• Disable our free file and process entropy scanner.

• Neutralize the clamav anti-virus scanner and any active SELinux controls.

• Flush firewall rules, ensuring open system access.

We take some pride in being targeted, echoing the sentiment: "The flak is heaviest when you're over the target." But beyond our tools, these attacks on Linux serve as a real-world reminder: security infrastructure remains under threat.

Defending Against Weasels

At Sandfly, we anticipated attackers aiming at security infrastructure and have engineered countermeasures for anti-evasion and defense. Although we are discussing our own product in these examples, it may be worth thinking how you can deploy similar tactics for other tooling you use for cyber defense.

Appear Unmonitored

Sandfly does not leave a permanently running endpoint agent on any host it protects. The host in fact appears unmonitored at first blush. This tactic invites attackers to let their guard down, only to be caught off-guard.

Going further, combined with standard AV and EDR agents, the tactic amplifies effectiveness. Attackers disabling AV/EDR tools can be taken by complete surprise when an out-of-band Sandfly sweep shows up to threat hunt on a Linux host. The appearance suddenly of another tool they didn't expect can seriously impact operations.

Concealing Infrastructure with SSH Jump Hosts

Shield your security infrastructure by operating it on protected network segments. With Sandfly, you can use single or multi-jump SSH proxies, not just for convenience but also for hiding your infrastructure's origin.

Consider these two use cases:

1) Hiding the location of Sandfly scanning nodes with a single SSH jump host as a proxy.

2) Creating a virtual Tor network with multi-jump SSH proxies.

Let's discuss these two applications.

Single Jump SSH Proxy

The simplest way to hide Sandfly infrastructure is to use a single SSH jump host. The jump host just needs to be scaled to handle the SSH connections if you have many hosts. Sandfly will use this jump host for all outbound connections from each scanning node. Attackers on remote systems will see the IP address of the jump host and not that of the scanning node itself. You can rotate the SSH jump host addresses as often as you like.

Adding a jump host is straightforward. Give Sandfly a name for the jump host, an address or hostname, credential, and SSH port. After that, when you add hosts just pick the single jump host to use.

Multi-Jump SSH Proxy

The next step up in concealing your infrastructure is to build a virtual Tor network of sorts using SSH jump hosts.

This works because Sandfly allows you to string together up to 10 SSH jump hosts. Sandfly will connect to these systems in the order given before connecting to the final destination. Below is what this looks like architecturally.

In a real-world example we were assisting a customer with an incident and we wanted to scan the boxes but not leave anything to chance that infrastructure leakage would occur. To prevent this we spun up multiple inexpensive cloud systems as our SSH jumps and did the investigations. After we were done, it was simple to destroy the SSH jumps and there is no chance the attacker will work out where the scans originated.

Doing multi-hops inside Sandfly is easy. Just setup your jump hosts like normal with different names. When you are ready to use them simply add your hosts and use the drop down to select them in order you want.

Innocent Binary Names

Next, let's take a page from the "If you can't beat em', join em'" playbook. Linux malware has used process name masquerading for years to hide from admins. Malware names appear innocent in process listings (e.g. systemd) and it's often enough to avoid notice from casual observation.

This is a fine tactic and Sandfly can be easily configured to run under a different binary name on the remote system it is scanning as well. This will hide Sandfly's presence from attackers looking for specific binary names to evade. The default name used is "sandfly", but customers can change it easily under the Server Configuration page like below:

In the above example, each time Sandfly connects to a host we will select one of these bogus names at random. The binary will be run under that name on the remote system making potential detection and evasion harder for attackers.

Most recon scripts look for known vendor names running in the process list to alert the intruder to their presence. Simply changing the name of the binary they run under is often enough to cause these scripts to fail to identify any monitoring happening.

Generic Users

Sandfly uses SSH credentials to log into systems. These users can be anything customers want to call them. We recommend not calling the user "sandfly" or even anything related to admin or security. Give the user a generic sounding name unrelated to the actual task. This is also a good idea to follow for any security related accounts on systems.

Random Security Sweep Schedules

Security tooling on Linux can often present a scheduled time that attackers know to avoid. For instance the 4AM full disk anti-virus or Yara sweep for malware can be made so that at 03:59 the malware goes into a shutdown mode that hides.

One favorite red team backdoor we've seen inserted a user at 03:00 into the /etc/passwd file and then removed them again at 03:30. This of course provided a short window for unauthorized access while appearing clean for the rest of the day.

Randomized sweeps combat such tactics and also reduce system strain. Instead of one intensive malware scan, distributed mini-sweeps throughout the day are less taxing on the system and never leave large periods of time when systems are not being checked.

Random schedules are built in to Sandfly. The default of 60-120 minutes in the image below means that every 1-2 hours we'll pick a random time to scan a system and random threat hunting modules. After the scan a new time 1-2 hours in the future is picked again with another random selection of threat hunting modules. Time limits can be shortened or lengthened depending on customer needs.

Random sweeps prevent evasion, gives better performance, and have deeper coverage of threats.

Killing Wild Weasels

Strategies of probing and disabling defenses have ancient roots. As we face an increase in these evasion tactics on Linux, it’s essential to leverage the features and strategies offered by tools like Sandfly to safeguard networks against these Wild Weasel methods.