Persistence and Lateral Movement Questions

Advanced adversary persistence and lateral movement techniques used in post compromise operations and red team engagements, as well as the defensive controls and detection strategies defenders should apply. Topics include methods for maintaining access across reboots and remediation attempts such as installing backdoors, service and scheduled task manipulation, startup and autorun modifications, registry or profile changes, kernel and boot level implants, firmware persistence, web shell and agent implantation, and covert remote access tunnels. Also covers techniques for moving laterally within networks including credential theft and replay, pass the hash, pass the ticket, Kerberoasting, service ticket abuse, pivoting via compromised hosts, remote execution over management protocols such as remote desktop and secure shell, exploitation of trust relationships, and use of proxying or tunneling. The description includes trade offs between stealth and reliability, common indicators of compromise, forensic evidence left by each mechanism, detection and logging strategies, containment and mitigation approaches, and secure architecture practices to limit lateral movement such as segmentation, least privilege, and strong authentication.

MediumTechnical

36 practiced

You suspect firmware (UEFI/BIOS) persistence on a server after cleaning OS-level artifacts. Describe a safe, enterprise-appropriate investigation and evidence-collection plan: what to collect from the host, vendor engagement considerations, useful tooling or lab steps, and chain-of-custody practices before any destructive validation.

Sample Answer

**Objective & principles**- Preserve evidence, avoid destructive actions without authorization, document everything, maintain chain-of-custody, and involve vendor/stakeholder early for support and risk mitigation.

**What to collect from the host (non-destructive first)**- Full system metadata: make/model/serial, BIOS/UEFI version, ME/PSI/EC firmware versions, SMBIOS output (dmidecode), BMC firmware.- Volatile artifacts: live memory (cold boot if allowed), running processes, active kernel modules.- Firmware-facing artifacts: UEFI variables (efivar -l / efibootmgr), NVRAM contents export, system event logs (SEL/IPMI), TPM event/logs.- Disk images (forensic bitstream) and relevant OS logs (with hashes).

**Tooling & lab validation steps (safe, repeatable)**- Read-only collection tools: fwupdmgr (info), efibootmgr/efivarfs, dmidecode, ipmitool, fwupd.- For deeper analysis in a controlled lab: CHIPSEC (enumeration), UEFITool and UEFIExtract (analysis), Binwalk, Volatility for memory, Flashrom + SPI programmer or vendor-provided dump tool for SPI ROM reads.- Lab should mirror hardware revision; use hardware write-protect, write-blockers, and SPI programmers to take off-host dumps. Always work on copies, never on production.- Validate dumps by re-reading and comparing hashes.

**Vendor engagement considerations**- Contact vendor early; provide minimal identifying data and classification. Ask for official firmware images, known indicators, safe read-only dump procedures, and authorized tools or mitigations.- Get written approval before any destructive tests (re-flash/erase) or guided RMA; coordinate maintenance windows.

**Chain-of-custody & documentation**- Log who, what, when, where, how for every action; label evidence; compute SHA256 hashes at collection and after transfers; store originals in secure evidence storage.- Use signed forms, timestamps, and access controls. If legal admissibility is a concern, involve legal/forensics team.

**When destructive validation is authorized**- Prefer vendor-assisted reflash or lab clone. If you must flash, document approvals, take pre-flash full dumps/hashes, use vendor tools, and capture post-flash verification.

This plan balances safe evidence preservation, technical depth for firmware analysis, and enterprise governance for vendor and legal coordination.

EasyTechnical

47 practiced

In PowerShell (no destructive actions), write a script or sequence of commands that enumerates common Windows autorun persistence locations: HKCU/HKLM Run keys, Scheduled Tasks, Services, Startup folder, and WMI persistent event subscriptions. Output a consolidated JSON report summarizing findings per host.

Sample Answer

**Approach**Enumerate non-destructive persistence locations, collect results into objects, and output a consolidated JSON per host. I run only read/query operations.

**PowerShell script**

powershell

# Enumerate common autorun persistence locations and export JSON
$report = [PSCustomObject]@{
  Host = $env:COMPUTERNAME
  Timestamp = (Get-Date).ToString("o")
  HKCU_Run = @()
  HKLM_Run = @()
  ScheduledTasks = @()
  Services = @()
  StartupFolder = @()
  WmiEventSubscriptions = @()
}

# Registry Run keys
$rkCU = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
$rkLM = 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'
if (Test-Path $rkCU) { $report.HKCU_Run = Get-ItemProperty -Path $rkCU | Select-Object -Property * -ExcludeProperty PS* | ConvertTo-Json -Depth 3 | ConvertFrom-Json }
if (Test-Path $rkLM) { $report.HKLM_Run = Get-ItemProperty -Path $rkLM | Select-Object -Property * -ExcludeProperty PS* | ConvertTo-Json -Depth 3 | ConvertFrom-Json }

# Scheduled Tasks (read-only)
$report.ScheduledTasks = Get-ScheduledTask | Select-Object TaskName, TaskPath, State, Principal | ConvertTo-Json -Depth 3 | ConvertFrom-Json

# Services (auto/boot/startup types)
$report.Services = Get-CimInstance -ClassName Win32_Service | Where-Object { $_.StartMode -in @('Auto','Boot') } | Select-Object Name, DisplayName, PathName, StartMode, State | ConvertTo-Json -Depth 3 | ConvertFrom-Json

# Startup folder
$startupPaths = @(
  "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup",
  "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"
)
$report.StartupFolder = foreach ($p in $startupPaths) { if (Test-Path $p) { Get-ChildItem -Path $p -File | Select-Object FullName, Name } }

# WMI permanent event consumers and subscriptions (read-only)
try {
  $report.WmiEventSubscriptions = Get-WmiObject -Namespace root\subscription -Class __EventFilter -ErrorAction SilentlyContinue | Select-Object Name, Query, QueryLanguage
} catch { $report.WmiEventSubscriptions = @() }

# Output JSON
$report | ConvertTo-Json -Depth 5

**Notes / Considerations**- Script avoids changes (read-only). Run elevated for full visibility.- May miss custom persistence (LNK misuse, scheduled tasks in XML elsewhere). Correlate findings manually and validate suspicious entries during engagements.

EasyTechnical

35 practiced

Describe the differences between a Kerberos TGT (Ticket Granting Ticket) and service (TGS) tickets. Then briefly explain Kerberoasting: what an attacker requests, how an attacker extracts offline password material, and a high-level defense that reduces its effectiveness.

Sample Answer

**Differences: TGT vs Service (TGS) ticket**

- **Purpose** - TGT: Proof that the client authenticated to the KDC; used to request service tickets without reauthenticating. - TGS ticket: Ticket for a specific service (identified by SPN) that the client presents to that service to get access.

- **Who can decrypt** - TGT: Encrypted with the KDC/krbtgt long‑term key; only the KDC can decrypt/validate it. - TGS: Encrypted with the target service principal’s key (derived from that service account password or managed key); the service and KDC can decrypt.

- **Lifetime & use** - TGT: Longer lifetime, renewable; used repeatedly to obtain TGS tickets. - TGS: Shorter lifetime, service-specific, presented to the service to establish a session.

**Kerberoasting (brief, attacker POV)**

- **What the attacker requests** - Attacker requests a TGS for a target SPN by issuing an AS-REQ / TGS-REQ for that service on behalf of a compromised (or valid) user. The KDC returns a TGS encrypted with the service account’s NTLM/AES key.

- **How attacker extracts offline password material** - The attacker extracts the TGS ticket blob from memory or from the response (e.g., via Rubeus, GetUserSPNs/SetSPN enumeration + TGS request). - That ticket contains data encrypted with the service account’s key. The attacker performs offline brute‑force / dictionary attacks against that ciphertext to recover the service account’s plaintext password (or its key). No online AD interaction required, so rates limited only by attacker resources.

- **High‑level defense to reduce effectiveness** - Use strong, long, randomly generated service account passwords and rotate them frequently — or use Group Managed Service Accounts (gMSA) so passwords aren’t human‑set. - Disable legacy/weak ciphers (RC4) and enforce AES keys where possible. - Limit which accounts have SPNs and avoid using high‑privilege accounts (e.g., domain admins) for services. - Monitor/alert on anomalous TGS‑REQ patterns and mass SPN enumeration.

This answer reflects how an attacker performs Kerberoasting and practical mitigations you’d recommend during a pentest report.

EasyTechnical

49 practiced

If advising a mid-size enterprise (5k-20k endpoints) on minimal instrumentation to detect common persistence and lateral movement techniques, what logs, agents, and configurations would you require on Windows endpoints, Linux servers, domain controllers, and core network devices? Prioritize by highest signal-to-noise.

Sample Answer

**Approach (brief)** Prioritize data sources that give high-fidelity indicators of persistence and lateral movement with low noise: process/command-line visibility, auth/logon events, service/install changes, network connection metadata, and DNS. Centralize to SIEM with NTP and correlated detection rules.

**Windows endpoints (high → low priority)** - Agents: Sysmon (v13+) + forwarder; host-based EDR if available. - Logs/configs: - Sysmon: ProcessCreate (with CommandLine), CreateRemoteThread, ImageLoad, ProcessAccess, DriverLoad, FileCreateTime, NetworkConnect, Registry (Create/Set/Delete) for hives used by persistence (Run, Services). - Windows Security Audit: 4624/4625 (logon), 4672 (priv use), 4720/4726 (user add/remove), 7045 (service installed). - PowerShell: Module logging, ScriptBlockLogging, Module logging, Transcription. - WMI/WinRM/PSRemoting audit. - Rationale: Sysmon + PowerShell logs capture malicious tooling and command-lines with high signal.

**Linux servers** - Agents: auditd (or osquery + agent), syslog forwarded. - Logs/configs: - auditd rules: execve, key:process_start; watches for /etc/cron*, /etc/init.d, systemd unit dirs, /etc/rc.local, /usr/bin/sudoers changes, sshd config. - auth.log / secure: ssh logins, sudo, su. - process accounting (acct) or osquery for commandline. - Rationale: exec and file watches detect persistence installs and suspicious remote shells.

**Domain Controllers** - Agents: Event forwarding from DCs to SIEM. - Logs/configs: - Kerberos/AD audit: 4768/4769/4771 (TGT/TGS activity), 4672, 4720/4728/4729, 4732/4733 (group changes), 5136 (AD modify), replication anomalies. - DNS server logs for suspicious lookups (lateral discovery, DGA). - Rationale: AD changes and abnormal Kerberos patterns reveal Golden/Silver ticket, account abuse, lateral movement.

**Core network devices (switches/routers/firewalls)** - Data: NetFlow/sFlow/IPFIX, firewall accept/deny logs, DHCP, RADIUS/AAA, switch syslog (port changes, MAC moves). - Configs: Export flows to collector; log administrative sessions (enable session logging). - Rationale: Flow + DHCP/RADIUS correlates device movement and unauthorized lateral tunnels.

**Operational notes (SIEM & tuning)** - Centralize, normalize, enrich (username, asset owner, AD status). - Correlation rules: unusual source process + network connect to internal admin svc; new service + scheduled task + remote connection; multiple host authentication failures then success. - Reduce noise: disable benign noisy Sysmon events (FileCreateTime) where needed, whitelist known admin tooling, apply baselines.

Example detection: Sysmon ProcessCreate (cmdline contains "schtasks" or "reg add HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run") + subsequent NetworkConnect to SMB ports → alert for persistence + lateral movement.

MediumTechnical

35 practiced

When investigating an endpoint suspected of autorun modification persistence, which specific forensic artifacts across the file system, registry, MFT, and event logs would you collect to build a tampering timeline? Include registry key paths and relevant Windows event IDs to look for.

Sample Answer

**Approach (brief)** Collect targeted artifacts across file system, registry, MFT/NTFS journals and Windows event logs, then correlate timestamps (MFT, file timestamps, USN, registry LastWrite, event time) to build a tampering timeline.

**File system / artifacts to collect**- Startup locations: %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup, %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, %SystemDrive%\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup- Prefetch files (.pf) for binaries launched from autorun- LNK shortcuts in user profiles (resolve target & timestamps)- Scheduled Tasks folder: C:\Windows\System32\Tasks and XML task files- Service binaries under C:\Windows\System32 or custom paths- USN Journal and $MFT entries for changed/created files- Jump lists, Recent Items, and DLLs (AppInit_DLLs locations)

**Registry keys (exact paths)**- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run- HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce- HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices / RunServicesOnce- HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName> (ImagePath, Start, Parameters)- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon (Userinit, Shell)- HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows (AppInit_DLLs)- HKCR\*\shell and specific ProgID autorun entries

Collect LastWrite timestamps and cached copies (NTUSER.DAT for HKCU).

**MFT / NTFS metadata**- $MFT entry timestamps (Created, Modified, MFT Changed, Access) for autorun files, task XMLs, service binaries- USN Journal records for creation/deletion- $LogFile and $UsnJrnl for sequence-based ordering

**Windows event IDs to extract**- Security: 4688 (Process Creation) — find process that wrote registry/files- Security: 4657 (A registry value was modified) — indicates registry tampering- Security: 4698 (A scheduled task was created), 4699 (deleted), 4700 (enabled/disabled), 4702 (updated)- System/Application: 7045 (A service was installed) — service autorun- TaskScheduler Operational: 106 (Task registered), 140 (Task started) — correlate to task XML- Sysmon (if present): 1 (Process Create), 11 (FileCreate), 13 (Registry value set), 6/7 for driver load

**Correlation / timeline building**- Start with authoritative events (4657, 7045, 4698, 4688) to anchor times. Cross-reference MFT/USN for file create times and registry LastWrite to determine sequence. Use prefetch and LNK to confirm execution and user context. Note gaps (time skew, anti-forensic changes) and validate via multiple sources.

**Example quick sequence** - 09:01 — Security 4688: regedit.exe spawned - 09:02 — Security 4657: HKCU\...\Run value created - 09:03 — $MFT shows file created in Startup folder -> matches Run target

This combination gives a defensible tampering timeline and attribution of actor/process.

Unlock Full Question Bank

Get access to hundreds of Persistence and Lateral Movement interview questions and detailed answers.

Join thousands of developers preparing for their dream job.