1.2 Extract opportunities from services

Strategy map | Master Notes | Operational index | Cheatsheets

A service can disclose names, files, rights or execution. Test authentication, read, write and execution separately. A write becomes an execution path only when a useful consumer and trigger exist.

Speedrun blocks: 2; authenticated re-enumeration throughout. Documented methods: 17.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

1.2.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

1.2.1.1 Try SMB with the actual access context

Use the anonymous form first when no credentials exist; use the authenticated variant when an identity is available.

smbclient -N -L //TARGET

• If A readable share contains config, backups or keys: Read the exact file and record its source before testing any recovered value. → Classify the artifact and its identity context.
• If A working domain identity: Enumerate domain shares with that identity; share listing alone is not file access. → Read domain shares, SYSVOL and NETLOGON for useful artifacts.
• Otherwise: SMB is denied: inspect another discovered protocol, not repeated guesses against the same identity. → Identify applications and validate selected NSE checks.

1.2.1.2 Query exposed names and configuration

Use only an observed/assigned community and the correct SNMP version; preserve the returned OIDs.

snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1.1

• If Process arguments or configuration contain an account value: Classify its account scope and format. → Classify the artifact and its identity context.
• If A hostname or directory-service clue: Resolve it through the relevant name service. → Expand names through DNS records and zone transfers.
• Otherwise: No useful SNMP response: return to the confirmed service list and choose its native client. → Identify applications and validate selected NSE checks.

1.2.1.3 Inspect database identity and grants

Use this branch only for confirmed SQL Server with an accepted login. Other database clients are separate procedures.

SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@VERSION;
SELECT IS_SRVROLEMEMBER('sysadmin');

• If A permitted impersonation or command facility: Check the effective login and the exact enabled operation before attempting an OS effect. → Use SQL Server rights, impersonation and command facilities.
• If MySQL/MariaDB identified instead of SQL Server: Use the MySQL/MariaDB grants and file rules rather than SQL Server syntax. → Use MySQL/MariaDB data and file primitives.
• Otherwise: Login succeeds but the action is denied: inspect grants under the same identity. → Use SQL Server rights, impersonation and command facilities.

1.2.2 Discovery workflow

Start with application evidence from discovery; anonymous access, valid credentials and useful rights are separate questions.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

1. Use the matching protocol client and establish which identity the service accepts: Use anonymous or authenticated FTP file access; Enumerate SMB/RPC shares, files and identities; Use SSH passwords, keys and forwarding-capable access.
2. Treat file-service namespaces and exact-name retrieval as separate mechanisms: Inspect RPC/NFS exports and effective file identity; Inspect rsync modules and retrieve selected artifacts; Retrieve an evidence-backed file over TFTP.
3. Investigate names, account clues and configuration with the available service context: Expand names through DNS records and zone transfers; Extract configuration and process information through SNMP; Enumerate SMTP identities and accessible mailbox protocols; Discover LDAP naming contexts and authenticated search.
4. For databases inspect the current identity and grants before file or execution hypotheses: Use MySQL/MariaDB data and file primitives; Use SQL Server rights, impersonation and command facilities; Use PostgreSQL data and privileged program execution.
5. Retrieve relevant artifacts, classify credentials, and re-enumerate with any new accepted identity: Classify the artifact and its identity context; Validate known passwords and context-specific reuse.

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

1.2.3 Method families

• File and shell access: Use anonymous or authenticated FTP file access, Enumerate SMB/RPC shares, files and identities, Inspect RPC/NFS exports and effective file identity, Inspect rsync modules and retrieve selected artifacts, Retrieve an evidence-backed file over TFTP, Use SSH passwords, keys and forwarding-capable access.
• Identity and configuration disclosure: Expand names through DNS records and zone transfers, Extract configuration and process information through SNMP, Enumerate SMTP identities and accessible mailbox protocols, Discover LDAP naming contexts and authenticated search.
• Database privileges and primitives: Use MySQL/MariaDB data and file primitives, Use SQL Server rights, impersonation and command facilities, Use PostgreSQL data and privileged program execution, Inspect Redis access and persistence boundaries, Triage Oracle listener and database identity.
• Remote access and uncommon applications: Validate RDP, WinRM, VNC and Telnet access contexts, Investigate SIP/IRC identity and configuration clues.

1.2.4 Choose a method

1.2.5 Use anonymous or authenticated FTP file access

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.5.1 Purpose and result

Retrieved files, configuration or a verified writable location.

1.2.5.2 Recognition clues

An FTP banner or accessible listing.

1.2.5.2.1 Find the clue from your starting access

Where to investigate: After identifying FTP, test the allowed anonymous context or one known credential and inspect its directory namespace.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

curl -v ftp://TARGET/
curl -v --user 'USER:PASSWORD' ftp://TARGET/

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

230 Login successful
LIST: application.conf; backups/
RETR application.conf: 226 Transfer complete

Recognize this detail: A listing identifies candidate artifacts; a completed RETR with recognizable bytes establishes read access.

Still missing before method selection: Validate the account context, file contents, data-channel reachability and any separate write/consumer conditions.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.5.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Anonymous login allowed or a valid FTP identity; data-channel connectivity and object-specific read/write rights.

1.2.5.4 Discover and verify prerequisites

curl -v ftp://TARGET/
curl -v --user 'USER:PASSWORD' ftp://TARGET/

1.2.5.5 Why it works

FTP authentication and directory listing do not guarantee downloads or uploads. Passive/active data channels can fail independently of the control connection; uploaded bytes need a separate execution consumer.

1.2.5.6 Execute and choose variants

Recognize: FTP usually appears on TCP/21, but trust an FTP banner or protocol response on any port. Goal: determine authentication, listable/readable content and effective write locations.

1.2.5.6.1.1 Baseline: anonymous access

ftp TARGET

At the prompts, try user anonymous and an email-like password. Then:

status
pwd
ls -la
binary
get FILE
quit

If login succeeds but listing/transfer fails, use the client's passive command to toggle data-channel mode and retry once before changing credentials.

Decisive output: code 230 accepts the login; directory listings and successful RETR establish read access. Inspect downloaded backups, configuration, keys and source locally. Store target artifacts outside this public repository.

ftp TARGET

hydra -l USER -P /PATH/passwords.txt -t 1 -f -o ftp-found.txt TARGET ftp

hydra -l USER -P /PATH/passwords.txt -t 1 -f -s PORT -o ftp-found.txt TARGET ftp

curl --list-only ftp://TARGET/
curl -o FILE ftp://TARGET/path/FILE
curl --user USER ftp://TARGET/
curl --user USER -o FILE ftp://TARGET/path/FILE
curl --user USER --upload-file ./probe.txt ftp://TARGET/path/probe.txt

nmap -sV -p PORT --script ftp-anon,ftp-syst TARGET

Failure cues: 530 means that login was rejected, not that FTP has no other usable identity. A listing failure after 230 may be a data-channel/passive-mode or authorization problem. A successful upload proves write access only; it does not prove that a web server, scheduled task or privileged process consumes that file.

Next action: inspect recovered files; record exact read/write boundaries; validate any new credential once against its likely service; send a writable-consumer hypothesis to the appropriate web, execution or privilege-escalation block.

1.2.5.7 Worked example — hypothetical

Observation: anonymous login succeeds. Test: list and download one relevant readable configuration. Illustrative output: an application username is present. Interpretation: classify its credential context and test only a compatible service.

1.2.5.8 Verify the result

Retrieve recognizable bytes or independently verify an uploaded canary; distinguish listing, read and write rights.

1.2.5.9 Failure and fallback

Login succeeds but transfers hang: diagnose the data path. A writable upload directory alone does not establish command execution.

1.2.5.10 Continue from the interpreted result

1.2.6 Enumerate SMB/RPC shares, files and identities

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.6.1 Purpose and result

Domain/user clues, readable files or object-specific writable access.

1.2.6.2 Recognition clues

SMB/RPC endpoints, domain clues or new credentials.

1.2.6.2.1 Find the clue from your starting access

Where to investigate: Start from confirmed SMB and explicitly compare anonymous versus a known authenticated context, then open a relevant named share.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

smbclient -L //TARGET -N
smbclient -L //TARGET -U 'DOMAIN/USER'

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Sharename       Type
SHARE           Disk
NETLOGON        Disk

Recognize this detail: A share name supplies a filesystem investigation target; listing it does not prove read, write or service creation.

Still missing before method selection: Connect to the named share under the identity that listed it, then ls/get the exact object. Listing a share does not prove read or write. For a write candidate, verify the path operation and identify a separate execution consumer before treating it as access.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.6.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter.

1.2.6.4 Discover and verify prerequisites

smbclient -L //TARGET -N
smbclient -L //TARGET -U 'DOMAIN/USER'

1.2.6.5 Why it works

Session establishment, share enumeration, filesystem rights and remote execution are separate authorization layers. A credential change can reveal entirely new shares and files.

1.2.6.6 Execute and choose variants

Recognize: direct-hosted SMB commonly uses TCP/445; NetBIOS session service commonly uses TCP/139; MS-RPC endpoint mapping commonly uses TCP/135. They are related Windows surfaces but not interchangeable. Goal: distinguish null, guest and authenticated contexts; enumerate shares, files, users, groups, domain/workgroup clues and actual permissions.

1.2.6.6.1.1 Baseline: list shares without credentials

smbclient -N -L //TARGET

smbclient -L //TARGET -U 'DOMAIN/USER'
smbclient //TARGET/SHARE -U 'DOMAIN/USER'
smbclient -L //TARGET -U 'TARGET/USER'
smbclient -L //TARGET -U 'guest%'

pwd
ls
allinfo FILE
get FILE
mkdir probe-dir
rmdir probe-dir
exit

smbclient //TARGET/SHARE -U 'DOMAIN/USER' -c 'recurse ON;prompt OFF;mget *'

rpcclient -U '' -N TARGET
rpcclient -U 'DOMAIN/USER' TARGET

srvinfo
enumdomains
enumdomusers
enumdomgroups
queryuser RID
netshareenumall
quit

nxc smb TARGET -u USER -p PASSWORD --shares
enum4linux-ng -A TARGET

nmap -p 139,445 --script smb-protocols,smb2-security-mode,smb2-time TARGET

net view \\TARGET /all
Get-ChildItem \\TARGET\SHARE
Get-Content \\TARGET\SHARE\FILE

# Known domain account: enumerate share access without creating a probe file
smbmap -H TARGET -d DOMAIN -u USER -p 'PASSWORD' --no-write-check

# Inspect the selected share to a bounded depth
smbmap -H TARGET -d DOMAIN -u USER -p 'PASSWORD' -r 'SHARE' --depth 2 --no-write-check

# Download the specific file found above
smbmap -H TARGET -d DOMAIN -u USER -p 'PASSWORD' --download 'SHARE\PATH\FILE' --no-write-check

# No credentials: anonymous RPC/SMB candidates
enum4linux-ng -A TARGET

# Known identity: domain objects visible to this account
enum4linux-ng -A -w DOMAIN -u USER -p 'PASSWORD' TARGET

Failure cues: distinguish connection failure, authentication failure, share enumeration denial and file authorization denial. A share named IPC$ is not a general file share. Guest acceptance may look like success while returning a restricted namespace. A share marked writable still needs a consumer/trigger before it becomes an execution path.

Next action: inspect readable content, record per-share rights, validate names/domain clues, and re-run authenticated enumeration whenever identity changes. Move file-consumer hypotheses to web/execution/escalation and signing/relay hypotheses to the later credential/AD blocks.

1.2.6.6.1.2 NetBIOS names before SMB enumeration

Use when UDP/137 or SMB suggests Windows names but DNS/domain identity is unclear.

# Ask the assigned host for its NetBIOS names
nbtscan TARGET
nmblookup -A TARGET

Read: a machine name and group/domain label are leads. A workgroup label does not prove AD membership. Resolve the returned name and use the SMB/LDAP checks with the accepted identity. No reply can mean filtering or disabled NetBIOS while TCP/445 still works.

Sources: upstream 1.

1.2.6.6.1.3 SMB/RPC RID lookups when a normal user listing is denied

Use when the accepted identity can translate SIDs but cannot list the directory directly. Keep the queried host/domain and a bounded RID range explicit.

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --rid-brute 4000

Read: classify returned SID types—users, groups and machine accounts are different objects. The upper bound is coverage, not proof that higher RIDs contain nothing. A resolved name is not a password, service authorization or successful logon. Prefer the existing native directory/RPC listing when it is available; do not infer no accounts from a single denied enumeration method.

Sources: upstream 1.

1.2.6.7 Worked example — hypothetical

Observation: anonymous share listing is denied but a recovered domain credential works. Test: open one relevant share and retrieve a configuration. Illustrative output: a service account secret appears. Interpretation: record its identity and re-enter credential validation.

1.2.6.8 Verify the result

Prove the specific share/object action; a successful login or administrative indicator does not establish every remote-execution route.

1.2.6.9 Failure and fallback

Access denied after login usually means authorization/context. Test local/domain qualification and the exact object rather than repeating passwords.

1.2.6.10 Continue from the interpreted result

1.2.7 Inspect RPC/NFS exports and effective file identity

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.7.1 Purpose and result

Readable files or a controlled write with established identity semantics.

1.2.7.2 Recognition clues

RPC/NFS listeners or export information.

1.2.7.2.1 Find the clue from your starting access

Where to investigate: Follow RPC/NFS discovery with export inspection, then examine actual ownership/mapping on an allowed mount.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

rpcinfo -p TARGET
showmount -e TARGET

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

100003  3  tcp  NFS_PORT  nfs
Export list for TARGET:
/EXPORT CLIENT_SCOPE

Recognize this detail: An export lists a filesystem candidate and client policy; it does not establish file access or trusted UID 0.

Still missing before method selection: Use the owning procedure to verify NFS version, allowed client, numeric identity mapping, read/write and squash/mount policy.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.7.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable RPC/NFS transports, permitted client address and an export whose UID/GID mapping grants relevant access.

1.2.7.4 Discover and verify prerequisites

rpcinfo -p TARGET
showmount -e TARGET

1.2.7.5 Why it works

NFS authorization can depend on numeric IDs and export options. root_squash prevents remote UID 0 from automatically becoming server root; no_root_squash alone still needs a useful consumer or execution path.

1.2.7.6 Execute and choose variants

Recognize: rpcbind commonly appears on TCP/UDP 111 and NFS on TCP/UDP 2049, with additional dynamically assigned RPC ports. Goal: find exports, allowed client ranges and effective UID/GID-based permissions.

1.2.7.6.1.1 Baseline: list RPC services and exports

rpcinfo -p TARGET
showmount -e TARGET

nmap -sV -p 111,2049 --script nfs-showmount,nfs-ls,nfs-statfs TARGET

sudo mkdir -p /mnt/nfs-audit
sudo mount -t nfs -o ro,vers=3,nolock TARGET:/EXPORT /mnt/nfs-audit
find /mnt/nfs-audit -maxdepth 3 -ls
sudo umount /mnt/nfs-audit

ls -lan /mnt/nfs-audit
find /mnt/nfs-audit -maxdepth 3 -type f -readable -ls

sudo mount -t nfs -o rw,vers=3,nolock TARGET:/EXPORT /mnt/nfs-audit
touch /mnt/nfs-audit/probe-file
ls -ln /mnt/nfs-audit/probe-file
rm /mnt/nfs-audit/probe-file
sudo umount /mnt/nfs-audit

Failure cues: showmount failure does not rule out NFSv4. access denied by server can mean export client restrictions or wrong path/version. permission denied after mounting is file authorization, not network failure. Do not change local UIDs or write to an export during concept study.

Next action: inspect readable backups, home data, keys and configuration; record numeric ownership and actual write boundaries; send a writable/privileged-consumer hypothesis to the escalation block.

1.2.7.6.1.2 Rsync daemon — list modules before copying

Recognize: an rsync daemon normally listens on TCP/873, although the application can use another port. The daemon namespace uses HOST::MODULE or rsync://HOST/MODULE; a single colon is SSH/remote-shell syntax and is a different access path.

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

# One selected artifact
rsync -av rsync://TARGET/MODULE/path/FILE ./FILE

# A reviewed module into a dedicated local evidence directory
mkdir -p ./rsync-MODULE
rsync -av --safe-links rsync://TARGET/MODULE/ ./rsync-MODULE/

Failure cues: no listed modules can mean the daemon hides its module list; @ERROR: auth failed is an authentication boundary; @ERROR: Unknown module is a namespace error; a listed module can still deny individual reads or writes.

Next action: inspect selected readable backups, keys, source and configuration locally. Treat a writable module as file placement only until a specific consumer, destination identity and trigger are proven. Do not use --delete against a remote module during enumeration.

1.2.7.6.1.3 TFTP — known-name retrieval only

Recognize: TFTP normally uses UDP/69 for the initial request and has no directory-listing or login model. It is useful only when configuration, source, boot metadata or another service gives a plausible filename.

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

printf '%s\n' 'TFTP_WRITE_CANARY' > tftp-probe.txt

tftp TARGET
tftp> binary
tftp> put tftp-probe.txt
tftp> quit

Next action: inspect a retrieved artifact and follow only evidence-backed filenames. A successful upload is not execution; prove the server-side path and consumer separately.

1.2.7.7 Worked example — hypothetical

Observation: an export permits the assessment client. Test: inspect ownership and a scoped read. Illustrative output: a backup configuration is readable under a matching numeric UID. Interpretation: recover its secrets; assess writes separately.

1.2.7.8 Verify the result

Verify the export, mapped identity, actual bytes and any created file's server-side ownership.

1.2.7.9 Failure and fallback

An empty showmount response does not rule out NFSv4. Mount failure may be transport/export/client-policy rather than absence of files.

1.2.7.10 Continue from the interpreted result

1.2.8 Inspect rsync modules and retrieve selected artifacts

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.8.1 Purpose and result

A verified module namespace and selected readable configuration, backup, key or source artifact.

1.2.8.2 Recognition clues

An rsync daemon banner, TCP/873 listener or disclosed rsync module.

1.2.8.2.1 Find the clue from your starting access

Where to investigate: After application identification shows an rsync daemon, list visible modules and inspect one selected namespace before copying data.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Module: backups
Listing: app/config.yml

Recognize this detail: A visible module and file listing identify an rsync namespace; they do not establish write or execution.

Still missing before method selection: Retrieve one selected file and verify its bytes; record anonymous or supplied-account context.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.8.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable rsync daemon and a module/path readable by the anonymous or supplied account.

1.2.8.4 Discover and verify prerequisites

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

1.2.8.5 Why it works

Rsync daemon syntax uses a double colon or rsync URL. Module listing, file listing, read and write are separate permissions; a writable module is not execution without a useful consumer.

1.2.8.6 Execute and choose variants

Recognize: an rsync daemon normally listens on TCP/873, although the application can use another port. The daemon namespace uses HOST::MODULE or rsync://HOST/MODULE; a single colon is SSH/remote-shell syntax and is a different access path.

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

# One selected artifact
rsync -av rsync://TARGET/MODULE/path/FILE ./FILE

# A reviewed module into a dedicated local evidence directory
mkdir -p ./rsync-MODULE
rsync -av --safe-links rsync://TARGET/MODULE/ ./rsync-MODULE/

Failure cues: no listed modules can mean the daemon hides its module list; @ERROR: auth failed is an authentication boundary; @ERROR: Unknown module is a namespace error; a listed module can still deny individual reads or writes.

Next action: inspect selected readable backups, keys, source and configuration locally. Treat a writable module as file placement only until a specific consumer, destination identity and trigger are proven. Do not use --delete against a remote module during enumeration.

1.2.8.7 Worked example — hypothetical

Observation: the daemon lists a backup module. Test: list it and retrieve one configuration file. Illustrative output: the bytes contain an application connection string. Interpretation: classify the credential and retain the module's actual read boundary.

1.2.8.8 Verify the result

Verify the module, authentication context, path and retrieved bytes; do not infer write or execution from a visible name.

1.2.8.9 Failure and fallback

A hidden module list, authentication error and per-path denial are different boundaries. Do not mirror large trees or use remote delete during enumeration.

1.2.8.10 Continue from the interpreted result

1.2.9 Retrieve an evidence-backed file over TFTP

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.9.1 Purpose and result

Verified bytes for one known filename, or a separately justified bounded file-placement primitive.

1.2.9.2 Recognition clues

A UDP/69 service plus a plausible filename from configuration, source or boot metadata.

1.2.9.2.1 Find the clue from your starting access

Where to investigate: Use TFTP only after another artifact or boot/configuration clue supplies a plausible exact filename.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Transfer complete
Local file: recognizable configuration bytes

Recognize this detail: The exact known filename is retrievable; TFTP still exposes no general directory namespace.

Still missing before method selection: Verify recognizable bytes and provenance; distinguish read from any separately required write test.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.9.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable TFTP service and an exact server-relative filename permitted for read or write.

1.2.9.4 Discover and verify prerequisites

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

1.2.9.5 Why it works

TFTP has no directory listing or login negotiation. Initial UDP/69 contact normally switches to a transfer port, so silence does not identify the failed layer.

1.2.9.6 Execute and choose variants

Recognize: TFTP normally uses UDP/69 for the initial request and has no directory-listing or login model. It is useful only when configuration, source, boot metadata or another service gives a plausible filename.

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

printf '%s\n' 'TFTP_WRITE_CANARY' > tftp-probe.txt

tftp TARGET
tftp> binary
tftp> put tftp-probe.txt
tftp> quit

Next action: inspect a retrieved artifact and follow only evidence-backed filenames. A successful upload is not execution; prove the server-side path and consumer separately.

1.2.9.7 Worked example — hypothetical

Observation: a boot configuration reveals a TFTP filename. Test: request that exact name. Illustrative output: the retrieved bytes match the expected configuration. Interpretation: inspect its paths and credentials; do not guess a whole filesystem.

1.2.9.8 Verify the result

Verify the local file's recognizable bytes and provenance; a client success message without the expected file is insufficient.

1.2.9.9 Failure and fallback

Timeout can mean filtering, transfer-port policy or a missing/denied name. TFTP provides no general remote cleanup, so do not upload a probe without a cleanup route.

1.2.9.10 Continue from the interpreted result

1.2.10 Use SSH passwords, keys and forwarding-capable access

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.10.1 Purpose and result

An authenticated shell, subsystem or forwarding capability with verified identity.

1.2.10.2 Recognition clues

An SSH service and a known password, private key or agent context.

1.2.10.2.1 Find the clue from your starting access

Where to investigate: Find SSH in service discovery, then trace a candidate password/key back to its recorded user before a bounded authentication attempt.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

ssh -v -p PORT USER@TARGET
ssh -v -i KEY -p PORT USER@TARGET

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Authenticated to TARGET using publickey
uid=USER_ID(USER) gid=GROUP_ID(GROUP)

Recognize this detail: Accepted key authentication plus a verified shell identity establishes that specific login, not root or unrestricted forwarding.

Still missing before method selection: Check actual account/shell/subsystem and separately inspect forwarding policy if a tunnel is needed.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.10.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission.

1.2.10.4 Discover and verify prerequisites

ssh -v -p PORT USER@TARGET
ssh -v -i KEY -p PORT USER@TARGET

1.2.10.5 Why it works

SSH authentication can succeed while shell access is restricted. Key ownership, passphrase and server authorization matter independently; forwarding is a separately controlled feature.

1.2.10.6 Execute and choose variants

Recognize: SSH commonly uses TCP/22. Prerequisite for access: an accepted authentication method plus a permitted account/session context.

1.2.10.6.1.1 Baseline: validate one known identity

ssh -v -p PORT USER@TARGET

chmod 600 KEY
ssh -v -i KEY -p PORT USER@TARGET

nmap -p PORT --script ssh-auth-methods --script-args "ssh.user=USER" TARGET

ssh -o BatchMode=yes -o ConnectTimeout=5 -i KEY -p PORT USER@TARGET 'id'

Failure cues: timeout suggests route/filtering/service issues; refusal means no accepting listener in that context; host-key failure occurs before user authentication; Permission denied proves that the attempted method/context failed, not that every credential is invalid. A valid account may still have no shell or be restricted by server policy.

Next action: after a shell, verify whoami, groups, hostname and addresses, then re-enumerate locally. Password spraying and key-passphrase cracking belong to the credential-attack block, not this procedure.

1.2.10.7 Worked example — hypothetical

Observation: a disclosed private key names a local user. Test: inspect the key and authenticate to that user. Illustrative output: a shell returns with a non-root UID. Interpretation: establish Linux state and inspect allowed forwarding.

1.2.10.8 Verify the result

Run hostname and id in the resulting context; retain whether a shell, SFTP or only forwarding was actually granted.

1.2.10.9 Failure and fallback

Permission denied may be username, key, passphrase, policy or method mismatch. A successful banner exchange proves none of these.

1.2.10.10 Continue from the interpreted result

1.2.11 Expand names through DNS records and zone transfers

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.11.1 Purpose and result

Hostnames, address relationships and possibly a zone inventory.

1.2.11.2 Recognition clues

A DNS server, domain name or host aliases.

1.2.11.2.1 Find the clue from your starting access

Where to investigate: Use DNS-server evidence and discovered domain names to query authority and specific records before considering a transfer.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

dig @TARGET DOMAIN SOA
dig @TARGET DOMAIN NS
dig @TARGET DOMAIN AXFR

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

DOMAIN. SOA DC_HOST. HOSTMASTER.
HOSTNAME.DOMAIN. A TARGET
Transfer completed

Recognize this detail: An authoritative zone and returned records can expose hostnames, aliases and applications needing separate enumeration.

Still missing before method selection: Check each new name's scope/address and verify host/virtual-host behavior.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.11.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer.

1.2.11.4 Discover and verify prerequisites

dig @TARGET DOMAIN SOA
dig @TARGET DOMAIN NS
dig @TARGET DOMAIN AXFR

1.2.11.5 Why it works

A DNS answer belongs to a server and zone context. AXFR exposes zone records only when the server is authoritative and permits the transfer; names become discovery or virtual-host inputs.

1.2.11.6 Execute and choose variants

Recognize: DNS uses UDP/53 for most queries and TCP/53 for operations including conventional zone transfers and oversized responses. Prerequisite: a known or inferred domain for meaningful record and name enumeration.

1.2.11.6.1.1 Baseline: query the target DNS server directly

dig @TARGET DOMAIN SOA
dig @TARGET DOMAIN NS
dig @TARGET DOMAIN A
dig @TARGET DOMAIN MX
dig @TARGET DOMAIN TXT

dig @TARGET -x IP
dig @TARGET DOMAIN AXFR

dnsrecon -d DOMAIN -n TARGET -t std
dnsrecon -d DOMAIN -n TARGET -D WORDLIST -t brt
dnsenum --dnsserver TARGET DOMAIN

dnsrecon -r SUBNET -n TARGET

host -t mx DOMAIN TARGET
host -t txt DOMAIN TARGET

nslookup HOST.DOMAIN TARGET
nslookup -type=TXT HOST.DOMAIN TARGET
nslookup -type=MX DOMAIN TARGET

Failure cues: NXDOMAIN means that queried name does not exist in that view; NOERROR with no answer can mean the name exists but lacks that record type. Timeout can be filtering, loss or a silent/unreachable server. A recursive answer does not establish that the server is authoritative.

Next action: add new hostnames/IPs to the scoped queue, correlate naming roles with observed services, and repeat discovery/service identification for those in-scope endpoints.

1.2.11.7 Worked example — hypothetical

Observation: the authoritative server permits AXFR. Test: inspect the returned A/CNAME records. Illustrative output: a previously unknown application hostname. Interpretation: confirm scope/address reachability and request that virtual host.

1.2.11.8 Verify the result

Identify responding server, record type, answer and zone authority; transfer refusal disproves only that transfer/context.

1.2.11.9 Failure and fallback

No answer may mean wrong server, recursion policy, transport or zone. Resolve authoritative context before retrying AXFR.

1.2.11.10 Continue from the interpreted result

1.2.12 Extract configuration and process information through SNMP

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.12.1 Purpose and result

Host, interface, software or process/configuration clues from permitted OID branches.

1.2.12.2 Recognition clues

UDP/161 evidence or an exposed management plane.

1.2.12.2.1 Find the clue from your starting access

Where to investigate: Take UDP/161 evidence and a justified management credential/community, then request a small known OID branch before a broad walk.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1.1

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SNMPv2-MIB::sysDescr.0 = STRING: OS_AND_BUILD
SNMPv2-MIB::sysName.0 = STRING: HOSTNAME

Recognize this detail: A real OID response confirms the accepted read context and supplies software/name clues.

Still missing before method selection: Determine which useful views/branches are actually readable; process data and write rights are separate.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.12.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: An accepted read community or SNMPv3 identity/security level; transport and view permissions.

1.2.12.4 Discover and verify prerequisites

snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1.1

1.2.12.5 Why it works

An SNMP community acts as an access selector; views can expose only some trees. A successful system OID does not grant write access or all process data.

1.2.12.6 Execute and choose variants

Recognize: SNMP queries commonly use UDP/161. Versions 1 and 2c authenticate with a community string sent without modern transport protection; version 3 can provide user-based authentication and privacy. Goal: turn a valid read context into host, interface, route, process, software, user and listener clues.

1.2.12.6.1.1 Baseline: find a read community, then walk

onesixtyone -c COMMUNITY_FILE TARGET
snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1

Use -v1 instead when version 1 is indicated. Start with the standard system tree before a huge full walk.

Decisive output: returned OID/value pairs prove that the selected version/community can read those objects. Hostnames, interfaces, routes, users, processes and locally listening ports become new hypotheses to validate through the appropriate service or post-access path.

snmpbulkwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1

snmpwalk -v1 -c COMMUNITY TARGET 1.3.6.1.4.1.77.1.2.25
snmpwalk -v1 -c COMMUNITY TARGET 1.3.6.1.2.1.25.4.2.1.2
snmpwalk -v1 -c COMMUNITY TARGET 1.3.6.1.2.1.25.6.3.1.2
snmpwalk -v1 -c COMMUNITY TARGET 1.3.6.1.2.1.6.13.1.3

snmpwalk -v3 -l authPriv -u USER -a SHA -A AUTH_PASSWORD -x AES -X PRIV_PASSWORD TARGET 1.3.6.1.2.1

sudo nmap -sU -sV -p 161 --script snmp-info TARGET

Failure cues: UDP silence can remain open|filtered; it does not prove that the community is wrong. Timeout: No Response can be version mismatch, wrong community, filtering, loss or an unavailable OID view. No Such Object means the queried OID is absent/not exposed, not that the whole service failed. Do not use a discovered write community to change configuration during enumeration.

Next action: translate output into exact host/service/user hypotheses, scan newly disclosed in-scope addresses/listeners from the proper source position, and keep configuration-changing SNMP actions outside this stage.

1.2.12.7 Worked example — hypothetical

Observation: a system OID responds. Test: inspect the relevant interface/process branch. Illustrative output: an internal subnet and application command line. Interpretation: return the subnet to scoped discovery and classify any exposed credential.

1.2.12.8 Verify the result

Preserve the OID, accepted security context and returned value; empty branches can reflect view restrictions.

1.2.12.9 Failure and fallback

Silence can mean UDP filtering, wrong community/version or denied view; change only the condition supported by evidence.

1.2.12.10 Continue from the interpreted result

1.2.13 Enumerate SMTP identities and accessible mailbox protocols

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.13.1 Purpose and result

Validated mail capabilities, possible usernames or authenticated mailbox artifacts.

1.2.13.2 Recognition clues

SMTP capabilities or mail-related account clues.

1.2.13.2.1 Find the clue from your starting access

Where to investigate: Identify mail-related listeners, inspect greeting/capabilities and compare permitted user-discovery replies with a known-invalid control.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

nc -nv TARGET 25

Then enter the protocol dialogue:

EHLO example.invalid
VRFY USER
VRFY INVALID_CONTROL
QUIT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

220 HOSTNAME ESMTP
250-VRFY
VRFY USER -> 250 USER
VRFY INVALID_CONTROL -> 550 No such user

Recognize this detail: A reproducible reply difference can expose a possible mailbox identity.

Still missing before method selection: Check catch-all policy and account context; recipient acceptance does not prove mailbox credentials or OS access.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.13.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable SMTP/POP3/IMAP service; enumeration or mailbox access must be enabled for the selected context.

1.2.13.4 Discover and verify prerequisites

nc -nv TARGET 25

1.2.13.5 Why it works

VRFY/RCPT differences may disclose account existence but catch-all policy can invalidate inference. A valid recipient is not an authenticated mailbox or operating-system login.

1.2.13.6 Execute and choose variants

Recognize: SMTP commonly uses TCP/25, submission uses 587, and implicit TLS commonly uses 465. Goal: collect banner/capabilities, mail-domain clues and only defensible user evidence.

1.2.13.6.1.1 Baseline: banner and capabilities

nc -nv TARGET PORT

Then enter:

EHLO example.invalid
HELP
VRFY USER
EXPN postmaster
QUIT

openssl s_client -connect TARGET:587 -starttls smtp -crlf -quiet
openssl s_client -connect TARGET:465 -crlf -quiet

smtp-user-enum -M VRFY -U users.txt -t TARGET -p PORT
smtp-user-enum -M RCPT -U users.txt -t TARGET -p PORT

Test-NetConnection -ComputerName TARGET -Port PORT

Failure cues: multiline replies begin with NNN- and finish with NNN ; read the final line. 503 often means the command sequence is wrong. Uniform 252 or 550 responses make enumeration inconclusive. A visible AUTH method does not mean anonymous relay or valid credentials.

Next action: add confirmed/candidate names and domains to the private evidence ledger; test new names only in the later credential block. Do not send real mail or run relay checks unless the objective requires it.

1.2.13.6.1.2 POP3 and IMAP handoff

Mail-access services expose mailbox capabilities and, with legitimate credentials, stored messages that may contain workflow or reset links.

openssl s_client -connect TARGET:995 -crlf -quiet   # POP3S
openssl s_client -connect TARGET:993 -crlf -quiet   # IMAPS

POP3 dialogue:

CAPA
USER USER
PASS PASSWORD
STAT
LIST
QUIT

IMAP dialogue:

a1 CAPABILITY
a2 LOGIN USER PASSWORD
a3 LIST "" "*"
a4 LOGOUT

1.2.13.7 Worked example — hypothetical

Observation: two recipient probes produce different replies. Test: compare known-invalid controls and repeated responses. Illustrative output: only one candidate is consistently accepted. Interpretation: retain a possible username and check account context before authentication testing.

1.2.13.8 Verify the result

Record response/control differences and separate inferred account existence from successful mailbox authentication.

1.2.13.9 Failure and fallback

Uniform replies, disabled VRFY or a catch-all make username enumeration inconclusive; investigate other identity sources.

1.2.13.10 Continue from the interpreted result

1.2.14 Discover LDAP naming contexts and authenticated search

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.14.1 Purpose and result

A directory base DN and permitted account/group/computer attributes.

1.2.14.2 Recognition clues

LDAP/Kerberos listeners or a probable AD domain.

1.2.14.2.1 Find the clue from your starting access

Where to investigate: Identify the directory endpoint and query RootDSE before a subtree search under a known bind identity.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

ldapsearch -x -LLL -H ldap://DC_IP -s base -b '' defaultNamingContext namingContexts

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

dn:
defaultNamingContext: DC=DOMAIN,DC=TLD

Recognize this detail: RootDSE supplies the search base; it does not grant arbitrary anonymous subtree access.

Still missing before method selection: Check bind identity, transport/signing requirements and read visibility on the selected objects.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.14.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachable directory; anonymous query permission or valid bind identity; required signing/TLS and naming context.

1.2.14.4 Discover and verify prerequisites

ldapsearch -x -H ldap://DC_IP -s base -b '' namingContexts defaultNamingContext

1.2.14.5 Why it works

RootDSE can disclose naming contexts without permitting subtree enumeration. A bind identity, search base and attribute/object ACLs independently constrain results.

1.2.14.6 Execute and choose variants

Recognition: LDAP commonly appears on TCP/389 or TCP/636; Global Catalog on TCP/3268 or 3269; Kerberos on TCP/UDP 88. Applications may listen elsewhere, so follow protocol evidence rather than port labels.

1.2.14.6.1.1 Baseline: discover naming contexts

Prerequisite: LDAP reachability. Coverage: RootDSE only; this can work even when directory searches require authentication. Decisive output: defaultNamingContext and dnsHostName.

ldapsearch -x -LLL -H ldap://TARGET:389 -s base -b '' \
  defaultNamingContext rootDomainNamingContext configurationNamingContext dnsHostName

Convert DC=corp,DC=example into corp.example for DNS/Kerberos work. Preserve the server's exact hostname because Kerberos is name-sensitive.

openssl s_client -connect TARGET:636 -servername DC_HOST </dev/null
ldapsearch -x -LLL -H ldaps://DC_HOST:636 -s base -b '' defaultNamingContext dnsHostName

1.2.14.6.1.2 Check which directory objects are readable without credentials Anonymous directory search

Prerequisite: known base DN and server permitting anonymous search. Failure cue: Inappropriate authentication or Insufficient access closes only the anonymous path.

ldapsearch -x -LLL -H ldap://DC_IP:389 -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user))' \
  sAMAccountName userPrincipalName memberOf description

ldapsearch -x -LLL -H ldap://DC_IP:389 -b 'DC=DOMAIN,DC=TLD' \
  '(objectClass=group)' cn member description

1.2.14.6.1.3 Query directory objects with your accepted identity Authenticated search

Prerequisite: a valid directory identity. Decisive output: objects/attributes unavailable anonymously. Avoid placing a real password in shell history when an interactive prompt is available.

ldapsearch -x -LLL -H ldap://DC_HOST:389 \
  -D 'USER@DOMAIN.TLD' -W -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user))' \
  sAMAccountName userPrincipalName memberOf description servicePrincipalName userAccountControl

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(objectClass=computer)' \
  dNSHostName operatingSystem operatingSystemVersion servicePrincipalName

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(objectClass=group)' cn member

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(&(objectCategory=person)(servicePrincipalName=*))' \
  sAMAccountName servicePrincipalName memberOf

1.2.14.6.1.4 Kerberos prerequisites before an attack

Kerberos failures are often name/time/route failures rather than credential failures. Establish:

getent hosts DC_HOST
nc -nvz DC_IP 88
date -u
nmap -Pn -sV -p 88,389,445,464,636,3268,3269 DC_IP -oN dc-services.txt

1.2.14.6.1.5 Continue with the capability your result enables Handoff

• New users, groups, computers, SPNs or domain names → domain mapping.
• A user confirmed without preauthentication → Kerberos and identity transitions.
• Valid credentials → rerun authenticated LDAP plus SMB/share/remote-access enumeration.
• Certificate templates/AD CS clues → AD CS and object-control abuse.

1.2.14.7 Worked example — hypothetical

Observation: RootDSE returns a base DN. Test: attempt the permitted scoped search with the appropriate bind. Illustrative output: anonymous search is denied but a domain bind succeeds. Interpretation: continue authenticated domain mapping.

1.2.14.8 Verify the result

Record DC, base DN, bind identity and actual returned attributes; RootDSE alone is not a complete directory dump.

1.2.14.9 Failure and fallback

Stronger-auth-required may mean TLS/signing policy; invalid credentials or an empty base require different fixes.

1.2.14.10 Continue from the interpreted result

1.2.15 Use MySQL/MariaDB data and file primitives

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.15.1 Purpose and result

Useful data or a permission-backed server-side file operation.

1.2.15.2 Recognition clues

A MySQL-compatible service and valid application/database credentials.

1.2.15.2.1 Find the clue from your starting access

Where to investigate: Use a known application/database login and inspect identity, grants and file-operation constraints before choosing an OS transition.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

SELECT USER(),CURRENT_USER(),VERSION();
SHOW GRANTS;
SHOW VARIABLES LIKE 'secure_file_priv';

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

CURRENT_USER(): APP_USER@%
GRANT SELECT ON APP_DB.*
secure_file_priv: /RESTRICTED_DIRECTORY/

Recognize this detail: SELECT permits data investigation; absent FILE/admin rights and the restricted directory constrain file/OS hypotheses.

Still missing before method selection: Check exact grants, useful tables, destination OS permissions and an execution consumer before escalating a file operation.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.15.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions.

1.2.15.4 Discover and verify prerequisites

SELECT USER(),CURRENT_USER(),VERSION();
SHOW GRANTS;
SHOW VARIABLES LIKE 'secure_file_priv';

1.2.15.5 Why it works

Database rights and operating-system rights intersect. FILE permission alone does not guarantee a writable executable web directory or a usable destination.

1.2.15.6 Execute and choose variants

mysql -h TARGET -P PORT -u USER -p

SELECT VERSION(), USER(), CURRENT_USER();
SHOW DATABASES;
SHOW GRANTS;
USE DATABASE;
SHOW TABLES;
DESCRIBE TABLE;
SELECT * FROM TABLE LIMIT 20;
SELECT @@secure_file_priv;

SELECT LOAD_FILE('/path/on/database/server');
SELECT 'probe' INTO OUTFILE '/allowed/server/path/probe.txt';

1.2.15.7 Worked example — hypothetical

Observation: the application database login can read configuration tables. Test: inspect grants before any file operation. Illustrative output: no FILE privilege. Interpretation: use data/credential disclosure; do not assume server execution.

1.2.15.8 Verify the result

Check current database identity, grants and actual returned data or written file through an independent observation.

1.2.15.9 Failure and fallback

Permission denied or a restricted file directory changes the available primitive; pivot to data/credential use or a different entry point.

1.2.15.10 Continue from the interpreted result

1.2.16 Use SQL Server rights, impersonation and command facilities

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.16.1 Purpose and result

Database data, a more useful SQL security context or verified server command execution.

1.2.16.2 Recognition clues

SQL Server credentials or a Windows identity accepted by the database.

1.2.16.2.1 Find the clue from your starting access

Where to investigate: Once SQL Server authentication works, inspect actual login/server role and supported impersonation context.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@VERSION;
SELECT IS_SRVROLEMEMBER('sysadmin');

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SYSTEM_USER: DOMAIN\USER
ORIGINAL_LOGIN: DOMAIN\USER
IS_SRVROLEMEMBER: 0

Recognize this detail: A valid login with sysadmin=0 is data/rights evidence, not permission to enable xp_cmdshell.

Still missing before method selection: Enumerate actual database/server grants and useful impersonation; independently verify any OS facility and its identity.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.16.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Correct SQL versus Windows authentication; database role and configuration must permit the requested operation.

1.2.16.4 Discover and verify prerequisites

SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@VERSION;
SELECT IS_SRVROLEMEMBER('sysadmin');

1.2.16.5 Why it works

SQL login, sysadmin/impersonation rights and xp_cmdshell configuration are separate conditions. OS commands run under the SQL service or configured proxy context, not automatically as domain administrator.

1.2.16.6 Execute and choose variants

impacket-mssqlclient 'USER@TARGET'
impacket-mssqlclient 'DOMAIN/USER@TARGET' -windows-auth

Let the tool prompt for the password. At the SQL prompt:

SELECT @@VERSION;
SELECT SYSTEM_USER;
SELECT IS_SRVROLEMEMBER('sysadmin');
SELECT name FROM sys.databases;
USE DATABASE;
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES;
SELECT TOP 20 * FROM SCHEMA.TABLE;

EXEC xp_cmdshell 'whoami';

1.2.16.6.1.1 MSSQL linked-server and login-context mapping

Treat a linked server as another authentication and authorization boundary. The local SQL login, its mapped remote login, remote SQL role and RPC/data-access settings can all differ.

SELECT SYSTEM_USER AS current_login,
       ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS effective_login,
       IS_SRVROLEMEMBER('sysadmin') AS is_sysadmin;

SELECT name, product, provider, data_source, is_linked
FROM sys.servers
WHERE is_linked = 1;

EXEC master.dbo.sp_helplinkedsrvlogin;

After selecting one named link, test the smallest remote query supported by its configuration:

EXEC ('SELECT SYSTEM_USER AS remote_login,
              ORIGINAL_LOGIN() AS remote_original_login,
              IS_SRVROLEMEMBER(''sysadmin'') AS remote_is_sysadmin')
AT [LINKED_SERVER];

If RPC execution is disabled but data access is allowed, use a read-only pass-through query instead:

SELECT *
FROM OPENQUERY([LINKED_SERVER],
  'SELECT SYSTEM_USER AS remote_login,
          ORIGINAL_LOGIN() AS remote_original_login');

EXECUTE AS LOGIN = 'LOGIN';
SELECT SYSTEM_USER, ORIGINAL_LOGIN(), SUSER_SNAME(), IS_SRVROLEMEMBER('sysadmin');
REVERT;

Do not enable RPC, create mappings or change server configuration merely to enumerate. A remote SQL query is not OS execution; independently validate any file or command facility and the operating-system identity behind it.

Sources: Microsoft sys.servers, sp_helplinkedsrvlogin, EXECUTE AS, and OPENQUERY.

1.2.16.7 Worked example — hypothetical

Observation: Windows authentication succeeds to SQL Server. Test: inspect role and allowed impersonation. Illustrative output: only a low-privilege database user. Interpretation: enumerate permitted data and relationships before proposing xp_cmdshell.

1.2.16.8 Verify the result

Verify SQL identity and any OS effect with hostname/whoami; record service/proxy execution identity.

1.2.16.9 Failure and fallback

Login success with denied configuration changes is a rights boundary. Do not repeatedly enable an unavailable facility.

1.2.16.10 Continue from the interpreted result

1.2.17 Use PostgreSQL data and privileged program execution

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.17.1 Purpose and result

Database information or a verified privilege-backed OS effect.

1.2.17.2 Recognition clues

PostgreSQL access or an application connection string.

1.2.17.2.1 Find the clue from your starting access

Where to investigate: Authenticate to the observed database and inspect current/session identity and role attributes before program/file functions.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

SELECT current_user,session_user,version();
SELECT rolname,rolsuper FROM pg_roles WHERE rolname=current_user;

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

current_user | session_user
APP_USER     | APP_USER
rolname      | rolsuper
APP_USER     | f

Recognize this detail: An ordinary database role does not automatically have COPY PROGRAM or server-file access.

Still missing before method selection: Inspect effective role memberships and exact operation rights, then the database service's OS context.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.17.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Accepted connection/database role; COPY PROGRAM needs the corresponding server privilege and an executable OS context.

1.2.17.4 Discover and verify prerequisites

SELECT current_user,session_user,version();
SELECT rolname,rolsuper FROM pg_roles WHERE rolname=current_user;

1.2.17.5 Why it works

SQL access does not imply server superuser. File/program functions execute as the database service and are gated by database roles and OS permissions.

1.2.17.6 Execute and choose variants

psql -h TARGET -p PORT -U USER -d postgres

\conninfo
\l
\du
\dn
\dt *.*

SELECT version(), current_user, session_user;
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles;

SELECT pg_has_role(current_user, 'pg_read_server_files', 'member');
SELECT pg_has_role(current_user, 'pg_write_server_files', 'member');
SELECT pg_has_role(current_user, 'pg_execute_server_program', 'member');

Failure cues: connection refusal/timeout is network or listener context; login rejection is authentication/context; an empty database list may be visibility limits; object denial is authorization. Query only bounded rows first. Never assume that reading application credentials or obtaining database admin implies OS execution.

Next action: identify application accounts, hashes/credentials, paths and linked systems; record the precise grant enabling any file or execution primitive; validate recovered credentials in the later credential block and re-enumerate after any identity change.

1.2.17.7 Worked example — hypothetical

Observation: a database role can read application tables. Test: inspect role attributes. Illustrative output: rolsuper is false and program-execution rights are absent. Interpretation: recover useful data without treating SQL access as a shell.

1.2.17.8 Verify the result

Separate returned rows, file operations and command execution; prove the actual operating-system identity for the latter.

1.2.17.9 Failure and fallback

Role or OS permission failures require another allowed primitive, not a different spelling of the same denied operation.

1.2.17.10 Continue from the interpreted result

1.2.18 Inspect Redis access and persistence boundaries

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.18.1 Purpose and result

Useful accessible keys or a precisely bounded persistence/file-write candidate.

1.2.18.2 Recognition clues

A Redis listener or application cache credentials.

1.2.18.2.1 Find the clue from your starting access

Where to investigate: Identify Redis and use its authentication context to distinguish accepted commands from denied administrative facilities.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

redis-cli -h TARGET -p PORT PING

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

PONG
Administrative operation: NOPERM this user has no permissions

Recognize this detail: The connection is usable but command ACLs can remove persistence/configuration methods.

Still missing before method selection: Inspect allowed operations, data visibility and actual persistence/destination/consumer conditions.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.18.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Reachability and accepted authentication/ACL commands; persistence writes need CONFIG rights, destination permissions and a consumer.

1.2.18.4 Discover and verify prerequisites

redis-cli -h TARGET -p PORT PING

1.2.18.5 Why it works

Redis keys may disclose sessions or secrets. Historical file-write chains depend on command permissions, persistence format and a writable useful path; an open port alone proves none of them.

1.2.18.6 Execute and choose variants

nmap -Pn -sV --script redis-info -p PORT TARGET
redis-cli -h TARGET -p PORT PING
redis-cli -h TARGET -p PORT INFO
redis-cli -h TARGET -p PORT ACL WHOAMI
redis-cli -h TARGET -p PORT ACL LIST

Authenticated when a password is legitimately known:

redis-cli -h TARGET -p PORT --askpass

1.2.18.7 Worked example — hypothetical

Observation: PING returns PONG but CONFIG is denied. Test: inspect allowed data access. Illustrative output: only application keys are readable. Interpretation: investigate session/credential value while rejecting a presumed arbitrary-file-write chain.

1.2.18.8 Verify the result

Verify authentication context, allowed commands and actual key/file effects without assuming old Redis exploit defaults.

1.2.18.9 Failure and fallback

NOAUTH and NOPERM identify different boundaries. Investigate credentials or permitted data rather than assuming unauthenticated execution.

1.2.18.10 Continue from the interpreted result

1.2.19 Triage Oracle listener and database identity

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.19.1 Purpose and result

A confirmed listener/service context and permission-scoped database access.

1.2.19.2 Recognition clues

An Oracle TNS listener or connection descriptor.

1.2.19.2.1 Find the clue from your starting access

Where to investigate: Use service discovery and an application's connection descriptor to distinguish listener identification from a valid database session.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

nmap -Pn -sV -p 1521 TARGET

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

1521/tcp open oracle-tns Oracle TNS Listener
Application descriptor: SERVICE_NAME

Recognize this detail: Listener/product evidence and a service name establish a connection candidate, not database credentials or DBA rights.

Still missing before method selection: Validate the exact descriptor/account and inspect its permitted database action.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.19.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Correct service/SID, reachable database transport and valid database credentials for authenticated work.

1.2.19.4 Discover and verify prerequisites

nmap -Pn -sV -p 1521 TARGET

1.2.19.5 Why it works

A TNS listener is a connection broker; knowing its version or service name does not establish database authentication or DBA rights.

1.2.19.6 Execute and choose variants

nmap -Pn -sV --script oracle-tns-version -p 1521 TARGET
nmap -Pn --script oracle-sid-brute -p 1521 TARGET

1.2.19.7 Worked example — hypothetical

Observation: TNS responds on 1521. Test: identify the configured service and validate a known credential. Illustrative output: listener identification succeeds but database authentication fails. Interpretation: retain the service clue and seek the correct account/descriptor.

1.2.19.8 Verify the result

Distinguish listener identification, database login and a permitted SQL action.

1.2.19.9 Failure and fallback

An invalid service descriptor is different from an invalid password; resolve it before further credential decisions.

1.2.19.10 Continue from the interpreted result

1.2.20 Validate RDP, WinRM, VNC and Telnet access contexts

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.20.1 Purpose and result

A verified remote session or a precise authentication/authorization failure.

1.2.20.2 Recognition clues

An exposed remote-access application and compatible known credentials.

1.2.20.2.1 Find the clue from your starting access

Where to investigate: Take remote-access listeners from discovery and validate one known identity against the specific endpoint/logon type.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

Test-NetConnection TARGET -Port 3389
Test-NetConnection TARGET -Port 5985

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

RemotePort : 3389; TcpTestSucceeded : True
RemotePort : 5985; TcpTestSucceeded : False

Recognize this detail: Transport offers an RDP candidate from this source; it does not establish remote-interactive rights.

Still missing before method selection: Check actual protocol, local/domain context, accepted authentication and endpoint/logon authorization.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.20.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Enabled destination service, matching authentication and protocol-specific logon/session rights.

1.2.20.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 3389
Test-NetConnection TARGET -Port 5985

1.2.20.5 Why it works

Remote interactive logon and remote management are different rights. VNC may use its own password; Telnet may expose a different account context from Windows/domain authentication.

1.2.20.6 Execute and choose variants

Recognize: RDP commonly uses TCP/3389; WinRM commonly uses 5985/HTTP and 5986/HTTPS. Goal: determine whether one known credential is accepted in the correct local/domain context and whether it is authorized for a usable session.

1.2.20.6.1.1 RDP baseline: authentication-only check

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

Some distributions expose the binary as xfreerdp. Omit /d:DOMAIN for the intended local-account context; use /u:TARGET\\USER if needed to make that context explicit.

Decisive output: successful authentication-only validation supports that the credential is accepted for RDP/NLA. It does not prove an interactive desktop will be granted under every policy/session condition.

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

nmap -p 3389 --script rdp-enum-encryption,rdp-ntlm-info TARGET

1.2.20.6.1.2 RDP host-side inspection: local administrative context

Use this read-only sequence after obtaining an authorized local administrative session on the destination, or when the exercise explicitly supplies equivalent remote-management access. It answers four different questions: is RDP enabled, is a listener actually present, what security layer/NLA policy applies, and does the candidate identity have an effective remote-interactive logon right? Do not change registry values or policy merely to make a credential work.

1.2.20.6.1.3 Listener, service and configured port

Get-Service TermService
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
qwinsta

netstat -ano | findstr LISTENING | findstr ":3389"

1.2.20.6.1.4 NLA, transport security and policy precedence

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SecurityLayer

gpresult /scope computer /v

1.2.20.6.1.5 Candidate membership and effective logon rights

net localgroup "Remote Desktop Users"
whoami /groups

From an elevated PowerShell or Command Prompt, export the currently applied user-right assignments and inspect only the RDP entries:

$policy = Join-Path $env:TEMP 'rdp-user-rights.inf'
secedit /export /mergedpolicy /areas user_rights /cfg $policy /quiet
Select-String -Path $policy -Pattern '^SeRemoteInteractiveLogonRight','^SeDenyRemoteInteractiveLogonRight'

1.2.20.6.1.6 Source-relative validation and decision

nmap -Pn -n -p 3389 --reason TARGET
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

Security baseline: on a normally secured host, RDP may be disabled when not needed; when enabled, NLA is normally retained, access is limited to intended administrative/remote-user principals, deny assignments override broad membership, and the firewall limits exposure. The state machine records deviations and capabilities; it does not recommend weakening these controls.

1.2.20.6.1.7 WinRM baseline: interactive session

evil-winrm -i TARGET -u USER

evil-winrm -i TARGET -u 'DOMAIN\\USER'

Omitting -p makes the established Ruby client prompt for the password.

Decisive output: an interactive PowerShell prompt establishes WinRM authorization. Immediately verify identity and host context with whoami, hostname and Get-NetIPAddress.

evil-winrm -i TARGET -u USER -S -P 5986

$cred = Get-Credential
Enter-PSSession -ComputerName TARGET -Credential $cred

Failure cues: certificate warnings are different from authentication failure. RDP errors can reflect NLA, account context, expired/locked accounts or missing logon rights. WinRM 401 supports authentication/authorization failure; WinRM cannot process the request can be name resolution, trusted-host, listener or transport context. Valid SMB credentials do not guarantee RDP or WinRM rights.

Next action: after a session, re-enumerate identity, groups, privileges, files, local services/listeners and routes. Password spraying, pass-the-hash and ticket use belong to later credential/AD blocks.

Host-inspection sources: Microsoft RDP troubleshooting · Microsoft secedit /export · Microsoft account-right constants · Microsoft qwinsta · Microsoft Remote Desktop Services policy

1.2.20.6.1.8 Validate access to an exposed VNC desktop VNC

nmap -Pn -sV --script vnc-info -p PORT TARGET
vncviewer TARGET:PORT

1.2.20.6.1.9 Identify the Telnet service and validate available access Telnet

nmap -Pn -sV -p PORT TARGET
nc -nv TARGET PORT
telnet TARGET PORT

1.2.20.6.1.10 GNU Inetutils telnetd — conditional authentication-bypass check

Use only after identifying the affected GNU Inetutils telnetd/login chain and its patch status. CVE-2026-24061 concerns how a supplied USER value reaches login; it does not apply to every Telnet server. Distribution backports matter.

# Client supports sending the autologin USER environment value
USER='-f root' telnet -a TARGET PORT

Read: if a shell is obtained, verify hostname and id. A prompt or echoed username is not root access. A different daemon, fixed build, client negotiation mismatch or a rejected USER value → return to service identification. The affected upstream range and distribution fixes must be checked against the advisory rather than inferred from port 23.

Sources: upstream 1.

1.2.20.7 Worked example — hypothetical

Observation: SMB accepts a credential but RDP rejects it. Test: separate the RDP service and logon-right checks. Illustrative output: the account lacks remote-interactive authorization. Interpretation: test a justified WinRM or SMB execution path instead.

1.2.20.8 Verify the result

Verify destination hostname, represented identity and usable effect in the resulting session.

1.2.20.9 Failure and fallback

A valid password is not proof of RDP/WinRM rights. Diagnose TLS, transport, account qualification and logon policy separately.

1.2.20.10 Continue from the interpreted result

1.2.21 Investigate SIP/IRC identity and configuration clues

Blocks: 2; authenticated re-enumeration throughout. Operational procedure | Quick sheet

1.2.21.1 Purpose and result

Service capabilities, identity clues or an evidence-matched exploit candidate.

1.2.21.2 Recognition clues

A confirmed SIP or IRC application.

1.2.21.2.1 Find the clue from your starting access

Where to investigate: Classify the unusual listener, then use its normal greeting/registration behavior and the owning procedure's bounded protocol checks.

Discovery action — reference example:

Access/context: A confirmed reachable application; anonymous context or one identified credential

nmap -Pn -sV -p PORT TARGET
nc -nv TARGET PORT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

PORT/tcp open irc APPLICATION_VERSION
:HOSTNAME NOTICE AUTH :registration required

Recognize this detail: The real protocol and registration state determine the next client operation; the expected port label is insufficient.

Still missing before method selection: Verify application/version, accepted interaction and exact exploit/access conditions.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

1.2.21.3 Prerequisites

Starting access: A confirmed reachable application; anonymous context or one identified credential. Required conditions: Application-specific request format; permitted registration/channel/configuration access.

1.2.21.4 Discover and verify prerequisites

nmap -Pn -sV -p PORT TARGET

1.2.21.5 Why it works

Protocol identification and configuration may expose useful users or product versions. Do not replace application evidence with the expected service at a conventional port.

1.2.21.6 Execute and choose variants

These source-site topics contain only first-pass reconnaissance. Treat them as application-identification branches, not default exploitation paths.

1.2.21.6.1.1 Find SIP identity and configuration clues SIP

Commonly UDP/TCP 5060 or TLS 5061; follow protocol evidence.

nmap -Pn -sU -sV --script sip-methods -p 5060 TARGET
nmap -Pn -sT -sV --script sip-methods -p 5060 TARGET

1.2.21.6.1.2 Find IRC identity and configuration clues IRC

nmap -Pn -sV --script irc-info -p PORT TARGET
nc -nv TARGET PORT

Minimal registration for an authorized test client:

NICK testnick
USER testuser 0 * :Test User
QUIT

1.2.21.7 Worked example — hypothetical

Observation: a nonstandard port responds as IRC. Test: inspect its normal registration/banner behavior. Illustrative output: a named build and accessible channel information. Interpretation: record identity clues and verify any public exploit's exact prerequisites.

1.2.21.8 Verify the result

Retain protocol responses and distinguish product clues from confirmed vulnerabilities.

1.2.21.9 Failure and fallback

A generic banner or denied registration leaves access unproven; return to version/configuration matching.

1.2.21.10 Continue from the interpreted result

1.2.22 Sources and shared concepts

Supplied PEN-200 DNS pp136–142, SMB/SMTP pp156–160, SNMP pp161–164, databases pp282–285; service-specific official sources remain linked beside the operational procedures. Hexdump enumeration supplement.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.