Exploitation, Post-Exploitation, and Red Team Operations Questions

Direct answer

A strong exercise starts from a clear detection-outcome objective, not a "get Domain Admin" objective: pick a small, connected set of real MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) techniques that chain credential theft into lateral movement, run them from an assumed-breach foothold inside a tightly scoped segment, and measure what the security operations center (SOC) and endpoint detection and response (EDR) tooling actually caught, not whether the team reached the final target.

Objectives

• Primary: measure whether the SOC and EDR pipeline detects and correctly triages a realistic credential-theft-to-lateral-movement chain, not whether the attacker "wins."
• Secondary: identify which specific step in the chain is the actual detection gap, so remediation is targeted instead of a vague "buy more tooling" recommendation.
• Non-objective (explicitly out of scope): full external initial-access simulation, real data exfiltration, or techniques outside the credential and lateral-movement kill chain.

Selected techniques (MITRE ATT&CK, real technique IDs)

Six techniques across two tactics is deliberately small. A detection-validation exercise should isolate variables, not showcase every technique the team knows.

Scope and constraints

• Start position: assumed breach. The team is handed a low-privileged domain user account on one workstation rather than spending days on external initial access, because the objective is detecting what happens AFTER a foothold exists, not gaining one.
• Target segment: one named subnet or object set (for example, one office's workstation range plus one file server), never "the whole domain," so an unexpected finding does not turn into an unscoped incident.
• Time box: a fixed window, commonly one to two weeks, agreed in advance with the client's trusted agent (the single client-side contact read into the fact the exercise is live).
• Explicitly disallowed: disabling or evading the EDR agent itself, using unvalidated custom exploit code, and any technique outside the six listed above.

Allowed actions and rules of engagement

• The team may attempt each listed technique against in-scope hosts using well-known, widely documented tooling, not custom or unstable code.
• The trusted agent has a pre-agreed channel and a kill-switch phrase to pause testing immediately if something looks like it is affecting production.
• The team documents the exact time and host for each technique attempt in near real time, independent of whether it succeeds, so the client can later correlate any real alert against the known test timeline.

Success metrics and stop conditions

• Detection coverage: of the six techniques attempted, how many produced an actionable SOC alert. As an illustrative example, if 4 of 6 produce an alert, coverage is 4/6, about 67%, which points at exactly which two steps are blind spots instead of giving one vague overall score.
• Mean time to detect (MTTD): the time from technique execution to the first correctly triaged SOC alert for that technique, where one fires at all.
• Triage accuracy: whether the SOC correctly identified the technique's category (credential access versus lateral movement) rather than logging it as generic "suspicious process," since accurate triage drives the right response.
• Stop conditions: the trusted agent invokes the kill switch, a technique causes unintended production impact (for example, a service disruption from repeated Kerberos ticket requests), or the team reaches the pre-agreed final objective (for example, a successful DCSync run from a simulated Domain Admin-equivalent account) without the SOC having reacted to it, at which point testing pauses for a live purple-team debrief instead of escalating further.

flowchart TD
  A["Define objectives: validate detection of credential theft and lateral movement"] --> B["Scope and rules of engagement: assumed-breach foothold, target segment, blast-radius limits"]
  B --> C["Select ATT&CK techniques: T1003.001, T1003.006, T1558.003, T1550.002, T1021.002, T1078.002"]
  C --> D["Execute chain against scoped hosts"]
  D --> E{"SOC or EDR detects this step?"}
  E -->|Yes| F["Log detection, continue or pause per rules of engagement"]
  E -->|No| G["Continue chain toward objective"]
  F --> H["Reach stop condition or objective"]
  G --> H
  H --> I["Purple-team debrief: map ATT&CK coverage and detection gaps"]

Trade-offs and pitfalls

• Assumed breach versus a full chain from external recon: assumed breach is faster and isolates the detection question, but it never tests whether the SOC would have caught the actual initial access; a mature program eventually needs both.
• Generic ATT&CK technique selection, as described above, versus threat-informed emulation of one named adversary group's specific tool set and sequencing: the latter, run with a platform like MITRE CALDERA or Atomic Red Team mapped to a specific group's known tactics, techniques, and procedures (TTPs), is the more rigorous version of this exercise, but it is a heavier, senior-specialist undertaking that most organizations do not need for a first detection-validation pass.
• Grading the exercise on whether the team reached Domain Admin instead of on whether each technique got detected rewards stealth over the actual purpose of the test and leaves the SOC with nothing actionable.
• Skipping live documentation is a common miss: without a timestamped log of exactly what was attempted and when, a genuine unrelated incident during the test window can get misread as caused by the red team, or the reverse.

Direct answer

A Ticket Granting Ticket (TGT) is issued once, after a client proves knowledge of their password to the domain's Key Distribution Center (KDC), and lets the client request further tickets without re-entering credentials. A service ticket (issued by the KDC's Ticket Granting Service, hence TGS) is requested afterward, using the TGT, for one specific service, and it is encrypted with a key derived from THAT SERVICE ACCOUNT's password, not the domain's own signing key. That single difference is exactly what makes Kerberoasting possible.

Structured elaboration

• TGT. Obtained through an initial authentication exchange with the KDC. It is encrypted with a key derived from the secret of the domain's ticket-signing account (commonly called KRBTGT). Its purpose is to let the client repeatedly ask for service tickets without re-proving their password each time.
• TGS (service ticket). Requested from the KDC using a valid TGT, for a specific service identified by its Service Principal Name (SPN). Critically, this ticket is encrypted with a key derived from the TARGET SERVICE ACCOUNT's own password hash, because that service, not the domain controller, needs to be able to validate it.
• Kerberoasting. Because any authenticated domain user, no matter how low-privileged, can request a service ticket for any account that has a registered SPN, an attacker only needs ordinary domain credentials to request tickets for high-value service accounts, which are frequently over-privileged and configured with old, never-rotated passwords. The attacker takes the returned ticket offline and attempts to guess the service account's password by checking which candidate password would produce the correct encryption key, entirely without touching the domain controller again after the initial request, so there's no lockout risk from repeated failed guesses.
• High-level defense. Require long, random, regularly rotated passwords for service accounts, or migrate them to a managed account type where the domain itself generates and rotates a long random secret instead of a human choosing one. Disabling the older, weaker ticket encryption type in favor of a modern one also makes offline password recovery far more computationally expensive.

Worked example

A newly compromised, ordinary domain user account requests service tickets for every account in the domain that has a registered SPN, a request that is entirely legitimate-looking from the domain controller's point of view. One of those service tickets belongs to a database service account whose password was set five years ago and never rotated. The attacker takes that ticket offline and, because the password is a common dictionary word with a year appended, recovers it within a short offline attempt, gaining that service account's full set of privileges without ever alerting the domain controller.

Trade-offs and pitfalls

A frequent misconception is that Kerberoasting requires administrative or Domain Admin rights to attempt; it doesn't, it only requires any valid domain credential, which is exactly what makes it dangerous as an early-stage technique rather than a late-stage one. A second common gap is describing the offline password-guessing step without explaining why it can happen offline at all, namely that the ticket's encryption key is derived from the service account's password, so the attacker never needs to interact with the domain controller during the guessing phase.

Direct answer

On a compromised Linux host, the common persistence mechanisms are scheduled execution (cron jobs or systemd timers), a malicious systemd service, shell startup file modification, SSH key injection, legacy boot scripts, and, at the most severe end, a backdoored kernel module. Each leaves a distinguishable artifact, though the highest-severity option is specifically designed to hide its own artifacts.

Structured elaboration

• Cron jobs and systemd timers. An entry added to the system crontab, a user's crontab, or a systemd timer unit that relaunches the implant. Artifact: the crontab entry itself, or a timer/service unit file, plus execution history in system logs.
• Systemd services. A malicious unit file installed to start at boot. Artifact: the unit file on disk, and its start events in the system journal.
• Shell startup file modification (a user's shell configuration file, or a system-wide profile script). Appending a command that runs whenever a shell starts. Artifact: an unexpected addition to an otherwise-static file, often visible as an unusual modification timestamp relative to the file's normal change history.
• SSH authorized-keys injection. Adding an attacker-controlled public key to a user's list of keys allowed to log in without a password. Artifact: an unexpected key entry, identifiable by comparing its comment or fingerprint against known legitimate operator keys, plus authentication log entries showing key-based logins from unfamiliar source addresses.
• Legacy boot scripts. Older init-time script hooks that some systems still execute at startup. Artifact: modified script content and its execution timestamp.
• Backdoored kernel modules or rootkits. The most severe option, since a loaded kernel module can provide both persistence and active concealment of files, processes, or network connections from the host's own normal tools. Artifact: an unexpected entry in the list of loaded kernel modules, kernel log anomalies, or a mismatch against known-good module hashes during an integrity check. The core difficulty is that a well-built rootkit actively hides these very artifacts from the live system's own tools, which is why detecting one often depends on offline or out-of-band forensic analysis rather than trusting anything the compromised host reports about itself.

Worked example

A defender reviewing a suspected-compromised host checks the obvious places, cron and systemd services, and finds nothing unusual. A closer review of a specific administrative user's authorized-keys file turns up an extra public key with no matching comment or known owner, and the authentication log shows successful key-based logins from an unfamiliar external address on a regular, unattended schedule, exactly the pattern an SSH-key backdoor produces and one that is easy to miss if the investigation stops at the more commonly-checked locations.

Trade-offs and pitfalls

SSH key persistence is quiet, simple, and frequently under-checked, which is exactly why it's a favorite for real operators. Kernel module persistence is more powerful but riskier for the attacker too, since it introduces real stability risk and, if caught, is unambiguous, undeniable evidence of compromise, which makes it overkill for a standard assessment where the goal is to demonstrate risk, not to plant the most sophisticated possible backdoor. A common investigative mistake is checking only cron and missing systemd timers, which have largely replaced cron as the default scheduling mechanism on modern distributions.

Direct answer

Pass-the-hash abuses the fact that Windows' NTLM (NT LAN Manager) authentication protocol only requires proving knowledge of a fixed-size cryptographic hash of the password, never the plaintext password itself. An attacker who obtains just the hash, for example from a compromised machine's memory or from a stolen local credential database, can present that hash directly to authenticate to another machine, without ever cracking it back into a plaintext password.

Structured elaboration

Why it works. NTLM's challenge-response exchange is entirely a mathematical function of the hash. There is no step in the protocol that re-derives or checks the underlying plaintext, so from the protocol's own point of view, the hash IS the credential. Windows also caches these hashes in memory for convenience, so a single sign-on experience across a network is possible, which is exactly what makes them recoverable and reusable by an attacker who gets code execution on the box.

Three enterprise mitigations:

1. Restrict or disable NTLM authentication in favor of Kerberos wherever the environment allows it, using domain policy to audit and eventually block NTLM on servers that don't genuinely need it.
2. Deploy unique, randomized local administrator passwords per machine rather than sharing one local admin password fleet-wide, so a stolen local-admin hash on one host cannot simply be replayed against every other host.
3. Enable memory-isolation protections for cached credentials (a virtualization-based security feature that keeps authentication secrets out of reach of even an administrator on the same box), and restrict high-privilege logons to a small number of hardened, dedicated administrative workstations so that a compromised low-tier machine never has a high-value credential cached on it in the first place.

Worked example

An organization sets the same local administrator password across its entire workstation fleet for ease of management. An attacker compromises a single low-value workstation, dumps its local credential store, and recovers the shared local administrator hash. Because that exact hash is valid for every other workstation in the fleet, the attacker authenticates to dozens of machines using pass-the-hash without ever needing the plaintext password or touching a domain controller.

Trade-offs and pitfalls

The single most common interview mix-up is treating pass-the-hash as a form of password cracking; it is the opposite, the whole point is that the attacker never needs to recover the plaintext at all. A second common gap is naming a mitigation like disabling NTLM without acknowledging that some legacy applications and devices still require it, meaning the real-world fix is usually a staged reduction and monitoring plan rather than an instant flip of a single setting.

Direct answer: The exploitation and post-exploitation lifecycle is the sequence a tester moves through from being handed a target to closing out the engagement: get a foothold, prove it can be turned into meaningful access, show what that access could reach or extract, and then leave no trace while documenting everything precisely enough for the client to fix it. Every phase applies the same four-part discipline to a different problem: what you're trying to prove, how you prove it, how you prove it without causing real harm, and what evidence backs the claim.

The lifecycle, phase by phase

Worked example: one small engagement, start to finish

Recon turns up an internal-looking web app accidentally exposed to the internet with an outdated plugin. Exploiting the plugin's known vulnerability (initial access) drops a lightweight agent that beacons out every 60 seconds (C2 established). Enumeration from that foothold shows the host is joined to the internal network and has a cached service-account credential. That credential (harvested) doesn't have admin rights on its own host, but a misconfigured scheduled task running as a privileged account (privilege escalation) grants SYSTEM. With SYSTEM, the same credential authenticates cleanly to two other servers (lateral movement). A scheduled task is added on one server as proof persistence would survive a reboot, then removed before the day ends. A search of a file share on that server turns up a folder that would plausibly hold customer records; a same-sized decoy file is moved to a controlled destination to prove exfiltration was possible without touching real data. At close, every dropped agent, task, and credential use is checked off against the running artifact log, and the final report chains all seven steps into one risk narrative for the client's leadership.

Trade-offs & pitfalls: this is a mental model, not a strict pipeline; real engagements loop back constantly (new enumeration after lateral movement often restarts credential harvesting on the new host). Treating it as a checklist to recite is a common interview mistake: what's actually being tested is the judgment call embedded in "ethical validation" at every single phase, not just the technique names. Skipping that judgment under time pressure, for example running a destructive proof instead of a safe one because it's faster, is the most common way a legitimate test causes real operational damage.