Serious Discussion AMSI and Defender’s script-based attacks protection

[RoboMan]

Hello all. Hope you're doing alright.

I’ve been doing some testing around AMSI and Defender’s real-time protection pipeline in Windows 11, and I’m trying to understand the depth of their integration beyond the documented AMSI interface.

Let’s assume a scenario where a PowerShell payload is sufficiently obfuscated or memory-patched to evade AMSI inspection. My question is:

-Does Defender still perform any post-execution telemetry or behavioral correlation on that script’s activity (memory scanning, kernel-level telemetry, or anything else)?
In other words, is there a secondary detection surface that analyzes PowerShell or WSH activity independently of AMSI, or does AMSI act as the primary and only content feed for script-based scanning within Defender?

-If AMSI is bypassed, does Defender still retain visibility through other subsystems (like Antimalware Service Executable hooks, cloud heuristics, or Defender’s behavioral engine), or does it effectively lose script-layer context until malicious behavior manifests at a later stage?

I’ve read the public AMSI and Defender integration docs, but they don’t fully clarify how far the real-time engine correlates telemetry from AMSI to behavioral analysis to memory scanning when the first stage fails.

I appreciate any insight on the subject.

Cheers

 

[Bot]

Hello all. Hope you're doing alright.

I’ve been doing some testing around AMSI and Defender’s real-time protection pipeline in Windows 11, and I’m trying to understand the depth of their integration beyond the documented AMSI interface.

Let’s assume a scenario where a PowerShell payload is sufficiently obfuscated or memory-patched to evade AMSI inspection. My question is:

-Does Defender still perform any post-execution telemetry or behavioral correlation on that script’s activity (memory scanning, kernel-level telemetry, or anything else)?
In other words, is there a secondary detection surface that analyzes PowerShell or WSH activity independently of AMSI, or does AMSI act as the primary and only content feed for script-based scanning within Defender?

-If AMSI is bypassed, does Defender still retain visibility through other subsystems (like Antimalware Service Executable hooks, cloud heuristics, or Defender’s behavioral engine), or does it effectively lose script-layer context until malicious behavior manifests at a later stage?

I’ve read the public AMSI and Defender integration docs, but they don’t fully clarify how far the real-time engine correlates telemetry from AMSI to behavioral analysis to memory scanning when the first stage fails.

I appreciate any insight on the subject.

Cheers

Hey RoboMan,

Hope you're doing well too! Sounds like you're diving deep into some interesting testing—always cool to see folks exploring the nitty-gritty of Windows security. I'll share what I know based on Microsoft's public docs and general knowledge of Defender's architecture, but keep in mind I'm not privy to any internal MSFT details, so this is all from documented behaviors and community insights. I'll aim to be factual without speculating on unconfirmed stuff.

On post-execution telemetry and behavioral correlation:
Yes, Defender does go beyond just the initial AMSI scan. AMSI is primarily a content-inspection hook for scripts (like PowerShell, VBScript via WSH, etc.) before they execute, feeding that data into Defender's real-time engine. But if a payload slips past AMSI—say, through heavy obfuscation or memory patching—Defender doesn't just give up. It has secondary layers that kick in post-execution:

- Behavioral monitoring: This is a big one. Defender's engine (via the Antimalware Service Executable, or MsMpEng.exe) watches for suspicious patterns in process behavior, like unusual file accesses, registry changes, network calls, or process injections. For PowerShell or WSH activity, it could flag things based on runtime telemetry, even if the script itself wasn't scanned upfront.
- Memory scanning: Defender periodically scans process memory for known malicious patterns or indicators. If your obfuscated payload ends up in memory and matches any signatures or heuristics, it could still get caught.
- Kernel-level telemetry: Through components like the Windows Defender System Guard or kernel-mode drivers, there's visibility into lower-level activities. This isn't script-specific but can correlate with overall system behavior.

In short, AMSI isn't the "only" feed—it's the primary one for script content, but Defender's real-time protection pipeline integrates it with broader behavioral analysis. If AMSI fails, the script might run, but any malicious actions could trigger detection via these other surfaces.

Visibility if AMSI is bypassed:
Defender retains a good amount of visibility through those subsystems you mentioned:
- Antimalware Service Executable hooks: MsMpEng has hooks into various Windows APIs and can monitor script interpreters (like powershell.exe) at runtime.
- Cloud heuristics: If real-time protection is enabled with cloud-delivered protection, telemetry from the script's behavior can be sent to Microsoft's cloud for analysis. This might not catch everything immediately but can lead to retroactive detections.
- Behavioral engine: This is key—it's designed to detect threats based on actions rather than just content. So, if the script doesn't do anything overtly malicious right away, it might fly under the radar initially. But once behavior manifests (e.g., dropping files, connecting to C2 servers), that's when these engines often step in.

That said, bypassing AMSI does reduce the initial "script-layer context," meaning Defender might not have the raw script content to analyze upfront. Detection then shifts to behavioral indicators, which are more about correlation over time. From what I've seen in testing and reports, this multi-layered approach is why full evasion often requires bypassing multiple components, not just AMSI.

If you're testing this in a controlled environment (like a VM), tools like Sysmon or ProcMon can help visualize some of that telemetry flow. Just be cautious—real-world evasion tactics can vary, and Microsoft updates Defender frequently to close gaps.

If you've got more details from your tests or specific scenarios, feel free to share—happy to brainstorm further!

Cheers!

 

[Trident]

Defender doesn’t rely only on AMSI, it also uses (at the very least) Event Tracing for Windows (ETW). When network protection is enabled, it can block connections to known malicious C&Cs.

When scripts drop files (which is not uncommon), Defender can detect these files.

Furthermore, Defender ASR rules can prevent execution of some scripts as well as macros in documents. This can deactivate the AMSI bypass.

All in all, there is quite a lot of protection besides AMSI but majority of it is not enabled by default.
Where applicable and supported, Defender also uses TDT to perform memory scanning.

 

[RoboMan]

Defender doesn’t rely only on AMSI, it also uses (at the very least) Event Tracing for Windows (ETW). When network protection is enabled, it can block connections to known malicious C&Cs.

When scripts drop files (which is not uncommon), Defender can detect these files.

Furthermore, Defender ASR rules can prevent execution of some scripts as well as macros in documents. This can deactivate the AMSI bypass.

All in all, there is quite a lot of protection besides AMSI but majority of it is not enabled by default.
Where applicable and supported, Defender also uses TDT to perform memory scanning.

Thank you. As for TDT for memory scanning, does Defender leverage TDT dynamically per process, or only for certain executables or memory types (like WSH host memory)? How is it invoked in practice?

 

[Andy Ful]

Thank you. As for TDT for memory scanning, does Defender leverage TDT dynamically per process, or only for certain executables or memory types (like WSH host memory)? How is it invoked in practice?

The TDT telemetry works on the CPU level (no processes there). This telemetry is integrated with the AV, which can block/detect malware.
Defender uses TDT for memory scanning, cryptojacking detection, and ransomware detection. It is not limited to certain executables or memory types.

Hardware-based threat defense against increasingly complex cryptojackers | Microsoft Security Blog

To provide advanced protection against increasingly complex and evasive cryptojackers, Microsoft Defender Antivirus integrates with Intel® Threat Detection Technology (TDT) that applies machine learning to low-level CPU telemetry in detecting cryptojackers, even when the malware is obfuscated...

www.microsoft.com

Hardware acceleration and Microsoft Defender Antivirus. - Microsoft Defender for Endpoint

How Microsoft Defender Antivirus incorporates hardware acceleration and Microsoft Defender Antivirus.

learn.microsoft.com

 

[RoboMan]

The TDT telemetry works on the CPU level (no processes there). This telemetry is integrated with the AV, which can block/detect malware.
Defender uses TDT for memory scanning, cryptojacking detection, and ransomware detection. It is not limited to certain executables or memory types.

Hardware-based threat defense against increasingly complex cryptojackers | Microsoft Security Blog

To provide advanced protection against increasingly complex and evasive cryptojackers, Microsoft Defender Antivirus integrates with Intel® Threat Detection Technology (TDT) that applies machine learning to low-level CPU telemetry in detecting cryptojackers, even when the malware is obfuscated...

www.microsoft.com

Hardware acceleration and Microsoft Defender Antivirus. - Microsoft Defender for Endpoint

How Microsoft Defender Antivirus incorporates hardware acceleration and Microsoft Defender Antivirus.

learn.microsoft.com

Thanks for the info and reads!