6.3 Secrets, Permissions, and Wireless Enumeration

Objective 2.2 does not stop at hosts and names. CompTIA also wants secrets enumeration, permission enumeration, and wireless enumeration. These three techniques still belong to the inventory stage. You are identifying credentials, rights, and radio networks that exist in scope. You are not yet using a stolen key to create infrastructure, not yet abusing sudo, and not yet running a wireless attack from Domain 4. Exam stems that skip from "found an AWS key" to "paste it into a public validator" are testing professional handling as much as identification.

Secrets enumeration: keys, passwords, tokens

The official secrets list is short and worth memorizing: cloud access keys, passwords, API keys, and session tokens. Identification is pattern recognition plus authorized file and traffic review.

Cloud access keys include Amazon Web Services access key IDs that begin with AKIA (or related prefixes), Azure client secrets and storage keys, and Google Cloud service-account JSON. They hide in front-end JavaScript bundles, mobile application packages, infrastructure-as-code samples, continuous-integration logs, and forgotten .env files committed to git. Passwords hide in the same places, plus comments in HTML, backup copies of web.config or wp-config.php, database connection strings on a guest share, and the description-adjacent notes people should never have typed. API keys show up as Bearer literals, x-api-key headers in HAR files, map-platform keys, and chatbot or email-gateway tokens in client-side code. Session tokens live in cookies (sessionid, PHPSESSID, ASP.NET_SessionId), in browser localStorage or sessionStorage (id_token, access_token), and in authorization headers captured during an authorized intercept.

Where 2.2 wants you to look

On the Windows Server 2019 worked example, the guest IT-ARCHIVE share is a secrets-enum surface: old backup catalogs, exported .env files, and leftover deployment scripts. On a web application, download the JavaScript bundles the browser already loads and search them — that is still enumeration of an in-scope origin, not an exploit. On a mobile assessment that is actually in the statement of work, the application package is a zip-structured archive of resources and strings; testers look there for hardcoded keys. Git history for an in-scope repository is in play when the SoW includes it: a key that was "removed" in the latest commit may still exist in an older commit.

Handling: do not paste live secrets into public chat

A recovered secret is a live credential until the client rotates it. Store the value only in the evidence channel named in the rules of engagement. Redact it in screenshots that will travel more widely than the encrypted store. Do not paste cloud keys, session tokens, or passwords into a public chatbot, a public GitHub issue, a vendor "key checker" that is not in the RoE, or a group chat that includes people who should not have production access. The exam-ready next step is: record the location, the secret type, the identity it appears to belong to, and a recommendation to rotate and move the secret into a secrets manager. Using the key to prove blast radius may be in scope later; spraying it onto the open Internet never is.

Permission enumeration: who is allowed to do what?

Permission enumeration inventories rights, not secrets. On Linux, that means sudoers rules, group membership in sudo or wheel, setuid binaries as permission facts (you note that a binary is setuid root; you do not need a proof-of-concept to call it enumeration), and world-writable paths. On Windows, that means NTFS access control lists (ACLs) on files and folders, share-level ACLs that differ from NTFS, group membership, and user rights assignments. In cloud, that means identity and access management (IAM) policies, trust relationships, and which principal can assume which role.

Permissions are how a low-privilege identity becomes interesting. Guest-read on IT-ARCHIVE is a share ACL fact. If backup_svc is in a group that can restore onto a domain controller, that is a permission fact. If an IAM user whose key you found in JavaScript can s3:GetObject on a bucket of database snapshots, that is a permission fact. You are still mapping. Exploitation and privilege escalation are later domains.

Exam trap: calling a password in a file "permission enumeration" because the file was readable. Readability of the file is a permission fact; the password inside it is secrets enumeration. You often find both on the same path, and the report should say both.

Wireless enumeration: inventory the air, do not attack it yet

Wireless enumeration on 2.2 is a site-survey style inventory of in-scope radio networks. Record service set identifiers (SSIDs), whether a network is advertised or hidden, which clients are associated or probing, the channel or band, and the encryption type: open, legacy Wired Equivalent Privacy (WEP) if it still exists, Wi-Fi Protected Access 2 (WPA2) personal or enterprise, and WPA3. Hidden networks still leak: clients probe for them, and those probes name the SSID. Encryption type is the decision the exam wants — WPA3-Enterprise is a different later attack surface than WPA2-PSK — not a completed handshake capture.

What 2.2 is not: deauthentication floods, evil-twin access points, handshake cracking, or evil-twin captive portals. Those live with wireless attacks (objective 4.7) and only when the RoE names the SSID and the technique. Hearing an SSID from the parking lot does not put a neighbor's guest network in scope. Corporate "hidden" SSIDs are still out of scope until the statement of work lists them. Write the inventory, mark encryption, note clients that might be in-scope laptops, and stop.

Put the three techniques back on the worked example. The guest share may hold a .env with a cloud access key (secrets). backup_svc may have restore rights that a normal user does not (permissions). The same office visit may show a WPA2-PSK SSID named after the company plus a hidden SSID that client probes reveal (wireless). Three bullets, three notes, still no exploit.