BSides Cape Town 2025

From Clone to Cloak: Bypassing EDR with Open-Source Tooling
2025-12-06 , Track 3

Modern Endpoint Detection and Response (EDR) solutions present one of the toughest challenges for red teamers and offensive tool developers. This talk showcases a methodology used to adapt an open-source shellcode loader to bypass a modern EDR solution. Rather than showcasing a novel evasion technique destined to be signatured, the focus is on a reproducible approach to evading both static and behavioural detections.

Attendees will gain insight into the full chain of the bypass methodology:
* Identifying static signatures on disk
* Modifying loader behaviour to evade runtime detection
* Iterative testing and validation
* Applying this workflow to other public offensive tooling


Description

This talk will take the attendees through the methodology I undertook in previously getting Shhhloader (https://github.com/icyguider/Shhhloader), an open-source shellcode loader, to bypass the Microsoft Defender for Endpoint (MDE) EDR solution, and load a piece of malware that establishes Command and Control (C2) communications. Whilst the modifications to Shhhloader have since been signatured and are unable to bypass MDE, the methodology itself is reproducible and can be applied for most offensive open-source tooling.

The basics: EDR and detections

The talk will begin by establishing a baseline. I'll quickly run through what an EDR is, and its role in a security stack. Following that I will talk about the types of detections that are made by EDR solutions and anti-viruses and what they are detecting on. This section will be a short baseline so that everyone understands the key concepts and acronyms we will be talking about.

Getting on disk: Bypassing static detections

As is always the case with popular offensive open-source tooling, if you just download, compile and use the software, it will almost always get flagged by any good AV or EDR solutions. The reason being is that there are signatured strings within the code that are getting identified by the security product. This section of the talk will walk the attendees through the iterative process of identifying these strings, modifying them, and re-compiling the code to test if we can bypass the static detections. This will be illustrated with the static strings I found in Shhhloader that were signatured and some of the trial and error I did to get past these static detections to get my malware on disk.

Getting into memory: Bypassing the EDR

Once we are on disk, we need to get execution of the malware working. This section is a bit more of a technical deep dive into how Windows works so we'll start out with explaining a bit more about Windows, system calls, shellcode, and assembly, however still relatively high-level so as to not lose the audience in the details. We're tackling this now so that it is fresh in the attendees minds as we dive into Windows.

This malware (and many others) made use of direct system calls built using other open-source tooling called SysWhispers (https://github.com/klezVirus/SysWhispers3), similarly to ShhhLoader the default version of SysWhispers is well-known and subsequently well-signatured. However, when dealing with EDR solutions we need to consider more than signature, we also need to consider the behaviour of our system calls as well. We will go through how it was identified that Syswhispers was the portion getting detected and then how we changed the behaviour and signature of the system calls to bypass the EDR solution and get malware to execute and establish C2 communications. As with the previous section, this will be illustrated with code snippets of the actions I performed and focus on the methodology of how this was performed.

Getting Detected: Building defences

To close off, I'll highlight that this methodology can be applied to most offensive security tooling to bypass EDR solutions. I'll also talk about the ever-evolving "cat and mouse" game exhibited with offensive and defensive security tooling, and how blue team tooling suites are built based-off of offensive security techniques and tooling.

Key Takeaways

  • Methodology over tools: The real value is not the specific Shhhloader or SysWhispers modifications (which are now signatured), but the reproducible process of analysing detections, testing iteratively, and adapting until a new bypass is achieved.
  • Detection is never the end: Sooner or later, defences will catch up. The methodology shown gives red teamers a repeatable approach for identifying new detections and reworking tooling to regain execution. After all, blue team tools and detection rules are built off the back of offensive tooling.
  • Big picture: The talk highlights a realistic offensive development workflow. The iterative testing, focusing on methodology, and understanding both the static and behavioural layers of modern endpoint defences.

I am a computer engineer who is a self-motivated and disciplined individual impassioned by cybersecurity and technology. I'm a hard worker and willing to go the extra mile because I am ambitious, eager to succeed and always enthusiastic to learn. I take pride in what I do and see myself as being conscientious and diligent, with a good work ethic. I am proactive, innovative and "think outside the box".

I have a passion for performing red team exercises, namely simulating real-world advanced cyberattacks where I can employ the latest tactics, techniques and procedures to execute on attacker goals whilst remaining undetected; with the aim of identifying security weaknesses and areas where change can be implemented to enhance security practices.