1. Abusing Native Trust & Reputation (BYOR): Security controls and cloud filters (like Microsoft SmartScreen) often grant higher reputation trust to native extensions like .bat, .cmd, or .vbs because they are standard files used daily in enterprise environments. By wrapping malicious logic inside a trusted format, red teams can bypass reputation prompts, initial file-hash blocklists, and basic static analysis.
   
   
2. Obfuscation and Dynamic Assembly: Static AV scanners look for known malicious strings, API calls, or byte signatures. Batch files and VBScript can be heavily obfuscated using string concatenation, environment variable expansion, XOR encoding, or reverse-string functions. The script looks like garbled text on disk; it only deobfuscates or reconstructs the payload dynamically in memory at the exact moment of execution.
   
   
3. Bypassing PowerShell Execution Policies: Many environments restrict direct PowerShell execution (powershell.exe -ExecutionPolicy Restricted). Red teams use .bat or .vbs as wrappers to invoke PowerShell or download payloads via alternative paths (e.g., using mshta, rundll32, or hidden flags like -NoProfile -WindowStyle Hidden -Command), effectively bypassing standard logging and block policies.
   
   
4. Disabling Security Controls (Tampering): Scripts run with whatever privileges the user context allows. If an operator gains local administrator rights, a batch script can execute rapid-fire commands to blind defenses. This includes stopping specific services, deleting shadow copies, modifying firewall rules, or running sc stop / net stop against known AV/EDR agents before the secondary tooling drops.
   
   
5. Staging and Multi-Stage Droppers: Dropping a heavy, fully compiled executable (.exe or .dll) onto a disk triggers immediate EDR behavioral blocking. Instead, the .bat/.vbs acts as a lightweight loader. It uses native utilities like certutil.exe or curl.exe to fetch the real payload from a remote C2 directly into memory, or unpacks it from a harmless-looking text file embedded in the script, drastically reducing the disk footprint.
   

• Unusual Process Spawning: Monitoring when cmd.exe or wscript.exe spawns unexpected child processes like powershell.exe, whoami.exe, or network utilities (net.exe, certutil.exe).
  
• Command-Line Logging: Capturing full command-line arguments to spot obfuscated strings, base64 encoding, or remote URL requests.
  
• Script Block Logging: Enabling advanced script block logging (AMSI / Event ID 4104) to catch the deobfuscated payload regardless of whether it started via a .bat or .vbs file.
  

• Loaders: A loader's primary job is execution and memory injection. It reads a payload (often encrypted shellcode), allocates a secure space in the computer's memory, decrypts the payload, and executes it without ever writing the unencrypted malicious file to the hard drive.
  
• Packers: A packer's primary job is obfuscation and compression on disk. It takes an existing executable, compresses or encrypts it, and wraps it in a new executable container (a stub). When run, the stub decompresses the original program directly into memory.
  

• Memory Scanning (Fluctuating Protections): EDRs look for memory regions marked as RX (Read/Execute) or RWX (Read/Write/Execute) that do not map back to a legitimate file on disk.
  
• AMSI (Antimalware Scan Interface): Even if a loader obfuscates a payload, AMSI intercepts it at the exact moment it is decrypted in memory, just before execution.
  
• API Hooking: EDRs monitor critical Windows API functions (like VirtualAllocEx or CreateRemoteThread) that loaders commonly use to request memory space.
  

1. Evading AMSI: When a .vbs file runs via wscript.exe, Windows routes the script text through AMSI. If known C2 domains are seen in clear text, it blocks it instantly. Red teams bypass this by dynamically slicing strings with complex math or environment variables rather than basic Base64 (which EDRs decode automatically).
   
2. Living off the Land (LoLBins) for Staging: Spawning an unknown executable directly from a script triggers a high-fidelity alert. Instead, scripts invoke trusted binaries. A .bat might use a native utility to reconstruct an encrypted file in a temp folder, while a .vbs might use the Wscript.Shell object to silently call Microsoft-signed tools to map a remote network share and grab the next stage.
   

1. Scripts Cannot Unhook EDR: EDRs monitor systems by injecting user-mode "hooks" into standard Windows system libraries (like ntdll.dll). Scripts cannot interact with memory closely enough to remove these. A compiled loader can manually read a fresh copy of ntdll.dll from disk and rewrite the hooked functions in memory, "blinding" the EDR.
   
2. Advanced Injection Techniques: To blend in, an Overlord beacon should run inside the memory space of a legitimate Windows process (e.g., explorer.exe or svchost.exe). Loaders handle the heavy mathematical and system-level operations required, such as Indirect Syscalls (talking directly to the OS kernel to bypass APIs) and API Hashing (hiding which APIs the malware uses).
   
3. In-Memory Sleep Obfuscation: Once an Overlord beacon is inside memory, it periodically "beacons" back to its server. During quiet periods, a routine YARA memory scan will spot it. A loader wraps the C2 agent with Sleep Obfuscation. When it sleeps, the loader encrypts the agent's memory region and changes permissions from Executable (RX) to Read-Only (RO), making it look like harmless data until it wakes up.
   

(Sep 21, 2026 10:04 PM)7 Wrote:  Nice thread, I will read it all properly later but im pretty much up to date with this anyway.
But nice share

(Sep 21, 2026 10:18 PM)roker8866 Wrote:  This is such an excellent and detailed article! I’m going to take the time to read through every point carefully.
Thanks for the post!

(Sep 22, 2026 03:45 AM)DramaKing Wrote:  This is good material for the most part, but I winder if you were studying up-to-date material. VBS support is either completely removed from Windows 11 now or is about to be. Also, even if running a script in an elevated context and knowing the relevant service name, trying to stop a service should work on about 0 EDRs. And you mention patching AMSI in-memory (which seems to trigger detection now, no matter what) but state that a script cannot unhook APIs, which is a contradiction.

I thought, too, that Jinx didn't do any encryption/decryption, except maybe with an encrypted channel.