Study guide
6.3 Secrets, Permissions, and Wireless Enumeration
CompTIA PenTest+ PT0-003
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current PT0-003 Exam Facts 1.2 Format, PBQs, Scoring, and Retake Policy 1.3 Recertification, CEUs, and Career Fit
2 Pre-Engagement Planning
2.1 Scope, Rules of Engagement, and Agreements 2.2 Target Selection and Assessment Types 2.3 Shared Responsibility, Legal Authorization, and Ethics
3 Collaboration, Frameworks, and Threat Modeling
3.1 Collaboration, Escalation, and Stakeholder Communication 3.2 Testing Frameworks and Methodologies 3.3 Threat Modeling: STRIDE, DREAD, and OCTAVE
4 Reporting and Remediation
4.1 Penetration Test Report Components 4.2 Findings Analysis and Remediation Recommendations
5 Information Gathering
5.1 Active vs Passive Reconnaissance 5.2 OSINT Sources and Techniques 5.3 DNS, Certificate Transparency, and Search Engine Enumeration 5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing
6 Enumeration Techniques
6.1 OS Fingerprinting, Service Discovery, and Host Discovery 6.2 DNS, Directory, Share, and Account Enumeration 6.3 Secrets, Permissions, and Wireless Enumeration 6.4 WAF Enumeration, Web Crawling, and Attack Path Mapping
7 Recon Scripting and Tools
7.1 Modifying Bash, Python, and PowerShell for Recon 7.2 Recon and Enumeration Tools
8 Vulnerability Scan Types
8.1 Network, Host, Authenticated, and Wireless Scans 8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans 8.3 Container, Secrets, and ICS Vulnerability Assessment 8.4 Core Vulnerability Scanners (Nessus, OpenVAS, Nikto)
9 Scan Analysis and Physical Security
9.1 Specialized Discovery Tools 9.2 Validating Scan, Recon, and Enumeration Results 9.3 Public Exploit Selection and Scripted Validation 9.4 Physical Security Concepts for PenTests
10 Attack Prioritization and Preparation
10.1 Target Prioritization: CVSS, CVE, CWE, and EPSS 10.2 Exploit Selection, Customization, and Attack Documentation
11 Network Attacks
11.1 On-Path, VLAN Hopping, Relay, and Multihomed Hosts 11.2 Default Credentials, Misconfigured Services, Packet Crafting, and Certificate Services
12 Authentication Attacks
12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks 12.2 Password Attacks, MFA Fatigue, LDAP Injection, OIDC, and SAML
13 Host-Based Attacks
13.1 Privilege Escalation and Credential Dumping 13.2 Process Injection, Security Bypass, and Host Attack Tools
14 Web Application Attacks
14.1 SQL, Command, XSS, and SSTI Injection 14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal 14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking
15 Cloud Attacks
15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage 15.2 Container Escape, Supply Chain, and Cloud Attack Tools
16 Wireless and Social Engineering
16.1 Wireless Attacks and Tools 16.2 Phishing, Spearphishing, Whaling, Vishing, and Smishing 16.3 Physical Social Engineering and SE Tools
17 Specialized Systems
17.1 Mobile Attacks and AI Prompt/Model Attacks 17.2 OT/ICS, NFC, RFID, and Bluetooth Attacks
18 Attack Scripting and BAS
18.1 PowerShell, Python, and Bash Attack Automation 18.2 Breach and Attack Simulation (Caldera, Infection Monkey, Atomic Red Team)
19 Persistence
19.1 Scheduled Tasks, Services, Accounts, and Shells 19.2 C2, Backdoors, Rootkits, and Security-Control Tampering
20 Lateral Movement
20.1 Pivoting, Relays, and Additional Credential Capture 20.2 Remote Services: SMB, RDP, WinRM, WMI, SSH, and Others 20.3 Lateral Movement Tools and LOLbins
21 Exfiltration and Cleanup
21.1 Staging and Exfiltration 21.2 Cleanup, Restoration, and Artifact Preservation
6.3 Secrets, Permissions, and Wireless Enumeration
Key Takeaways Explain This Topic AI
PT0-003 secrets enumeration explicitly includes cloud access keys, passwords, API keys, and session tokens — identification of live credentials, not a treasure hunt to paste into public chat.
Cloud access keys often hide in JavaScript bundles, .env files in git, CI logs, and mobile application packages; an AKIA-style AWS access key ID is a secret finding.
Permission enumeration inventories rights: Linux sudoers, NTFS and share ACLs, and cloud IAM policies or group membership that grant execute, write, or assume-role.
Wireless enumeration on 2.2 is inventory of SSIDs, hidden networks, associated clients, and encryption type (WPA2 versus WPA3), not the Domain 4 wireless-attack playbook.
Handle every recovered secret as a live credential: store it only in the agreed evidence channel, recommend rotation, and never paste it into a public chatbot, gist, or out-of-scope checker.
Last updated: August 2026
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.
2.2 technique What you identify Typical location Handling / exam trap
Cloud access keys AKIA-style AWS IDs, Azure/GCP credentials JS bundles, .env , git, APKs Do not paste into public chat
Passwords Cleartext or reversible secrets Configs, comments, guest shares Distinguish from hashes you cannot use yet
API keys Bearer or vendor key strings Client-side code, HAR files Still a secret even if "only" a map key
Session tokens Cookies, localStorage, Authorization headers Browser storage, intercepts Treat as equivalent to a password
- Permissions sudoers, NTFS ACL, IAM allow/deny Host, share, cloud policy Rights are not the secret itself
- Wireless SSID, hidden net, clients, WPA2/WPA3 In-scope RF window Inventory, not deauth or evil twin
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.