Reading malicious activity on a host

Why this matters

The network tells you that two machines spoke. The host tells you what actually ran, and on a modern intrusion that is where the answer lives — because so much of the activity never crosses a network sensor at all.

Host analysis is also where the exam gets specific. You will be shown a process tree, a command line, a persistence entry or a directory listing and asked what it indicates. The reasoning is consistent: legitimate software has habits, and malicious activity breaks them in a small number of recognisable ways.

The lesson

Process ancestry and why parentage is the tell

A single process name proves almost nothing. powershell.exe is on every Windows machine and runs legitimately thousands of times a day. What makes it interesting is what launched it.

Normal ancestry is boring and consistent. A user opens a document: explorer.exe launches winword.exe. A scheduled task runs: the task scheduler service is the parent.

Suspicious ancestry breaks the pattern:

• An Office application spawning a command interpreter. winword.exe → powershell.exe is the classic macro execution chain, and there is almost no benign reason for it.
• A browser spawning a script host, which usually means a download was executed.
• A web server process spawning a shell — w3wp.exe or httpd → cmd.exe or /bin/sh — which is a web shell, and one of the highest-fidelity detections in existence.
• A system process with the wrong parent. lsass.exe should be launched by wininit.exe; a copy started by something else is masquerading.
• A process running from the wrong path. svchost.exe lives in System32; the same name in a temporary directory is not it.

The command line matters as much as the ancestry, which is why enabling command-line logging is worth so much:

• Encoded commands — -EncodedCommand, base64 blobs — are rarely legitimate.
• Execution policy bypasses and hidden window flags together are a strong signal.
• Downloads piped directly into execution.
• Very long command lines generally: legitimate invocations are usually short.

The habit to build: read the tree, not the process. Ask what launched this, what it launched in turn, and whether that chain makes sense for this machine.

Persistence: services, scheduled tasks, run keys, cron

An attacker who loses access on reboot has to start again, so persistence is established early and is one of the most reliable things to hunt for.

On Windows, the common locations:

• Run and RunOnce registry keys, per-user and machine-wide.
• Scheduled tasks, including ones with innocuous names, and tasks that trigger on logon or on an event rather than a schedule.
• Services, especially newly created ones pointing at unusual paths, or existing services whose binary path has been altered.
• WMI event subscriptions — a filter, a consumer and a binding — which is fileless, survives reboot, and is missed by anyone only looking at the registry and task scheduler.
• Startup folders, the simplest mechanism and still used.
• DLL search order hijacking, where a legitimate application loads an attacker's library because of where it sits.

On Linux and macOS:

• cron and at jobs, including user crontabs that are easy to overlook.
• systemd units and timers, which have largely replaced init scripts.
• Shell profile files — .bashrc, .bash_profile, .zshrc — executed on every login.
• SSH authorized_keys: adding a key is quiet, durable, and requires no malware at all.
• LaunchAgents and LaunchDaemons on macOS.

The strongest detection here is change-based rather than signature-based. New service creation, new scheduled task, new WMI subscription, modified authorized_keys — these are rare on a stable system, which makes the alert volume tolerable and the signal high.

Living-off-the-land binaries and signed abuse

Modern intrusions frequently drop no malware at all. They use the tools already present, which are signed by the vendor, allowed by policy, and above suspicion to any control based on reputation.

Windows examples you should recognise:

• PowerShell for essentially everything.
• certutil for downloading and for base64 decoding.
• bitsadmin and curl for transfers.
• regsvr32, rundll32, mshta for executing code in ways that avoid a direct process launch.
• wmic for remote execution and reconnaissance.
• schtasks for persistence.
• vssadmin for deleting shadow copies — a near-certain ransomware signal.

On Linux: curl, wget, base64, nc, python, plus package managers and container runtimes.

Because the binaries are legitimate, detection has to key on usage, not presence:

• certutil downloading anything, ever.
• vssadmin delete shadows, which has no defensible administrative use in the middle of a workday.
• Administrative tooling running on a machine whose user is not an administrator.
• A tool running from an unusual parent, which returns us to ancestry.

The same logic applies to signed driver and application abuse: a valid signature says the file is what its publisher shipped, not that its current use is legitimate. "It is signed" is not an exoneration, and scenarios lean on that.

Memory-resident activity and injection

Some activity deliberately leaves no file to find. It runs in memory, inside a process that is allowed to be running.

The techniques worth naming:

• Process injection: writing code into another process's memory and executing it there. The host process keeps its legitimate name and signature.
• Process hollowing: starting a legitimate process suspended, replacing its contents, then resuming it. The image on disk is genuine; what runs is not.
• Reflective loading: loading a library from memory without it ever touching the file system.
• Script-based in-memory execution, where a downloader pulls code straight into an interpreter.

What still gives it away:

• The network connection. Injected code still needs to communicate, and a process making connections it never normally makes is conspicuous.
• Unusual memory permissions — regions that are both writable and executable are rare in normal software.
• A mismatch between the process on disk and the process in memory.
• Handle access to sensitive processes. Anything opening lsass.exe with read rights is trying to read credentials from memory, and that single detection catches an enormous amount.
• Parent-child anomalies, again, because the initial launch usually still happens somewhere visible.

The practical point for an analyst: absence of a file is not absence of an intrusion, and "the antivirus found nothing" is entirely compatible with an active compromise.

File system and registry artefacts worth pulling

When you need to collect, collect deliberately. A targeted set answers more questions than a disk image you have no time to process.

Usually worth having:

• Execution evidence: prefetch files, Shimcache and Amcache on Windows, which record that a binary ran even after it has been deleted.
• Recent file and path artefacts: LNK files, jump lists, recent documents — useful for showing what a user, or an attacker acting as one, opened.
• Browser history and downloads, which frequently contain the initial delivery.
• Temporary directories and user profile paths, the default drop locations.
• Registry hives for persistence and configuration, including USB device history where removable media is in scope.
• Event logs, exported rather than read in place, because they roll.
• Scheduled task definitions and service configurations.

Two disciplines apply from the first moment, and both are covered properly in the evidence lesson later: hash what you collect, and work from a copy. Opening a file on the original system changes timestamps, and an analyst who destroys the timeline while examining it has removed the only account of what happened.

A final ordering note that matters more than it sounds: collect volatile data first. Memory disappears on power-off; disk does not. If a decision has to be made between capturing memory and rebooting to contain, that is a decision someone should make consciously, knowing what is lost either way.

Topics this lesson owns

• [x] Process ancestry and why parentage is the tell
• [x] Persistence: services, scheduled tasks, run keys, cron
• [x] Living-off-the-land binaries and signed abuse
• [x] Memory-resident activity and injection
• [x] File system and registry artefacts worth pulling