Our Threat Research Team was curious to see how far STRIEGO could go in defending against some serious threats. The only way to test that was to see what it did when pushed against its limits.

So, instead of running an exploit and calling it a day, they built a custom attack chain (just like how real-world attackers do) and put STRIEGO against it.

Through this blog, we will see how real-world zero-day attacks happen and how STRIEGO not just fights back but also defeats them.

Our goal behind the exercise was simple – when an attacker uses a system’s own guardrails against it, STRIEGO still sees it.

Disclaimer: This was a live-simulation exercise conducted within SharkStriker’s controlled lab environment by our research team. It was done strictly for research purposes. It is not a how-to guide and does not intend to target anything (production, third-party system, etc.). Reproducing these techniques against any system not owned by you without authorization to test is illegal.

The RedSun zero-day

Imagine a burglar trying to get into a home. But this isn’t just a regular burglar who picks the lock, he is a sly one. He fools the security system to unlock the door for him.

This is the logic of a TOCTOU or time-of-check/time-of-use attack. Before it was patched by Microsoft, the RedSun zero-day was exploited by attackers globally to carry out TOCTOU attacks.

RedSun was originally released as a public proof-of-concept by an independent researcher and was later formalized and patched by Microsoft (CVE-2026-41091).

Our simulation exercise centered around RedSun. Our threat team built a bespoke attack chain using a custom dropper, a custom C2 implant, and a unique staging sequence that replicates modern attackers.

Our custom attack chain, stage-by-stage

Stage 1 – A quiet foothold: Initial Access

Every attack starts with something that seems ordinary. Ours started with an email.

We crafted a phishing message that seemed like a daily business communication. Something that is normal for an employee who checks email throughout the day. When the target opened the attachment, it executed our custom dropper, silently in the background, without raising any warnings or alarms.

Stage 2 – Going invisible: Execution and defense evasion

Getting in was just the first half, staying undetected was the second half.

Once the dropper ran, our first priority was making the entire operation undetectable. We obfuscated the code so antivirus scanners saw it like normal software behavior, nothing unusual in its instruction pattern.

Next our custom loader pulled the beacon then removed the Mark-of-the-Web tag from the downloaded file so Windows treats it as a trusted local file. When windows sees this tag it knows the file came from the internet and it treats it with suspicion. So without the tag, the file was just something that was treated with same trust level as something that already is on the system. The next thing was creating exclusions for specific script files in the Defender that would allow the payload to operate freely without getting caught.

Stage 3 – Seven ways back in: Establishing persistence

We made multiple ways back in because we knew that a single foothold might be susceptible to Defender catching us.

At every login, the Registry run keys made the chain restart automatically.

A scheduled task hid itself behind a Microsoft Edge update.

We hijacked the Image File Execution option to help us get back on Windows’ own accessibility tools.

A Windows Management Instrumentation subscription fired a re-trigger every 300 seconds via a __EventFilter consumer subscription.

A Windows service ran silently in the background.

COM and shell-open hijacks quietly rewired how the operating system handles common file types, so that even if a cleanup swept everything else away, we were back the next time the user opens a document.

We did all this because that is what attackers do. They build a chain that is resilient enough to survive remediation.

Stage 4 – Aiming our gun while the Defender pulls the trigger: Privilege escalation

To get full control of the user account from standard user account control, we used the RedSun technique that exploits the timing flaw in Microsoft Defender without triggering detection.

Security tools follow a sequence: they verify first whether a file is safe and then perform the operation. RedSun lives in the gap between the two steps.

Think of it like a logistics center. A package arrives, gets checked at the front desk, and is cleared for delivery. In the moment between the clerk stamping it safe and the courier picking it up, someone swaps the delivery address. The courier doesn’t re-check, so it gets delivered to a new address without raising suspicion.

We placed a bait file in the system and registered it through Windows’ Cloud Files API – enough to raise the eyebrow of Defender and trigger remediation. When Defender moved to act on it, we used the opportunity to freeze Defender’s operation for a fraction of a second (long enough to change the delivery address). The filesystem junction (a feature that performs path redirection in Windows) pointed Defender away to a System32 location instead of its intended target.

The payload was then picked up by a Service Control Manager call routed through a COM class invocation — Windows started it as a service, at SYSTEM privilege, completing the escalation.

After that fraction window, Defender woke up, saw a file that was approved, and completed the write to a location only the operating system can touch.

We aimed the gun and the Defender pulled the trigger.

Command-and-control followed immediately. Our custom implant established an encrypted HTTPS connection back to us. It was routed through a Cloudflare tunnel, so all any network monitor could see was ordinary web traffic to an unremarkable domain. Behind that cover, we had a full interactive shell into the machine using AdaptixC2, an open-source post-exploitation framework that has seen real adoption among ransomware operators. We had full, hidden, interactive control.

Stage 5 – Misson successful: Target compromised

From the outside, it looked normal. There were no alerts, no crashes, nothing on the user’s screen. But behind the screen, every mechanism we established was running at the highest privilege level, immune to standard cleanup. There were seven mechanisms, so even if the user reboots or changes their password, we would still be inside their system.

How STRIEGO detected and blocked the zero-day attack?

STRIEGO didn’t need a signature to catch our custom dropper, scripts, or implants. It acted based on a pattern it detected in hidden script launch, security tool tampering, suspicious service installs running as LocalSystem, a file-association rewrite, and a beacon to a throwaway tunnel domain.

It correlated all the happenings into a single incident story and a confident alert that can be acted upon.

It did what OS couldn’t – blocking the malicious actions, isolating the host, and remediating with 24/7 SOC at each step, ensuring the right action.

STRIEGO didn’t work at one moment. It worked at multiple stages of the kill chain. To explain how, we will use an example of a bank heist with STRIEGO playing the role of the bank’s security system.

Stage 2 (Evasion)

STRIEGO flagged the Add-MpPreference exclusion creation for the script files immediately. Tampering with Defender’s exclusion list is a high-confidence behavioral signal regardless of what files are being excluded. This was the first event in the correlated incident.

Tampering with Defender’s exclusion list is a big red flag, regardless of what the excluded files are. STRIEGO immediately detected and flagged the Add-MpPreference exclusion creation for script files. The first behavioral signal in the entire incident story.

Simpler explanation

The first step a thief takes before doing anything is to disable the security control to stop surveillance of specific routes he will take. It doesn’t matter what he will carry through those routes. The act of reaching a security system itself is an alarm. The security system doesn’t wait for the thief to make his next move and flags the attempt itself. The very first flag of the whole incident.

Stage 3 (Persistence)

Four detections fired in quick succession:

• PowerShell launched with -WindowStyle Hidden -ExecutionPolicy Bypass -NonInteractive from a user-writable path — a strong execution anomaly.
• File-association hijack: the txtfile\shell\open\command registry key rewritten to point at wscript.exe running a VBScript — caught immediately.
• COM CLSID re-registration to a non-standard binary — flagged.
• Windows Event ID 4697: a new service named WinDefenderHealth installed with auto-start, LocalSystem privilege, and a script-host command line – one of the clearest signals in the chain. STRIEGO flagged it as both a suspicious service install and a masked service name (Defender-lookalike, non-Microsoft binary).

Simpler explanation

The thief tries to create multiple pathways so he can return anytime. And the security system flags every one of them while the attempt is made.

• He slips in through the maintenance door instead of the front entrance, using a uniform of a maintenance personnel to move quietly (PowerShell from a user-writable path) – Flagged!
• He rewrites the instructions at the front desk “if lost, send it to office” so the specific type of paperwork goes to his office instead of the security team’s (txtfile shell hijack redirecting to the script host) – Flagged!
• He swaps the internal phone routing directory so calls get forwarded to his own line (the COM CLSID re-registration) – Flagged!
• He forges an employee badge for a fake building maintenance inspector for full anytime access without raising any alarm (The LocalSystem, auto-start WinDefenderHealth) – Both flagged!

Stage 4 (Privilege escalation)

STRIEGO detected the oplock pattern on files inside protected directories, and the key one  MpEng.exe (the Defender engine process) writing a binary into %SystemRoot%\System32, combined with a filesystem junction pointing from a user-writable path into System32. That combination - the AV engine itself writing to System32 via a junction is the fingerprint of an AV-coerced write, and STRIEGO caught it before the service was started.

Simpler explanation

The thief can’t get into the vault himself, so he plans to trick the vault’s own security system into getting access to the vault. But the security system finds that something fishy is going on and blocks the thief before he can make his move.

Stage 5 (C2)

Outbound HTTPS beacon to a Cloudflare tunnel domain was flagged as anomalous C2 traffic.

Simpler explanation

To call his driver waiting outside, the thief uses a legitimate phone line that the bank uses to communicate with customers (the HTTP beacon riding through the Cloudflare tunnel). The bank system notices that the call is being made at an odd hour and flags it.

We built a custom attack chain like the most sophisticated attackers out there to test how STRIEGO does. We built not one but seven ways back in but STRIEGO needed only one thing to stop all of them. It flagged them all at not one, but at every stage of our attempt.

The entire exercise proved that STRIEGO can help organizations detect and fend off advanced threats like RedSun zero-day attack with its ability to find a pattern among suspicious behaviors, flagging them before the real execution of the attack even happens.

Paired with MDR, it offers a powerful combination of a 24/7 SOC and technological prowess that organizations need to not just stop threats but also predict and prevent them.