CCNA Antivirus Evasion Questions

Manually building the syscall stub bypasses userland hooks because the hook resides in ntdll's exported function, not in the kernel transition path. By placing the syscall number in EAX and executing the syscall instruction directly, the loader skips the modified ntdll code entirely. This works without kernel privileges and is a standard PEN-200 technique for evading EDR hooks on memory allocation and protection APIs.

Heuristic engines look for characteristics and behaviors rather than exact byte sequences. By identifying that the file structure or the sequence of API calls closely resembles known malware, the antivirus can make an educated guess that the file is malicious, even if the specific strings and variables have been altered by the penetration tester.

Antivirus vendors include the signatures for common Metasploit encoder stubs in their databases. Even though the payload itself is 'randomized' by the encoder, the small piece of code that decrypts that payload remains recognizable. Since this stub must run first, the antivirus identifies it immediately and blocks the execution before the payload is even unpacked.

Indirect syscalls bypass the user-mode hooks installed by EDRs in common Windows APIs like NtAllocateVirtualMemory. By invoking the kernel directly from the assembly, the shellcode avoids passing through monitored functions, effectively blinding the EDR to the memory allocation process, which is the primary indicator of malicious injection.

Because the application searches HKCU first, it will find and use the attacker's malicious COM mapping instead of the legitimate one in HKLM. This results in the trusted application loading the attacker's DLL. This is an effective evasion technique because the malicious activity is masked by the legitimate process's identity.

Certutil is a command-line program for managing certificates, but it includes a '-urlcache -split -f' parameter that allows it to download files from the internet. Because it is a trusted system utility, many basic antivirus programs and firewall rules do not flag it when it initiates a network connection to retrieve a file.

By breaking a keyword like 'amsiInitFailed' into smaller pieces (e.g., 'am' + 'si' + 'Init') and joining them at runtime, the static scanner cannot see the full word. Since AMSI often relies on keyword-based signatures, this simple technique can effectively prevent the script from being flagged during the pre-execution scan.

Shikata_ga_nai is an encoder that transforms the payload's bytes using a polymorphic XOR additive feedback loop, changing the binary appearance while preserving functionality. Applying it multiple times further mutates the signature, which can help evade static signature-based detection. This is a classic PEN-200 technique for altering the file's binary appearance without changing what the payload does.

Heuristic analysis analyzes the structural makeup of an executable, including imported DLLs like VirtualAlloc and CreateThread. When these suspicious API combinations appear together in an unknown binary, the engine flags it as a potential threat based on risk scoring.

Static on-disk scanning matches byte signatures and PE characteristics before execution. A crypter that XOR-encrypts the original payload bytes and only reconstructs them in memory changes the stored file's byte pattern, so the signature that flagged the plaintext implant no longer matches the file on disk. The implant logic still runs after decryption, satisfying the requirement to preserve behavior while reducing file-based detection.

Signature detection compares a file's content against a list of known malware 'fingerprints.' Behavioral detection, on the other hand, monitors the actual operations a program performs while running, such as attempting to inject code into another process or modifying sensitive registry keys, allowing it to catch zero-day threats.

XOR encoding modifies every byte of the payload based on a key, entirely changing the static file hashes and byte signatures. A custom runtime stub allocates memory, decrypts the payload on the fly, and executes it without ever writing the cleartext binary back to disk.

Raw msfvenom output embeds the default Meterpreter stager stub, whose fixed byte sequences and shellcode patterns are catalogued by antivirus vendors. Detection therefore occurs on signature alone, before any behavioural analysis, so custom encoding or obfuscation is required.

Invoke-Expression evaluates a string as PowerShell code in the current session. When combined with a download cradle such as (New-Object Net.WebClient).DownloadString('http://...'), the script is fetched into memory and executed immediately, leaving no file on disk. This is a common in-memory execution technique that helps evade file-based detection, though AMSI may still inspect the script content at runtime.

Allocating memory as RWX is a strong indicator of malicious behavior. By first allocating with PAGE_READWRITE, writing the shellcode, and then changing the protection to PAGE_EXECUTE_READ via VirtualProtect, the loader avoids leaving an RWX region, which many behavioral engines flag. This technique is a common evasion step and preserves local execution without introducing remote process operations.

Embedded plaintext shellcode is a strong static indicator because its bytes match known signatures. Storing the shellcode XOR-encrypted and decrypting it at runtime removes those recognizable bytes from the on-disk binary, so signatures targeting the shellcode no longer match. Behavior is preserved because the decrypted buffer is what executes, making this a direct way to reduce static detection while keeping functionality.

EDR user-mode hooks live in the ntdll.dll code that the loader would normally call. By extracting the syscall service numbers and issuing the syscall instruction from the loader's own memory, the execution never passes through the hooked ntdll stubs. The kernel still performs the operation, but the EDR's user-mode interception point is skipped. This directly addresses the described hooking mechanism.

AMSI ultimately routes assembly and script content through AmsiScanBuffer in amsi.dll. By overwriting the function prologue in the current process with a stub that returns a clean result, the tester prevents Defender from receiving the buffer for inspection. This is a classic runtime AMSI bypass that works for .NET assembly loads because the CLR calls into AMSI via that same exported function. It does not require disabling Defender globally.

Defender's behavioral engine commonly flags a single allocation that is simultaneously writable and executable, since legitimate code rarely needs RWX pages. Allocating as RW, writing the decrypted shellcode, then flipping to RX via VirtualProtect mimics how a normal loader maps code and removes the RWX indicator. The shellcode still executes, but the high-signal memory characteristic that triggered termination is eliminated.

Antivirus software heavily relies on scanning new files created on the hard drive against a database of known malware signatures. By executing code directly in memory using Invoke-Expression, the payload never triggers the file system write hooks that would normally prompt an immediate scan, allowing the code to run if it can evade behavioral analysis.

EDR behavioral monitoring often flags the creation of a new, unsigned process that immediately performs suspicious actions. Injecting into an existing trusted process like explorer.exe avoids a new process creation event and places the malicious code inside a process the EDR considers benign. This directly addresses the behavioral monitoring component described in the scenario.

Importing VirtualAlloc from kernel32.dll via P/Invoke declarations supplies the missing unmanaged Win32 API that the .NET runtime cannot expose natively, resolving the compile error. This satisfies the stem's requirement for low-level memory allocation, since managed C# has no built-in equivalent for reserving executable pages.

Packing involves using a tool to compress and wrap the original executable within a new outer layer. When the file is scanned on disk, the antivirus only sees the packer's code rather than the malicious payload. At runtime, the packer decompress the original code into memory, effectively hiding the malware from static analysis.

Security solutions place inline hooks within user-mode DLLs like ntdll.dll to monitor API calls. Implementing direct system calls bypasses these hooked functions entirely, allowing the payload to interact directly with the kernel without triggering user-mode security monitoring alerts.

Sideloading takes advantage of the Windows DLL search order, which prioritizes the application's directory over system directories. By naming the malicious file after a required dependency, the attacker tricks a trusted application into executing their code. This is a highly effective way to gain execution while appearing as a legitimate, signed process.

Automated sandboxes are often resource-constrained to save costs, frequently operating with only one or two CPU cores and minimal memory. Legitimate modern workstations typically have more resources. Malware can check these hardware specifications and terminate execution if they fall below a certain threshold, assuming the environment is a virtualized analysis lab.

A custom loader with encrypted embedded shellcode presents a different on-disk artifact than the original msfvenom executable, so the signature that matched the raw payload no longer applies. The executable's own code is unique to the tester, and the shellcode is not present in a recognizable form until runtime decryption. This directly addresses signature-based detection at delivery without relying on well-known encoders.

EDR tools can compare the executable's entry point and memory map against the original file on disk. When a process is hollowed, the memory contents and the entry point are modified to point to the malicious code. This mismatch is a clear sign that the process has been tampered with and is no longer legitimate.

Static signatures often include byte sequences from compiled code, strings, and payload data. Renaming functions and inserting junk instructions alters the compiled output's byte layout and instruction sequence while preserving the program's logic. Rebuilding produces a new binary whose bytes no longer match the original signature, which directly addresses signature matching without changing behavior, matching the tester's stated goal.

Patching AmsiScanBuffer in memory (e.g., by overwriting its first bytes with a return value of S_OK or a benign HRESULT) prevents AMSI from scanning the buffer, effectively bypassing detection without disabling Defender. This is a common in-memory evasion technique taught in PEN-200 for evading AMSI.

AMSI scans the script content as it is submitted for execution, matching known malicious patterns. If the script is rewritten so that no contiguous string matches an AMSI signature, the scan passes and the script executes. Techniques such as string splitting, character substitution, and dynamic construction change the textual representation while preserving behavior. This directly targets AMSI's pattern-matching inspection of the script.

Module stomping writes shellcode into the existing executable .text section of a legitimately loaded DLL, so no new executable memory is allocated. Because the memory is already marked executable and belongs to a signed module, behavioral monitors that focus on new executable allocations or thread creation may not flag it. This technique is stealthier against memory-permission-based detection, though integrity checks on the DLL could still reveal tampering.

AMSI resolves AmsiScanBuffer from amsi.dll inside each process. Overwriting the function's prologue in the current process's memory so it returns a benign result causes subsequent scans to report no detection, and this works within the user's own process without admin rights or disk changes. It matches the requirement to disable scanning for the current process only and leaves files untouched.

Encrypting the payload with a unique key ensures that the on-disk bytes are different for each build, defeating static signatures that rely on fixed byte patterns. The custom loader decrypts the payload in memory before execution, so functionality is preserved. This is a strong method for evading static detection because the encrypted payload does not match known signatures. It requires the loader to handle decryption and execution, often leading to in-memory execution.