Unit 4: Malware Persistence, Injection and Hooking - Subjective Questions

Malware functionality refers to the actions and capabilities implemented by malicious software to achieve an attacker's objectives.

Common capabilities include:

• System reconnaissance: Collects operating-system, hardware, user-account, process, network, and security-product information.
• Credential theft: Obtains passwords, browser data, tokens, cookies, or authentication material.
• Command and control: Communicates with remote infrastructure to receive commands and return collected data.
• Persistence: Maintains access by arranging for malicious code to execute after logon, reboot, or another system event.
• Defense evasion: Uses obfuscation, packing, process injection, or security-tool interference to reduce detection.
• Data exfiltration: Transfers selected files or captured information to an attacker-controlled destination.
• Payload execution: Encrypts data, downloads additional components, spies on users, or disrupts system operation.

A malware sample may combine several of these capabilities and activate them conditionally according to its environment.

Malware persistence is the ability of malicious code to regain execution after an interruption such as a reboot, user logoff, process termination, or temporary loss of access.

Persistence is important because it can:

• Preserve access across system restarts.
• Reduce the need to exploit the victim repeatedly.
• Allow long-term surveillance or data collection.
• Support later delivery of additional payloads.
• Re-establish command-and-control communication.

Persistence commonly leaves observable evidence, including:

• New or modified startup configuration entries.
• Unexpected scheduled tasks, services, drivers, or logon scripts.
• Altered application settings or system configuration files.
• Suspicious files in startup-related directories.
• Event-log entries showing service, task, or account changes.
• Network activity shortly after boot or logon.

Analysts correlate these artifacts with file timestamps, process ancestry, digital signatures, and configuration history before deciding whether an entry is malicious.

Registry-based persistence abuses Windows configuration locations that cause programs or components to execute during startup, logon, or specific application events.

A safe investigation procedure includes:

1. Acquire evidence: Export relevant registry hives or collect them through approved forensic tooling.
2. Establish a baseline: Compare entries against a known-good image, enterprise inventory, or previous snapshot.
3. Inspect execution references: Look for unusual executable paths, scripts, command interpreters, encoded arguments, or user-writable locations.
4. Validate referenced files: Calculate hashes, check signatures, record timestamps, and examine file metadata.
5. Correlate activity: Compare registry modification times with process, authentication, endpoint, and event-log data.
6. Assess scope: Determine whether the entry exists per user or system-wide and whether it appears on other hosts.
7. Preserve before remediation: Record the original value and associated evidence before disabling or removing it.

An unfamiliar startup entry is not automatically malicious; software installers and legitimate administration tools also create such entries.

Both mechanisms have legitimate administrative uses. Detection should therefore consider context, provenance, executable reputation, configuration changes, and behavior rather than relying only on the mechanism's existence.

Four common persistence methods and associated clues are:

• Scheduled tasks: Malware creates an event-based or periodic task. A useful clue is a new task that launches an unsigned file from a temporary or user-writable directory.
• Services or drivers: A malicious component is registered with the operating system. Analysts may observe an unexpected service installation event or an unusual binary path.
• Startup folders or logon scripts: A shortcut, script, or executable is placed where it runs at user logon. A useful clue is a recently created file with an uncommon extension or hidden attributes.
• Application or document add-ins: Malware is loaded when a particular application starts. Detection may reveal an unapproved add-in, template, extension, or configuration change.
• Boot-level modification: Malicious code alters components involved early in startup. Clues include integrity-check failures, unrecognized boot components, or changes outside normal patch activity.

The strongest conclusions come from combining configuration evidence with process execution and file analysis.

Virtual memory is an abstraction that gives each process its own logical address space. The operating system and processor translate virtual addresses into physical memory locations through page tables.

Conceptually, an address can be divided into a virtual page number and an offset. If the page size is bytes, the lower bits represent the offset:

Virtual memory is important in malware analysis because:

• Processes normally cannot directly access one another's address spaces.
• Memory pages have permissions such as read, write, and execute.
• Loaded modules and mapped files appear in identifiable memory regions.
• Injected or unpacked code may exist only in memory.
• Address-space layout randomization changes module locations between executions.
• Shared libraries can be mapped into multiple processes while remaining logically separated.

Memory maps, page permissions, allocation history, and module lists can therefore reveal anomalous executable regions or hidden payloads.

A process virtual address space commonly contains:

• Executable image region: Holds the program's mapped code and static data. Analysts compare it with the on-disk image to detect unexpected modifications.
• Loaded-module regions: Contain shared libraries and runtime components. Unlinked, unsigned, or unexpectedly located modules may require investigation.
• Heap: Stores dynamically allocated data. Decrypted configurations, unpacked payloads, and command data may appear here.
• Stack: Holds function frames, local variables, saved registers, and return addresses. It is useful for reconstructing execution flow.
• Memory-mapped files: Provide file-backed regions for efficient access or interprocess sharing. Their paths and protections can identify suspicious mappings.
• Private anonymous regions: Are not directly backed by ordinary files. Executable anonymous memory can indicate runtime code generation, unpacking, or injection.

No single region proves malicious activity. Analysts evaluate memory protection, contents, ownership, allocation history, and relationships to active threads.

Operating systems assign page-level protections that control whether a process can read, write, or execute a memory region. These controls support isolation and make accidental or malicious code execution more difficult.

A region that is writable and executable at the same time can allow generated or copied bytes to run as code. Similarly, a transition from writable to executable memory may occur when software constructs code dynamically.

These patterns are relevant because malware may:

• Decrypt or unpack a payload into memory.
• Copy code into another process.
• Replace legitimate instructions with a detour.
• Execute code without storing a conventional executable on disk.

However, such transitions are not conclusive evidence. Just-in-time compilers, browsers, emulators, and some security products also generate code dynamically. Reliable detection combines protection changes with factors such as unusual process ancestry, unsigned modules, remote memory operations, suspicious thread starts, and network activity.

Kernel-mode malware can obtain broader control and hide user-mode artifacts, but modern systems apply driver signing, secure boot, kernel integrity protections, and access controls to make kernel compromise more difficult.

A system call is a controlled interface through which a user-mode process requests a privileged operating-system service.

The general sequence is:

1. The application prepares a system-call identifier and required arguments.
2. A library wrapper or runtime invokes the processor's designated system-call mechanism.
3. The processor changes privilege level and transfers control to a validated kernel entry point.
4. The kernel verifies parameters, permissions, object references, and memory boundaries.
5. The requested kernel service performs the permitted operation.
6. The kernel places a return value or status code in the expected location.
7. The processor restores the user-mode execution context and resumes the caller.

This boundary is security-critical. Malware may monitor, bypass, or tamper with parts of the path, while analysts examine anomalous calls and return values. Kernel validation remains essential because user-mode input cannot be trusted.

Code injection is the placement or redirection of executable logic into a process so that the target process runs code that was not part of its expected execution path.

Malware may use injection to:

• Blend with trusted processes: Malicious actions appear to originate from a legitimate application.
• Access process data: Injected code may observe information available inside the target.
• Reuse privileges: Code may operate with the target process's effective permissions, subject to operating-system controls.
• Evade simple detection: The original launcher can terminate while the payload remains active elsewhere.
• Intercept APIs: Execution can be redirected to monitor or alter function calls.
• Maintain operational continuity: A payload may survive the termination of an initial process.

Injection itself is not exclusively malicious; debuggers, accessibility tools, profilers, and endpoint security products may use related mechanisms. Context and behavior are therefore essential for classification.

At a conceptual level, remote-process injection commonly involves the following stages:

1. Target selection: A process is chosen based on trust, privilege, lifetime, or network access. Indicators include unusual process relationships or access attempts.
2. Process access: The source obtains rights over the target. Endpoint telemetry may record access requests with memory-modification permissions.
3. Memory preparation: Memory is allocated, mapped, or repurposed in the target. Indicators include new private regions or unexpected mapped sections.
4. Content transfer: Code or supporting data appears in the target. Memory scans may find executable content not associated with a normal module.
5. Execution redirection: A new or existing execution context is made to enter the injected region. Indicators include threads starting outside known modules or abnormal call stacks.
6. Cleanup or concealment: Handles, files, or metadata may be removed. Analysts may notice missing backing files, unlinked modules, or short-lived launcher processes.

Detection is strongest when telemetry connects several stages rather than treating one memory event as definitive.

All three techniques attempt to execute code within another process context, but their loading paths and artifacts differ. Memory analysis should be combined with process creation, file, signature, and access telemetry.

Process hollowing is an injection technique in which a process created from a legitimate executable has its expected execution image replaced, altered, or bypassed so that different code runs within that process identity.

An analyst may look for:

• A mismatch between the executable on disk and executable pages in memory.
• An entry point that resolves outside the expected image code.
• Memory regions with unusual allocation types or protection histories.
• A main thread whose call stack does not correspond to the declared image.
• Suspicious parent-child relationships or command-line inconsistencies.
• A process created in a paused state followed by immediate memory manipulation.
• Missing, damaged, or inconsistent executable headers and module metadata.
• Network behavior that is atypical for the apparent application.

A robust investigation reconstructs the in-memory image, calculates hashes where practical, compares sections with the original file, and correlates the result with process-creation telemetry.

Thread execution hijacking redirects an existing thread so that it executes unexpected code before possibly returning to its normal path.

Its general principle is:

• A target thread is identified.
• Its execution state is temporarily controlled or observed.
• The instruction pointer or related execution context is redirected toward another memory region.
• The thread resumes and executes the redirected logic.

Potential artifacts include:

• Cross-process access with thread-control permissions.
• Sudden changes to a thread's execution context.
• An instruction pointer located in private or unrecognized executable memory.
• Call stacks that begin outside loaded modules or contain broken transitions.
• Memory allocations or protection changes shortly before thread resumption.
• A mismatch between the thread's expected role and its network or file activity.

Because debuggers and diagnostic tools also manipulate thread contexts, analysts should validate the initiating process, authorization, timing, and destination memory.

API hooking is the interception or redirection of a function call so that another routine can inspect, modify, block, or supplement the original operation.

Legitimate uses include:

• Debugging and performance profiling.
• Accessibility and compatibility support.
• Security monitoring and policy enforcement.
• Application instrumentation and testing.

Malicious uses include:

• Hiding files, processes, registry entries, or network connections.
• Capturing credentials or sensitive input.
• Modifying security-relevant results returned to applications.
• Monitoring communications and altering data.
• Redirecting execution to an injected payload.

A hook may modify code, function pointers, import tables, or other dispatch structures. Since hooking has valid uses, analysts must consider the hook owner, code signature, installation method, target function, destination address, and resulting behavior.

Both techniques redirect control flow. Analysts should account for legitimate instrumentation and for sophisticated hooks that restore bytes temporarily, chain multiple handlers, or conceal their destination.

A trampoline is a small executable sequence used to preserve access to the original function when its initial instructions have been replaced by a hook.

Conceptually, it:

1. Stores the complete original instructions displaced by the redirection.
2. Executes those instructions when original behavior is required.
3. Transfers control back to the original function after the modified region.

Instruction boundaries matter because machine instructions have variable lengths on common architectures. Copying only part of an instruction produces invalid or unintended execution. Relative addresses also matter because a copied branch or data reference may calculate its destination from the instruction's current address. Moving that instruction can therefore change its meaning unless the reference is adjusted.

For analysts, trampoline indicators include executable private memory, copied function prologues, branches back into known modules, and code pages that differ from their trusted on-disk versions.

Kernel-mode hooking redirects or modifies execution within privileged operating-system code paths, driver callbacks, dispatch routines, or other kernel-controlled mechanisms.

It is more challenging because:

• Privilege is broad: Kernel code can access critical memory and system objects.
• Visibility may be manipulated: A malicious driver may alter information returned to user-mode tools.
• Failure impact is high: Incorrect analysis or removal can crash the operating system.
• Artifacts are specialized: Investigation may require kernel debugging, trusted memory acquisition, and driver analysis.
• Security controls intervene: Driver signing, secure boot, kernel integrity checks, and virtualization-based protections affect what modifications are possible.
• Version dependence is significant: Internal structures and protections differ across operating-system releases.

Defenders use trusted boot measurements, driver inventories, code-integrity events, kernel telemetry, memory forensics, and comparisons across independent data sources to identify hidden or redirected behavior.

A defensible workflow should preserve evidence while progressively validating the suspected behaviors:

1. Contain the host: Isolate it according to incident-response policy while preserving necessary management access.
2. Record volatile state: Capture active processes, threads, network connections, logged-on users, handles, loaded modules, and memory where authorized.
3. Build a process timeline: Correlate parent-child relationships, command lines, account context, process access, and network events.
4. Inspect persistence: Review startup configuration, tasks, services, drivers, logon mechanisms, and application extensions against a baseline.
5. Examine memory: Identify executable private regions, image-memory mismatches, suspicious protection changes, and threads executing outside recognized modules.
6. Check for hooks: Compare code bytes and function pointers with trusted references; inspect redirection destinations and ownership.
7. Validate files: Hash relevant files, verify signatures, preserve samples, and examine metadata in an isolated environment.
8. Correlate evidence: Connect persistence changes to the process responsible, then connect that process to injection or hook artifacts.
9. Determine scope: Search other endpoints for the same hashes, paths, configuration patterns, certificates, and behaviors.
10. Remediate and verify: Remove or reimage according to risk, rotate exposed credentials, close the initial access path, and confirm that indicators do not return after reboot.

Every action should be documented with timestamps, tool versions, evidence sources, and chain-of-custody information.