0.7 Conditional attack-surface notes

Quick commands.

• Enter: you have authorized local administrative or equivalent management access to a Windows destination, and RDP access is relevant or failing.
• Discover: inspect TermService, fDenyTSConnections, configured PortNumber, qwinsta listener state and the actual source-to-port path.
• Validate: inspect NLA/security-layer policy, applied GPO, local Remote Desktop Users membership, and the effective SeRemoteInteractiveLogonRight / SeDenyRemoteInteractiveLogonRight assignments. Deny overrides allow.
• Execute: RDP host-side inspection; then use the RDP access procedure only when its conditions are satisfied.
• Verify: a usable desktop followed by whoami, hostname and ipconfig establishes the new host/identity/source position. Authentication-only success is not an interactive session.
• Outcomes: listener/right/client conditions satisfied → remote operation preflight then session verification; decisive deny/no listener → ruled out here; policy, SID expansion or filtering unresolved → inconclusive.

Quick commands.

• Enter: a specific computer object is relevant and the current directory principal may read ms-Mcs-AdmPwd.
• Discover: identify the computer object and test the attribute read; merely enumerating the object is not enough.
• Validate: the returned value is present, current and scoped to that computer's managed local account; identify the intended local username and destination service separately.
• Execute: Delegated LAPS/gMSA reads.
• Verify: validate the password on one compatible service using explicit local-account context, then prove the specific permitted operation. Password acceptance does not prove local administration or remote execution.
• Outcomes: readable current value → credential classification/remote operation preflight; attribute denied/absent for this principal/object → ruled out here; schema, replication freshness or object identity unresolved → inconclusive.

Quick commands.

• Enter: a relevant computer uses Windows LAPS and the principal may read msLAPS-Password or decrypt the protected value.
• Discover: query the exact computer attribute and record whether the result is plaintext JSON, encrypted content, empty or denied.
• Validate: plaintext/decryption rights, password age, managed account name and host scope. An encrypted blob without the permitted decryption context is not a password.
• Execute: Delegated LAPS/gMSA reads.
• Verify: validate only against the named host and intended local account, then establish the actual service capability.
• Outcomes: usable current password → credential classification/remote operation preflight; no read/decrypt right → ruled out here; returned protected data but decryption context unknown → inconclusive.

Quick commands.

• Enter: a specific gMSA is used by a relevant service and the current identity may read msDS-ManagedPassword.
• Discover: inspect the gMSA object and allowed managed-password readers; distinguish a raw blob from a decoded NT hash.
• Validate: exact account name including $, managed-password read permission, working LDAPS/tool path, decoded representation and intended service/host.
• Execute: Raw and decoded gMSA checks.
• Verify: test one service compatible with the decoded material and record the exact accepted identity and operation. Authentication is not administrative execution.
• Outcomes: decoded material accepted for the intended identity → credential classification/remote operation preflight; read denied or wrong object type → ruled out here; raw blob, TLS failure or empty output → inconclusive.

Quick commands.

• Enter: the effective principal can write the target object's msDS-KeyCredentialLink, and the assigned lab permits the object change.
• Discover: list existing key credentials before mutation and preserve their identifiers.
• Validate: target identity, exact effective write right, DC PKINIT/key-trust support, DNS/time/KDC route, certificate tooling and a cleanup route.
• Execute: Shadow credentials — add, authenticate and remove only the added DeviceID.
• Verify: establish the cached target principal and one intended service action; then confirm that only the newly added key credential was removed.
• Outcomes: target TGT/service capability established → ticket and key context/remote operation preflight; effective write or PKINIT prerequisite disproved → ruled out here; write succeeds but certificate/KDC mapping is unresolved → failed-boundary diagnosis/inconclusive.

Quick commands.

• Enter: you possess a certificate and private key plausibly mapped to an AD identity, and LDAP over TLS is reachable.
• Discover: identify certificate subject/SAN/EKU, trust chain, private-key availability and the DC TLS path.
• Validate: the certificate maps to the intended principal, the private key matches, Schannel authentication is accepted and the mapped identity has the exact object right required by the intended LDAP operation.
• Execute: PassTheCert identity check and LDAP shell.
• Verify: whoami/bind establishes only the mapped LDAP identity; separately verify the selected LDAP read or write and its object state.
• Outcomes: mapped identity and permitted object operation confirmed → directory-right validation; mapping/trust/private key disproved → ruled out here; PKINIT fails while Schannel remains untested, or TLS errors mask mapping → inconclusive.

Quick commands.

• Enter: a validated RBCD/delegation path needs a service principal or machine key you control.
• Discover: inspect machine-account quota, target OU/container ACL, existing names and whether the current identity can create the account in the intended location.
• Validate: the downstream path actually needs this principal, the resulting SPNs/key will be usable, target-object rights are independently present, and cleanup/deletion rights are understood.
• Execute: Powermad machine-account creation.
• Verify: confirm the created object, its SPNs and controlled key; do not record RBCD or target access until the separate delegation operation and service ticket succeed.
• Outcomes: controlled principal created for an already validated receiver path → conditional AD paths; quota/ACL/name condition fails → ruled out here; object exists but downstream target right is missing → retain only the machine-account capability.

Quick commands.

• Enter: the controlled principal is a direct/effective DNSAdmins member or has equivalent DNS-server configuration rights.
• Discover: identify the actual DNS server, DNS service state/identity and service ACL from the current authorized source.
• Validate: effective configuration permission, product/build behavior, a usable plugin/configuration operation, payload delivery path and a separately authorized restart trigger. A restart on a DC is disruptive and is never a discovery probe.
• Execute: DNSAdmins condition checks.
• Verify: current content supports only membership/service/trigger investigation. A complete plugin execution and cleanup procedure is not registered; see the pending action procedure.
• Outcomes: all prerequisites identified → ready for a separately reviewed procedure; membership absent/effective right denied → ruled out here; group present but configuration or trigger unknown → inconclusive.

Quick commands.

• Enter: host policy or traffic indicates the machine uses WSUS.
• Discover: read WUServer, WUStatusServer and UseWUServer; record URL, port, TLS and actual source reachability.
• Validate: authenticated access to the identified server, update-approval/content/signing/deployment rights, target group scope and the privileged client consumer. Client configuration alone supplies none of those rights.
• Execute: WSUS client authority discovery.
• Verify: this state produces a named update authority and a missing-rights checklist, not code execution. A complete update-deployment procedure is not registered; see the pending action procedure.
• Outcomes: authority plus exact server-side control established → ready for a separately reviewed procedure; server rights denied → ruled out here; registry values absent or server role unknown → inconclusive.

Quick commands.

• Enter: CcmExec, SMS_Client or readable client configuration indicates Configuration Manager.
• Discover: identify client state, assigned site, management point and reachable authenticated interfaces.
• Validate: SMS Provider/site-server authorization, deployment or CMPivot rights, relevant collection scope and any specifically readable credential source. Client presence does not imply server rights.
• Execute: SCCM client recognition checks.
• Verify: this state establishes product/site context only. A complete SCCM rights-to-action procedure is not registered; see the pending action procedure.
• Outcomes: exact management interface and relevant permission found → ready for a separately reviewed procedure; no applicable server permission → ruled out here; namespace access denied or site/role unresolved → inconclusive.

Quick commands.

• Enter: directory or native trust enumeration identifies another domain/forest relationship.
• Discover: record source and destination domain, direction, trust type/transitivity, same-forest versus cross-forest context, selective authentication and SID filtering.
• Validate: destination DNS/KDC/service reachability, accepted identity, target SPN, allowed-to-authenticate/resource rights and the exact capability sought. A trust object or child-domain administration is not automatically forest compromise.
• Execute: Trust-boundary inspection, then movement preflight.
• Verify: establish one destination service action under the named identity. Trust-key/SID-history forgery and coercion chains are not registered complete procedures; see the pending action procedure.
• Outcomes: destination service accepts the identity and action → remote operation preflight; filtering/selective-auth/resource authorization decisively denies it → ruled out here; direction/filtering/identity or route unresolved → inconclusive.

Quick commands.

• Enter: the application exposes login, registration, recovery, role change, state-changing business action, authenticated API or another session-dependent flow.
• Discover: capture a working anonymous and/or authenticated request, then record method, scheme/host/path, headers, cookies/tokens, body fields, hidden values, redirects, role and each step required to complete the action. Include non-GET/POST methods, JSON/XML bodies and WebSocket/API messages when the application actually uses them.
• Validate: replay the unchanged request first; then change one identity, object, property or session boundary at a time. Confirm freshness, CSRF/token coupling, object ownership and whether the result is server-side rather than a browser-only presentation change.
• Execute: HTTP and web mapping, then route only the demonstrated effect to the existing parameter, authorization, IDOR, mass-assignment, XSS, parser or command/SQL method.
• Verify: preserve one reproducible request/response pair and the exact role/session/object delta. Mapping a field or flow is not itself exploitation.
• Outcomes: controlled unauthorized effect → application authorization or the matching primitive; invariant authorization/ownership enforcement → ruled out for that transition; token expiry, cache, redirect or client-side behavior masks the result → inconclusive/failed-boundary diagnosis.
• Source: OWASP WSTG entry-point mapping.

Quick commands.

• Enter: service detection or an application response identifies Java RMI on a selected port.

• Discover: enumerate bound names, classes, remote endpoints and codebase annotations without assuming the registry is exploitable:

  nmap -sV -p PORT --script rmi-dumpregistry TARGET
  

• Validate: confirm the selected endpoint is the actual registry/service, its class-loading/serialization behavior, Java/version prerequisites and whether any proposed test is intrusive. The Nmap class-loader probe is categorized intrusive and must not be the baseline:

  nmap -p PORT --script rmi-vuln-classloader TARGET
  

• Execute: no generic RMI/serialization execution procedure is registered. Route a matched component/version/condition to exploit prerequisite matching only after the required behavior is established; see the pending action procedure.

• Verify: registry names or a vulnerable class-loader result are component evidence, not a session. A complete action must separately verify the executed identity and resulting capability.

• Outcomes: matching component and vulnerable behavior → candidate for reviewed exploit prerequisite matching procedure; no registry or prerequisite decisively absent → ruled out here; filtered/incomplete registry or ambiguous class loading → inconclusive.

• Sources: Nmap rmi-dumpregistry and rmi-vuln-classloader.

Quick commands.

• Enter: the application is confirmed as Apache Tomcat and a /manager/* interface responds.

• Discover: inspect the selected interface and authentication boundary without spraying credentials:

  curl -sk -D - "https://TARGET:PORT/manager/html" -o /dev/null
  curl -sk -D - "https://TARGET:PORT/manager/text/list" -o /dev/null
  

• Validate: identify the accepted account and manager role: manager-gui, manager-script, manager-jmx or manager-status. GUI access and text-script access are intentionally separate; a 401, 403 and application 404 have different meanings.

• Execute: current notes do not yet own a version-scoped deployment, verification and cleanup procedure. Preserve the authenticated management capability and see the pending action procedure. JBoss/Jenkins and other managers remain separate product branches under the pending action procedure.

• Verify: a manager listing proves the interface/role only. A deployable application, reachable context path and server-side execution identity require separate proof.

• Outcomes: accepted deployment-capable role → ready for a reviewed product procedure; role/interface denies the required operation → ruled out for that role; proxy rewriting, wrong scheme/path or ambiguous realm → inconclusive.

• Source: Apache Tomcat Manager App HOW-TO.

Quick commands.

• Enter: a working MSSQL login reveals one linked server or login mapping.
• Discover: enumerate sys.servers and sp_helplinkedsrvlogin, preserving local login, remote server, provider/data source and mapping.
• Validate: test one read-only remote identity query through the supported RPC or data-access mechanism. Do not enable RPC, create mappings or change configuration for enumeration.
• Execute: MSSQL linked-server and login-context mapping.
• Verify: record returned SYSTEM_USER, ORIGINAL_LOGIN() and the remote role result. A remote SQL query is not OS command execution.
• Outcomes: mapped remote query succeeds → re-enter database identity for that server/identity; link exists but RPC/data access is decisively unavailable → ruled out for that mechanism; mapping/authentication/provider failure is unresolved → inconclusive/failed-boundary diagnosis.

Quick commands.

• Enter: you control a Windows Server/DC context where offline credential material is relevant and the token may hold administrative or backup rights.
• Discover: inspect whoami /priv, vssadmin list shadows, then diskshadow → list shadows all.
• Validate: establish platform, exact volume, existing-versus-new snapshot, read rights, matched NTDS.dit and SYSTEM-hive requirement, output destination and cleanup authority.
• Execute: shadow-copy boundary checks. Creating/exposing/deleting a shadow and acquiring the matched files remain unavailable until the pending action procedure is complete.
• Verify: listing proves only snapshot metadata. Credential acquisition requires readable, point-in-time-compatible NTDS/SYSTEM material and successful offline parsing.
• Outcomes: suitable existing snapshot and read path identified → ready for the pending action procedure procedure; platform/rights/volume/source decisively incompatible → ruled out here; snapshot listed but access/freshness/matching hive unresolved → inconclusive.
• Source: Microsoft DiskShadow.

Quick commands.

• Enter: an explicitly authorized, live NTLM authentication source is already present and a different receiver target is relevant. A saved Net-NTLMv2 response alone does not enter this state.
• Discover: identify source protocol/event, relayed principal, receiver protocol/host and source-to-target reachability. For a selected SMB receiver, inspect signing with nmap -p 445 --script smb2-security-mode TARGET.
• Validate: receiver accepts NTLM, signing/EPA/channel binding/reflection protections permit the exchange, and the relayed principal has one useful target operation. Current exam rules prohibit poisoning/spoofing; Responder name-resolution poisoning is never the source in the exam workflow.
• Execute: the existing tool reference is not a complete action-specific procedure. Keep execution unavailable pending the pending action procedure.
• Verify: define success as the chosen receiver operation under the relayed identity, not merely an inbound connection or captured challenge-response.
• Outcomes: source + compatible receiver + useful authorization established → ready for the pending action procedure procedure; signing/protocol/authorization decisively blocks it → ruled out for that receiver; protection or source-event behavior unresolved → inconclusive.

Quick commands.

• Enter: AD-integrated DNS is present and a selected zone or record object may be writable by the current principal.

• Discover: enumerate the zone container and record objects from a domain Windows context:

  $Root = (Get-ADRootDSE).defaultNamingContext
  $DnsBase = "CN=MicrosoftDNS,DC=DomainDnsZones,$Root"
  Get-ADObject -SearchBase $DnsBase -LDAPFilter '(objectClass=dnsNode)' -Properties dnsRecord -ResultSetSize 50
  

• Validate: identify one exact dnsNode distinguished name, effective create/write-child or record-property right, zone replication scope, resolver path, intended record/value, TTL and cleanup/restore plan. Zone visibility is not write permission.

• Execute: no record-add/modify/delete procedure is registered; keep mutation unavailable under the pending action procedure.

• Verify: a future write must resolve through the intended client path and cleanup must restore only the changed record. LDAP success alone is insufficient.

• Outcomes: exact writable object/zone and resolver path established → ready for the pending action procedure; effective right denied or non-AD-integrated zone → ruled out here; object visible but ACL/replication/client resolver unresolved → inconclusive.

Quick commands.

• Enter: a computer/service account has TrustedForDelegation/unconstrained delegation and the selected host/session context is accessible.
• Discover: confirm the account/SPNs and inspect the actual selected ticket cache with klist or Rubeus.exe triage in the permitted context.
• Validate: ticket owner, realm, service/TGT type, validity, logon-session/LUID access, export/cache compatibility and the exact receiving service. A delegation flag without a cached client ticket is only configuration.
• Execute: when a relevant ticket already exists, use the ticket classification and cache procedure and movement preflight. Forced/coerced authentication remains unavailable under the pending action procedure.
• Verify: prove one named service action under the ticket principal, then preserve the host/LUID/cache scope. Do not record a password, hash or domain-wide privilege.
• Outcomes: usable cached ticket accepted by the named service → ticket and key context/remote operation preflight; no relevant ticket in the inspectable context → current cached-ticket path ruled out; inaccessible LUID, stale ticket or ambiguous principal → inconclusive.