Pentesting: How Attacks Work

A penetration test asks whether someone can cross a security boundary, shows how that happens, and explains how to fix it. Start with the account, resource and permission at each step. A tool automates a request; understanding why the server accepts it is what lets you choose a useful next step.

This page brings together the attacks and supporting techniques in the reviewed DAEMONSEC machine write-ups, university reports and DAEMONSEC-VAULT notes, plus examples from the supplied 198-page Red Block report. Each entry explains the mechanism, required conditions, evidence and fix. Report examples and partial notes are labelled separately. All examples are for agreed test scope or lab systems.

How to read: learn the foundations, choose an attack family, then follow a tool link for commands. Each diagram reads left to right on a wide screen and top to bottom on a phone. Open a step to see what happens there. Everything stays on this page; opening a tool card is optional.

Foundations: what you are testing

The boundaries

An application has users and roles; an operating system has process identities and file permissions; a domain has accounts and delegated rights. They overlap without being identical. A web administrator might execute code as a low-privilege service, and a local Windows administrator might have no domain administrative rights.

A repeatable workflow

Agree scope and evidence handling, discover hosts, enumerate services, validate a candidate weakness, prove the smallest useful impact, then clean up and report. A new password or route sends you back to enumeration. Real paths loop; they are not a mandatory sequence of exploits.

Passwords, hashes, challenges and keys

A password is the secret a user supplies. A stored password verifier is a one-way representation used to check guesses. Offline cracking tests candidates against a captured verifier without sending each guess to the target. Online guessing sends attempts to a service and can trigger account lockout.

An NT hash is a particular password-derived key used by Windows authentication. NetNTLMv2 is a challenge-response exchange captured from network authentication: it can be cracked or relayed under the right conditions, but is not directly the NT hash used for pass-the-hash. An SSH private key or a certificate’s private key is another kind of authentication secret. File encryption passwords, login passwords and database hashes may all be different values.

Active Directory and Kerberos, from the beginning

Active Directory stores accounts, groups, computers and permissions. A domain controller (DC) hosts directory and authentication services. A SID identifies a security principal; a UPN is a user-style name. Names can change without creating a new SID. Nested groups and object permissions can give an account useful rights even when its group list does not say Domain Admins.

Kerberos uses the DC’s KDC to issue a TGT (a ticket for asking for other tickets) and TGS/service tickets (tickets for a particular service). An SPN names that service. Ticket requests, service account keys and delegated impersonation are distinct parts of a chain. Correct time and name resolution matter.

AD CS is certificate infrastructure. A CA issues certificates using a template’s rules. A certificate plus its private key may authenticate an account if its purpose, trust and identity mapping are accepted. Enrolment, requesting another identity and successfully authenticating as that identity are three separate checks. Historical weak-mapping examples may fail on patched domains with strong mapping enforced.

Linux and Windows privileges

Linux file owner/group/mode checks, sudo rules, SUID bits and capabilities determine what a process can do. A special mode bit alone is not proof of a usable escalation; the program must preserve or exercise the privilege in a reachable operation.

Windows uses tokens, groups, privileges and resource ACLs. SeBackupPrivilege, SeImpersonatePrivilege and SeTcbPrivilege have different operations and prerequisites. A disabled privilege can already be present; an absent privilege cannot be created just by toggling a token flag. Windows SYSTEM is a local service identity, distinct from a domain administrator.

Minimal evidence and cleanup

Record the starting identity, exact resource, relevant permission, request/command and observed result. Prefer a harmless marker, identity query or one permitted sample record to a bulk dump. Confirm the result from a fresh session where needed. Restore changed SPNs, UPNs, group memberships, ACLs, services, uploaded plugins and test files. A failed callback may be a listener or route problem; a claimed vulnerability still needs independent proof.

Find an attack family

• Credentials and exposed data - 12 explanations
• Web attacks - 18 explanations
• Services and application trust - 9 explanations
• Active Directory permissions and Kerberos - 14 explanations
• Certificate attacks - 5 explanations
• Linux privilege escalation - 8 explanations
• Windows privilege escalation - 8 explanations
• Movement, sessions and boundaries - 8 explanations
• Worked chains
• Tools from the Red Block report
• Source coverage and evidence limits

Credentials and exposed data

Anonymous SMB, LDAP and FTP access | NFS export and file-permission abuse | SNMP information disclosure | Credentials in files, directory attributes and history | Cleartext authentication interception | Offline password, key and vault cracking | Online brute force and default credentials | Password spraying | Password reuse and local/domain identity confusion | Forced authentication and NetNTLM capture | DNS zone-transfer disclosure | Cisco type 7 decoding and type 5 cracking

Anonymous SMB, LDAP and FTP access

A service accepts a guest or unauthenticated identity and gives it more information than intended. SMB can expose files, LDAP can expose directory objects, and FTP can expose downloads. Enumeration turns that disclosure into usernames, programs or configuration to investigate; an anonymous connection alone does not mean administrative access.

Needs: The service must allow that identity to read the particular share, directory query or file. Permissions differ between listing a share and opening it.

Evidence: A specific file or query result is returned without an authorised account. Record the access identity and resource.

Fix: Remove unnecessary guest access and grant read permissions only to the principals that need them.

Documented example: Support, Forest, Timelapse (DAEMONSEC-VAULT). Tool commands.

NFS export and file-permission abuse

NFS lets a client mount a remote directory as part of its own filesystem. An overly broad export can expose sensitive files. With AUTH_SYS the server uses client-supplied numeric user and group IDs; poorly restricted mappings can let a client read another user’s files. This is different from breaking encryption.

Needs: A reachable export, matching export restrictions and a usable identity mapping. root_squash maps client root to an anonymous identity; it does not repair an export that is readable by another allowed UID.

Evidence: An otherwise protected file is readable through the export. A visible export list alone is insufficient.

Fix: Restrict clients and paths, enforce file ownership, use root squashing, and prefer authenticated NFS security where appropriate.

Documented example: CMP314. Tool commands.

SNMP information disclosure

SNMP exposes management information such as interfaces and running processes. A guessable community string on older SNMP versions acts like a shared access token. If a process was started with a password on its command line, the management data can disclose that password.

Needs: SNMP read access and an exposed object containing useful data. A community string permitting reads does not necessarily permit configuration changes.

Evidence: The response includes the actual sensitive argument or management information, with the credential redacted in evidence.

Fix: Restrict management access, use SNMPv3 authentication/privacy, and keep secrets out of command-line arguments.

Partial note: Pandora (DAEMONSEC-VAULT).

Credentials in files, directory attributes and history

A password stored in an accessible file is already known to anyone who can read that file. Common locations in your work were spreadsheets, installation configurations, scripts, AD description/info fields, PowerShell history, setup logs, application environment files and AutoLogon settings. This is disclosure, rather than cryptographic cracking.

Needs: Read access to the exact resource. Registry ACLs and the way AutoLogon was configured matter; not every Windows host stores a readable plaintext AutoLogon password.

Evidence: A redacted source location and a confirmed login as the expected principal. A string that looks like a password is only a lead.

Fix: Use secret stores, remove credentials from notes/history, limit read permissions and rotate any exposed secrets.

Documented example: EscapeTwo, Support, Sauna, Cicada (DAEMONSEC-VAULT), Resolute (DAEMONSEC-VAULT), Timelapse (DAEMONSEC-VAULT), MetaTwo, Zephyr (DAEMONSEC-VAULT). Tool commands.

Cleartext authentication interception

Protocols such as unprotected FTP, Telnet and LDAP simple bind can send reusable passwords over the network. A packet capture or a service endpoint under your control can expose them. Support involved observing a downloaded program’s LDAP bind; Return redirected a printer’s configured LDAP server to a listener.

Needs: An unencrypted authentication exchange visible at the capture point, or control of a destination that a client will authenticate to. TLS-protected traffic is not readable merely because packets were captured.

Evidence: The trace identifies the protocol and account, and shows an unprotected credential field. Preserve a redacted extract.

Fix: Use protected transport, validate server certificates and lock down applications’ authentication destinations.

Documented example: Support, Return (DAEMONSEC-VAULT), Cap (DAEMONSEC-VAULT), CMP314.

Offline password, key and vault cracking

An attacker takes a password verifier or encrypted container away and tests guesses locally. Each guess is hashed or used to derive a decryption key, then checked against the stolen data. Slow, salted password functions make this expensive; they do not rescue a weak password that is already in the candidate list.

Needs: A readable hash, challenge-response or supported encrypted ZIP, PFX, SSH key, KeePass database or PGP key. Formats and KDFs differ; selecting a mode by filename alone is unreliable.

Evidence: The original key, archive or database opens, or a controlled login succeeds. A cracker’s output alone is not enough.

Fix: Use long unique secrets, strong supported KDFs and strict access controls on encrypted stores and password hashes.

Documented example: Builder, MetaTwo, Postman, Jeeves, Timelapse (DAEMONSEC-VAULT), GoodGames (DAEMONSEC-VAULT), CMP314, Sauna, Forest, Fluffy, TombWatcher, Red Block pp. 136-139, 157-161. Tool commands.

Online brute force and default credentials

Online guessing submits candidate passwords to the real login service. Brute force commonly tests many guesses for one account; default-credential testing checks the vendor’s initial login. These requests reach the target, consume resources and can trigger lockout. Hydra does not crack a remote password hash when it submits logins.

Needs: A reachable login and a scoped attempt budget based on the lockout policy. A reliable success/failure detector is essential for web forms.

Evidence: An authenticated session or service response proves the credential, not just a different HTTP response length.

Fix: Remove defaults, apply rate limiting and monitored lockout controls, use MFA, and require unique strong passwords.

Documented example: Jerry (DAEMONSEC-VAULT), BoardLight (DAEMONSEC-VAULT), CMP210, CMP314, CMP319. Tool commands.

Password spraying

Spraying tries a small number of plausible passwords across multiple usernames. It exploits password reuse and predictable choices while spreading attempts across accounts. It can still lock accounts: retries across different services may accumulate against the same directory policy.

Needs: A username list, a defensible candidate and a known attempt policy. Validating an already recovered password against its known owner is credential validation, not automatically spraying.

Evidence: A verified matching identity and service. A successful SMB login does not imply WinRM or administrative access.

Fix: Use unique passwords and MFA, monitor cross-account login patterns and remove credentials from descriptions or shares.

Documented example: Support, EscapeTwo, Cicada (DAEMONSEC-VAULT), Resolute (DAEMONSEC-VAULT), Zephyr (DAEMONSEC-VAULT). Tool commands.

Password reuse and local/domain identity confusion

A secret recovered for one purpose also works somewhere else: a key passphrase may be a local password, a database password may work over SSH, or the same username may have a separate local and domain account. Those accounts have different SIDs and permissions even when their visible names match.

Needs: The second account actually shares the secret and accepts the chosen authentication method. Username similarity is not proof of a shared account.

Evidence: The effective account SID/name and realm match the intended login. Your working directory does not prove administrator rights.

Fix: Use unique credentials, managed service accounts and local administrator password rotation; restrict cross-service logon.

Documented example: Postman, MetaTwo, EscapeTwo, GoodGames (DAEMONSEC-VAULT), BoardLight (DAEMONSEC-VAULT), Papers (DAEMONSEC-VAULT), Zephyr (DAEMONSEC-VAULT).

Forced authentication and NetNTLM capture

A file or application feature makes Windows connect to an attacker-controlled network path. The client may attempt NTLM authentication automatically. Responder receives a challenge-response, commonly NetNTLMv2. That response can support offline guessing; it is not the reusable NT hash accepted by pass-the-hash.

Needs: A processing trigger, outbound connectivity and a client permitted to use NTLM. In your notes the triggers included Media playlists, Fluffy library files and Zephyr PDFs.

Evidence: An authentication exchange arrives from the expected client. Capture, cracking and relay are three separate outcomes.

Fix: Patch the triggering flaw, restrict outbound SMB/NTLM and avoid automatic authentication to untrusted resources.

Documented example: Media, Fluffy, Zephyr (DAEMONSEC-VAULT), Red Block pp. 80-89. Tool commands.

DNS zone-transfer disclosure

AXFR copies a DNS zone from an authoritative server. It is intended for authorised secondary servers. If an unrelated client can transfer it, internal naming and address information can be disclosed in bulk. This provides discovery leads rather than a login or command execution.

Needs: A reachable authoritative server that allows the client to transfer the specific zone.

Evidence: A completed transfer with the expected SOA boundaries and records. A denied or interrupted request is not success.

Fix: Restrict transfers to approved secondaries and authenticate them where supported.

Report example: Red Block pp. 9. Tool commands.

Cisco type 7 decoding and type 5 cracking

Type 7 configuration passwords are reversibly obfuscated. A reader can decode them without guessing. Type 5 enable secrets are MD5-crypt verifiers and require offline candidate testing. They have different mechanisms even when found in the same leaked router configuration.

Needs: Readable configuration and an intact supported record; password reuse elsewhere is a separate condition.

Evidence: A decoded or recovered value confirmed for its original role.

Fix: Protect configuration backups, use supported strong storage and rotate exposed secrets.

Report example: Red Block pp. 23-27. Tool commands.

Web attacks

IDOR and missing object authorisation | SQL injection | Reflected cross-site scripting | Stored cross-site scripting | Path traversal and local file inclusion | XML external entity injection | Server-side request forgery | Server-side template injection | Operating-system command injection | Shellshock in Bash-backed CGI | API role modification and broken function authorisation | Jenkins CLI arbitrary file read | CMS configuration and draft disclosure | Unsafe deserialization | Zabbix SAML session bypass | Invitation bypass through format-only validation | Upload plus PHP file inclusion | Webmin privileged file-write escalation

IDOR and missing object authorisation

An application uses a caller-controlled identifier to choose a record or file, but does not check whether the caller may access that specific object. Changing the identifier then reads someone else’s resource. Predictable IDs make testing easier, but the vulnerability is the missing authorisation check.

Needs: At least one resource that your test identity should not be able to read or change. Using a random UUID does not replace an ownership check.

Evidence: The same caller obtains a resource belonging to another identity. Use controlled accounts when available.

Fix: Check object ownership or policy on every server-side access, independently of the identifier format.

Documented example: Cap (DAEMONSEC-VAULT).

SQL injection

SQL injection happens when untrusted input changes the structure of a database query instead of remaining a parameter value. A modified predicate can bypass a login; a UNION or other extraction technique can return extra data. The permissions of the application’s database account limit the impact.

Needs: An input reaching an unsafe query, the correct database syntax and a observable response or inference channel. A nonce or logged-in session may be required by the endpoint without preventing injection.

Evidence: A controlled data or logic change repeatably linked to the input. A generic server error is not confirmation.

Fix: Use prepared statements with bound values, allowlist dynamic identifiers and minimise database permissions.

Documented example: MetaTwo, GoodGames (DAEMONSEC-VAULT), Pandora (DAEMONSEC-VAULT), CMP319. Tool commands.

Reflected cross-site scripting

The server immediately places input into a response without the correct encoding for that HTML or JavaScript context. When a browser interprets the result, attacker-supplied content executes in the application’s origin. This affects the visiting browser, rather than inherently executing a command on the web server.

Needs: An executable reflection context and a victim visiting the crafted request. Browser controls and CSP can change what a payload can do.

Evidence: A harmless controlled action executes in the browser. Merely finding the text in the source is not sufficient.

Fix: Apply context-specific output encoding, safe DOM APIs and an effective CSP as additional protection.

Documented example: CMP319. Tool commands.

Stored cross-site scripting

Stored XSS persists untrusted content in a comment, profile or other saved record. The application later renders that content as executable browser code. One submission can affect multiple readers because the vulnerable output is served whenever the saved record is displayed.

Needs: A writable field and an unsafe output context when another session views the saved data.

Evidence: A second controlled session executes a benign proof after loading the saved record. Remove the test value afterwards.

Fix: Encode at the final output context, sanitise permitted rich HTML with a maintained library and remove stored payloads.

Documented example: CMP319. Tool commands.

Path traversal and local file inclusion

Path traversal lets a filename escape its intended directory. Local file inclusion occurs when an application includes an attacker-selected local file in its execution/rendering path. Both can disclose data, but reading a file is not itself proof of code execution. Papers’ bot used directory traversal; Bumtree had a file-inclusion input.

Needs: A controllable path reaching file handling and filesystem read rights in the application’s identity.

Evidence: A benign file outside the permitted directory is returned. Report read-only disclosure separately from any proven execution.

Fix: Resolve allowed file IDs server-side, canonicalise paths, enforce a directory allowlist and minimise filesystem privileges.

Documented example: Papers (DAEMONSEC-VAULT), CMP319.

XML external entity injection

An XML parser resolves an attacker-supplied external entity as a file or URL. The parser then accesses that resource with the server process’s privileges. In MetaTwo, XML inside WAV metadata was the entry point; the result was file disclosure, not a WAV codec memory exploit.

Needs: An XML parsing route with external entity resolution enabled and a visible or out-of-band result channel.

Evidence: A controlled file marker or callback confirms resolution in the target’s context. A DNS lookup alone proves only that lookup.

Fix: Disable external entities/DTDs, restrict parser network access and patch the affected parsing dependency.

Documented example: MetaTwo.

Server-side request forgery

SSRF makes the server send a request to a destination chosen by an untrusted caller. Because the server is on a different network, it may reach services the tester cannot reach directly. Sau’s Request Baskets instance became a forwarding route to a localhost Maltrail service.

Needs: A controllable destination and a permitted network route from the requesting server. An SSRF response is not automatically a shell.

Evidence: A unique controlled callback or the internal service’s response establishes the server-side request.

Fix: Allowlist destinations and schemes, revalidate redirects and resolved addresses, and restrict backend egress.

Documented example: Sau (DAEMONSEC-VAULT).

Server-side template injection

A template engine treats user input as template source instead of data supplied to a trusted template. An expression may be evaluated by the server; in an unsafe engine context that evaluation can reach objects or functions capable of command execution. GoodGames used a Flask/Jinja route.

Needs: Input that is compiled as a template and an engine/context with exploitable capabilities. A rendered expression alone does not prove arbitrary command execution.

Evidence: A repeatable harmless expression result establishes evaluation; a separate identity marker establishes execution if tested.

Fix: Keep templates fixed and pass input as values. Use restricted contexts and avoid exposing powerful runtime objects.

Documented example: GoodGames (DAEMONSEC-VAULT).

Operating-system command injection

An application combines untrusted data with a shell command. The shell interprets part of that value as command syntax, allowing an additional operation in the application’s OS identity. Authentication requirements vary: TwoMillion needed application-admin access, Maltrail did not, and Webmin required an eligible authenticated user.

Needs: An unsafe shell call reachable by the current identity and a payload matching its quoting/context.

Evidence: A benign identity or unique marker proves execution. Do not infer root from the web application’s administrator role.

Fix: Avoid the shell, use fixed executable paths and argument arrays, validate allowed inputs and run services with minimal privileges.

Documented example: TwoMillion (DAEMONSEC-VAULT), Sau (DAEMONSEC-VAULT), Postman.

Shellshock in Bash-backed CGI

Shellshock is a historical Bash environment-parsing flaw. A CGI server turns request fields such as headers into environment variables. When a vulnerable Bash process starts, crafted function-like environment content can execute appended commands. The CGI-to-Bash handoff is the critical connection.

Needs: An unpatched Bash parser and a request path that starts Bash with attacker-influenced environment variables. An Apache banner alone does not establish either condition.

Evidence: CMP314 records a harmless command response and a subsequent session. CMP319 has a scanner finding, not the same depth of proof.

Fix: Patch Bash, remove unnecessary CGI handlers and minimise the CGI account’s access.

Evidence differs by source: CMP314, CMP319.

API role modification and broken function authorisation

An endpoint accepts a sensitive field such as an administrator flag from a caller who should not control it. The server trusts the submitted change instead of deriving permission from trusted state. In TwoMillion, modifying the role unlocked another endpoint whose command injection was a separate flaw.

Needs: A reachable role-setting function with missing permission checks or unsafe field binding. Discovering an admin URL does not mean it can be used.

Evidence: The role changes in trusted server state and an otherwise denied function becomes usable.

Fix: Authorise every function, allowlist editable properties and derive privileged roles exclusively from trusted server decisions.

Documented example: TwoMillion (DAEMONSEC-VAULT).

Jenkins CLI arbitrary file read

Jenkins’ affected CLI parser expands arguments beginning with @ into local file contents. A command’s error output can echo part of that content back to the caller. Builder used this to read a stored password hash, then cracked it; disclosure and password recovery were separate steps.

Needs: The affected CLI/argument-expansion behaviour, a reachable transport and a command that reveals useful expanded content. Access and number of returned lines depend on the command and permissions.

Evidence: A benign file marker appears in the CLI response. Record the command, transport and returned portion.

Fix: Upgrade Jenkins or apply the vendor’s mitigation and restrict CLI access.

Documented example: Builder.

CMS configuration and draft disclosure

A CMS access-control flaw exposes configuration or unpublished content to an unauthorised caller. Devvortex’s Joomla API disclosed configuration; Papers’ WordPress route disclosed a draft containing another service location. Information disclosure can start a chain even when it gives no immediate command execution.

Needs: The affected endpoint, version/configuration and an access level that should be denied the data.

Evidence: The response contains a controlled restricted item while unauthorised. A version match is only a reason to test.

Fix: Patch the CMS, protect administrative/API routes and keep reusable secrets out of public-facing stores.

Documented example: Devvortex (DAEMONSEC-VAULT), Papers (DAEMONSEC-VAULT).

Unsafe deserialization

Deserialization reconstructs runtime objects from a message. If untrusted input can choose dangerous object types or relationships, reconstruction can invoke a chain of methods with unwanted effects. The Interpreter note records a Mirth Connect pre-authentication RCE test; its borrowed walkthrough material is not evidence of every described later step.

Needs: An unsafe deserializer, an appropriate available gadget chain and a reachable parser before the necessary protection. XML syntax by itself does not imply XXE or deserialization RCE.

Evidence: A benign controlled effect in the server context. The vault records a Metasploit shell for the initial Mirth step.

Fix: Use strict data schemas and safe types, avoid native deserialization of untrusted data, and install the vendor fix.

Partial note: Interpreter (DAEMONSEC-VAULT).

Zabbix SAML session bypass

CVE-2022-23131 affected how Zabbix stored SAML session state on the client. Altering trusted session data could let an attacker authenticate as another known user. Zephyr’s note records generating a cookie, placing it in the browser and entering the SSO flow. This is a Zabbix session flaw, distinct from forging a signed AD FS assertion.

Needs: An affected Zabbix instance with SAML SSO enabled and the required user information. Generic SAML use does not imply this weakness.

Evidence: A session is authenticated as the intended test user. A locally generated cookie is not proof until the server accepts it.

Fix: Apply the Zabbix security update and invalidate exposed sessions; keep session identity decisions server-side.

Documented example: Zephyr (DAEMONSEC-VAULT).

Invitation bypass through format-only validation

A format check proves that a value has the right shape. It does not prove the server issued that invitation. The supplied report reads application source and finds a regular expression used as the entire acceptance decision, allowing a made-up matching value to unlock an upload feature.

Needs: An application that uses syntax validation without validating existence, ownership, expiry and intended use.

Evidence: An unissued test invitation unlocks the protected function.

Fix: Validate server-issued tokens and their binding, expiry and one-time use; keep format checking as a preliminary check.

Report example: Red Block pp. 31-38.

Upload plus PHP file inclusion

An upload endpoint can accept script content because it checks only filenames. A separate PHP include vulnerability then executes the uploaded file. The report requests index.php with the uploaded path: PHP inclusion explains execution even if a direct request for the image-like filename would serve it as data.

Needs: Accepted attacker-controlled content, a predictable readable upload path and an include operation able to reach it.

Evidence: A benign server-side marker via inclusion; a double extension or successful upload alone is insufficient.

Fix: Store uploads outside executable paths, verify file content, and allowlist include destinations.

Report example: Red Block pp. 38-39.

Webmin privileged file-write escalation

A less-privileged Webmin account can cross its assigned boundary if a vulnerable file operation writes as root. A privileged file write can then become command execution. The report labels its final chain CVE-2022-30708 but claims a version beyond the range in the vendor advisory; the version discrepancy remains unresolved.

Needs: An actually affected build and an account with access to the vulnerable operation. A working web login does not establish either condition.

Evidence: Evidence of the unauthorised privileged write or process under the tested build; do not infer it from a banner alone.

Fix: Apply vendor fixes and restrict untrusted application users and modules.

Report example: Red Block pp. 197-198. Tool commands.

Services and application trust

Jenkins Script Console execution | Build pipeline and credential-binding abuse | CMS code editing and upload-to-execution | Tomcat Manager application deployment | SQL Server xp_cmdshell execution | Redis persistence-file write to SSH access | Management-console script execution | Liferay and Nexus administrative scripting | Legacy SonarQube plugin loading

Jenkins Script Console execution

The Script Console is deliberately capable of running Groovy code on the Jenkins controller. If an untrusted caller can reach it, normal administrative functionality becomes OS execution as Jenkins’ service account. Jeeves required discovering the application’s sub-path before the exposed console was visible.

Needs: Console access, authorised by a dangerous permission or missing authentication. Discovering a Jenkins installation is not sufficient.

Evidence: A harmless controller-side identity check returns. Application access and OS privilege are recorded separately.

Fix: Require authentication and strict administrative permissions; keep controller secrets and agent separation protected.

Documented example: Jeeves.

Build pipeline and credential-binding abuse

A pipeline author may be allowed to ask the build system to use stored deployment credentials. If that author can run arbitrary build logic in the credential’s scope, they can often use or expose the credential. Builder used an SSH Agent-bound root key to reach the host.

Needs: Permission to define or modify a job and access to the relevant credential scope or plugin. A visible credential name does not prove the key is available.

Evidence: A controlled authenticated operation to the authorised target proves the binding’s reach. Printing a key is unnecessary for many tests.

Fix: Separate job authors from privileged credential scopes, isolate agents and use narrowly scoped deployment identities.

Documented example: Builder.

CMS code editing and upload-to-execution

A CMS administrator may edit server-side templates or create executable pages. A role intended to manage content can therefore become OS code execution if it also controls code. Devvortex used Joomla template editing; BoardLight used the Dolibarr PHP execution flaw. Acceptance of an uploaded file alone does not establish execution.

Needs: Code-editing/deployment rights or a specific flaw bypassing those restrictions, plus a server execution route for the written content.

Evidence: A harmless server-side marker proves execution at the written location. Save and restore the original content.

Fix: Disable production code editors, separate content from executable files and patch permission-bypass flaws.

Documented example: Devvortex (DAEMONSEC-VAULT), BoardLight (DAEMONSEC-VAULT), Media.

Tomcat Manager application deployment

Tomcat Manager can deploy Java web applications packaged as WAR files. A weak manager login grants that deployment power to an attacker. The deployed application runs as the Tomcat service account; Jerry’s service was highly privileged, but that is not universal.

Needs: Manager deployment rights and a valid WAR/application compatible with the instance.

Evidence: A controlled application marker and verified service identity. Remove the deployed application after testing.

Fix: Restrict manager reachability and roles, remove default credentials and run Tomcat as an unprivileged account.

Documented example: Jerry (DAEMONSEC-VAULT).

SQL Server xp_cmdshell execution

xp_cmdshell is SQL Server’s facility for invoking operating-system commands. It may be disabled, but a sufficiently privileged SQL login can enable it. Commands run as the SQL service account for sysadmin callers, or the configured proxy for eligible non-sysadmin callers. Database sysadmin does not necessarily equal Windows administrator.

Needs: The SQL permission to use/enable the feature and an eligible service/proxy configuration.

Evidence: A harmless OS identity result, with feature state and caller privileges recorded.

Fix: Avoid unnecessary SQL sysadmin grants, keep the feature disabled where possible and minimise service/proxy permissions.

Documented example: EscapeTwo.

Redis persistence-file write to SSH access

An exposed Redis instance can become a filesystem-write primitive when it permits changing the persistence directory/filename and saving data. Postman wrote public-key material into the Redis account’s SSH authorisation file. The database daemon’s OS permissions, not Redis’ name, determine which paths it can write.

Needs: Reachable unauthorised Redis commands, permitted configuration/persistence operations, a writable SSH authorisation path and an SSH account that accepts that key.

Evidence: A successful controlled SSH login. A successful Redis save is only the file-write stage.

Fix: Isolate Redis, enforce authentication/ACLs, restrict configuration commands and prevent writes to authentication files.

Documented example: Postman. Tool commands.

Management-console script execution

Monitoring and administration systems often support running scripts on managed hosts. Once an attacker holds the relevant application role, that intended feature can execute code as a service account with reach beyond the web interface. Zephyr used Zabbix scripts after gaining an application session.

Needs: The actual role permitting script creation/execution and the managed execution route. Application admin status is not automatically OS root.

Evidence: A harmless marker from the expected managed host. Record server-side versus agent-side execution.

Fix: Restrict script roles and destinations, use narrowly privileged service accounts and audit script changes.

Documented example: Zephyr (DAEMONSEC-VAULT).

Liferay and Nexus administrative scripting

Some application roles intentionally permit server-side Groovy scripts. A compromised account with that role can execute code as the application service. This is abuse of trusted administrative capability, not proof of an unauthenticated product vulnerability.

Needs: A reachable scripting feature and the actual script-execution permission; host execution inherits the service identity.

Evidence: A marker and identity returned by server-side script execution.

Fix: Limit scripting roles and run the application with only the OS privileges it requires.

Report example: Red Block pp. 57-59, 169-174. Tool commands.

Legacy SonarQube plugin loading

The supplied report turns a SonarQube administrator login into host execution by loading a custom plugin through an old upload API and restarting the service. A plugin runs inside the application process. SYSTEM in that report comes from the particular Windows service account, not a universal plugin property.

Needs: Application administrator rights, the affected legacy upload workflow, a compatible plugin and an allowed restart.

Evidence: A loaded plugin producing a marker with verified identity; upload success alone is not execution.

Fix: Remove legacy upload exposure, restrict administrator accounts and reduce the service privileges.

Report example: Red Block pp. 178-181. Tool commands.

Active Directory permissions and Kerberos

AS-REP roasting | Kerberoasting and targeted SPN abuse | Group membership, AddSelf and inherited access | WriteOwner, WriteDACL and object control | ForceChangePassword and account takeover | gMSA managed-password read abuse | Shadow credentials | Constrained delegation and S4U abuse | Resource-based constrained delegation | DCSync replication-right abuse | LAPS password-read delegation | AD Recycle Bin restoration and stale permissions | Writable logon scripts and scriptPath abuse | RODC ticket forgery and Kerberos Key List abuse

AS-REP roasting

Kerberos normally requires pre-authentication before issuing an AS response. If it is disabled for an account, the KDC can return an encrypted response to a caller who only knows the username. Part of that response is protected by a key derived from the account’s password, so weak candidates can be tested offline.

Needs: A valid account with pre-authentication disabled and reachable Kerberos service. A username and an open port alone are insufficient.

Evidence: An AS-REP verifier is returned; cracking and a subsequent login are separate evidence stages.

Fix: Enable Kerberos pre-authentication and use strong unique account secrets.

Documented example: Sauna, Forest. Tool commands.

Kerberoasting and targeted SPN abuse

A domain identity can request a service ticket for an SPN. The service-facing part of the ticket is encrypted using the service account’s key, allowing offline guesses against a weak account password. Targeted Kerberoasting first uses a writable SPN attribute to make a chosen account ticket-requestable, as TombWatcher did.

Needs: A usable requesting identity, an SPN on the target account and a weak recoverable secret. Targeted roasting additionally requires the SPN write right and restoration of the original value.

Evidence: A ticket for the intended SPN/account; a controlled login confirms any recovered password.

Fix: Use managed/high-entropy service secrets, restrict SPN writes and monitor unusual ticket-request patterns.

Documented example: TombWatcher, Fluffy, Zephyr (DAEMONSEC-VAULT), Red Block pp. 93-96, 147-148. Tool commands.

Group membership, AddSelf and inherited access

An attacker changes a group’s membership or uses a permitted self-membership operation to inherit that group’s rights. Nested memberships can carry those rights through several groups. The power comes from the group’s real permissions over downstream objects, not its name.

Needs: An effective membership-write/AddSelf right and a group that grants useful access. Protected groups and explicit denies can alter the path.

Evidence: Membership is present and the claimed downstream operation is now allowed.

Fix: Minimise delegated membership writes, review nested groups and monitor unexpected additions.

Documented example: Forest, Fluffy, TombWatcher, Certified (DAEMONSEC-VAULT), Garfield (DAEMONSEC-VAULT).

WriteOwner, WriteDACL and object control

WriteOwner changes who owns an AD object; WriteDACL changes its access list. Ownership commonly permits rewriting the DACL, unless owner-specific restrictions apply. The chain is to take ownership, grant the necessary right, then perform the allowed operation. GenericAll is broad object control; GenericWrite does not mean every right on every attribute.

Needs: Effective ACL rights on the exact object, including inheritance, protected-object rules and any OWNER RIGHTS restrictions.

Evidence: The saved original ACL/owner and a successful specific operation after the change. BloodHound edges are leads to validate.

Fix: Remove unnecessary object-control delegation, monitor ACL changes and restore the original owner/DACL after a test.

Documented example: Forest, EscapeTwo, TombWatcher, Certified (DAEMONSEC-VAULT), Administrator (DAEMONSEC-VAULT).

ForceChangePassword and account takeover

An account with the password-reset extended right can set another account’s password without knowing the old one. The attacker then authenticates as that target. This is different from a normal password change, which generally requires the current password.

Needs: The effective reset right over a specific target. Resets can disrupt services and make some user-protected data inaccessible.

Evidence: A login as the target after the reset. Record impact and the recovery plan rather than implying old credentials can always be restored.

Fix: Restrict reset delegation and monitor sensitive-account resets.

Documented example: TombWatcher, Administrator (DAEMONSEC-VAULT), Garfield (DAEMONSEC-VAULT).

gMSA managed-password read abuse

A group Managed Service Account has a directory-managed password. Authorised principals can retrieve the managed-password data so services can use it. An attacker who joins that reader set or inherits its read rights can recover usable authentication material for the gMSA. The password is strong; this bypasses guessing by using legitimate retrieval.

Needs: An effective managed-password retrieval right and a gMSA with useful permissions.

Evidence: Retrieval succeeds and a controlled operation authenticates as the gMSA. A service account may not be allowed interactive WinRM.

Fix: Tightly restrict managed-password readers and reduce the gMSA’s downstream privileges.

Documented example: TombWatcher. Tool commands.

Shadow credentials

An attacker adds a public-key credential to a target’s msDS-KeyCredentialLink attribute, while retaining its private key. In a compatible AD environment that key supports PKINIT authentication as the target. This is key-trust abuse, not a password reset and not a certificate issued by a vulnerable template.

Needs: Write access to the attribute and compatible key-trust/PKINIT infrastructure. CA enrolment permission is not the same prerequisite.

Evidence: Authentication as the intended target; save the original attribute and remove only the injected credential afterwards.

Fix: Restrict attribute writes and monitor key-credential additions to service and privileged accounts.

Documented example: Fluffy, EscapeTwo, Certified (DAEMONSEC-VAULT). Tool commands.

Constrained delegation and S4U abuse

Constrained delegation lets a trusted service obtain tickets for a user to specific backend services. If an attacker controls the service identity and its delegation configuration permits the required flow, S4U requests can turn that control into an impersonated backend ticket. Zephyr used a constrained-delegation path before DCSync.

Needs: Control of the delegating service, the configured backend SPNs and an allowed S4U/delegation path. Protected users, delegation restrictions and service identity matter.

Evidence: The backend accepts the ticket as the intended identity. A minted ticket is not automatically a successful remote session.

Fix: Reduce delegation scope, protect privileged accounts from delegation and secure the service credentials.

Documented example: Zephyr (DAEMONSEC-VAULT).

Resource-based constrained delegation

RBCD moves the delegation allowlist onto the backend computer object. If an attacker can edit that attribute, they can authorise a controlled service/computer to act for users to that backend. Support used a controlled computer account and tickets for the domain-controller service.

Needs: Control of an eligible service identity and write access to the backend’s delegation attribute. Creating a computer via MachineAccountQuota is one route, not the vulnerability or a universal entitlement.

Evidence: The target service accepts the impersonated ticket; preserve and restore the original delegation attribute.

Fix: Restrict computer-object writes, audit delegation attributes and control computer creation and service keys.

Documented example: Support, Garfield (DAEMONSEC-VAULT).

DCSync replication-right abuse

Domain controllers replicate directory secrets using the directory replication protocol. A principal with the necessary replication rights can request that data without running code on the DC. DCSync uses authorised replication access; it is different from copying SAM or reading LSASS memory.

Needs: Effective replication rights over the domain naming context and access to the replication endpoint. Rights depend on the requested data; ordinary LDAP read access is insufficient.

Evidence: A controlled target account’s replication response, with sensitive data redacted.

Fix: Limit replication rights to expected DCs/services, monitor replication from other hosts and investigate domain ACL changes.

Documented example: Sauna, Forest, Zephyr (DAEMONSEC-VAULT), Red Block pp. 141-143.

LAPS password-read delegation

LAPS rotates local administrator passwords and stores the recovery material in AD under controlled access. Reading it as a deliberately authorised recovery operator is expected behaviour; an overly broad reader group turns a low-privilege compromise into local administrator access. Timelapse used that relationship.

Needs: The specific read/decrypt permissions for the deployed LAPS version and a target storing a password. Encrypted Windows LAPS data can require separate decryption authorisation.

Evidence: The intended local account authenticates on the target computer; record the retrieval right and password age without publishing the secret.

Fix: Restrict and audit LAPS read/decrypt delegation and rotate a password after approved use.

Documented example: Timelapse (DAEMONSEC-VAULT).

AD Recycle Bin restoration and stale permissions

A deleted account can still be referenced by its SID in an ACL. Restoring the matching object can bring that identity and its stale privileges back into use. TombWatcher’s restored certificate administrator had enrolment rights needed for the next attack. Restoration is the bridge, rather than the certificate flaw itself.

Needs: A recoverable deleted object, effective restore/container rights and a useful surviving ACL reference. Display-name similarity is not enough: match the object SID.

Evidence: The restored SID matches the referenced principal and the intended operation is permitted.

Fix: Remove stale privileged ACL entries and tightly delegate restoration rights.

Documented example: TombWatcher.

Writable logon scripts and scriptPath abuse

A user’s scriptPath points Windows logon at a script. An attacker who can change that attribute and write a script at the reachable location can make code run when the user logs on. The script runs in the user’s context; it becomes an account pivot when that user holds another useful right.

Needs: Both a permitted scriptPath change and write access to a script location, plus a logon trigger. A share-level read-only label does not necessarily describe all file ACLs.

Evidence: A controlled marker or delegated operation tied to the logon, with both the script and attribute changes recorded.

Fix: Restrict logon-script/attribute writes, audit SYSVOL ACLs and restore the original path/file after testing.

Documented example: Garfield (DAEMONSEC-VAULT).

RODC ticket forgery and Kerberos Key List abuse

An RODC uses its own krbtgt key and a password-replication policy controlling which users’ secrets it may cache. Compromising that RODC key can permit RODC-scoped ticket forgery. An eligible Key List request can then expose a target’s key material. Garfield’s note also changes the allow/deny policy; that policy is central to the result.

Needs: The RODC-specific key/identifier, appropriate ticket state and a target permitted by the effective password-replication policy. This is not automatically an unrestricted writable-DC Golden Ticket.

Evidence: A Key List response for the permitted test identity; Garfield records that response but a later ticket-conversion route failed.

Fix: Protect RODC keys, enforce explicit Tier Zero exclusions and review policy writes; rotate compromised RODC secrets.

Documented example: Garfield (DAEMONSEC-VAULT).

Certificate attacks

AD CS ESC1: requester-chosen authentication identity | AD CS ESC4: template control becomes ESC1 | AD CS ESC9: missing template SID extension | AD CS ESC15: application-policy injection | AD CS ESC16: CA-wide missing SID extension

AD CS ESC1: requester-chosen authentication identity

A certificate template lets the enrollee supply an identity while permitting authentication use. If the requester can enrol and no effective approval/signature gate blocks issuance, the CA may issue a certificate for a privileged identity. The certificate must then satisfy the DC’s actual mapping rules.

Needs: All required template permissions/settings and a mapping path accepting the requested identity. Modern SID binding must be evaluated; a UPN printed in a certificate is not sufficient proof.

Evidence: Authentication proves the intended account, rather than just successful issuance.

Fix: Remove unnecessary subject supply, restrict enrolment and enforce strong certificate identity mapping.

Documented example: EscapeTwo. Tool commands.

AD CS ESC4: template control becomes ESC1

ESC4 is write control over a certificate template. Rather than finding an already unsafe template, the attacker modifies one to permit a dangerous request, for example an ESC1 condition. Restoring the template does not revoke certificates already issued during the change.

Needs: Effective template-control rights, publication by a reachable CA, enrolment access and a viable downstream authentication configuration.

Evidence: A saved original template, the issued certificate properties and successful target-identity authentication.

Fix: Restrict template ownership/ACLs, monitor changes and revoke certificates issued through malicious changes.

Documented example: EscapeTwo. Tool commands.

AD CS ESC9: missing template SID extension

A template’s NoSecurityExtension setting can omit the SID security extension. In the historical weak-mapping environment used in Certified, a controlled account’s UPN was temporarily changed before enrolment, causing the resulting certificate to map to another identity. Missing SID data alone does not make this work on fully enforced mapping.

Needs: The template-level omission, enrolment rights, account-name control and a compatible mapping weakness or additional chain.

Evidence: Authentication as the intended principal. A NoSecurityExtension flag is a configuration finding until the whole path is proven.

Fix: Include the security extension, restrict name writes and use enforced strong mapping.

Documented example: Certified (DAEMONSEC-VAULT). Tool commands.

AD CS ESC15: application-policy injection

On affected unpatched CAs, a schema-v1 template can accept requester-supplied application policies, giving a certificate capabilities the template did not intend. TombWatcher used that capability in an enrolment-agent/on-behalf-of chain. It is different from merely requesting a new subject name.

Needs: An affected CA, a version-1 template you can enrol in, and a usable policy/second-template chain. A V1 WebServer template on a patched CA is not automatically vulnerable.

Evidence: The issued policy and the second enrolment/authentication result establish the full chain.

Fix: Apply the CA security fix, replace legacy template usage where appropriate and restrict enrolment-agent policy.

Documented example: TombWatcher. Tool commands.

AD CS ESC16: CA-wide missing SID extension

ESC16 concerns a CA-wide setting suppressing the SID security extension, whereas ESC9 is template-specific. Fluffy combined this with control of an enrollee’s UPN and the lab’s weak identity mapping. Suppressing the extension does not by itself defeat a fully enforced modern mapping policy.

Needs: CA-wide omission, an eligible authentication template, enrolment and account-control rights, plus a viable mapping weakness or additional chain.

Evidence: Certificate authentication as the intended target, with the original UPN restored.

Fix: Re-enable SID extension issuance and enforce strong mapping; audit certificates issued while it was suppressed.

Documented example: Fluffy. Tool commands.

Linux privilege escalation

Sudo access to a scriptable tool | Sudo pager shell escape | SUID helper and PATH hijacking | Vulnerable SUID helper: Enlightenment | Linux capability abuse | Container bind-mount ownership and SUID abuse | Polkit authorisation race | OverlayFS/FUSE copy-up privilege flaw

Sudo access to a scriptable tool

Sudo authorises a program, but that program may itself be able to execute arbitrary code. Giving an account root access to a script interpreter or a tool with a scripting engine effectively gives that code root privileges. Zephyr’s allowed Nmap scripting route is one example.

Needs: A sudo rule permitting the relevant program/arguments and a usable script-execution feature. A restricted rule can block the needed arguments.

Evidence: A harmless identity check in the tool’s actual subprocess shows UID 0.

Fix: Restrict sudo to narrow operations and arguments; avoid delegating general-purpose interpreters or scriptable tools as root.

Documented example: Zephyr (DAEMONSEC-VAULT).

Sudo pager shell escape

A privileged program launches an interactive pager such as less to display output. If it keeps root privileges and the pager permits shell commands, a display feature becomes a root execution path. Your examples were systemctl status in Sau and apport-cli in Devvortex.

Needs: A qualifying sudo rule, an interactive pager invocation and absent effective secure-pager restrictions. Merely installing less is not a vulnerability.

Evidence: A benign identity result from the pager’s subprocess. Version, TTY and secure-pager mode can change the behaviour.

Fix: Patch the affected application, enforce secure/non-interactive output and narrow sudo rules.

Documented example: Sau (DAEMONSEC-VAULT), Devvortex (DAEMONSEC-VAULT).

SUID helper and PATH hijacking

A SUID-root executable starts with an effective root identity. If it invokes a helper by a relative name and searches a caller-controlled PATH without dropping privilege, the attacker can replace the helper that it runs. Pandora’s summary records this route, but the detailed final steps are unfinished.

Needs: A SUID program that preserves privilege and searches a writable/prepended path for the needed command. A SUID bit by itself does not make every program exploitable.

Evidence: A controlled helper marker and effective UID demonstrate the path. Pandora is labelled as an unfinished source.

Fix: Use absolute helper paths, sanitise the environment, drop privileges and remove unnecessary SUID bits.

Partial note: Pandora (DAEMONSEC-VAULT).

Vulnerable SUID helper: Enlightenment

Even when the caller cannot replace a helper, a privileged helper may parse its own arguments unsafely. BoardLight’s Enlightenment helper flaw allowed caller-controlled path/input to reach unintended command execution with effective root privileges. This is a specific implementation bug, not proof that every SUID application is vulnerable.

Needs: The affected installed helper, its SUID privilege and the vulnerable input-handling path.

Evidence: A benign root-identity marker through the affected helper.

Fix: Install the fixed package and remove unnecessary SUID privilege from vulnerable helpers.

Documented example: BoardLight (DAEMONSEC-VAULT).

Linux capability abuse

Capabilities split root’s privileges into individual powers. A general-purpose interpreter with CAP_SETUID can change its process identity if that capability is effective. Cap’s Python binary held that power, letting an ordinary user move to UID 0 without a SUID Python binary.

Needs: An executable available to the user with the required effective capability and runtime support. CAP_NET_BIND_SERVICE alone does not allow changing UID.

Evidence: The interpreter’s process reports effective UID 0 after the controlled identity change.

Fix: Remove unnecessary file capabilities, particularly identity-changing powers from general-purpose interpreters.

Documented example: Cap (DAEMONSEC-VAULT).

Container bind-mount ownership and SUID abuse

A writable bind mount exposes the same host files inside a container. Without the necessary isolation, container root can alter ownership and modes on those host files. GoodGames used that shared path to create a root-owned SUID executable which was then run from a host session.

Needs: Writable shared storage, sufficient capability/UID mapping in the container, and host execution on a filesystem permitting SUID. Container UID 0 is not universally host root.

Evidence: The host observes the permission change and a controlled host execution proves privilege. A root container prompt alone does not.

Fix: Use user namespaces, restrict bind mounts/capabilities and avoid exposing writable host paths or SUID-enabled execution.

Documented example: GoodGames (DAEMONSEC-VAULT).

Polkit authorisation race

CVE-2021-3560 was an authorisation flaw in polkit’s handling of a disappearing D-Bus caller. In the affected path, disconnecting at the right point could make a credential-lookup error be treated as a privileged caller. Papers’ notes use this local route. It is a polkit flaw, despite the note’s synopsis calling it a sudo issue.

Needs: An affected polkit version/path, local access and the race conditions needed by the test.

Evidence: A controlled privileged account operation demonstrates the authorisation failure.

Fix: Update polkit and review/remove test accounts and privileges introduced during validation.

Documented example: Papers (DAEMONSEC-VAULT).

OverlayFS/FUSE copy-up privilege flaw

CVE-2023-0386 concerns OverlayFS copy-up handling of file ownership across user namespaces. An affected kernel can copy attacker-controlled metadata into a host-visible file with unintended privilege. TwoMillion used this kernel path after obtaining a normal local account.

Needs: An affected kernel and the user-namespace/FUSE/OverlayFS conditions required by the exploit. Distribution backports matter more than a broad version banner.

Evidence: A benign privilege result on the affected kernel, with patch state and prerequisites recorded.

Fix: Install the vendor kernel fix and reduce unnecessary unprivileged namespace exposure.

Documented example: TwoMillion (DAEMONSEC-VAULT).

Windows privilege escalation

Upload redirection through a directory junction | FullPowers service-token restoration | Token impersonation and Potato attacks | SeBackupPrivilege and offline credential-hive extraction | DnsAdmins server-plugin loading | Service configuration and Server Operators abuse | SeTcbPrivilege and disabled token privileges | Privileged GUI file-dialog escape

Upload redirection through a directory junction

A directory junction redirects filesystem operations to another directory. Media let a user pre-create an upload destination as a junction; the higher-privilege upload handler trusted it and wrote into the web root. This crossed a write boundary and created a code-execution route under Apache’s account.

Needs: Write/control over the destination directory, a handler following the reparse point and write permission at the destination for that handler’s identity.

Evidence: The file lands at the redirected path and a harmless execution marker identifies the resulting service account.

Fix: Use protected upload directories outside executable roots and securely reject/revalidate reparse points during writes.

Documented example: Media.

FullPowers service-token restoration

A Windows process token may have privileges removed even though the account normally receives them. FullPowers uses a compatible service/task context to obtain a fresh token for the same account with its default privileges. In Media this restored SeImpersonatePrivilege, enabling a later attack; FullPowers was not itself the SYSTEM step.

Needs: A compatible service identity and task/service configuration permitting the fresh-token route. It cannot generally manufacture rights the account is not entitled to receive.

Evidence: The new token lists the required privilege. Verify account identity separately from token privileges.

Fix: Avoid relying only on a stripped process token when the account can recover its default rights; minimise the service identity’s entitlement.

Documented example: Media.

Token impersonation and Potato attacks

Service accounts can hold impersonation privileges so servers may act for connecting clients. A suitable Potato exploit induces a privileged Windows component to authenticate to an attacker-controlled endpoint and abuses the resulting impersonation context to launch an elevated process. The particular protocol path depends on the tool and Windows build.

Needs: The required effective privilege, a compatible Windows component/build and the tool’s trigger conditions. A disabled/absent privilege or a mismatched build can stop the route.

Evidence: An identity check shows SYSTEM. Jeeves records original JuicyPotato success and newer-tool failures; Media records GodPotato after FullPowers.

Fix: Patch affected components and minimise service impersonation rights and endpoint exposure.

Documented example: Jeeves, Media. Tool commands.

SeBackupPrivilege and offline credential-hive extraction

Backup privilege can permit protected file reads through backup-aware operations, even when normal file ACLs deny access. Cicada’s note saves SAM and SYSTEM data and processes them offline. SAM holds local account verifiers; SYSTEM supplies material needed to decrypt them. Domain-controller NTDS extraction is a different dataset and requires its own evidence.

Needs: Effective backup/read capability, an operation that uses it and the required matching hive/database material.

Evidence: The extracted local account identity and a controlled authentication result. Do not relabel a SAM dump as DCSync.

Fix: Restrict backup operator privileges, protect backups and use local credential isolation/rotation appropriate to the host.

Documented example: Cicada (DAEMONSEC-VAULT).

DnsAdmins server-plugin loading

An eligible DNS administrator can configure a server-level plugin DLL. If the Windows DNS service subsequently loads that controlled DLL under its privileged service identity, directory/DNS administration becomes local execution as the service. Resolute’s narrative records that route.

Needs: Rights to configure the plugin, a DLL path readable by the DNS service and a valid service-load/restart trigger. Group membership alone does not prove all three.

Evidence: A controlled marker under the DNS service identity, and a saved original plugin setting.

Fix: Restrict DNS service configuration and restart rights, patch and audit server-level plugin changes.

Documented example: Resolute (DAEMONSEC-VAULT).

Service configuration and Server Operators abuse

A Windows service can run as a privileged account. An operator who can replace its executable command or writable binary, and trigger a start, can make it run tester-controlled code in that account. Return’s command notes use a service-control path after obtaining the printer’s service credential.

Needs: Effective change-configuration or binary-write rights and a service trigger. Read access to service metadata is not sufficient.

Evidence: A benign marker from the service context, with the original configuration captured and restored.

Fix: Restrict service ACLs and operator memberships, protect executable paths and monitor configuration changes.

Documented example: Return (DAEMONSEC-VAULT), Red Block p. 155.

SeTcbPrivilege and disabled token privileges

Disabled privileges can sometimes be enabled if they are already in a process token. This differs from acquiring a privilege that is absent. The report first enables present privileges, then uses a separate SeTcbPrivilege-specific helper to launch a privileged process.

Needs: SeTcbPrivilege present in the relevant token, a compatible helper/OS and access to the required system operations.

Evidence: Identity output from the newly launched process. An Enabled flag alone is not SYSTEM proof.

Fix: Restrict SeTcbPrivilege to the trusted operating-system components that need it.

Report example: Red Block pp. 59-62. Tool commands.

Privileged GUI file-dialog escape

A privileged desktop application may open a file dialog that can launch an unintended executable. The child can inherit the elevated application context. The report describes Remote Mouse GUI 3.008 and CVE-2021-35448; that is a specific affected application path, not a universal property of every file picker.

Needs: Interactive desktop access and the affected application actually running with elevated privileges.

Evidence: Process identity and token integrity demonstrating the boundary crossing.

Fix: Patch the affected application and avoid exposing privileged interactive interfaces to ordinary users.

Report example: Red Block pp. 68-73. Tool commands.

Movement, sessions and boundaries

Pass-the-hash | Kerberos ticket use and pass-the-ticket | Certificate and private-key authentication | SAM, LSA and LSASS credential access | SSH forwarding, SOCKS and routed pivots | SSH authorised-key modification | HTTP header trust and firewall-management abuse | NTFS Alternate Data Streams

Pass-the-hash

NTLM authentication proves knowledge of key material derived from the NT hash; the plaintext password is not needed to compute a valid response. A tool holding the NT hash can perform that calculation. This is not sending a captured NetNTLMv2 response unchanged, and it still requires a service accepting NTLM plus account authorisation.

Needs: The correct account’s NT hash, a compatible NTLM endpoint and the permissions needed for the operation. Local accounts can face remote restrictions.

Evidence: A controlled session identifies the correct account and allowed operation.

Fix: Reduce NTLM use, protect credential material and apply unique managed local passwords and least privilege.

Documented example: Sauna, Jeeves, EscapeTwo, Fluffy, TombWatcher, Cicada (DAEMONSEC-VAULT), Zephyr (DAEMONSEC-VAULT), Garfield (DAEMONSEC-VAULT). Tool commands.

Kerberos ticket use and pass-the-ticket

A Kerberos ticket proves an identity to the service for which it was issued. A caller controlling a valid ticket and its session key can use that authentication state without the user’s password. A TGT is used to obtain service tickets; a service ticket applies to a particular service, subject to validity and policy.

Needs: Valid ticket/key material, correct service principal/name, network reachability and acceptable clock/validity. Ticket conversion changes storage format, not privilege.

Evidence: The actual target service accepts the ticket as the intended account.

Fix: Protect ticket caches/session keys, minimise privileged logons and investigate credential theft or delegation paths.

Documented example: Forest, Support, Zephyr (DAEMONSEC-VAULT), Garfield (DAEMONSEC-VAULT).

Certificate and private-key authentication

A certificate binds a public key to an identity, and authentication requires proving possession of its private key. A stolen PFX can therefore be a credential even when the account password is unknown. Timelapse used recovered certificate/key files with WinRM TLS authentication; AD CS paths used Kerberos PKINIT, which is a different protocol flow.

Needs: The matching private key, a certificate valid for the authentication route and a server mapping that identity to an allowed account. A public certificate alone is insufficient.

Evidence: A successful session as the expected account using the documented authentication method.

Fix: Protect/export-restrict private keys, revoke compromised certificates and apply strong identity mappings.

Documented example: Timelapse (DAEMONSEC-VAULT), EscapeTwo, Fluffy, Certified (DAEMONSEC-VAULT), TombWatcher. Tool commands.

SAM, LSA and LSASS credential access

A privileged process can sometimes retrieve local password verifiers, service secrets or credential material from protected stores or authentication memory. Zephyr used secretsdump and Mimikatz/Kiwi routes after obtaining elevated access. These stores are different: SAM is local accounts, LSA secrets can contain service material, and LSASS holds authentication state.

Needs: The actual required privilege and readable/unprotected store. Credential Guard, protected processes and endpoint controls can prevent a particular memory route.

Evidence: A redacted result tied to its source store and a controlled validation. A tool error is not a successful dump.

Fix: Minimise privileged sessions, protect credential stores and apply isolation, endpoint protection and secret rotation.

Documented example: Zephyr (DAEMONSEC-VAULT), CMP210, Cicada (DAEMONSEC-VAULT).

SSH forwarding, SOCKS and routed pivots

A pivot sends traffic through a host with network reach that the testing machine lacks. SSH local forwarding maps one local port to a remote destination; SOCKS proxies compatible connections; Ligolo builds a routed path. The tunnel grants reachability, not credentials or authorisation to the destination.

Needs: An accessible controlled pivot, a route from it to the destination and correctly configured return traffic/name resolution.

Evidence: A known service is reachable through the intended path; then independently verify authentication. Track each hop in a double pivot.

Fix: Segment management traffic, limit egress and enforce strong destination authentication despite internal reachability.

Documented example: CMP314, Pandora (DAEMONSEC-VAULT), GoodGames (DAEMONSEC-VAULT), Zephyr (DAEMONSEC-VAULT), Garfield (DAEMONSEC-VAULT). Tool commands.

SSH authorised-key modification

Adding a public key to an account’s authorised keys lets the matching private key authenticate if the SSH server permits that account/key. This is legitimate credential installation with the wrong writer. It can be a foothold, as in Postman, or an access-maintenance step, as in CMP314.

Needs: Write access to the effective authorised-key location and a server accepting that account/key. Filesystem modes, account restrictions and network reachability still matter.

Evidence: A successful controlled key login. Remove only the injected key and preserve pre-existing entries.

Fix: Restrict writes to authentication files, audit key changes and constrain key options and account access.

Documented example: Postman, CMP314.

HTTP header trust and firewall-management abuse

Host and Referer are request metadata supplied by the client; they are not proof that a caller is trusted. CMP314 reached a firewall GUI through a pivot, rewrote its expected headers, authenticated with default credentials and changed rules. Reaching the GUI, passing a header check and changing policy were separate stages.

Needs: Network reach to the management interface, the vulnerable header check, valid management access and permission to change rules.

Evidence: The authorised test session changes a recorded rule and the intended route becomes reachable. Restore the rule afterwards.

Fix: Use real authentication/authorisation, remove defaults and isolate management interfaces; headers are only supplementary signals.

Documented example: CMP314.

NTFS Alternate Data Streams

NTFS files can have named data streams besides their ordinary contents. A plain directory listing may hide those streams, so reading only the unnamed file can miss data. Jeeves used this to locate the final proof. ADS is a storage/enumeration concept here, not a privilege-escalation exploit.

Needs: An NTFS file with an additional stream and permission to enumerate/read it.

Evidence: A named stream and its permitted content are visible. Flag values remain redacted.

Fix: Include streams in forensic/file inspection and review unexpected stream usage.

Supporting technique: Jeeves.

Worked chains

A chain connects separate weaknesses. Removing any necessary link can prevent the final outcome. These three examples show why a password, a permission and a network route should be tracked independently.

Web to root: MetaTwo

User to domain replication: Forest

Application to service identity: supplied report

Tools from the Red Block report

The supplied report’s tool order is encrypted to the Main_Key. The public ☧ mark identifies a related tool guide; its number, report pages and position appear only in the unlocked list. Guide titles and URLs use tool names.

☧ Unlock ordered tool index

Download the encrypted file, decrypt it locally with GPG, then open the resulting JSON in the panel. Repeated uses of a tool retain their separate numbers. Some historical commands occur only in screenshots; a flag or version label is not independent proof.

Read these differences before reproducing a historical command:

• The report uses the legacy PowerShell Inveigh script; the new guide documents the maintained C# build. Inspect the matching help rather than mixing flags.
• The report’s Ligolo setup is version-specific. The proxy, agent, interface and route must agree; a callback may need a pivot-side listener even when ordinary target connections work. Prefer verified certificate trust for tunnels.
• A file named .one yielding an Office verifier is not proof that every OneNote file is supported by office2john. Identify the actual container and check the installed extractor’s support.
• Readable deleted-account attributes do not demonstrate successful account restoration. The report uses a description/password clue; TombWatcher’s restored AD object is a separate documented path.
• gMSA output should be interpreted as account authentication material, often an NT hash; a convenient human-readable password is not guaranteed.
• The Anuko helper name in the report is a local rename, not an independently established upstream tool identity. Capture the authenticated Puncher request and review the parameter/affected build before using any automated helper.
• Webmin’s advisory names 1.991 and below for CVE-2022-30708. The report’s 1.996 label remains a discrepancy.
• Chisel and socat are mentioned as alternatives; the report does not establish their use in that path. Disabling protection software is not a prerequisite for explaining SharpHound collection.

Source coverage and evidence limits

The map below records which reviewed write-ups contribute each mechanism. Repeated vault copies of a published machine are treated as the same example. Placeholder templates, speculative alternatives and scan-only findings are not counted as completed exploitation. This is coverage of the reviewed documents as of 2026-10-11, rather than a claim to catalogue every possible penetration-testing attack.

CMP210’s TLS/SSH/PHP scanner findings are not represented as completed exploits. CMP314 demonstrates CGI Shellshock; CMP319’s scanner mention alone does not. Pandora and Administrator have unfinished sections, so their proposed endings are not presented as completed paths. Garfield records an RODC Key List result and a failed later ticket-conversion attempt. Pro-lab planning/checklist notes add terminology but do not establish that every suggested attack was performed.

Technical references

These references support the mechanism explanations and compatibility caveats. The prose and diagrams on this page are original; the supplied report is credited for its examples and is not redistributed.

• Kerberos protocol specification - tickets, pre-authentication and service identity.
• OWASP Web Security Testing Guide - web test categories and evidence.
• Microsoft strong certificate mapping guidance - historical versus enforced certificate identity mapping.
• Certipy privilege escalation documentation - AD CS permission and certificate paths.
• SpecterOps shadow credentials research - key-trust account takeover.
• SpecterOps RODC research - RODC-specific keys and replication policy constraints.
• Linux capabilities manual - per-process privilege capabilities.
• Zabbix’s security advisory - the session-state/SAML bypass is distinct from Golden SAML.
• GitHub Security Lab’s polkit advisory - the Papers local escalation mechanism.
• Webmin security advisories - keep different authenticated issues and version ranges separate.