Introduction

Threat Actors and malware developers need to protect their intellectual property just as much as benign software vendors. Every Cybersecurity professional who worked with malware samples will also know, that such a protection employed helps adversaries morph/mutate how their malicious artifacts look & feel under the hood, eventually evading signatured detection.

Executable protectors, obfuscators, encoders, packers/compressors, virtualizers – are all specialized software attempting to manipulate input artifacts, producing output with often altered code layout and contents. Sometimes for file size reduction purposes, other time to fend off reverse engineers aiming to disclose their technology & implementation details.

Malware samples used to employ all kinds of packers and protectors since years by now (raise your hand if you ever hunted for y0da protector OEP 👾). What differentiates advanced Threat Actors from unexperienced ones is how fast their cyber weaponry becomes traceable based on simple static detection signaturing.

As a Red Teamer, I observe surging trend of detection Use Cases (in SIEMs of customers I’ve worked with) and open-source signatures producing detections that are easily evadeable.

Blatantly borrowed from Will Schroeder
Hunting for Twitter handles
Hunting for command line parameters
Source: Red Siege – Bypassing Signature-Based AV

Threat detection based on filenames, existence of offensive experts’ Twitter handles in executables or Powershell scripts, easily replaceable strings or even what happened to me personally (banning email address based on my contributions on Github) – constitute evasion potential, making signatures prone to false-negatives. Such a detection engineering approach might not be effective as soon as implementation of covered TTP changes. Consider all these signatures hunting mimikatz by the presence of gentilkiwi inside and how they became obsoleted when offensive community switched to Rubeus.

Someone might even argue it looks like taking shortcuts focusing on detecting Red Teams instead of threats they’re emulating.

Why do Red Teams fell into such trival traps?

Adversary Emulation gigs are quite expensive as they entail team of highly specialized individuals involved in numerous operational activities. Most of them require special care for OPSEC considerations. In the middle of exercise’s heat it can get easy to forget about applying a single evasion that could protect Red Team from not leaving obvious traces such as command-line parameter names.

Red Teams do OPSEC failures too.

Sometimes due to workload they’re under, maybe lack of experience, other times because of the time-pressure (imagine burden of changing strings and recompiling all the tools RT typically use if they don’t have Offensive CI/CD in place).

So with the release of this OST tooling, I strive to increase technical prowess of fellow Red Teams at spreading the knowledge among our cyber-defence colleagues on how important it is to aim for high-fidelity signatures rooted in strong signals.

From fellow Red Teamer with Love

🔵 Blue Team wizards

Detection engineers, you young malware analysts who contribute 30+ signatures daily to your AVs – stop detecting Red Teamers, adding our Twitter handles, e-mail addresses or tool names to your rule collections. That doesn’t make the World any safer from meticulously prepared adversaries investing more resources into their OPSEC. Instead, we might be better off focusing on examining TTPs, what IOCs they emit, cherry-picking those hardly avoidable ones and using them to come up with cruel, definitive detections based on strong signals.

Following traits might be considered easily evadeable and therefore aren’t that effective as rule building blocks:

Example:
Instead of looking for kerberoast in monitored command lines, we could hunt for anomalous kerberos queries, events triggered in Domain Controllers. Such traits would serve hardly bypassable building blocks.

On the other hand, we can list set of traits giving much stronger evidences of ongoing malicious activity, easily captured by behavioral & network traffic feeds:

  • ETW Ti feeds exposing suspicious Windows API calls, such as opening LSASS handle, modifying/reading remote process memory
  • Network traffic anomalies, packet-level peculiarities
  • Suspicious VBA reserved words & functions extracted from Office Macros
  • Suspicious access to sensitive Files/Registry keys, such as Chrome cookies database
  • File format-specific anomalies: PE headers manipulation, dodgy VBA code
  • HIPS-styled behavioral rules triggering on uncommon system-wide activity patterns: running CPL/XLL files from Browser Downloads directory
  • Discrepancies in process Parent-Child hierarchy as captured by EDR during process creation compared to what is evident now

🔴 Dearest Red Team folks

Consider incorporating PE Packers/Protectors/Obfuscators into your Offensive CI/CD pipelines. If you don’t have Offensive CI/CD pipeline built yet, establishing one will be a great enhancement of your team’s collective operational capability.

Example of Offensive CI/CD Pipeline

Be responsible – watermark your samples for their tracking and back-correlation with previous engagements. Collect IOCs before each delivery. The ProtectMyTooling package includes RedWatermarker.py script to help you automate the process.

Use injected watermarks to maintain operational oversight & retrohunt in VirusTotal with content: “My Watermark” . That will help you stay alerted when Blue Team comes after your malwarezzzz.

ProtectMyTooling – What’s the fuss about?

I’m releasing a tool that amplifies the concept behind PE Packers/Protectors showcasing risks they’ve been posing for a long time now. That might alert whoever is not yet aware, of how easy for sophisticated Threat Actors is to slip through ineffectively designed STIXes/Sigma rules/YARAs and others.

It used to be accessible to my Github sponsors for the last several months. Now I’m releasing it to the public:

https://github.com/Binary-Offensive/ProtectMyTooling

A convenient multi-packer wrapper that easies the hassle for getting our payloads obfuscated without having us memorize all their parameters, adjust config XMLs, learn all that stuff for every packer over and over.

Generation of protected & obfuscated malware samples is now as easy as it can get, giving plethora of weak static signatures no chances and what’s more important – helping us, professional offensive engineers – spread the knowledge, teach defenders, reinforce current detections and influence signature engineering efforts by promoting higher-fidelity signals instead of hardcoding volatile string sequences.

ProtectMyTooling & ProtectMyToolingGUI

That’s the suspect we’re talking all about. It exposes us to the power of daisy-chained packers, protectors and shellcode loaders that we can exploit during Initial Acccess & Weaponisation stages. That will help increase Red Team chances as emulated adversaries and fly below the radar of shakeable detections, hopefully highlighting poorly designed ones.

Help our beloved customers experience and combat TTPs employed by advanced Threat Actors – known for their extreme attention to OPSEC.

Act responsibly – collect your implants IOCs, watermark them at every occassion and share your knowledge with Detection Experts.

Script can be conveniently used from command line, clicked through a cute GUI or even called out from within of a Cobalt Strike thanks to a companion aggressor script and dedicated commands exposed:

  • protected-upload
  • protected-execute-assembly

RedWatermarker.py

If your Red Team delivery process doesn’t mandate pre-setting implants with purposely injected IOCs, consider implementing that idea.

Watermarking helps Red Teams track their implants across Virus Total and other threat intelligence feeds, answer Blue Team questions “is that yours?” and correlate executables to previously held operations. If you never got time to come up with script that could automate that – now there’s no excuse 🙂 I deliver.

Simulation & presentation of backdoored executables is something, that used to catch eyes of inexperienced analysts I worked with. It’s a still actively abused vector for malware delivery and therefore should be modelled during adversary emulation exercises that Threat Actors are backdooring Putty.exe for long now.

RedBackdoorer.py

What’s cool about it (and I’m particularly happy of) is that it refreshes an oldschool malware execution trick known as TLS Callback. Some’ve heard, hardly one seen it actually weaponised. Herefore I deliver. Code emulation are prone to miss exotic malicious entrypoints, but fortunately – regardless of how virus acquired code execution, ultimately it’s still going to be a subject for behavioral triaging of any decent AV/EDR. Someday, however, I’m gonna challenge that claim too.

Conclusions

I believe wholeheartedly in improving World’s cyber-resilience by continuously raising the technical difficulty bar for real-world adversaries – and I follow my mission through what I think I can do best: sharing knowledge & code, consulting, testing.

At first, release of this potentially dangerous toolkit might look like acting on the contrary, however in the long run I’d like to impact the way we think about static signatures, scrutinize and challenge poorly designed ones, favoring focus on techniques detection instead of tools implementing them.