Antivirus Evasion practice questions

It allows the application to run with SYSTEM privileges automatically.

Why it fails: Using direct syscalls only changes how the application communicates with the kernel; it does not grant any additional privileges. The process still operates within its original security context. To gain SYSTEM privileges, an attacker would still need to perform a separate privilege escalation exploit regardless of how they invoke system functions.

It ensures the payload is compatible with all versions of Windows.

Why it fails: Direct syscalls are actually less compatible than standard APIs because syscall numbers often change between different Windows versions and service packs. An attacker using this method must include logic to dynamically identify the correct syscall number for the specific version of the operating system they are currently targeting to avoid crashing.

It encrypts the parameters passed to the kernel to hide their intent.

Why it fails: Syscalls do not provide encryption for their parameters. The data passed to the kernel (such as memory addresses or process IDs) is still visible to kernel-mode monitoring tools. The technique's strength lies in bypassing user-mode hooks, not in concealing the nature of the data being processed by the operating system's kernel.

Compress the entire executable using standard UPX packing with default parameters.

Why it fails: Standard packing tools like UPX are heavily signatured by modern endpoint security solutions. Using default parameters simply wraps the payload in a well-known container that security software unpacks or flags immediately based on the packer header itself.

Rename all internal variable names and function signatures using random alphanumeric characters.

Why it fails: Renaming symbols changes metadata within managed assemblies like C#, but string literals and overall control flow structures remain completely intact. Modern antivirus engines analyze raw byte sequences and embedded strings rather than relying solely on developer-defined symbol names.

Prepend dummy null-bytes to the beginning of the PE file header to alter the file hash.

Why it fails: Modifying file headers or padding files only alters cryptographic hashes like MD5 or SHA256. Antivirus signatures operate on structural heuristics, entropy analysis, and byte patterns rather than simple file hashes, rendering cosmetic header changes ineffective.

Modify the Windows Registry to disable Windows Defender real-time protection permanently.

Why it fails: Modifying protected registry keys related to Windows Defender typically requires administrative privileges that are either restricted by system policies or actively monitored by tamper protection mechanisms, making this an unreliable method for live session bypasses.

Run the PowerShell script inside an elevated prompt using the -NoProfile and -NonInteractive flags.

Why it fails: Built-in command-line switches like -NoProfile only control profile loading and user interaction settings. They do not interact with or disable the Antimalware Scan Interface, which evaluates script blocks regardless of how the shell was launched.

Inject the payload directly into the winlogon.exe process using standard CreateRemoteThread calls.

Why it fails: Cross-process injection into critical system binaries like winlogon.exe usually triggers strict behavioral heuristics and modern endpoint detection and response solutions, resulting in immediate process termination rather than a successful AMSI bypass.

Stripping the symbol table and debug information from the compiled executable.

Why it fails: Removing debug symbols helps reduce file size and obscures function names, but it does not change the core binary structure or signatures that AV engines check. Most modern AV solutions ignore debug symbols and focus on the import address table and executable code sections for signature matching.

Modifying the program icon and metadata to mimic a legitimate system file.

Why it fails: Changing metadata like file versions or icons is a common social engineering tactic, but it does not alter the underlying machine code. Antivirus engines focus on the binary data and logic flows rather than cosmetic attributes, making this approach ineffective against automated signature-based detection mechanisms.

Using a well-known public obfuscator to scramble the control flow of the binary.

Why it fails: Publicly available obfuscators are frequently fingerprinted by antivirus vendors. Using common tools often creates a predictable pattern that AV engines easily recognize, effectively acting as a signature itself. Relying on well-known tools typically results in faster detection than using no obfuscation at all during penetration testing.

Using base64 encoding for the entire script file to hide its contents.

Why it fails: Modern AMSI implementations automatically decode common encodings like base64 before scanning the script content. Simply encoding the script does not prevent detection; the engine will decode it in memory, inspect the underlying logic, and identify the malicious patterns anyway, rendering this approach ineffective for modern evasion.

Adding excessive comments to the PowerShell script to confuse the engine.

Why it fails: Adding comments to a script file does not interfere with the logic of the engine. AMSI parses the script and strips away irrelevant formatting and comments before evaluating the code for malicious signatures. This technique is easily filtered by the parser and provides no real benefit against detection.

Changing the file extension of the script from .ps1 to .txt.

Why it fails: Changing a file extension does not impact how the script is executed by the host process. When the interpreter runs the file, the content is still passed to the AMSI engine for inspection. The engine evaluates the actual code logic rather than the file system metadata.

Disable Windows Defender's real-time protection via PowerShell before uploading the tool.

Why it fails: Disabling real-time protection requires administrative privileges and may trigger alerts or be logged. In many PEN-200 scenarios, the tester may not have admin rights, and such an action could be detected. The goal is to evade without disabling security controls, so this is not the most appropriate technique.

Upload the tool with a different file extension (e.g., .txt) and rename it after execution.

Why it fails: Changing the file extension does not alter the file's content or signature; Defender scans files based on content, not extension. When the file is executed, real-time protection will still scan it and likely detect the malicious code, so this technique is ineffective.

Use the 'migrate' command to move the Meterpreter session into a trusted process before uploading the tool.

Why it fails: Migrating to a trusted process can help avoid process-specific detection, but it does not prevent Defender from scanning the uploaded tool on disk or upon execution. Real-time protection will still scan the file when it is written or run, so migration alone does not bypass file scanning.

Sign the assembly with a self-signed code-signing certificate to satisfy Defender's trust requirements.

Why it fails: Self-signed certificates are not trusted by the operating system's certificate store and therefore carry no reputation weight with Defender. Cloud-delivered protection evaluates the signing chain against Microsoft's reputation services; an untrusted or unknown publisher can actually increase suspicion. Signing does not remove the suspicious API usage that triggered the initial detection.

Add Thread.Sleep(5000) before the first network callback to stagger execution and avoid cloud submission.

Why it fails: Delaying the callback does not remove the static indicators that triggered quarantine; Defender's cloud-delivered protection can submit and verdict the binary at write time or on first execution regardless of sleep duration. The delay may even increase exposure because the process remains resident long enough for behavioral inspection to complete, so this change does not address the root cause.

Compile the implant with the /platform:anycpu flag so it runs under both 32-bit and 64-bit processes.

Why it fails: Platform targeting affects process bitness and memory layout, not detection surface. Defender's heuristics evaluate the import table, strings, and runtime behavior of the assembly irrespective of whether it runs as AnyCPU, x86, or x64. Changing this flag may even alter which APIs are used, but it does not remove the flagged P/Invoke signatures that caused the quarantine.

Use bitsadmin /transfer to queue the payload, then use wmic process call create to run it from the cache.

Why it fails: bitsadmin and wmic both operate on files on disk; BITS transfers write the downloaded content into a local cache file, and wmic launches an executable from a path. Neither loads bytes directly into memory. The payload therefore lands on disk and is subject to scanning, violating the no-disk-write requirement and increasing the chance of quarantine before execution.

Use certutil.exe -urlcache -split -f to download the payload to the current directory and execute it.

Why it fails: certutil -urlcache writes the downloaded content to a file on disk, which violates the no-disk-write requirement. It is a classic Living off the Land download technique, but it produces a persistent artifact that real-time scanners can inspect and quarantine. Because the scenario explicitly requires avoiding disk writes, this method fails the constraint despite being a valid download mechanism.

Invoke-WebRequest to save the payload to $env:TEMP, then Start-Process to launch it.

Why it fails: Invoke-WebRequest writing to $env:TEMP places the payload on disk, which directly violates the no-disk-write requirement. A file on disk is also subject to real-time scanning, so it may be quarantined before Start-Process runs. This approach fetches and executes but fails the core constraint of avoiding disk, making it unsuitable for the scenario even though the download itself may succeed.

Use HeapCreate with HEAP_CREATE_ENABLE_EXECUTE and HeapAlloc to store and execute the shellcode.

Why it fails: Creating an executable heap and allocating shellcode there is an old technique that is now widely flagged. EDR solutions monitor for executable heap allocations because they are rarely used by legitimate applications. The HEAP_CREATE_ENABLE_EXECUTE flag is a strong indicator of malicious intent, and executing code from the heap is unusual. This approach is more suspicious than using standard memory APIs with a permission change, so it does not reduce the behavioral footprint.

Use NtCreateSection and NtMapViewOfSection to map the shellcode as an image section with execute permissions.

Why it fails: Mapping an image section with execute permissions can be stealthy, but it often results in memory that is executable and may still be flagged if the section is not backed by a legitimate file on disk. Moreover, these native APIs are less commonly used and can themselves be monitored. While section mapping can avoid some API hooks, it does not inherently reduce the behavioral footprint compared to a simple permission change, and it may introduce other anomalies such as unbacked executable memory.

Use VirtualAllocEx to allocate memory in a remote process and write the shellcode, then use CreateRemoteThread to execute it.

Why it fails: This is the classic remote injection pattern that EDR solutions heavily monitor. Allocating memory in another process and creating a remote thread is a well-known indicator of compromise. Even if the memory protection is not RWX, the cross-process operations and remote thread creation are highly suspicious. This approach does not reduce the behavioral footprint; it increases it by involving another process and remote thread creation, which are prime detection targets.

Use wmic.exe to create a process that executes a remote payload directly from memory.

Why it fails: Wmic.exe can be used for lateral movement and process creation, but it does not natively support executing a remote payload directly from memory. Any payload executed through wmic would typically be written to disk or passed through a command line that is logged and inspected. This technique does not provide the same level of evasion as executing a remote scriptlet or HTA through a trusted binary.

Use certutil.exe to download a base64-encoded payload and decode it to disk before execution.

Why it fails: Certutil.exe can download files, but writing the payload to disk increases the chance of on-access scanning by Defender, which will inspect the file when it is written and again when it is executed. This technique is more suited to staging files than to evading real-time protection. The question asks for techniques that leverage trusted binaries to evade detection, and writing to disk undermines that goal.

Use bitsadmin.exe to transfer the payload from a remote server to the local disk.

Why it fails: Bitsadmin.exe is a signed binary used for background file transfers, but like certutil it writes the payload to disk, where Defender's real-time protection can scan it. While it may bypass some network-based controls, it does not provide the in-memory or scriptlet-based execution that avoids on-disk detection. It is therefore not the most appropriate choice for evading real-time protection in this scenario.

Split the suspicious strings into concatenated substrings within the script.

Why it fails: String concatenation can evade simple static signatures, but AMSI's dynamic analysis reconstructs strings and inspects the script's behavior. AMSI hooks into the PowerShell engine and can detect suspicious patterns even when strings are split, especially for well-known tools like Invoke-Mimikatz. This technique may reduce detection by some signature-based scanners but is not reliable against AMSI's runtime inspection.

Base64-encode the entire script and execute it with powershell -EncodedCommand.

Why it fails: Base64 encoding obfuscates the script from casual inspection but is trivially decoded by AMSI before scanning. AMSI receives the decoded script content and inspects it for suspicious strings, so encoding does not prevent detection of 'Invoke-Mimikatz' or 'AmsiUtils'. This technique is more effective against simple logging than against AMSI's content inspection.

Run the script in a separate PowerShell process with the -NoProfile flag.

Why it fails: Using -NoProfile avoids loading the user's profile, which can reduce noise and prevent some profile-based detections, but it does not disable AMSI. AMSI is initialized within each PowerShell process regardless of the profile, so the script content will still be scanned. This flag is useful for operational security but does not bypass AMSI's inspection.

It bypasses the Antimalware Scan Interface (AMSI) entirely by default.

Why it fails: Modern versions of PowerShell automatically integrate with the Antimalware Scan Interface to scan script contents before execution. Even if the script is loaded directly into memory without touching the disk, AMSI will still intercept the code and send it to the resident antivirus engine for evaluation, requiring additional obfuscation to successfully bypass detection.

PowerShell scripts are automatically trusted by the Windows integrity system.

Why it fails: Windows does not inherently trust PowerShell scripts simply because they are part of the operating system's management environment. Execution policies and integrated security features like Constrained Language Mode and AMSI are specifically designed to restrict or monitor script activity, ensuring that even native tools are subject to scrutiny when executing potentially harmful commands.

The method uses the System.Net.WebClient class which encrypts the payload.

Why it fails: The WebClient class is used for retrieving data over network protocols like HTTP or HTTPS, but it does not provide automatic encryption for the payload itself. While HTTPS provides transport layer security, the payload remains in its original form once downloaded into memory, meaning the antivirus can still inspect the plaintext script unless the attacker manually implements encryption.

The antivirus is using signature-based detection on the specific junk code.

Why it fails: Junk code is typically unique or randomized, making it an unlikely candidate for a static signature in a database. Antivirus vendors focus their signatures on the functional parts of the malware that are difficult to change, rather than the decorative or filler instructions that an attacker adds specifically to disrupt simple pattern matching.

The file's entropy was too low, triggering an automatic quarantine.

Why it fails: Low entropy indicates a file is likely plain text or highly structured, which is common for legitimate applications. High entropy usually triggers suspicion as it suggests encryption or packing, which are common traits of malware. Therefore, low entropy would not typically be the reason for a 'Trojan.Generic' detection in this specific scenario.

The junk instructions were identified as malicious shellcode by the CPU.

Why it fails: CPUs do not have built-in antivirus capabilities to identify malicious intent in instructions; they simply execute whatever valid code is provided. Security features like Data Execution Prevention (DEP) can prevent execution in certain memory regions, but they do not analyze the logic of 'junk' instructions to determine if they belong to a Trojan.

Process Hollowing

Why it fails: Process hollowing is a dynamic evasion technique used to hide the execution of malicious code within a legitimate process's memory space. While it helps evade detection during runtime, it is not a method for altering the static appearance of a file on disk before it is executed, which is the focus of signature-based bypass.

Direct System Calls

Why it fails: Using direct system calls is a technique designed to bypass EDR hooks and API monitoring during execution. It involves manually invoking kernel functions instead of using standard Windows API libraries. This is a dynamic evasion strategy aimed at bypassing behavioral monitoring rather than changing the static signature or binary appearance of the file on disk.

Token Manipulation

Why it fails: Token manipulation is a post-exploitation technique used for privilege escalation or impersonation by stealing and applying access tokens from other processes. It does not involve changing the binary structure or appearance of a file to bypass antivirus signatures, making it irrelevant to the goal of evading static detection during the initial delivery.

DLL Injection

Why it fails: DLL Injection involves forcing a running process to load a DLL from an external source, typically using APIs like CreateRemoteThread and LoadLibrary. In the scenario described, the process loads the DLL naturally during its startup routine due to the file's location, rather than being forced to do so by an external actor after execution.

COM Hijacking

Why it fails: COM Hijacking involves modifying registry keys to redirect Component Object Model (COM) object lookups to a malicious DLL. While it also involves loading a DLL, it relies on registry manipulation rather than the file system search order. The scenario specifically mentions placing a file in the same directory as an executable, indicating sideloading.

Reflective DLL Loading

Why it fails: Reflective DLL loading is a technique where a DLL is loaded into a process's memory without using the standard Windows loader or touching the disk. In the described scenario, the DLL is explicitly placed on the disk in a specific directory, which contradicts the 'stealth' and 'memory-only' nature of reflective loading techniques.

Executing a large number of NOP instructions to increase file size

Why it fails: Adding NOP instructions is a static evasion technique used to change a file's signature or offset code blocks. It does not help in detecting a sandbox environment during runtime. While it might slightly delay execution, it is not a reliable or primary method for identifying whether the code is running in a virtualized analysis tool.

Using direct syscalls to bypass the Windows API hooks

Why it fails: While direct syscalls are used to evade EDR and sandbox monitoring of API calls, they are a method of bypassing the 'hooks' rather than detecting the sandbox itself. This technique allows the malware to function while being watched, whereas sandbox evasion aims to prevent the malware from functioning at all until it is safe.

Signatures look for file hashes, while behavior looks for network traffic.

Why it fails: While signatures often involve hashes and behavior can include network traffic, this definition is too narrow. Signature-based detection looks at any static byte pattern in a file, while behavioral detection monitors local system actions like API calls, file modifications, and process creation, regardless of whether network activity occurs.

Signatures are only used for disk scans, while behavior is for memory scans.

Why it fails: This is a common misconception. Signatures can be applied to both files on disk and data in memory (such as during a full system scan). Similarly, behavioral analysis can be applied to script execution and macro activity that might not involve traditional 'memory' scanning but focuses on the sequence of execution.

Behavioral detection is always more accurate and faster than signature-based.

Why it fails: Behavioral detection is prone to false positives because many legitimate administrative tasks look like malicious activity. It also requires more system resources to monitor every action in real-time. Signature-based detection is extremely fast and accurate for known threats, which is why most antivirus solutions use a combination of both methods.

Memory Patching

Why it fails: Memory patching involves using P/Invoke to call Windows APIs like WriteProcessMemory to disable AMSI in the current process. While highly effective, this is a more advanced technique that involves interacting with the system's memory and DLLs, rather than just obfuscating the script content itself as specified in the question.

Registry Modification

Why it fails: Modifying registry keys to disable security features like Windows Defender or Script Block Logging is a configuration-based evasion tactic. It does not involve obfuscating the script itself. Furthermore, modern Windows systems protect these registry keys, often requiring high-level privileges that an initial script execution might not yet possess.

Kernel Driver Loading

Why it fails: Loading a malicious kernel driver is a technique used to gain the highest level of system access and disable security tools from the kernel level. This is far beyond the scope of simple script obfuscation and requires significant privileges, making it unsuitable for the task of bypassing AMSI via script modifications.

By performing a privilege escalation to modify the HKLM hive.

Why it fails: The beauty of COM Hijacking in HKCU is that it does not require administrative privileges or HKLM modification. The user has permission to write to their own HKCU hive by default. Modifying HKLM would be more difficult and more likely to be flagged by security software as a suspicious system-wide change.

By using the missing key to trigger a buffer overflow in the application.

Why it fails: COM Hijacking is a logic-based redirection attack rather than a memory corruption exploit. While a missing key might cause an error, it does not inherently provide a path to a buffer overflow. The goal here is to use the existing, legitimate functionality of the COM subsystem to load a malicious library.

By deleting the HKLM key to force the application to use HKCU.

Why it fails: The application already searches HKCU first by design; there is no need to delete the HKLM key. Furthermore, deleting keys in HKLM requires administrative privileges, which defeats the purpose of an evasion technique that is often used precisely because it can be implemented with standard user-level permissions in the HKCU hive.

calc.exe

Why it fails: While 'calc.exe' is often used as a proof-of-concept to show successful code execution, the calculator itself does not have built-in functionality to download or execute external code. It is a simple utility with no network or scripting capabilities, making it useless as a tool for delivering or staging a malicious payload.

notepad.exe

Why it fails: Notepad is a basic text editor and lacks any features that would allow it to download files or execute scripts. While it can be used to view malicious code, it cannot be 'lived off the land' to facilitate the execution or delivery of a payload in the same way that tools like mshta or certutil can.