Privilege Escalation Techniques Questions

Focuses specifically on techniques and methodologies for moving from low privilege to higher privilege on target systems and across environments. Topics include identifying and exploiting operating system misconfigurations, weak file and directory permissions, improper service configurations, insecure scheduled tasks, weak sudo rules, credential reuse and harvesting, kernel vulnerabilities and local exploit development, group membership and privilege boundaries, horizontal movement between accounts, and platform specific differences for Windows and Linux. Candidates should also be able to discuss detection considerations, safe testing practices in scope, and mitigations.

HardTechnical

31 practiced

Explain Windows token impersonation and duplication in detail: differentiate impersonation tokens from primary tokens, explain how DuplicateTokenEx and CreateProcessAsUser are used to create processes under another identity, and give a realistic scenario where obtaining a SYSTEM token enables privilege escalation. Also list detection signals and event artifacts defenders can use to spot token duplication abuse.

Sample Answer

**Brief definition & intent**- A Windows token is an object representing a security context (user SID, groups, privileges). Tokens come as: - Primary token: attached to a process; can be used to create new processes. - Impersonation token: attached to a thread; allows a thread to execute with another identity but cannot directly be used with CreateProcessAsUser unless converted/duplicated into a primary token.

**Impersonation levels**- Anonymous, Identification, Impersonation, Delegation — higher levels allow more actions (Impersonation lets a thread act as the client on the local machine).

**DuplicateTokenEx vs CreateProcessAsUser (practical)**- DuplicateTokenEx: takes an existing token (often an impersonation token) and creates a new token object. You can request a primary token by passing TokenPrimary in the TokenType parameter and set desired access (TOKEN_ALL_ACCESS). Typical flow for a pentester: 1. Obtain handle to target token (e.g., from a service or via SeDebugPrivilege to LSASS). 2. Call DuplicateTokenEx(..., TokenPrimary, SECURITY_IMPERSONATION_LEVEL_SecurityImpersonation, ...).- CreateProcessAsUser: takes a primary token and creates a new process under that identity. After DuplicateTokenEx produced a primary token, call CreateProcessAsUser(token, ...).- Alternative: CreateProcessWithTokenW can be used when you have an elevated primary token but lack certain privileges.

**Realistic escalation scenario**- Compromise a low-privilege service account that runs a network service. Use named pipe or RPC impersonation to get an impersonation token for SYSTEM (e.g., service performs client auth and issues impersonation). DuplicateTokenEx to get a primary SYSTEM token, then CreateProcessAsUser to spawn cmd.exe or a service with SYSTEM privileges — full local privilege escalation; persistence or credential dumping follows.

**Detection signals & artifacts (what defenders/logs to check)**- Security logs: - 4688 (Process Creation) with suspicious parent/child combos (e.g., svchost -> cmd.exe) and unusual CommandLine aligning to CreateProcessAsUser/CreateProcessWithTokenW usage. - 4672 (Special privileges assigned) when high-privilege tokens are used. - 4624 with Elevated token info (Logon Type and Terminal) — look for SYSTEM or unexpected account types.- Sysmon: - Event ID 10 (ProcessAccess) showing handles opened to lsass.exe or token-holding processes. - Event ID 8 (CreateRemoteThread) and Event ID 1 (ProcessCreate) showing remote injection or spawned elevated processes. - ProcessCreate (1) commandline containing CreateProcessAsUser-style tools (e.g., psexec-like, runas /netonly oddities).- ETW/LSA telemetry: - Unusual DuplicateHandle/NT API calls, high frequency token duplication patterns.- Host artifacts: - Processes running as SYSTEM that normally aren’t; new service installations; suspicious scheduled tasks. - Presence of tools that call DuplicateTokenEx (mimikatz, custom exploits); suspicious DLLs loaded into lsass or services.

**Hunting tips**- Alert on processes opening PROCESS_QUERY_INFORMATION or PROCESS_VM_READ against lsass or on processes that obtain SeDebugPrivilege.- Correlate process access events (Sysmon 10) with subsequent process creation under SYSTEM.- Baseline normal service-process relationships; flag deviations.

This knowledge lets a pentester demonstrate exploitation paths (impersonation → DuplicateTokenEx → CreateProcessAsUser) and advise defenders on focused telemetry to detect token-duplication abuse.

MediumTechnical

31 practiced

Describe Kerberoasting: list prerequisites (SPNs and service accounts), explain how to enumerate SPN-bearing accounts, request and capture service tickets, and why attackers crack these tickets offline. Provide common detection indicators and defensive measures (password policy, constrained delegation) and explain safe lab testing boundaries for this technique.

Sample Answer

**Brief definition**Kerberoasting is an attack where an attacker requests Kerberos service tickets (TGS) for SPN-associated service accounts, extracts the encrypted service ticket, and crackes it offline to recover the service account plaintext password.

**Prerequisites**- Valid domain user account (any low-privileged user can request TGS).- Service Principal Names (SPNs) registered to service accounts (often AD service accounts, managed or local).- Target accounts have AES/RC4-encrypted Kerberos tickets (older/weak hashes make cracking easier).

**Enumerate SPN-bearing accounts**- Use built-in or common tools:

powershell

# PowerView
Get-NetUser -SPN
# setspn
setspn -T domain -Q */*

**Request & capture service tickets**- Request TGS for an SPN to receive an encrypted ticket:

powershell

# Rubeus (request TGS)
Rubeus.exe kerberoast /user:svc_account /format:kirbi
# or request all:
Invoke-Kerberoast -Verbose

- Save the ticket (.kirbi or ccache) and export to hash format for cracking.

**Why offline cracking**- Tickets contain service account-derived key material (encrypted with account password). Offline cracking avoids noisy network interaction and allows time-intensive attacks against weak passwords.

**Detection indicators**- Unusual high-volume TGS requests for many SPNs from a low-privileged account.- Service tickets exported to disk or abnormal processes running Rubeus/Invoke-Kerberoast.- Authentication spikes for accounts with SPNs.

**Defensive measures**- Enforce strong, complex, and lengthy passwords for service accounts and use managed/automated rotation.- Prefer gMSA or computer accounts (no user passwords).- Disable RC4; require AES.- Constrained delegation / resource-based constrained delegation where appropriate.- Monitor for TGS request patterns, uncommon service ticket exports, and logging via Kerberos event IDs (4769, 4624 correlation).

**Safe lab testing boundaries**- Only test in authorized environments. Use isolated AD lab, non-production accounts, and notify stakeholders. Never capture or crack tickets from production or accounts you don’t own. Keep cracked passwords confidential and follow engagement rules of engagement.

EasyTechnical

33 practiced

Scenario: On a Linux server you discover a root-owned cron job that executes '/usr/local/bin/backup.sh' every hour. The file '/usr/local/bin/backup.sh' is owned by root but group-owned by 'users' and writable by that group; your low-privileged account is a member of 'users'. Describe step-by-step how you could exploit this to escalate to root while staying within scope and avoiding disruption, list safety precautions, and recommend fixes.

Sample Answer

**High-level approach (one-sentence)** Leverage the group-writable root-owned cron script by modifying its contents to execute a benign proof-of-exploit command as root, confirm escalation, then clean up — all under authorization and non-destructive safeguards.

Step-by-step exploit (safe, scoped)1. Recon: verify cron entry and schedule (e.g., sudo cat /etc/crontab or sudo ls /etc/cron.hourly) and read /usr/local/bin/backup.sh contents.2. Confirm perms: ls -l /usr/local/bin/backup.sh shows owner root, group users, group-writable, and you are in group users.3. Prepare payload locally: create a short, non-destructive payload that demonstrates root execution. Example actions (choose one): - create a timestamped file /tmp/root-owned-<uid> written by root (touch, chown root:root). - create a SUID test binary only if permitted by scope (prefer avoided).4. Modify script safely: append a single line that executes the payload. Example (append via editor): echo "date > /tmp/cron_proof && chown root:root /tmp/cron_proof" >> /usr/local/bin/backup.sh5. Wait for cron run (within an hour) or trigger if allowed (do not manually run the script as root). After cron executes, verify /tmp/cron_proof is owned by root.6. Cleanup: remove appended lines and proof files; restore original script from backup.

Safety precautions- Obtain written authorization and confirm scope/times.- Use only non-destructive, reversible proofs (file creation, timestamp) — avoid shells or persistent backdoors.- Notify stakeholders if test may trigger alerts.- Work on a copy, keep original backed up; perform changes during agreed maintenance windows.- Log all actions and immediately revert changes after verification.

Remediation recommendations- Remove group-write: chmod 0644 /usr/local/bin/backup.sh.- Change group ownership to a dedicated, minimal-privilege group or root.- Run privileged cron tasks under a dedicated service account with minimal privileges.- Store scripts in version-controlled, audited location and validate integrity (checksums).- Restrict who is in the 'users' group; apply principle of least privilege.- Use sudo with strict rules or setuid alternatives only when necessary.

Why this works / rationaleCron runs as root; any code in a root-owned script executed by cron runs with root privileges. If unprivileged users can modify that script, they can cause root to run arbitrary commands — the safest verification is a harmless file creation to prove control and then remediate.

HardTechnical

28 practiced

Explain methods to bypass modern exploit mitigations such as ASLR, DEP (NX), SMEP and SMAP when designing local privilege escalation exploits on x86_64 Linux. For each mitigation describe concrete evasion techniques at a conceptual level and then list defensive controls and monitoring that defenders should implement to mitigate these bypass techniques.

Sample Answer

**Overview (role: Penetration Tester)** Below are conceptual evasion techniques for ASLR, DEP/NX, SMEP and SMAP on x86_64 Linux, followed by defensive controls and monitoring recommendations defenders should implement.

**ASLR (Address Space Layout Randomization)** - Evasion techniques: - Infoleaks: memory disclosure bugs (format strings, infoleak via /proc, userland pointers) to read libc/stack heap pointers and compute base addresses. - Heap/stack grooming: trigger deterministic allocations to reduce entropy and brute-force on low-entropy targets (e.g., 32-bit compat, partially randomized ASLR). - Return-oriented programming (ROP) using relative offsets when module rebasing is predictable (JIT spraying equivalent).- Defensive controls: - Full ASLR with high entropy (64-bit PIE for binaries), KASLR for kernel. - Harden services to reduce infoleaks (sanitize logs, restrict /proc/pid/maps access). - Monitoring: detect repeated crashes/brute-force patterns, unusual reads of /proc/*, and memory-exposure system calls.

**DEP / NX (Data Execution Prevention)** - Evasion techniques: - ROP/JOP chains to perform useful work without executable stack. - Return-to-libc / ret2syscall to invoke mprotect to mark pages executable. - Use of existing executable memory (JIT or writable-executable pages).- Defensive controls: - Enforce NX for user and kernel, enable W^X policies (no writable+executable pages). - Control mprotect/mmap privileges via seccomp or LSMs. - Monitoring: audit mmap/mprotect with unusual PROT_EXEC requests, inspect process memory permissions, leverage EDR to flag in-memory ROP gadget patterns.

**SMEP (Supervisor Mode Execution Protection)** - Evasion techniques: - Kernel ROP: build chains using kernel-space gadgets to avoid executing userland pages. - Use kernel vulnerabilities to flip CR4.SMEP or corrupt control flow to call trusted kernel code that maps user pages as executable. - Return-to-userland only after bypassing SMEP via stack pivot to kernel code that disables SMEP.- Defensive controls: - Keep SMEP enabled; enable SMAP too. - Kernel hardening: KASLR, restrict module loading, sign modules. - Monitoring: kernel integrity monitoring, detect writes to CR4-like control registers, anomalous kernel call sequences.

**SMAP (Supervisor Mode Access Prevention)** - Evasion techniques: - Kernel ROP that uses kernel-controlled buffers or copy_to_user/copy_from_user flaws to move attacker data into kernel-writable/executable buffers. - Flip SMAP bit or reuse kernel functions that temporarily disable SMAP (very rare but possible).- Defensive controls: - Keep SMAP enabled, patch copy_from_user/copy_to_user misuse. - Module signing, minimize attack surface for kernel callbacks. - Monitoring: syscall tracing for suspicious copy_to_user patterns, detect temporary SMAP disabling.

General defensive recommendations: apply least privilege, patch promptly, enable SELinux/AppArmor, use kernel exploit mitigations (KCFG, KPTI where relevant), attack-surface reduction (disable unneeded modules), and deploy EDR/host IDS with anomaly detection for process memory changes, unusual syscalls, repeated crashes, and mmap/mprotect exec requests.

Learnings for testing: focus on finding infoleaks, writable-exec surfaces, and kernel attack vectors; always document proof-of-concept and remediation steps.

MediumTechnical

34 practiced

Explain the DLL search-order hijacking (binary planting) technique on Windows. Describe (a) how to identify vulnerable applications on a host, (b) how an attacker could exploit such a vulnerability to run code in a higher-privileged context, and (c) practical mitigations developers and administrators should apply to prevent DLL hijacks.

Sample Answer

**Definition & basics**DLL search-order hijacking (binary planting) exploits Windows’ DLL load order so a malicious DLL placed in a directory searched before the legitimate DLL gets loaded by a privileged process. Result: attacker-controlled code runs in the context/privilege of that process.

**(a) Identifying vulnerable apps**- I scan hosts for executables that load non-system DLLs without fully-qualified paths. Tools: Process Monitor (ProcMon) to observe DLL search activity, Dependency Walker / CFF Explorer to list imports, and automated scanners (e.g., mimikatz’s FindLocalDLLs or custom PowerShell) to find apps that call LoadLibrary with relative names.- Look for services, installers, or scheduled tasks running as SYSTEM that run from writable directories (temp, user folders, network shares).

**(b) Exploitation flow**- Place a malicious DLL (matching exported functions) into a location earlier in search order (same folder as EXE, current directory, or a writable share).- Trigger the target app/service to start or reload the DLL (restart service, invoke functionality).- The OS loads attacker DLL; code executes with the process’s privileges (e.g., SYSTEM), enabling persistence or privilege escalation.

Example: a service running as SYSTEM launches an updater from C:\ProgramData\MyApp\ — if that directory is writable by low-privileged user, planting MyLib.dll leads to SYSTEM code execution when service restarts.

**(c) Practical mitigations**Developer controls:- Use fully-qualified paths when loading DLLs (LoadLibraryEx with LOAD_LIBRARY_SEARCH_SYSTEM32 or explicit path).- Adopt Safe DLL Search Mode and call SetDefaultDllDirectories with LOAD_LIBRARY_SEARCH_DEFAULT_DIRS.- Sign DLLs and validate signatures at load time; use side-by-side assemblies (manifests).- Avoid writing executables/services into world-writable locations.

Administrator controls:- Enforce least privilege on application directories; remove write permissions for non-admins.- Enable Windows Defender Exploit Guard / AppLocker to restrict DLLs.- Keep Safe DLL Search Mode enabled (default since Windows XP SP2) and apply Group Policy to enforce code integrity.- Monitor startup/service restarts and use ProcMon/ETW alerts for unexpected DLL loads.

Final note: during tests I always document reproducer steps, PoC DLL behavior, impacted hosts, and prioritized remediation for developer + admin teams.

Unlock Full Question Bank

Get access to hundreds of Privilege Escalation Techniques interview questions and detailed answers.

Join thousands of developers preparing for their dream job.