Process injection and credential dumping

Objective 4.3 in this course covers host-based attacks — CompTIA names privilege escalation, process injection and credential dumping. Lessons 27 and 28 took escalation; this takes the other two. Runs on a machine you own, in the lab from lesson 2.

Why this matters

These two are named in CompTIA's own scope bullet, so both are examinable by name. They are also the point where offensive technique meets defensive reality most directly: process injection is largely defined by what endpoint detection looks for, and credential dumping is what turns a single compromised host into lesson 26's replay across the estate.

The emphasis in this lesson is on understanding the concepts and the evidence they leave, not on evading detection — a distinction that matters both professionally and for the exam, which tests recognition rather than tradecraft.

The lesson

Why injection is about living inside a trusted process

Process injection means causing code to run inside another process's memory space, so it executes with that process's identity, privileges and trust.

Attackers want this for reasons that are worth understanding rather than memorising:

• Trust. Code running inside a process the system trusts inherits that trust — network access an allowlist permits, or a reputation the process has.
• Access to the host process's material. Injecting into a process that holds credentials or keys puts you next to them in memory.
• Persistence and blending. Living inside a legitimate process is harder to find than a new suspicious one.

For a tester the point is conceptual: the technique demonstrates that a "trusted" process is only as trustworthy as its integrity, and that endpoint controls which trust by process identity can be subverted from inside. You do not need to build novel injection to make that finding.

Common injection shapes, described and recognised

The exam expects recognition of the broad families rather than implementation:

• Writing code into another process and starting a thread there to run it — the classic shape.
• Hijacking an existing thread to run your code instead.
• Abusing legitimate extension mechanisms — features designed to load code into a process, repurposed to load yours.
• Replacing a process's image while keeping its identity, so a benign-looking process runs different code.

The common thread: a process's contents can differ from what launched it, so identifying software by the name of the process is unreliable. That is the defensive lesson, and it is why endpoint detection watches behaviour — the suspicious sequence of actions — rather than process names.

Dumping credentials from a machine you own

Credential dumping is extracting authentication material from a compromised host — the memory, databases and stores from lesson 26, made concrete.

On a machine you own, in the lab:

• Recover local account material from the local database.
• Recover material for accounts currently logged in, from the process that holds it in memory — which is where an administrator who logged in leaves reusable material.
• On a domain controller, the directory database holds everything, which is why it is the top target and why its protection matters most.

The purpose is always downstream: what you dump feeds lesson 26's replay and lesson 30's lateral movement. Dumping is not the finding; what it enables is — "from this one web server we recovered a credential that reached the domain controller" is the finding, and it is a chain (lesson 40).

What EDR sees when this happens

Endpoint detection and response is the control most relevant to this lesson, and understanding what it watches is both the defensive lesson and the honest framing for the report.

EDR does not primarily look for known-bad files. It looks for behaviour: a process opening another process's memory, a service account spawning a shell, a known-sensitive process being read by something that has no reason to, a sequence of actions that together look like an attack.

So the report has two halves again:

• What the client's EDR detected or blocked during your test. If it caught the credential access, that is a working control worth stating positively.
• What it missed. A gap here is a serious finding, because these techniques are exactly what EDR exists to catch.

Testing whether the detection fires is often more valuable to the client than the technical success of the technique — a red team framing (lesson 1) that is worth offering explicitly.

Handling dumped material as client data you must protect

Everything recovered here is the client's most sensitive data — the credentials to their entire environment — and lesson 4's rules apply at their strictest.

• Take the minimum that proves the finding. One recovered credential demonstrates the exposure; you do not need to dump and store the entire directory.
• Protect it absolutely. Encrypted at rest and in transit, never on a shared location, never in the report in cleartext.
• Report the exposure, not the values. "The domain credential database was recoverable from this host" is the finding; the contents are not printed.
• Destroy it on the agreed schedule, and be able to say you did.
• It is used only within scope, to demonstrate reachable impact, and for nothing else.

The stakes are the highest in the course: a tester who leaks a client's dumped credentials has handed an attacker the environment. The care is not optional politeness — it is the difference between an assessment and a breach you caused.

What to take into the exam

• Injection runs code inside another process to inherit its identity, privileges and trust; a process's contents can differ from what launched it, so process name is unreliable.
• Recognise the broad injection families rather than implementing them; the exam tests recognition.
• Credential dumping extracts authentication material to feed replay and lateral movement — the value is what it enables, as a chain.
• EDR watches behaviour, not just files; whether it detected your activity is a finding either way.
• Dumped credentials are the client's most sensitive data: minimum, protected, reported as exposure not values, destroyed on schedule.