Instruction: Describe Virtual Memory and its purpose.

Output: Virtual memory is an abstraction that provides each process with its own isolated address space, mapping virtual addresses to physical memory through page tables. The CPU's Memory Management Unit (MMU) translates virtual addresses to physical addresses, enabling memory isolation between processes and allowing the OS to use disk as extended memory (paging/swapping).


Instruction: How does Virtual Memory relate to security?

Output: Virtual memory isolation is fundamental to process security. Attackers who can manipulate page tables or bypass virtual memory isolation can read/write arbitrary process memory, escalate privileges, or escape sandboxes.


Instruction: What elements make up Virtual Memory?

Output:
Key components of Virtual Memory:

- Virtual Address Space (VAS) - isolated per-process memory view
- Page Tables - hierarchical structures mapping virtual to physical
- Page Table Entries (PTEs) - contain physical frame and permission bits
- Translation Lookaside Buffer (TLB) - CPU cache for page translations
- Memory Management Unit (MMU) - hardware performing translations


Instruction: How do attackers abuse Virtual Memory?

Output:
Attack vectors involving Virtual Memory:

- Kernel exploits targeting page table manipulation
- Rowhammer attacks causing bit flips in page tables
- Spectre/Meltdown exploiting speculative execution to leak memory
- Page table entry corruption for privilege escalation


Instruction: What evidence can be found from Virtual Memory activity?

Output:
Forensic artifacts for Virtual Memory:

- Page table structures in kernel memory
- CR3 register values per process
- Memory access patterns in crash dumps


Instruction: What is Process Address Space Layout?

Output: A process's virtual address space is divided into regions: code (.text) containing executable instructions, initialized data (.data), uninitialized data (.bss), heap growing upward for dynamic allocations, memory-mapped regions for shared libraries and files, and stack growing downward for function calls. Understanding this layout is critical for exploitation and forensics.


Instruction: From a security perspective, why is understanding Process Address Space Layout important?

Output: Attackers exploit predictable memory layouts to craft reliable exploits. Understanding layout enables buffer overflow exploitation, ROP chain construction, and heap spraying attacks.


Instruction: What elements make up Process Address Space Layout?

Output:
Key components of Process Address Space Layout:

- .text section - executable code (read/execute)
- .data section - initialized global/static variables
- .bss section - uninitialized globals (zeroed)
- Heap - dynamic allocations (malloc/new)
- Memory-mapped regions - shared libraries, mmap'd files
- Stack - function call frames, local variables
- Kernel space - upper portion of address space


Instruction: How do attackers abuse Process Address Space Layout?

Output:
Attack vectors involving Process Address Space Layout:

- Buffer overflows targeting stack or heap
- Return-oriented programming (ROP) using known code locations
- Heap spraying to place shellcode at predictable addresses
- Format string attacks to leak or write arbitrary addresses


Instruction: What forensic artifacts does Process Address Space Layout leave?

Output:
Forensic artifacts for Process Address Space Layout:

- Process memory maps (/proc/pid/maps, VADs)
- Section headers in PE/ELF files
- Heap metadata structures


Instruction: How does Address Space Layout Randomization (ASLR) work?

Output: ASLR is a security mechanism that randomizes the base addresses of executable, libraries, heap, and stack in memory. By making addresses unpredictable, ASLR defeats exploits that rely on hardcoded addresses. Full ASLR randomizes all regions; partial ASLR may leave some regions fixed.


Instruction: How does Address Space Layout Randomization (ASLR) relate to security?

Output: ASLR is a critical exploit mitigation. Bypassing ASLR is often the first step in modern exploitation, requiring information leaks to discover randomized addresses.


Instruction: What are the components of Address Space Layout Randomization (ASLR)?

Output:
Key components of Address Space Layout Randomization (ASLR):

- Executable base randomization (PIE/ASLR)
- Library load address randomization
- Stack base randomization
- Heap base randomization
- Entropy bits - amount of randomness (typically 8-28 bits)


Instruction: What attack vectors use Address Space Layout Randomization (ASLR)?

Output:
Attack vectors involving Address Space Layout Randomization (ASLR):

- Information leaks to disclose randomized addresses
- Partial overwrites exploiting low entropy
- Brute forcing on 32-bit systems with limited entropy
- JIT spraying to place code at known offsets
- Return-to-PLT/GOT attacks using fixed addresses


Instruction: What indicators of Address Space Layout Randomization (ASLR) can forensic analysts look for?

Output:
Forensic artifacts for Address Space Layout Randomization (ASLR):

- /proc/sys/kernel/randomize_va_space (Linux)
- DYNAMICBASE flag in PE headers (Windows)
- Position Independent Executable (PIE) flag


Instruction: What is Data Execution Prevention (DEP/NX)?

Output: DEP (Windows) / NX bit (Linux) is a hardware-enforced security feature that marks memory pages as non-executable. When enabled, the CPU will fault if code attempts to execute from pages marked as data (heap, stack). This prevents classic shellcode injection attacks where attackers write and execute code in data regions.


Instruction: How does Data Execution Prevention (DEP/NX) relate to security?

Output: DEP/NX is fundamental mitigation against code injection. Modern exploits must use code reuse techniques (ROP, JOP) since injected shellcode cannot execute directly.


Instruction: Describe the structure of Data Execution Prevention (DEP/NX).

Output:
Key components of Data Execution Prevention (DEP/NX):

- NX bit in page table entries
- Hardware enforcement via CPU (Intel XD, AMD NX)
- Software DEP (SafeSEH, SEHOP on Windows)
- Per-process and per-region settings


Instruction: How do attackers abuse Data Execution Prevention (DEP/NX)?

Output:
Attack vectors involving Data Execution Prevention (DEP/NX):

- Return-Oriented Programming (ROP) - chain existing code gadgets
- Jump-Oriented Programming (JOP)
- Return-to-libc attacks
- JIT spraying in browsers
- VirtualProtect/mprotect to change page permissions


Instruction: What forensic artifacts does Data Execution Prevention (DEP/NX) leave?

Output:
Forensic artifacts for Data Execution Prevention (DEP/NX):

- Page permissions in memory dumps
- NXCOMPAT flag in PE headers
- Memory protection flags in VADs/VMAs


Instruction: How does Windows Heap Internals work?

Output: The Windows heap manager provides dynamic memory allocation via HeapAlloc/HeapFree (or malloc/free which wrap them). The NT heap uses a frontend (Low Fragmentation Heap - LFH) for small allocations and backend for larger ones. Understanding heap metadata structures (HEAP, HEAP_ENTRY, free lists) is essential for heap exploitation and forensics.


Instruction: Why is Windows Heap Internals security-relevant?

Output: Heap exploitation techniques abuse heap metadata to achieve arbitrary writes or code execution. Modern Windows heaps include extensive mitigations but remain targets.


Instruction: What are the components of Windows Heap Internals?

Output:
Key components of Windows Heap Internals:

- HEAP structure - main heap descriptor
- HEAP_ENTRY - 8/16 byte header per allocation
- Low Fragmentation Heap (LFH) - frontend for small allocs
- Segment heap (Windows 10+) - modern heap implementation
- Free lists and lookaside lists
- Heap encoding/XOR cookies for integrity


Instruction: What attack vectors use Windows Heap Internals?

Output:
Attack vectors involving Windows Heap Internals:

- Heap overflow corrupting adjacent metadata
- Use-after-free exploiting dangling pointers
- Double-free corrupting free lists
- Heap spraying for predictable allocation placement
- Type confusion in heap objects


Instruction: What evidence can be found from Windows Heap Internals activity?

Output:
Forensic artifacts for Windows Heap Internals:

- HEAP structures in process memory
- Allocation patterns and sizes
- Freed chunk metadata
- LFH bucket structures


Instruction: What is glibc malloc Internals?

Output: glibc's malloc implementation (ptmalloc2) manages dynamic memory using arenas, bins, and chunks. Each allocation has a chunk header with size and flags. Free chunks are organized into bins (fast bins, small bins, large bins, unsorted bin) for efficient reuse. Understanding chunk metadata is critical for Linux heap exploitation.


Instruction: Why is glibc malloc Internals security-relevant?

Output: glibc heap has been heavily targeted. Techniques like unsafe unlink, fastbin dup, tcache poisoning, and house of techniques enable powerful exploitation primitives.


Instruction: What are the components of glibc malloc Internals?

Output:
Key components of glibc malloc Internals:

- malloc_chunk structure (prev_size, size, fd, bk pointers)
- Arenas - per-thread heap regions
- Fast bins - LIFO lists for small chunks
- Unsorted bin - recently freed chunks
- Small/Large bins - sorted by size
- Top chunk (wilderness) - expandable end of heap
- tcache (thread cache) - per-thread fast allocation


Instruction: How can glibc malloc Internals be exploited?

Output:
Attack vectors involving glibc malloc Internals:

- Unsafe unlink - corrupting fd/bk for arbitrary write
- Fastbin dup - double-free in fastbins
- Tcache poisoning - corrupting tcache next pointers
- House of Force - corrupting top chunk size
- House of Spirit - faking free chunks
- Overlapping chunks via size corruption


Instruction: What evidence can be found from glibc malloc Internals activity?

Output:
Forensic artifacts for glibc malloc Internals:

- Heap chunks and metadata
- Bin structures in main_arena
- Tcache entries per thread
- Allocation/free patterns


Instruction: How does Stack Mechanics and Calling Conventions work?

Output: The stack is a LIFO data structure used for function calls, storing return addresses, saved registers, and local variables. Calling conventions (cdecl, stdcall, fastcall, System V AMD64) define how arguments are passed and who cleans up the stack. Understanding stack frames is essential for exploitation and debugging.


Instruction: How does Stack Mechanics and Calling Conventions relate to security?

Output: Stack-based buffer overflows remain common. Overwriting return addresses enables control flow hijacking. Stack canaries, SafeSEH, and shadow stacks provide mitigations.


Instruction: Describe the structure of Stack Mechanics and Calling Conventions.

Output:
Key components of Stack Mechanics and Calling Conventions:

- Stack pointer (ESP/RSP) - top of stack
- Base pointer (EBP/RBP) - frame reference
- Return address - saved EIP/RIP for function return
- Saved registers - callee/caller saved
- Local variables - function-local storage
- Function arguments - passed via stack or registers


Instruction: What are common attacks involving Stack Mechanics and Calling Conventions?

Output:
Attack vectors involving Stack Mechanics and Calling Conventions:

- Stack buffer overflow overwriting return address
- SEH (Structured Exception Handler) overwrites
- Stack pivoting to attacker-controlled memory
- Format string attacks reading/writing stack
- ROP chains using gadgets ending in ret


Instruction: What forensic artifacts does Stack Mechanics and Calling Conventions leave?

Output:
Forensic artifacts for Stack Mechanics and Calling Conventions:

- Stack frames in crash dumps
- Return address patterns
- Stack cookies/canaries
- Call stack reconstruction


Instruction: Describe Stack Canaries (Stack Cookies) and its purpose.

Output: Stack canaries are random values placed between local variables and the return address on the stack. Before a function returns, the canary is checked against the original value. If corrupted by a buffer overflow, the program terminates. This prevents simple return address overwrites but can be bypassed with information leaks.


Instruction: Why is Stack Canaries (Stack Cookies) security-relevant?

Output: Canaries are effective against naive stack overflows but can be bypassed by leaking the canary value, overwriting other targets (SEH, function pointers), or using non-contiguous overwrites.


Instruction: What are the components of Stack Canaries (Stack Cookies)?

Output:
Key components of Stack Canaries (Stack Cookies):

- Canary value - random per-process or per-function
- Terminator canaries - include null, newline, EOF to stop string functions
- XOR canaries - XOR'd with return address for added protection
- Master canary - stored securely, checked against stack copy


Instruction: What are common attacks involving Stack Canaries (Stack Cookies)?

Output:
Attack vectors involving Stack Canaries (Stack Cookies):

- Information leak to disclose canary value
- Byte-by-byte brute force (fork-based servers)
- Overwriting data before canary check
- Targeting exception handlers (pre-canary-check)
- Format string to read canary from stack


Instruction: What forensic artifacts does Stack Canaries (Stack Cookies) leave?

Output:
Forensic artifacts for Stack Canaries (Stack Cookies):

- Stack cookie values in dumps
- __security_cookie in PE files
- GS cookie check routines


Instruction: What is Memory-Mapped Files?

Output: Memory-mapped files allow mapping file contents directly into a process's address space using mmap (Linux) or CreateFileMapping/MapViewOfFile (Windows). Changes to the mapped region can be written back to the file. This enables efficient file I/O, shared memory between processes, and is used for loading executables and libraries.


Instruction: Why is Memory-Mapped Files security-relevant?

Output: Memory-mapped files are used to load malicious code, create shared memory for IPC, and in exploitation to place controlled data at known addresses.


Instruction: What elements make up Memory-Mapped Files?

Output:
Key components of Memory-Mapped Files:

- mmap/munmap syscalls (Linux)
- CreateFileMapping/MapViewOfFile/UnmapViewOfFile (Windows)
- Mapping types: private (copy-on-write) vs shared
- Protection flags: read, write, execute
- File-backed vs anonymous mappings


Instruction: How do attackers abuse Memory-Mapped Files?

Output:
Attack vectors involving Memory-Mapped Files:

- Mapping shellcode from file into memory
- Shared memory injection between processes
- DLL/SO loading via memory mapping
- Exploiting file mapping permission misconfigurations


Instruction: What indicators of Memory-Mapped Files can forensic analysts look for?

Output:
Forensic artifacts for Memory-Mapped Files:

- VADs (Windows) / VMAs (Linux) showing mapped files
- Memory regions backed by files
- Shared memory sections


Instruction: Describe Copy-on-Write (COW) and its purpose.

Output: Copy-on-Write is a memory optimization where forked processes initially share the same physical pages as the parent. Pages are only duplicated when one process writes to them, triggering a page fault that creates a private copy. This makes fork() efficient and is used in process creation and memory deduplication.


Instruction: From a security perspective, why is understanding Copy-on-Write (COW) important?

Output: COW has security implications: Dirty COW (CVE-2016-5195) exploited race conditions in COW handling for privilege escalation. COW behavior affects process isolation and memory forensics.


Instruction: What elements make up Copy-on-Write (COW)?

Output:
Key components of Copy-on-Write (COW):

- Shared page table entries after fork
- Write-protect bit on shared pages
- Page fault handler for COW
- Private vs shared mapping flags


Instruction: What are common attacks involving Copy-on-Write (COW)?

Output:
Attack vectors involving Copy-on-Write (COW):

- Dirty COW - race condition writing to read-only mappings
- COW-based side channels
- Memory deduplication attacks

**MITRE ATT&CK**: T1068


Instruction: What indicators of Copy-on-Write (COW) can forensic analysts look for?

Output:
Forensic artifacts for Copy-on-Write (COW):

- Page sharing statistics
- COW fault counts in /proc
- Private vs shared memory accounting


Instruction: How does Working Set and Page Faults work?

Output: A process's working set is the subset of virtual pages currently resident in physical memory. When accessing a page not in the working set, a page fault occurs. Hard faults require reading from disk (slow); soft faults resolve from standby/modified lists (fast). Working set management affects performance and can be manipulated for attacks.


Instruction: How does Working Set and Page Faults relate to security?

Output: Page fault patterns can leak information (side channels). Forced paging can cause denial of service. Memory pressure affects exploit reliability.


Instruction: Describe the structure of Working Set and Page Faults.

Output:
Key components of Working Set and Page Faults:

- Working set - resident pages in physical memory
- Page fault - access to non-resident page
- Hard fault - page must be read from disk
- Soft fault - page found in memory caches
- Working set trimming - OS reclaiming pages
- Page file (swap) - disk backing for paged-out pages


Instruction: How can Working Set and Page Faults be exploited?

Output:
Attack vectors involving Working Set and Page Faults:

- Page fault side channels leaking access patterns
- Denial of service via memory exhaustion
- Timing attacks based on page fault latency
- Manipulating working set for deterministic heap state


Instruction: What indicators of Working Set and Page Faults can forensic analysts look for?

Output:
Forensic artifacts for Working Set and Page Faults:

- Page fault counters in performance data
- Working set information in process statistics
- Pagefile usage patterns


Instruction: Describe Memory Region Permissions (RWX) and its purpose.

Output: Memory regions have permissions controlling read (R), write (W), and execute (X) access. The combination RWX (read-write-execute) is dangerous as it allows writing and executing shellcode. Modern security requires W^X (write XOR execute) - pages should never be simultaneously writable and executable.


Instruction: Why is Memory Region Permissions (RWX) security-relevant?

Output: RWX memory enables classic shellcode attacks. Finding or creating RWX regions is a common exploit primitive. JIT compilers require careful permission management.


Instruction: What are the components of Memory Region Permissions (RWX)?

Output:
Key components of Memory Region Permissions (RWX):

- Read permission - can read contents
- Write permission - can modify contents
- Execute permission - can execute as code
- PAGE_EXECUTE_READWRITE - dangerous RWX permission
- W^X policy - writable or executable, never both


Instruction: What are common attacks involving Memory Region Permissions (RWX)?

Output:
Attack vectors involving Memory Region Permissions (RWX):

- Writing shellcode to RWX regions
- Finding existing RWX regions (JIT, etc.)
- VirtualProtect/mprotect to create RWX
- Return-to-mprotect to enable execution


Instruction: What evidence can be found from Memory Region Permissions (RWX) activity?

Output:
Forensic artifacts for Memory Region Permissions (RWX):

- Memory protection flags in VADs/VMAs
- !address output in WinDbg
- /proc/pid/maps permissions


Instruction: Explain VirtualAlloc and Memory Allocation APIs in the context of cross-platform.

Output: VirtualAlloc (Windows) and mmap (Linux) are the primary low-level APIs for allocating virtual memory regions. They allow specifying base address (or letting OS choose), size, allocation type (reserve/commit), and protection. Understanding these APIs is essential for both exploitation and detection.


Instruction: How does VirtualAlloc and Memory Allocation APIs relate to security?

Output: These APIs are used in every injection technique. Monitoring them reveals malicious memory operations. Remote variants (VirtualAllocEx) are especially suspicious.


Instruction: What elements make up VirtualAlloc and Memory Allocation APIs?

Output:
Key components of VirtualAlloc and Memory Allocation APIs:

- VirtualAlloc/VirtualAllocEx (Windows) - local/remote allocation
- VirtualFree - deallocation
- VirtualProtect - change page permissions
- mmap/munmap (Linux) - memory mapping
- mprotect (Linux) - change permissions
- MEM_COMMIT vs MEM_RESERVE


Instruction: How do attackers abuse VirtualAlloc and Memory Allocation APIs?

Output:
Attack vectors involving VirtualAlloc and Memory Allocation APIs:

- Allocating memory in remote processes for injection
- Creating executable regions for shellcode
- Reserving memory at predictable addresses
- Changing permissions to bypass DEP


Instruction: What evidence can be found from VirtualAlloc and Memory Allocation APIs activity?

Output:
Forensic artifacts for VirtualAlloc and Memory Allocation APIs:

- Allocated regions in VAD tree
- Memory allocation patterns
- Permission change history


Instruction: Describe Guard Pages and its purpose.

Output: Guard pages are memory pages marked with special protection that trigger an exception when accessed. They're used for stack growth detection, heap debugging, and security monitoring. When accessed, a STATUS_GUARD_PAGE_VIOLATION exception occurs, allowing handling before normal access.


Instruction: What are the security implications of Guard Pages?

Output: Guard pages help detect stack overflows and buffer overruns. Attackers may try to bypass guard pages or use them to detect debugging/analysis.


Instruction: What are the components of Guard Pages?

Output:
Key components of Guard Pages:

- PAGE_GUARD protection flag
- Stack guard pages - detect stack overflow
- VirtualAlloc with PAGE_GUARD
- Guard page exceptions
- One-shot behavior - guard removed after first access


Instruction: How can Guard Pages be exploited?

Output:
Attack vectors involving Guard Pages:

- Probing for guard pages to detect analysis
- Bypassing guard pages via non-contiguous writes
- Stack clash attacks jumping over guard pages


Instruction: What forensic artifacts does Guard Pages leave?

Output:
Forensic artifacts for Guard Pages:

- Guard page regions in memory maps
- Stack overflow exceptions
- Guard page violation events


Instruction: Explain Reserved vs Committed Memory in the context of cross-platform.

Output: Virtual memory can be reserved (address space claimed but no physical storage) or committed (backed by physical memory or pagefile). Reserving without committing saves resources while preventing other allocations. Committing actually allocates storage. Understanding this distinction is important for memory analysis.


Instruction: From a security perspective, why is understanding Reserved vs Committed Memory important?

Output: Large reservations can indicate heap spraying or exploit preparation. Commit patterns reveal allocation behavior. Over-commitment can cause stability issues.


Instruction: Describe the structure of Reserved vs Committed Memory.

Output:
Key components of Reserved vs Committed Memory:

- MEM_RESERVE - reserve address space only
- MEM_COMMIT - allocate physical storage
- MEM_RESERVE | MEM_COMMIT - both in one call
- Commit charge - total committed memory
- Virtual memory vs physical memory accounting


Instruction: What are common attacks involving Reserved vs Committed Memory?

Output:
Attack vectors involving Reserved vs Committed Memory:

- Heap spraying with large reservations then commits
- Memory exhaustion via excessive reservation
- Predictable address targeting with specific reservations


Instruction: What forensic artifacts does Reserved vs Committed Memory leave?

Output:
Forensic artifacts for Reserved vs Committed Memory:

- Reserved vs committed in VAD entries
- Process memory statistics
- System commit limit and usage


Instruction: Explain NUMA Memory Architecture in the context of cross-platform.

Output: Non-Uniform Memory Access (NUMA) architectures have memory physically distributed across nodes, with faster access to local memory than remote memory. Understanding NUMA is relevant for performance optimization and can affect exploit reliability across different system configurations.


Instruction: How does NUMA Memory Architecture relate to security?

Output: NUMA awareness affects exploit timing and reliability. Side channel attacks may exploit NUMA timing differences. Memory forensics must account for NUMA topology.


Instruction: Describe the structure of NUMA Memory Architecture.

Output:
Key components of NUMA Memory Architecture:

- NUMA nodes - groups of CPUs with local memory
- Local vs remote memory access latency
- Memory affinity - preferring local allocations
- NUMA-aware allocators
- Cross-node memory access penalties


Instruction: What attack vectors use NUMA Memory Architecture?

Output:
Attack vectors involving NUMA Memory Architecture:

- NUMA-based timing side channels
- Cross-NUMA memory access fingerprinting
- Exploiting NUMA-unaware code for DoS


Instruction: What indicators of NUMA Memory Architecture can forensic analysts look for?

Output:
Forensic artifacts for NUMA Memory Architecture:

- NUMA node information in system data
- Memory allocation node affinity
- Cross-node access statistics


Instruction: How does Windows API Layers work?

Output: Windows provides multiple API layers: Win32 (kernel32.dll, user32.dll, advapi32.dll) wraps the NT API (ntdll.dll), which makes syscalls into the kernel. Understanding these layers is crucial for security research, as attackers use lower layers to evade monitoring and defenders need to hook at appropriate levels.


Instruction: What are the security implications of Windows API Layers?

Output: EDRs typically hook Win32 or ntdll. Attackers use direct syscalls or unhooking to bypass these hooks. Understanding the layers enables effective evasion and detection strategies.


Instruction: What are the components of Windows API Layers?

Output:
Key components of Windows API Layers:

- Win32 API - documented, high-level (CreateFile, CreateProcess)
- kernel32.dll - core Win32 functions
- ntdll.dll - user-mode NT API (NtCreateFile, NtCreateProcess)
- Syscall stubs - transition to kernel mode
- Win32k.sys - kernel-mode graphics/windowing


Instruction: What attack vectors use Windows API Layers?

Output:
Attack vectors involving Windows API Layers:

- Direct syscalls bypassing ntdll hooks
- Unhooking ntdll to remove EDR hooks
- Calling Nt* functions directly to avoid Win32 logging
- Syscall number enumeration for version-independent attacks


Instruction: What indicators of Windows API Layers can forensic analysts look for?

Output:
Forensic artifacts for Windows API Layers:

- Syscall numbers in ntdll
- Hook presence/absence in ntdll
- API call patterns in ETW traces


Instruction: Explain NT Native API in the context of Windows.

Output: The NT API (Nt*/Zw* functions in ntdll.dll) provides the true interface to the Windows kernel. Many functions are undocumented but heavily used by attackers for their lower-level capabilities and reduced logging. Zw* versions run in kernel mode context; Nt* versions respect user/kernel mode of caller.


Instruction: How does NT Native API relate to security?

Output: Direct NT API usage often indicates advanced techniques bypassing Win32 logging. Malware commonly uses these functions for process injection, memory manipulation, and enumeration.


Instruction: What are the components of NT Native API?

Output:
Key components of NT Native API:

- NtCreateFile, NtReadFile, NtWriteFile - file operations
- NtCreateProcess, NtCreateThread - process/thread creation
- NtAllocateVirtualMemory - memory allocation
- NtProtectVirtualMemory - change protections
- NtMapViewOfSection - memory mapping
- NtQuerySystemInformation - system enumeration


Instruction: How do attackers abuse NT Native API?

Output:
Attack vectors involving NT Native API:

- NtMapViewOfSection for process hollowing
- NtCreateThreadEx for thread injection
- NtQuerySystemInformation to enumerate processes
- NtUnmapViewOfSection for hollowing target process


Instruction: What evidence can be found from NT Native API activity?

Output:
Forensic artifacts for NT Native API:

- NT API call traces
- System information query results
- Memory mapping events


Instruction: What is Windows Handle System?

Output: Handles are opaque references to kernel objects (files, processes, threads, registry keys, etc.). Each process has a handle table mapping handle values to object pointers. Handles have associated access rights determining permitted operations. Handle inheritance and duplication allow sharing objects between processes.


Instruction: From a security perspective, why is understanding Windows Handle System important?

Output: Handle manipulation is central to process injection and privilege escalation. Leaked or inherited handles can provide unauthorized access. Handle duplication enables cross-process attacks.


Instruction: What are the components of Windows Handle System?

Output:
Key components of Windows Handle System:

- HANDLE - opaque pointer value
- Handle table - per-process kernel structure
- Access rights - bitmask of permitted operations
- Handle inheritance - child processes inherit handles
- DuplicateHandle - copy handles between processes
- Pseudo-handles - special values like GetCurrentProcess()


Instruction: How do attackers abuse Windows Handle System?

Output:
Attack vectors involving Windows Handle System:

- Handle inheritance to access parent process objects
- DuplicateHandle for cross-process token theft
- Handle leaking from privileged processes
- Enumerating handles to find targets

**MITRE ATT&CK**: T1134


Instruction: What forensic artifacts does Windows Handle System leave?

Output:
Forensic artifacts for Windows Handle System:

- Handle table dumps
- Handle access rights
- Object reference counts


Instruction: How does Windows Object Manager work?

Output: The Object Manager is the kernel executive component managing all named objects in a hierarchical namespace. Objects include files, devices, registry keys, events, mutexes, and sections. The namespace starts at \ with directories like \Device, \BaseNamedObjects, \Sessions. Understanding object names is crucial for IPC and persistence analysis.


Instruction: What are the security implications of Windows Object Manager?

Output: Named objects enable IPC and can be abused for synchronization attacks. Object namespace hijacking can redirect operations to attacker-controlled objects.


Instruction: What elements make up Windows Object Manager?

Output:
Key components of Windows Object Manager:

- Object namespace - hierarchical object directory
- \BaseNamedObjects - global named objects
- \Sessions\X\BaseNamedObjects - per-session objects
- \Device - device objects
- \Registry - registry namespace
- OBJECT_ATTRIBUTES - structure specifying object name/attributes


Instruction: How can Windows Object Manager be exploited?

Output:
Attack vectors involving Windows Object Manager:

- Named object squatting/hijacking
- Symbolic link redirection attacks
- Device namespace manipulation
- Cross-session object access


Instruction: What indicators of Windows Object Manager can forensic analysts look for?

Output:
Forensic artifacts for Windows Object Manager:

- Object directory structure
- Named object security descriptors
- Symbolic links in namespace


Instruction: How does Registry API work?

Output: The Windows Registry is a hierarchical database storing configuration. The API (RegOpenKey, RegSetValue, RegQueryValue, etc.) provides access. Registry is heavily used for persistence, configuration storage, and system settings. Native API equivalents (NtOpenKey, etc.) exist for lower-level access.


Instruction: How does Registry API relate to security?

Output: Registry is the primary persistence mechanism on Windows. Understanding registry operations is essential for detecting malware persistence and configuration tampering.


Instruction: What elements make up Registry API?

Output:
Key components of Registry API:

- RegOpenKeyEx/RegCreateKeyEx - open/create keys
- RegSetValueEx/RegQueryValueEx - set/get values
- RegEnumKeyEx/RegEnumValue - enumerate contents
- RegNotifyChangeKeyValue - monitor changes
- HKEY predefined keys (HKLM, HKCU, HKU, etc.)


Instruction: How can Registry API be exploited?

Output:
Attack vectors involving Registry API:

- Run/RunOnce keys for persistence
- Services registry manipulation
- COM object hijacking via registry
- AppInit_DLLs injection
- Image File Execution Options debugger persistence

**MITRE ATT&CK**: T1547.001


Instruction: What forensic artifacts does Registry API leave?

Output:
Forensic artifacts for Registry API:

- Registry hive files (NTUSER.DAT, SYSTEM, SOFTWARE)
- Registry timestamps (LastWriteTime)
- Registry transaction logs


Instruction: Explain Service Control Manager API in the context of Windows.

Output: The Service Control Manager (SCM) API (OpenSCManager, CreateService, StartService, etc.) manages Windows services. Services run as background processes with configurable accounts, start types, and dependencies. SCM API is used for legitimate service management and malicious persistence.


Instruction: How does Service Control Manager API relate to security?

Output: Services provide powerful persistence running at boot with SYSTEM privileges. Attackers create malicious services or modify existing ones. Service binary hijacking is common.


Instruction: What elements make up Service Control Manager API?

Output:
Key components of Service Control Manager API:

- OpenSCManager - connect to SCM
- CreateService - install new service
- OpenService - open existing service
- StartService/ControlService - control service state
- ChangeServiceConfig - modify service properties
- QueryServiceStatus - check service state


Instruction: How do attackers abuse Service Control Manager API?

Output:
Attack vectors involving Service Control Manager API:

- Creating malicious services for persistence
- Service binary path manipulation
- DLL hijacking in service load paths
- Modifying existing service configurations
- Service account privilege abuse

**MITRE ATT&CK**: T1543.003


Instruction: What indicators of Service Control Manager API can forensic analysts look for?

Output:
Forensic artifacts for Service Control Manager API:

- Services registry key (HKLM\SYSTEM\CurrentControlSet\Services)
- Service binaries on disk
- Service creation/modification events


Instruction: How does Security Descriptors and ACLs work?

Output: Security Descriptors define access control for securable objects (files, registry keys, processes, etc.). They contain an owner SID, group SID, DACL (Discretionary Access Control List) specifying permissions, and SACL (System ACL) for auditing. Understanding security descriptors is essential for privilege analysis.


Instruction: What are the security implications of Security Descriptors and ACLs?

Output: Weak DACLs enable privilege escalation. Misconfigured permissions on services, registry keys, or files are common attack vectors. SACL manipulation can disable auditing.


Instruction: What elements make up Security Descriptors and ACLs?

Output:
Key components of Security Descriptors and ACLs:

- Owner SID - object owner
- Group SID - primary group (compatibility)
- DACL - list of ACEs specifying access rights
- SACL - audit ACEs for logging access
- ACE (Access Control Entry) - individual permission rule
- Inheritance flags - propagation to child objects


Instruction: How can Security Descriptors and ACLs be exploited?

Output:
Attack vectors involving Security Descriptors and ACLs:

- Exploiting weak DACLs on services for escalation
- File permission abuse (writable service binaries)
- Registry key permission exploitation
- Token manipulation affecting security context
- SACL modification to evade auditing


Instruction: What forensic artifacts does Security Descriptors and ACLs leave?

Output:
Forensic artifacts for Security Descriptors and ACLs:

- Security descriptors on objects
- ACL inheritance patterns
- Audit logs from SACLs


Instruction: Describe Token Manipulation APIs and its purpose.

Output: Access tokens contain the security context of processes/threads: user SID, group SIDs, privileges, and integrity level. Token APIs (OpenProcessToken, DuplicateToken, AdjustTokenPrivileges, SetThreadToken) allow examining and modifying tokens for privilege escalation and impersonation.


Instruction: Why is Token Manipulation APIs security-relevant?

Output: Token manipulation is central to privilege escalation and lateral movement. Stealing and impersonating tokens allows assuming another user's identity. Enabling privileges like SeDebugPrivilege unlocks powerful capabilities.


Instruction: What elements make up Token Manipulation APIs?

Output:
Key components of Token Manipulation APIs:

- OpenProcessToken/OpenThreadToken - get token handle
- DuplicateToken/DuplicateTokenEx - copy token
- AdjustTokenPrivileges - enable/disable privileges
- SetThreadToken - impersonate via thread token
- ImpersonateLoggedOnUser - impersonate user
- CreateProcessWithTokenW - spawn process with token


Instruction: How do attackers abuse Token Manipulation APIs?

Output:
Attack vectors involving Token Manipulation APIs:

- Token theft and impersonation
- Privilege escalation via SeDebugPrivilege
- Incognito-style token manipulation
- Pass-the-token attacks
- Primary token replacement

**MITRE ATT&CK**: T1134.001


Instruction: What evidence can be found from Token Manipulation APIs activity?

Output:
Forensic artifacts for Token Manipulation APIs:

- Token contents (user, groups, privileges)
- Impersonation level
- Token source and statistics


Instruction: How does Windows Privileges work?

Output: Privileges are rights allowing specific system operations. Key privileges include SeDebugPrivilege (debug any process), SeBackupPrivilege (bypass file ACLs for reading), SeRestorePrivilege (bypass ACLs for writing), SeTakeOwnershipPrivilege, and SeImpersonatePrivilege. Privileges must be enabled in the token before use.


Instruction: How does Windows Privileges relate to security?

Output: Privileges enable powerful operations. SeDebugPrivilege allows reading LSASS memory. SeBackupPrivilege bypasses file permissions. Privilege abuse is key for escalation.


Instruction: What elements make up Windows Privileges?

Output:
Key components of Windows Privileges:

- SeDebugPrivilege - debug any process
- SeBackupPrivilege - read any file (backup semantics)
- SeRestorePrivilege - write any file (restore semantics)
- SeTakeOwnershipPrivilege - take ownership of objects
- SeImpersonatePrivilege - impersonate clients
- SeLoadDriverPrivilege - load kernel drivers
- SeAssignPrimaryTokenPrivilege - assign process tokens


Instruction: How do attackers abuse Windows Privileges?

Output:
Attack vectors involving Windows Privileges:

- SeDebugPrivilege for credential dumping from LSASS
- SeBackupPrivilege for reading SAM/SYSTEM hives
- SeLoadDriverPrivilege for vulnerable driver loading
- SeImpersonatePrivilege for potato attacks
- SeTcbPrivilege for token manipulation

**MITRE ATT&CK**: T1134.002


Instruction: What forensic artifacts does Windows Privileges leave?

Output:
Forensic artifacts for Windows Privileges:

- Token privilege list
- Privilege enabled/disabled state
- Audit logs for privilege usage


Instruction: How does OpenProcess API work?

Output: OpenProcess obtains a handle to another process with specified access rights. Access rights like PROCESS_ALL_ACCESS, PROCESS_VM_READ, PROCESS_VM_WRITE, and PROCESS_CREATE_THREAD determine what operations are permitted. It's the entry point for most cross-process attacks.


Instruction: Why is OpenProcess API security-relevant?

Output: OpenProcess is required for process injection, credential theft, and process manipulation. Monitoring OpenProcess calls reveals targeting patterns.


Instruction: What are the components of OpenProcess API?

Output:
Key components of OpenProcess API:

- PROCESS_ALL_ACCESS - full control
- PROCESS_VM_READ - read memory
- PROCESS_VM_WRITE - write memory
- PROCESS_VM_OPERATION - change memory protections
- PROCESS_CREATE_THREAD - create threads
- PROCESS_QUERY_INFORMATION - query process info


Instruction: What attack vectors use OpenProcess API?

Output:
Attack vectors involving OpenProcess API:

- Opening LSASS for credential dumping
- Opening target processes for injection
- Process memory reading for secrets
- Process handle inheritance abuse

**MITRE ATT&CK**: T1003.001


Instruction: What evidence can be found from OpenProcess API activity?

Output:
Forensic artifacts for OpenProcess API:

- Process handle grants in security logs
- Handle access masks
- Cross-process relationships


Instruction: How does CreateRemoteThread API work?

Output: CreateRemoteThread creates a thread in another process's address space. Combined with VirtualAllocEx and WriteProcessMemory, it enables classic DLL injection by starting a thread at LoadLibrary with a DLL path argument. CreateRemoteThreadEx provides additional options.


Instruction: How does CreateRemoteThread API relate to security?

Output: CreateRemoteThread is the classic injection API. Nearly all injection techniques eventually create a remote thread. It's heavily monitored by security products.


Instruction: What elements make up CreateRemoteThread API?

Output:
Key components of CreateRemoteThread API:

- CreateRemoteThread - create thread in remote process
- CreateRemoteThreadEx - extended version with attributes
- Thread start address - where thread begins execution
- lpParameter - argument passed to thread function
- NtCreateThreadEx - native API equivalent


Instruction: How can CreateRemoteThread API be exploited?

Output:
Attack vectors involving CreateRemoteThread API:

- Classic DLL injection (LoadLibrary thread)
- Shellcode injection (direct execution)
- Reflective DLL loading
- Thread hijacking combined with CreateRemoteThread

**MITRE ATT&CK**: T1055.001


Instruction: What evidence can be found from CreateRemoteThread API activity?

Output:
Forensic artifacts for CreateRemoteThread API:

- Remote thread creation events
- Thread start address analysis
- Cross-process relationships


Instruction: Describe WriteProcessMemory API and its purpose.

Output: WriteProcessMemory writes data to another process's address space. It requires a process handle with PROCESS_VM_WRITE and PROCESS_VM_OPERATION access. Used legitimately by debuggers, it's also essential for injection attacks to write shellcode or DLL paths.


Instruction: From a security perspective, why is understanding WriteProcessMemory API important?

Output: Cross-process memory writing is a key injection primitive. Legitimate uses are rare outside debugging. Monitoring reveals injection attempts.


Instruction: What elements make up WriteProcessMemory API?

Output:
Key components of WriteProcessMemory API:

- WriteProcessMemory - write to remote process
- ReadProcessMemory - read from remote process
- NtWriteVirtualMemory - native API equivalent
- Required access: PROCESS_VM_WRITE | PROCESS_VM_OPERATION


Instruction: What attack vectors use WriteProcessMemory API?

Output:
Attack vectors involving WriteProcessMemory API:

- Writing shellcode for injection
- Writing DLL paths for LoadLibrary injection
- Modifying remote process code/data
- Process hollowing payload placement

**MITRE ATT&CK**: T1055


Instruction: What forensic artifacts does WriteProcessMemory API leave?

Output:
Forensic artifacts for WriteProcessMemory API:

- Memory write events
- Written data patterns
- Target region analysis


Instruction: How does NtQuerySystemInformation work?

Output: NtQuerySystemInformation queries various system information classes: running processes, loaded modules, handles, firmware tables, and more. It's the backbone of many enumeration tools but also used by malware for reconnaissance and anti-analysis checks.


Instruction: How does NtQuerySystemInformation relate to security?

Output: This API enables comprehensive system enumeration. Attackers use it for process discovery, handle enumeration (finding injection targets), and anti-analysis checks.


Instruction: What elements make up NtQuerySystemInformation?

Output:
Key components of NtQuerySystemInformation:

- SystemProcessInformation - enumerate processes
- SystemModuleInformation - kernel modules
- SystemHandleInformation - all system handles
- SystemKernelDebuggerInformation - debugger detection
- SystemFirmwareTableInformation - hardware info
- SystemCodeIntegrityInformation - CI status


Instruction: How do attackers abuse NtQuerySystemInformation?

Output:
Attack vectors involving NtQuerySystemInformation:

- Process enumeration for targeting
- Handle enumeration for token theft
- Debugger detection for anti-analysis
- Driver enumeration for vulnerability finding


Instruction: What evidence can be found from NtQuerySystemInformation activity?

Output:
Forensic artifacts for NtQuerySystemInformation:

- System information query results
- Process/handle enumeration data
- Anti-debug check patterns


Instruction: Describe Process Creation Internals and its purpose.

Output: CreateProcess (and NtCreateProcess/NtCreateUserProcess) creates new processes. The process involves creating the process object, allocating address space, mapping the executable, creating the initial thread, and notifying subsystems. Understanding internals enables detection of process creation manipulation.


Instruction: Why is Process Creation Internals security-relevant?

Output: Process creation is heavily logged and monitored. Attackers manipulate creation parameters, use suspended creation, or abuse parent PID spoofing to evade detection.


Instruction: Describe the structure of Process Creation Internals.

Output:
Key components of Process Creation Internals:

- CreateProcessW/A - Win32 process creation
- NtCreateUserProcess - modern NT API
- Process object creation in kernel
- Address space initialization
- PEB (Process Environment Block) setup
- Initial thread creation
- Image load callbacks


Instruction: How do attackers abuse Process Creation Internals?

Output:
Attack vectors involving Process Creation Internals:

- Parent PID spoofing
- Process hollowing via CREATE_SUSPENDED
- Command line manipulation
- Environment variable injection
- Desktop/station attacks

**MITRE ATT&CK**: T1055.012


Instruction: What indicators of Process Creation Internals can forensic analysts look for?

Output:
Forensic artifacts for Process Creation Internals:

- Process creation events
- Parent PID relationships
- Command line arguments
- Creation flags used


Instruction: Explain SetWindowsHookEx API in the context of Windows.

Output: SetWindowsHookEx installs hook procedures that intercept Windows messages, keyboard input, mouse events, and more. Hooks can be system-wide (requiring a DLL) or thread-specific. Used legitimately for accessibility and automation, but abused for keylogging and DLL injection.


Instruction: How does SetWindowsHookEx API relate to security?

Output: SetWindowsHookEx enables keylogging and automatic DLL injection into GUI processes. Low-level keyboard hooks (WH_KEYBOARD_LL) are especially dangerous for credential theft.


Instruction: What are the components of SetWindowsHookEx API?

Output:
Key components of SetWindowsHookEx API:

- WH_KEYBOARD/WH_KEYBOARD_LL - keyboard hooks
- WH_MOUSE/WH_MOUSE_LL - mouse hooks
- WH_CBT - computer-based training events
- WH_GETMESSAGE - message hooks
- Hook DLL - injected into hooked processes
- Hook chain - multiple hooks called in sequence


Instruction: What are common attacks involving SetWindowsHookEx API?

Output:
Attack vectors involving SetWindowsHookEx API:

- Keylogging via keyboard hooks
- DLL injection via hook DLL loading
- Mouse tracking for activity monitoring
- Message interception and manipulation

**MITRE ATT&CK**: T1056.001


Instruction: What evidence can be found from SetWindowsHookEx API activity?

Output:
Forensic artifacts for SetWindowsHookEx API:

- Hook chain in USER32 data
- Hook DLLs loaded in multiple processes
- Keyboard hook API calls


Instruction: What is MiniDumpWriteDump API?

Output: MiniDumpWriteDump (dbghelp.dll) creates process memory dumps. It's the API behind tools like procdump and is commonly used by attackers to dump LSASS memory for credential extraction. Various dump types control what's included (full memory, handles, threads, etc.).


Instruction: Why is MiniDumpWriteDump API security-relevant?

Output: MiniDumpWriteDump on LSASS is the most common credential dumping technique. Detecting and preventing LSASS dumps is critical for credential protection.


Instruction: Describe the structure of MiniDumpWriteDump API.

Output:
Key components of MiniDumpWriteDump API:

- MiniDumpWriteDump - create crash dump
- MINIDUMP_TYPE flags - control dump contents
- MiniDumpWithFullMemory - complete memory dump
- MiniDumpWithHandleData - include handles
- dbghelp.dll / dbgcore.dll - dump libraries


Instruction: What are common attacks involving MiniDumpWriteDump API?

Output:
Attack vectors involving MiniDumpWriteDump API:

- LSASS memory dumping for credentials
- Dumping other processes for secrets
- Offline analysis of sensitive process memory

**MITRE ATT&CK**: T1003.001


Instruction: What forensic artifacts does MiniDumpWriteDump API leave?

Output:
Forensic artifacts for MiniDumpWriteDump API:

- Dump files (.dmp, .mdmp)
- LSASS access events
- dbghelp.dll usage patterns


Instruction: How does Linux Syscall Mechanics work?

Output: Syscalls are the interface between user space and kernel. On x86, int 0x80 was used historically; modern x86_64 uses the syscall instruction. The syscall number goes in RAX, arguments in RDI, RSI, RDX, R10, R8, R9. The kernel's syscall table dispatches to handlers. VDSO optimizes some syscalls to avoid kernel transitions.


Instruction: Why is Linux Syscall Mechanics security-relevant?

Output: Understanding syscall mechanics enables exploit development, syscall filtering (seccomp), and security monitoring. Direct syscalls bypass library hooks.


Instruction: What elements make up Linux Syscall Mechanics?

Output:
Key components of Linux Syscall Mechanics:

- syscall instruction (x86_64) - fast syscall entry
- int 0x80 (x86) - legacy syscall method
- RAX - syscall number
- RDI, RSI, RDX, R10, R8, R9 - arguments
- syscall table - kernel dispatch table
- VDSO - virtual dynamic shared object for fast syscalls
- vsyscall page - legacy fast syscall mechanism


Instruction: What attack vectors use Linux Syscall Mechanics?

Output:
Attack vectors involving Linux Syscall Mechanics:

- Direct syscalls bypassing library monitoring
- Syscall number manipulation
- VDSO exploitation for code execution
- Syscall table hooking (rootkits)


Instruction: What indicators of Linux Syscall Mechanics can forensic analysts look for?

Output:
Forensic artifacts for Linux Syscall Mechanics:

- Syscall traces in strace output
- Audit logs with syscall numbers
- /proc/pid/syscall - current syscall


Instruction: How does fork, clone, and execve work?

Output: fork() creates a child process by duplicating the parent. clone() is more flexible, allowing shared resources (memory, file descriptors) and is used for threads. execve() replaces the current process image with a new program. Together, fork+execve is the standard process creation pattern.


Instruction: How does fork, clone, and execve relate to security?

Output: Process creation is fundamental for malware execution. Understanding fork/exec enables detection and containment. clone flags affect isolation.


Instruction: Describe the structure of fork, clone, and execve.

Output:
Key components of fork, clone, and execve:

- fork() - duplicate process (copy-on-write)
- vfork() - optimized fork (shared memory until exec)
- clone() - configurable process/thread creation
- clone flags - CLONE_VM, CLONE_FILES, CLONE_THREAD, etc.
- execve() - execute new program
- exec family - execl, execv, execvp wrappers


Instruction: How do attackers abuse fork, clone, and execve?

Output:
Attack vectors involving fork, clone, and execve:

- Fork bombs (denial of service)
- execve for payload execution
- Clone flag manipulation for sandbox escape
- Fork timing attacks

**MITRE ATT&CK**: T1059


Instruction: What evidence can be found from fork, clone, and execve activity?

Output:
Forensic artifacts for fork, clone, and execve:

- Process creation events in audit log
- Parent-child relationships
- execve arguments and environment


Instruction: Explain ptrace Syscall in the context of Linux.

Output: ptrace() enables one process to observe and control another. It's used by debuggers, strace, and injection techniques. Operations include PTRACE_ATTACH (attach to process), PTRACE_PEEKDATA/POKEDATA (read/write memory), PTRACE_GETREGS/SETREGS (manipulate registers), and PTRACE_SYSCALL (trace syscalls).


Instruction: What are the security implications of ptrace Syscall?

Output: ptrace enables debugging but also process injection and anti-debugging. Yama LSM provides ptrace_scope to restrict ptrace between processes.


Instruction: What elements make up ptrace Syscall?

Output:
Key components of ptrace Syscall:

- PTRACE_ATTACH - attach to running process
- PTRACE_PEEKDATA/POKEDATA - memory read/write
- PTRACE_GETREGS/SETREGS - register manipulation
- PTRACE_SYSCALL - stop at syscall entry/exit
- PTRACE_CONT - continue execution
- PTRACE_DETACH - detach from process


Instruction: What are common attacks involving ptrace Syscall?

Output:
Attack vectors involving ptrace Syscall:

- Process injection via ptrace memory writes
- Credential harvesting from process memory
- Anti-debugging (detect ptrace attachment)
- Syscall manipulation via register modification

**MITRE ATT&CK**: T1055.008


Instruction: What indicators of ptrace Syscall can forensic analysts look for?

Output:
Forensic artifacts for ptrace Syscall:

- TracerPid in /proc/pid/status
- ptrace syscall audit events
- Yama configuration


Instruction: Describe mmap and mprotect and its purpose.

Output: mmap() creates memory mappings - either anonymous (not backed by file) or file-backed. It's used for shared libraries, memory allocation, and shared memory. mprotect() changes memory protection (read/write/execute). These are fundamental for memory management and exploitation.


Instruction: Why is mmap and mprotect security-relevant?

Output: mmap with PROT_EXEC enables code execution. mprotect changing to executable is suspicious. Anonymous executable mappings indicate shellcode.


Instruction: What are the components of mmap and mprotect?

Output:
Key components of mmap and mprotect:

- mmap() - create memory mapping
- munmap() - remove mapping
- mprotect() - change page protections
- MAP_PRIVATE - copy-on-write mapping
- MAP_SHARED - shared mapping
- MAP_ANONYMOUS - not backed by file
- PROT_READ, PROT_WRITE, PROT_EXEC - protection flags


Instruction: How can mmap and mprotect be exploited?

Output:
Attack vectors involving mmap and mprotect:

- Allocating executable memory for shellcode
- mprotect to enable execution (bypass DEP)
- File mapping for code loading
- Shared memory for IPC attacks


Instruction: What forensic artifacts does mmap and mprotect leave?

Output:
Forensic artifacts for mmap and mprotect:

- /proc/pid/maps showing memory regions
- mmap/mprotect audit events
- Executable memory patterns


Instruction: How does File Syscalls (open, read, write) work?

Output: open() (or openat()) opens files returning a file descriptor. read() and write() transfer data. close() releases descriptors. Understanding these syscalls is essential for file access monitoring, detecting exfiltration, and analyzing malware file operations.


Instruction: Why is File Syscalls (open, read, write) security-relevant?

Output: File access patterns reveal malware behavior: reading credentials, writing payloads, accessing sensitive files. Monitoring these syscalls enables detection.


Instruction: What elements make up File Syscalls (open, read, write)?

Output:
Key components of File Syscalls (open, read, write):

- open/openat - open file, return fd
- read/pread - read data from fd
- write/pwrite - write data to fd
- close - release file descriptor
- O_RDONLY, O_WRONLY, O_RDWR - access modes
- O_CREAT, O_TRUNC, O_APPEND - creation flags


Instruction: How can File Syscalls (open, read, write) be exploited?

Output:
Attack vectors involving File Syscalls (open, read, write):

- Reading credential files (/etc/shadow)
- Writing persistent backdoors
- Accessing process memory via /proc/pid/mem
- Log tampering via truncation/overwrite


Instruction: What evidence can be found from File Syscalls (open, read, write) activity?

Output:
Forensic artifacts for File Syscalls (open, read, write):

- File access audit logs
- File timestamps (atime, mtime)
- Process file descriptor table (/proc/pid/fd)


Instruction: Describe ioctl Syscall and its purpose.

Output: ioctl() performs device-specific operations on file descriptors. It's a catch-all for operations not fitting read/write semantics. Common uses include terminal control, disk operations, and network configuration. Many kernel vulnerabilities exist in ioctl handlers.


Instruction: Why is ioctl Syscall security-relevant?

Output: ioctl handlers are common vulnerability targets due to complex parsing of user input. Kernel exploits often target driver ioctls for privilege escalation.


Instruction: What elements make up ioctl Syscall?

Output:
Key components of ioctl Syscall:

- ioctl(fd, request, arg) - device control
- Request codes - device-specific commands
- TIOCGWINSZ, TCGETS - terminal ioctls
- FIONREAD, SIOCGIFADDR - socket ioctls
- Custom driver ioctls - device-specific


Instruction: What attack vectors use ioctl Syscall?

Output:
Attack vectors involving ioctl Syscall:

- Kernel driver ioctl vulnerabilities
- Race conditions in ioctl handlers
- Information leaks via ioctl
- Container escape via device ioctls

**MITRE ATT&CK**: T1068


Instruction: What forensic artifacts does ioctl Syscall leave?

Output:
Forensic artifacts for ioctl Syscall:

- ioctl audit events
- Device access patterns
- Kernel driver interactions


Instruction: How does Signal Handling work?

Output: Signals are asynchronous notifications to processes. sigaction() sets signal handlers. Key signals include SIGTERM, SIGKILL, SIGSEGV, SIGSTOP, and real-time signals. Signal handlers run in user context and can be exploited for control flow manipulation.


Instruction: How does Signal Handling relate to security?

Output: Signal handlers can be exploited for code execution if they have vulnerabilities. Signal injection can disrupt or manipulate target processes.


Instruction: Describe the structure of Signal Handling.

Output:
Key components of Signal Handling:

- sigaction() - set signal handler
- signal() - legacy handler setup
- kill() - send signal to process
- sigqueue() - send signal with data
- SIGTERM, SIGKILL - termination signals
- SIGSEGV, SIGBUS - fault signals
- SIGSTOP, SIGCONT - process control


Instruction: What are common attacks involving Signal Handling?

Output:
Attack vectors involving Signal Handling:

- Signal handler exploitation
- SIGSTOP for process freezing
- Signal race conditions
- Signal-based injection techniques


Instruction: What indicators of Signal Handling can forensic analysts look for?

Output:
Forensic artifacts for Signal Handling:

- Signal delivery audit events
- Process signal masks (/proc/pid/status)
- Core dumps from fault signals


Instruction: Explain Linux Namespace Syscalls in the context of Linux.

Output: Namespaces provide isolation for various system resources. unshare() creates new namespaces. setns() joins existing namespaces. clone() with namespace flags creates processes in new namespaces. Types include PID, network, mount, user, UTS, IPC, and cgroup namespaces.


Instruction: How does Linux Namespace Syscalls relate to security?

Output: Namespaces are containers' isolation foundation. User namespaces enable unprivileged container creation. Namespace escapes compromise container security.


Instruction: What are the components of Linux Namespace Syscalls?

Output:
Key components of Linux Namespace Syscalls:

- unshare() - create new namespaces
- setns() - join existing namespace
- CLONE_NEWPID - new PID namespace
- CLONE_NEWNET - new network namespace
- CLONE_NEWNS - new mount namespace
- CLONE_NEWUSER - new user namespace
- CLONE_NEWUTS - new UTS namespace
- CLONE_NEWIPC - new IPC namespace


Instruction: What are common attacks involving Linux Namespace Syscalls?

Output:
Attack vectors involving Linux Namespace Syscalls:

- Container escape via namespace manipulation
- User namespace for privilege escalation
- Mount namespace escapes
- Network namespace pivoting

**MITRE ATT&CK**: T1611


Instruction: What indicators of Linux Namespace Syscalls can forensic analysts look for?

Output:
Forensic artifacts for Linux Namespace Syscalls:

- /proc/pid/ns/* namespace files
- Namespace hierarchy
- Container configuration


Instruction: What is seccomp (Secure Computing)?

Output: seccomp filters syscalls a process can make. Strict mode allows only read, write, exit, sigreturn. Filter mode (seccomp-bpf) uses BPF programs to make per-syscall decisions: allow, kill, errno, trace, or log. It's a fundamental sandbox mechanism.


Instruction: From a security perspective, why is understanding seccomp (Secure Computing) important?

Output: seccomp significantly reduces attack surface by limiting available syscalls. Container runtimes and sandboxes rely on seccomp for isolation.


Instruction: What elements make up seccomp (Secure Computing)?

Output:
Key components of seccomp (Secure Computing):

- seccomp() syscall - enable seccomp
- SECCOMP_MODE_STRICT - minimal syscalls only
- SECCOMP_MODE_FILTER - BPF-based filtering
- BPF program - filter logic
- SECCOMP_RET_ALLOW, KILL, ERRNO, TRACE - actions
- Secure computing state - inherited by children


Instruction: How do attackers abuse seccomp (Secure Computing)?

Output:
Attack vectors involving seccomp (Secure Computing):

- seccomp bypass via allowed syscalls
- Kernel vulnerability in allowed syscall
- Time-of-check time-of-use in filters
- Filter weaknesses allowing escalation


Instruction: What indicators of seccomp (Secure Computing) can forensic analysts look for?

Output:
Forensic artifacts for seccomp (Secure Computing):

- Seccomp field in /proc/pid/status
- seccomp audit events
- BPF filter programs


Instruction: Explain eBPF for Security Monitoring in the context of Linux.

Output: eBPF (extended Berkeley Packet Filter) allows running sandboxed programs in the kernel. It's used for networking, tracing, and security monitoring. Programs attach to tracepoints, kprobes, uprobes, and other hook points. eBPF enables powerful syscall and event monitoring.


Instruction: What are the security implications of eBPF for Security Monitoring?

Output: eBPF powers modern security tools (Falco, Cilium, bpftrace). It provides deep visibility without kernel modification. However, eBPF itself can be abused for rootkit-like capabilities.


Instruction: What elements make up eBPF for Security Monitoring?

Output:
Key components of eBPF for Security Monitoring:

- bpf() syscall - load/manage eBPF programs
- Tracepoints - stable kernel trace points
- Kprobes/Kretprobes - kernel function tracing
- Uprobes - user-space function tracing
- eBPF maps - data structures shared with userspace
- BPF Type Format (BTF) - type information
- BPF CO-RE - compile once, run everywhere


Instruction: How can eBPF for Security Monitoring be exploited?

Output:
Attack vectors involving eBPF for Security Monitoring:

- eBPF for hiding processes/files (rootkit)
- Network manipulation via eBPF
- Credential harvesting from eBPF hooks
- eBPF verifier bypass vulnerabilities


Instruction: What indicators of eBPF for Security Monitoring can forensic analysts look for?

Output:
Forensic artifacts for eBPF for Security Monitoring:

- Loaded eBPF programs (bpftool prog list)
- eBPF maps
- Kernel tracing output


Instruction: Explain /proc/pid/mem Access in the context of Linux.

Output: /proc/pid/mem provides direct access to a process's virtual memory. With appropriate permissions (same user or CAP_SYS_PTRACE), it allows reading and writing process memory without ptrace. This enables process inspection and injection.


Instruction: What are the security implications of /proc/pid/mem Access?

Output: /proc/pid/mem enables process memory access for debugging, analysis, and injection. It's an alternative to ptrace for memory operations.


Instruction: Describe the structure of /proc/pid/mem Access.

Output:
Key components of /proc/pid/mem Access:

- /proc/pid/mem - memory pseudofile
- /proc/pid/maps - memory layout
- lseek + read/write - memory access
- process_vm_readv/writev - efficient cross-process I/O
- Permission requirements - ptrace capability needed


Instruction: How can /proc/pid/mem Access be exploited?

Output:
Attack vectors involving /proc/pid/mem Access:

- Process injection via /proc/pid/mem
- Credential extraction from process memory
- Code modification in running processes
- Bypass library hooks via direct memory access

**MITRE ATT&CK**: T1055.009


Instruction: What forensic artifacts does /proc/pid/mem Access leave?

Output:
Forensic artifacts for /proc/pid/mem Access:

- File access audit logs for /proc/*/mem
- Memory modifications
- Cross-process memory operations


Instruction: How does memfd create Syscall work?

Output: memfd_create() creates anonymous memory-backed file descriptors. The resulting fd can be used with mmap, passed to other processes, and executed with fexecve() or execveat(). It enables fileless execution without touching the filesystem.


Instruction: Why is memfd create Syscall security-relevant?

Output: memfd_create enables fileless malware execution. Combined with execveat(AT_EMPTY_PATH), code can run without ever touching disk, evading file-based detection.


Instruction: Describe the structure of memfd create Syscall.

Output:
Key components of memfd create Syscall:

- memfd_create() - create anonymous fd
- MFD_CLOEXEC - close on exec flag
- MFD_ALLOW_SEALING - enable sealing
- fexecve()/execveat() - execute from fd
- Memory-backed execution - no file on disk


Instruction: What are common attacks involving memfd create Syscall?

Output:
Attack vectors involving memfd create Syscall:

- Fileless malware execution
- Memory-only payload deployment
- Bypassing file monitoring
- Anonymous shared memory creation

**MITRE ATT&CK**: T1620


Instruction: What indicators of memfd create Syscall can forensic analysts look for?

Output:
Forensic artifacts for memfd create Syscall:

- /proc/pid/fd entries showing 'memfd:'
- memfd_create audit events
- execveat syscalls with AT_EMPTY_PATH


Instruction: What is prctl Syscall?

Output: prctl() performs various process control operations: setting process name, controlling signal behavior, managing capabilities, enabling/disabling features like core dumps, and security-related operations like enabling seccomp or setting no_new_privs.


Instruction: What are the security implications of prctl Syscall?

Output: prctl sets important security properties. no_new_privs is required for unprivileged seccomp. Process name changes can aid evasion.


Instruction: What are the components of prctl Syscall?

Output:
Key components of prctl Syscall:

- PR_SET_NAME - set process name
- PR_SET_SECCOMP - enable seccomp
- PR_SET_NO_NEW_PRIVS - prevent privilege gains
- PR_SET_DUMPABLE - control core dump behavior
- PR_CAP_AMBIENT - ambient capabilities
- PR_SET_MM - modify memory map parameters


Instruction: What attack vectors use prctl Syscall?

Output:
Attack vectors involving prctl Syscall:

- Process name spoofing for evasion
- Disabling core dumps to hide crashes
- Manipulating capabilities
- Memory descriptor modification


Instruction: What evidence can be found from prctl Syscall activity?

Output:
Forensic artifacts for prctl Syscall:

- Process name in /proc/pid/comm
- prctl audit events
- Process capabilities


Instruction: How does Classic DLL Injection work?

Output: Classic DLL injection allocates memory in a target process using VirtualAllocEx, writes a DLL path using WriteProcessMemory, then creates a remote thread with CreateRemoteThread pointing to LoadLibraryA to load the malicious DLL. This is the foundational injection technique.


Instruction: Why is Classic DLL Injection security-relevant?

Output: This technique allows executing arbitrary code in another process's context, inheriting its privileges and trust level. It's heavily monitored but still commonly used.


Instruction: Describe the structure of Classic DLL Injection.

Output:
Key components of Classic DLL Injection:

- OpenProcess with PROCESS_ALL_ACCESS
- VirtualAllocEx to allocate memory for DLL path
- WriteProcessMemory to write DLL path string
- GetProcAddress to resolve LoadLibraryA address
- CreateRemoteThread targeting LoadLibraryA with DLL path as argument


Instruction: How can Classic DLL Injection be exploited?

Output:
Attack vectors involving Classic DLL Injection:

- Injecting into trusted processes (explorer.exe, svchost.exe)
- Credential theft by injecting into lsass.exe
- Bypassing per-process security controls
- Keylogging via injection into target applications

**MITRE ATT&CK**: T1055.001


Instruction: What indicators of Classic DLL Injection can forensic analysts look for?

Output:
Forensic artifacts for Classic DLL Injection:

- Loaded DLL in target's module list
- Remote thread creation events
- DLL file on disk (unless deleted)
- Memory allocation in target process


Instruction: What is Reflective DLL Injection?

Output: Reflective DLL injection uses a DLL containing its own loader that manually maps the DLL into memory without using LoadLibrary. The reflective loader parses PE headers, allocates memory, maps sections, resolves imports, and executes TLS callbacks. This bypasses DLL load monitoring.


Instruction: From a security perspective, why is understanding Reflective DLL Injection important?

Output: Reflective injection is stealthier than classic injection as LoadLibrary is never called. The DLL doesn't appear in standard module lists and may never touch disk.


Instruction: Describe the structure of Reflective DLL Injection.

Output:
Key components of Reflective DLL Injection:

- Reflective loader stub in DLL
- Manual PE header parsing
- Section mapping with correct permissions
- Import Address Table (IAT) resolution
- Relocation processing for base address
- TLS callback execution
- Entry point invocation


Instruction: What attack vectors use Reflective DLL Injection?

Output:
Attack vectors involving Reflective DLL Injection:

- Memory-only malware execution
- EDR evasion (no LoadLibrary hooks)
- Cobalt Strike, Metasploit payloads
- APT toolkits using reflective loading

**MITRE ATT&CK**: T1620


Instruction: What forensic artifacts does Reflective DLL Injection leave?

Output:
Forensic artifacts for Reflective DLL Injection:

- PE structure in unbacked memory
- Missing entry in PEB->Ldr module list
- Reflective loader stub patterns
- RWX memory allocations


Instruction: How does Process Hollowing work?

Output: Process hollowing creates a legitimate process in suspended state, unmaps its memory using ZwUnmapViewOfSection, writes malicious code to the hollowed process, adjusts the thread context to point to the new entry point, and resumes execution. The process masquerades as legitimate.


Instruction: How does Process Hollowing relate to security?

Output: Process hollowing allows malware to masquerade as a legitimate process, inheriting its name, path, and trust level while executing entirely different code.


Instruction: What are the components of Process Hollowing?

Output:
Key components of Process Hollowing:

- CreateProcess with CREATE_SUSPENDED flag
- ZwUnmapViewOfSection to hollow the process image
- VirtualAllocEx to allocate space for payload
- WriteProcessMemory to write malicious PE
- SetThreadContext to update entry point (RIP/EIP)
- ResumeThread to begin execution


Instruction: How can Process Hollowing be exploited?

Output:
Attack vectors involving Process Hollowing:

- Masquerading as svchost.exe or other system processes
- Evading process-name-based allowlisting
- Bypassing parent-child process analysis
- Running malware under legitimate process identity

**MITRE ATT&CK**: T1055.012


Instruction: What indicators of Process Hollowing can forensic analysts look for?

Output:
Forensic artifacts for Process Hollowing:

- Suspended process followed by resume
- Unmapped original executable sections
- Mismatched disk and memory images
- Modified thread context


Instruction: Describe Thread Hijacking and its purpose.

Output: Thread hijacking suspends an existing thread in a target process, saves its context, modifies the instruction pointer to point to malicious code, and resumes the thread. After execution, the original context can be restored. This avoids creating new threads.


Instruction: How does Thread Hijacking relate to security?

Output: Thread hijacking doesn't create new threads, potentially evading CreateRemoteThread monitoring. It's stealthier but more complex to implement reliably.


Instruction: What elements make up Thread Hijacking?

Output:
Key components of Thread Hijacking:

- OpenThread with THREAD_ALL_ACCESS
- SuspendThread to pause target thread
- GetThreadContext to save original context
- VirtualAllocEx/WriteProcessMemory for payload
- SetThreadContext to redirect execution
- ResumeThread to execute payload
- Restore original context after execution


Instruction: How can Thread Hijacking be exploited?

Output:
Attack vectors involving Thread Hijacking:

- Evading CreateRemoteThread detection
- Hijacking system threads for execution
- Stealth code execution in existing threads
- Combining with other injection techniques

**MITRE ATT&CK**: T1055.003


Instruction: What indicators of Thread Hijacking can forensic analysts look for?

Output:
Forensic artifacts for Thread Hijacking:

- Thread context modification events
- Suspended thread states
- Instruction pointer changes
- Memory allocations near hijack time


Instruction: What is APC Injection?

Output: Asynchronous Procedure Call (APC) injection queues a user-mode APC to a thread using QueueUserAPC. When the thread enters an alertable wait state, the APC executes. Early bird injection combines this with suspended process creation for reliable execution.


Instruction: Why is APC Injection security-relevant?

Output: APC injection is relatively simple but requires the target thread to enter alertable state. Combined with suspended process creation (early bird), it's more reliable.


Instruction: Describe the structure of APC Injection.

Output:
Key components of APC Injection:

- QueueUserAPC - queue APC to thread
- NtQueueApcThread - native API variant
- Alertable wait states - when APCs execute
- APC routine - function pointer to execute
- Thread must be in alertable state


Instruction: How do attackers abuse APC Injection?

Output:
Attack vectors involving APC Injection:

- Inject into processes with alertable threads
- Early bird: inject before process initialization
- Target system processes with known alertable waits
- Combine with process hollowing

**MITRE ATT&CK**: T1055.004


Instruction: What indicators of APC Injection can forensic analysts look for?

Output:
Forensic artifacts for APC Injection:

- APC queue events
- Alertable thread states
- Memory allocations for APC routines


Instruction: Describe Early Bird Injection and its purpose.

Output: Early bird injection creates a process in suspended state, queues an APC to the main thread, then resumes the process. The APC executes before the process's main code, during NtTestAlert in ntdll initialization. This achieves reliable execution timing.


Instruction: Why is Early Bird Injection security-relevant?

Output: Early bird injection executes code very early in process initialization, before most security products establish hooks. It's effective against user-mode security tools.


Instruction: What are the components of Early Bird Injection?

Output:
Key components of Early Bird Injection:

- CreateProcess with CREATE_SUSPENDED
- VirtualAllocEx/WriteProcessMemory for payload
- QueueUserAPC targeting main thread
- ResumeThread to start process
- APC executes during ntdll initialization


Instruction: How do attackers abuse Early Bird Injection?

Output:
Attack vectors involving Early Bird Injection:

- Executing before EDR hooks are established
- Bypassing user-mode security products
- Reliable execution timing
- Combining with masquerading as legitimate process

**MITRE ATT&CK**: T1055.004


Instruction: What forensic artifacts does Early Bird Injection leave?

Output:
Forensic artifacts for Early Bird Injection:

- CREATE_SUSPENDED process creation
- APC queued to suspended thread
- Memory allocation before resume


Instruction: How does Atom Bombing work?

Output: Atom bombing abuses the Windows global atom table to write data into target process memory. It adds a string to the atom table (GlobalAddAtom), then uses APC to trigger GlobalGetAtomName in the target, copying the string to a specified buffer. This bypasses some memory write detection.


Instruction: From a security perspective, why is understanding Atom Bombing important?

Output: Atom bombing uses legitimate Windows mechanisms for cross-process data transfer, potentially evading detection focused on WriteProcessMemory.


Instruction: What are the components of Atom Bombing?

Output:
Key components of Atom Bombing:

- GlobalAddAtom - add string to global atom table
- QueueUserAPC with GlobalGetAtomName
- Target buffer specification via APC parameter
- Atom table as shared data transport
- ROP chain for code execution after write


Instruction: How do attackers abuse Atom Bombing?

Output:
Attack vectors involving Atom Bombing:

- Bypassing WriteProcessMemory monitoring
- Injecting into processes without direct memory write
- Using legitimate APIs for malicious purposes
- Combining with code execution primitives

**MITRE ATT&CK**: T1055


Instruction: What evidence can be found from Atom Bombing activity?

Output:
Forensic artifacts for Atom Bombing:

- Atom table entries
- APC execution events
- Memory changes from atom retrieval


Instruction: What is Process Doppelgänging?

Output: Process doppelgänging abuses Windows transactional NTFS (TxF). It creates a transaction, writes malicious content to a file within the transaction, creates a process from the transacted file, then rolls back the transaction. The process runs but the malicious file never persists on disk.


Instruction: Why is Process Doppelgänging security-relevant?

Output: Process doppelgänging creates processes from files that never exist outside the transaction, evading file-based scanning and monitoring.


Instruction: What are the components of Process Doppelgänging?

Output:
Key components of Process Doppelgänging:

- CreateTransaction - begin NTFS transaction
- CreateFileTransacted - open file in transaction
- Write malicious PE to transacted file
- NtCreateSection from transacted file
- NtCreateProcessEx from section
- RollbackTransaction - undo file changes
- Process runs from rolled-back (non-existent) file


Instruction: How can Process Doppelgänging be exploited?

Output:
Attack vectors involving Process Doppelgänging:

- Fileless process execution
- Evading antivirus file scanning
- Bypassing file integrity monitoring
- Running malware without disk artifacts

**MITRE ATT&CK**: T1055.013


Instruction: What forensic artifacts does Process Doppelgänging leave?

Output:
Forensic artifacts for Process Doppelgänging:

- Transaction creation/rollback events
- Process with no corresponding disk file
- Transacted file operations


Instruction: What is Process Herpaderping?

Output: Process herpaderping writes malicious content to a file, creates a process section from it, modifies the file content to appear benign, then creates the process. Security products scanning the file see benign content while the process runs malicious code from the original section.


Instruction: What are the security implications of Process Herpaderping?

Output: Herpaderping exploits the timing gap between file writes and security product scans. The file appears benign when scanned but the process runs the original malicious content.


Instruction: Describe the structure of Process Herpaderping.

Output:
Key components of Process Herpaderping:

- CreateFile - create new file
- Write malicious PE content
- NtCreateSection - create section from malicious content
- Overwrite file with benign content
- NtCreateProcessEx from section
- File content doesn't match running process


Instruction: How can Process Herpaderping be exploited?

Output:
Attack vectors involving Process Herpaderping:

- Evading real-time file scanning
- Bypassing signature-based detection
- Mismatching file and process content
- Exploiting scan timing windows

**MITRE ATT&CK**: T1055


Instruction: What indicators of Process Herpaderping can forensic analysts look for?

Output:
Forensic artifacts for Process Herpaderping:

- Mismatched file and memory contents
- File modification timestamps
- Section creation events


Instruction: What is Module Stomping?

Output: Module stomping loads a legitimate DLL into the target process, then overwrites its memory with malicious code. The malicious code appears to belong to a legitimate, signed module, evading detection based on module reputation.


Instruction: What are the security implications of Module Stomping?

Output: Module stomping hides malicious code within legitimate modules. Memory scanning sees code in a signed, trusted DLL, potentially bypassing allowlisting.


Instruction: What are the components of Module Stomping?

Output:
Key components of Module Stomping:

- Load legitimate DLL into target process
- VirtualProtect to make DLL memory writable
- Overwrite DLL .text section with shellcode
- Execute from apparently legitimate module
- DLL remains in loaded module list


Instruction: What are common attacks involving Module Stomping?

Output:
Attack vectors involving Module Stomping:

- Hiding in signed Microsoft DLLs
- Evading module reputation systems
- Bypassing allowlisting based on module signatures
- Masquerading shellcode as legitimate code

**MITRE ATT&CK**: T1055


Instruction: What indicators of Module Stomping can forensic analysts look for?

Output:
Forensic artifacts for Module Stomping:

- Modified module memory
- VirtualProtect calls on DLLs
- Mismatched disk/memory module content


Instruction: Describe Ghostwriting Injection and its purpose.

Output: Ghostwriting uses ROP (Return-Oriented Programming) to write to memory without directly calling WriteProcessMemory. By chaining gadgets in the target process, an attacker can copy data from shared memory or other sources, evading WriteProcessMemory monitoring.


Instruction: Why is Ghostwriting Injection security-relevant?

Output: Ghostwriting avoids the most monitored injection APIs by using code reuse techniques. It's complex but can evade user-mode API hooks.


Instruction: What are the components of Ghostwriting Injection?

Output:
Key components of Ghostwriting Injection:

- Create shared memory section
- Map section into both attacker and target
- Build ROP chain using gadgets in target
- Trigger ROP via thread hijacking or APC
- ROP copies data from shared section to target memory


Instruction: What are common attacks involving Ghostwriting Injection?

Output:
Attack vectors involving Ghostwriting Injection:

- Bypassing WriteProcessMemory hooks
- Evasion of user-mode API monitoring
- Leveraging ROP for memory writes
- Combining with shared memory sections

**MITRE ATT&CK**: T1055


Instruction: What evidence can be found from Ghostwriting Injection activity?

Output:
Forensic artifacts for Ghostwriting Injection:

- Shared memory sections
- ROP gadget execution patterns
- Thread context modifications


Instruction: How does Linux ptrace Injection work?

Output: On Linux, ptrace enables process injection by attaching to a target, using PTRACE_POKEDATA to write shellcode, modifying registers to redirect execution, and resuming the process. It's the primary Linux injection mechanism.


Instruction: Why is Linux ptrace Injection security-relevant?

Output: ptrace is the standard Linux debugging interface but enables powerful injection capabilities. Yama LSM can restrict ptrace to mitigate this.


Instruction: Describe the structure of Linux ptrace Injection.

Output:
Key components of Linux ptrace Injection:

- PTRACE_ATTACH to target process
- Wait for process to stop
- PTRACE_POKEDATA to write shellcode
- PTRACE_GETREGS/SETREGS to modify instruction pointer
- PTRACE_CONT to resume execution
- PTRACE_DETACH to release process


Instruction: What are common attacks involving Linux ptrace Injection?

Output:
Attack vectors involving Linux ptrace Injection:

- Shellcode injection into running processes
- Credential theft from process memory
- Backdooring running services
- Post-exploitation persistence

**MITRE ATT&CK**: T1055.008


Instruction: What forensic artifacts does Linux ptrace Injection leave?

Output:
Forensic artifacts for Linux ptrace Injection:

- TracerPid field in /proc/pid/status
- ptrace syscall audit events
- Memory modifications in target


Instruction: Explain LD PRELOAD Injection in the context of cross-platform.

Output: LD_PRELOAD is an environment variable that specifies shared libraries to load before all others. Setting LD_PRELOAD to a malicious library causes it to be loaded into any new process, allowing function interception and code injection.


Instruction: How does LD PRELOAD Injection relate to security?

Output: LD_PRELOAD provides a simple injection method for new processes. It's blocked by secure execution (setuid binaries) but effective otherwise.


Instruction: Describe the structure of LD PRELOAD Injection.

Output:
Key components of LD PRELOAD Injection:

- LD_PRELOAD environment variable
- Malicious shared object (.so) file
- Function hooking via symbol interposition
- Library loaded before other dependencies
- /etc/ld.so.preload for system-wide preload


Instruction: How do attackers abuse LD PRELOAD Injection?

Output:
Attack vectors involving LD PRELOAD Injection:

- Injecting into all new user processes
- Hooking libc functions (authentication, crypto)
- Backdooring specific applications
- Credential interception via function hooks

**MITRE ATT&CK**: T1574.006


Instruction: What indicators of LD PRELOAD Injection can forensic analysts look for?

Output:
Forensic artifacts for LD PRELOAD Injection:

- LD_PRELOAD in process environment
- /etc/ld.so.preload file
- Unexpected libraries in process maps


Instruction: What is /proc/pid/mem Injection?

Output: The /proc/pid/mem pseudofile provides direct access to process memory. With appropriate permissions, an attacker can open this file, seek to the target address, and write shellcode directly. This is an alternative to ptrace for memory modification.


Instruction: What are the security implications of /proc/pid/mem Injection?

Output: /proc/pid/mem provides direct memory access without ptrace's complexity. It's subject to the same permission checks but may evade ptrace-specific monitoring.


Instruction: What elements make up /proc/pid/mem Injection?

Output:
Key components of /proc/pid/mem Injection:

- Open /proc/target_pid/mem
- Read /proc/target_pid/maps for memory layout
- lseek to target address
- write() to inject shellcode
- Requires same user or CAP_SYS_PTRACE


Instruction: What attack vectors use /proc/pid/mem Injection?

Output:
Attack vectors involving /proc/pid/mem Injection:

- Direct shellcode injection
- Modifying process code or data
- Alternative to ptrace injection
- Credential extraction from memory

**MITRE ATT&CK**: T1055.009


Instruction: What forensic artifacts does /proc/pid/mem Injection leave?

Output:
Forensic artifacts for /proc/pid/mem Injection:

- /proc/pid/mem access logs
- Memory modification events
- File descriptor access to mem files


Instruction: Explain Shared Library Injection via dlopen in the context of cross-platform.

Output: If an attacker can execute code in a target process (via any method), calling dlopen() with a path to a malicious shared library loads and initializes it. Constructor functions (__attribute__((constructor))) execute automatically upon load.


Instruction: Why is Shared Library Injection via dlopen security-relevant?

Output: dlopen injection is useful when you have code execution but want to load additional functionality. Library constructors provide automatic execution.


Instruction: What are the components of Shared Library Injection via dlopen?

Output:
Key components of Shared Library Injection via dlopen:

- dlopen() - dynamic library loading
- Constructor functions - execute on load
- Destructor functions - execute on unload
- Symbol resolution via dlsym()
- Library search paths (LD_LIBRARY_PATH, RPATH)


Instruction: What attack vectors use Shared Library Injection via dlopen?

Output:
Attack vectors involving Shared Library Injection via dlopen:

- Loading malicious functionality via dlopen
- Persistent backdoor via library with constructor
- Extending capabilities of injected code
- Plugin-based malware architecture

**MITRE ATT&CK**: T1055


Instruction: What forensic artifacts does Shared Library Injection via dlopen leave?

Output:
Forensic artifacts for Shared Library Injection via dlopen:

- Loaded libraries in process maps
- dlopen call traces
- Library files and their paths


Instruction: How does IAT hooking work and what are its limitations?

Output: IAT hooking works by modifying the Import Address Table entries in a PE module. The IAT contains resolved addresses of imported functions that the Windows loader populates when the module loads. By overwriting these addresses (after changing memory protection with VirtualProtect), calls through the IAT are redirected to hook functions. Key limitations: (1) Only intercepts calls made through the IAT - functions resolved via GetProcAddress or direct syscalls bypass it, (2) Must be applied per-module since each has its own IAT, (3) Easily detected by comparing IAT entries against actual export addresses from target DLLs.


Instruction: Why might malware implement IAT hooking in a target process?

Output: Malware implements IAT hooking to intercept and monitor API calls for various purposes: (1) Credential theft by hooking authentication APIs to capture passwords, (2) Network traffic interception by hooking socket functions, (3) File access monitoring to identify sensitive documents, (4) Hiding malicious activity by filtering results from enumeration APIs (process/file listing), (5) Injecting malicious content into legitimate operations, (6) Bypassing security checks by modifying API return values. IAT hooking is attractive because it's relatively simple to implement and provides comprehensive coverage of imports.


Instruction: Explain Import Address Table Hooking in the context of Windows.

Output:
Import Address Table (IAT) hooking intercepts API calls by modifying
        the IAT entries in a PE file's import directory. When a module is loaded, the loader
        resolves imported functions and writes their addresses to the IAT. By overwriting
        these addresses with pointers to hook functions, all calls through the IAT are
        redirected. This technique is relatively easy to implement but only catches calls
        made through the IAT - direct calls or dynamically resolved functions bypass it.


Instruction: From a security perspective, why is understanding Import Address Table Hooking important?

Output: Used by both malware (API monitoring, credential theft) and security tools (behavior monitoring, sandboxing)


Instruction: Summarize the essential points about Import Address Table Hooking.

Output:
Key points about Import Address Table Hooking:

- IAT contains resolved addresses of imported functions
- Hook by overwriting IAT entries with hook function addresses
- Requires making IAT memory writable (VirtualProtect)
- Only intercepts calls through IAT, not GetProcAddress calls
- Per-module - must hook each module's IAT separately
- Easy to detect by comparing IAT to actual export addresses


Instruction: What are the detection strategies for Import Address Table Hooking?

Output:
Detection indicators for Import Address Table Hooking:

- IAT entries pointing outside expected module ranges
- Discrepancy between IAT and GetProcAddress results
- Memory protection changes on IAT regions


Instruction: What advantages does EAT hooking have over IAT hooking?

Output: EAT hooking has several advantages over IAT hooking: (1) Global effect - modifying a DLL's export table affects ALL callers, not just one module's imports, (2) Catches dynamic resolution - intercepts GetProcAddress calls that IAT hooking misses, (3) Single point of modification - only need to hook the export once rather than every importing module, (4) Affects future loads - new modules loading after the hook is installed will also be affected. The tradeoff is increased complexity: must correctly handle forwarded exports, requires modifying system DLLs in memory, and some functions may be called before the hook can be installed.


Instruction: How would a security tool detect EAT hooking in a running process?

Output: Detection approaches for EAT hooking: (1) Compare in-memory EAT entries against the on-disk DLL exports - any discrepancy indicates modification, (2) Verify export addresses point within the module's legitimate code sections, not to external memory, (3) Check for memory protection changes on the export directory region, (4) Use code integrity verification to hash export table regions, (5) Monitor for WriteProcessMemory calls targeting system DLL export sections, (6) Cross-reference with GetProcAddress results from a known-clean module load. EDR tools often maintain baseline hashes of critical DLL export sections.


Instruction: Describe Export Address Table Hooking and its purpose.

Output:
Export Address Table (EAT) hooking modifies the export directory of a
        DLL to redirect function resolution. When GetProcAddress looks up a function, it
        reads the address from the EAT. By modifying EAT entries, all future GetProcAddress
        calls for that function return the hook address. This is more powerful than IAT
        hooking because it affects all callers, but requires modifying system DLLs in
        memory and is more complex to implement correctly.


Instruction: From a security perspective, why is understanding Export Address Table Hooking important?

Output: Advanced hooking technique for comprehensive API interception; harder to implement but more thorough coverage


Instruction: What are the key technical details of Export Address Table Hooking?

Output:
Key points about Export Address Table Hooking:

- Modifies export directory in target DLL
- Affects all GetProcAddress resolutions globally
- Requires finding and modifying loaded DLL in memory
- Must handle forwarded exports correctly
- More powerful than IAT hooks - catches dynamic resolution
- Changes persist until module unloaded or address restored


Instruction: What indicators reveal Export Address Table Hooking activity?

Output:
Detection indicators for Export Address Table Hooking:

- EAT entries pointing outside module's code section
- Hash/checksum changes in DLL export section
- Export addresses in unexpected memory regions


Instruction: Explain inline hooking and the role of the trampoline in preserving original functionality.

Output: Inline hooking works by overwriting the first bytes of a target function with a jump instruction redirecting to a hook function. For x86, this is typically a 5-byte 'JMP rel32'; for x64, it requires 12-14 bytes for absolute addressing. The trampoline is a small code stub that preserves original functionality: it contains (1) the original overwritten bytes from the function prologue, and (2) a jump back to the instruction following the hook in the original function. When the hook function wants to call the original, it calls the trampoline, which executes the saved prologue bytes then continues into the original function body. This allows the hook to inspect/modify arguments, call the original, then inspect/modify return values.


Instruction: What challenges exist when implementing inline hooks in a multi-threaded environment?

Output: Multi-threaded inline hooking challenges: (1) Race conditions - a thread might execute the function while bytes are being modified, causing crashes, (2) Instruction tearing - partial overwrites can create invalid instructions, (3) Suspended threads - threads might be suspended mid-function, and hook installation could corrupt their execution state, (4) Cache coherency - instruction cache may contain old bytes after modification. Mitigations: suspend all threads during installation, use atomic operations where possible (Windows hot-patch points start with 'mov edi, edi' allowing 2-byte short JMP), flush instruction cache (FlushInstructionCache), or use hardware breakpoints for initial redirect. Some frameworks use page guard exceptions for thread-safe transitions.


Instruction: How do EDR products use inline hooking for security monitoring?

Output: EDR products install inline hooks on security-sensitive functions to monitor process behavior: (1) NTDLL hooks - NtCreateProcess, NtWriteVirtualMemory, NtMapViewOfSection for process injection detection, (2) Network APIs - connect, send, recv for C2 communication monitoring, (3) File APIs - NtCreateFile, NtWriteFile for ransomware detection, (4) Registry APIs for persistence mechanism detection, (5) Crypto APIs to capture encryption keys. The hooks log parameters, check against behavioral rules, and can block suspicious operations. Modern EDR hooks are typically installed in userland (ntdll.dll) rather than kernel to avoid PatchGuard. This creates the cat-and-mouse game where malware attempts to unhook these functions to operate undetected.


Instruction: How does Inline/Detour Hooking work?

Output:
Inline hooking (also called detour or trampoline hooking) modifies
        the actual code bytes at the start of a function to redirect execution. Typically,
        the first few bytes are overwritten with a JMP instruction to the hook function.
        The original bytes are saved to a 'trampoline' that allows calling the original
        function. This technique works regardless of how the function is called but requires
        careful handling of instruction boundaries and concurrent execution.


Instruction: From a security perspective, why is understanding Inline/Detour Hooking important?

Output: Primary hooking method for security products (AV, EDR) and also used by malware; detection evasion often involves unhooking these