sentinel-pentest

name	sentinel-pentest
description	Authorized pentest workflow. When engagement summary or findings are delivered, MUST chain to sentinel-report — read sentinel-report/SKILL.md, ask save folder, Write .md + offline .html.

Sentinel: Penetration Testing

Mandatory handoff: When testing is complete or you deliver final findings, you must apply sentinel-report — read skills/sentinel/sentinel-report/SKILL.md, run Closing gate, Write report .md + .html. Do not stop at chat-only.

Penetration testing is authorized simulation of real attacks. The goal is to find what an adversary would find — before they do.

Core principle: ALWAYS confirm written authorization and defined scope before any active testing. Unauthorized testing is illegal regardless of intent.

Phase 0: Authorization & Rules of Engagement

MANDATORY before any active testing:

☐ Written authorization obtained (name the authorizing party)
☐ Scope defined — what IP ranges, domains, systems are in scope?
☐ Out-of-scope systems explicitly listed
☐ Testing window defined (hours, days)
☐ Emergency contact identified (who to call if something breaks)
☐ Data handling rules agreed (what happens to findings?)

If any of these are missing — stop. Ask the user to clarify before proceeding.

Phase 1: Reconnaissance

Gather information before touching anything in scope.

Passive Recon (no direct contact with target)

# DNS enumeration
amass enum -passive -d target.com
subfinder -d target.com

# Certificate transparency
curl "https://crt.sh/?q=%.target.com&output=json" | jq '.[].name_value'

# WHOIS, ASN, IP ranges
whois target.com
whois -h whois.radb.net -- '-i origin AS12345'

# Google dorks
site:target.com filetype:pdf
site:target.com inurl:admin
"target.com" ext:sql OR ext:env OR ext:bak

# Shodan / Censys (passive)
shodan search "hostname:target.com"

Active Recon (direct contact — confirm in scope first)

# Port scanning
nmap -sV -sC -p- --min-rate 1000 -oA scan_results target.com

# Web tech fingerprinting  
whatweb target.com
wappalyzer

# Directory enumeration
ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
     -u https://target.com/FUZZ -mc 200,301,302,403

# Parameter discovery
arjun -u https://target.com/api/endpoint

Recon Output Format

Document everything:

Host: 
Open Ports: 
Services & Versions: 
Technologies: 
Interesting Findings: 
Next Steps: 

Phase 2: Vulnerability Identification

Map what you found in recon to known vulnerability classes.

Web Application

• Run Nikto: nikto -h https://target.com
• Run OWASP ZAP or Burp Suite active scan (passive first, active after explicit confirmation)
• Manual testing of auth flows, input fields, file uploads
• Check for known CVEs in identified software versions

Network / Infrastructure

# Vulnerability scan
nmap --script vuln target.com
openvas-start  # if available

# SSL/TLS issues
testssl.sh target.com
sslscan target.com

# SMB (if in scope)
enum4linux -a target.com
smbclient -L //target.com

# Check for default credentials
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt target.com ssh

API Testing

• Does the API return more data than the UI shows? (excessive data exposure)
• Can you access other users' resources by changing IDs?
• Are HTTP methods properly restricted (PUT, DELETE, PATCH)?
• Is there a v1 API endpoint that lacks the security of v2?

Phase 3: Exploitation

Only exploit what is in scope and authorized.

For each potential vulnerability:

1. Research the CVE / technique
2. Confirm the system is in scope
3. Document your planned approach before executing
4. Execute with minimal footprint
5. Capture evidence (screenshots, command output, response bodies)

Common Exploitation Paths

SQL Injection:

sqlmap -u "https://target.com/page?id=1" --dbs --batch
# Always use --batch in automated runs, review output carefully

XSS Verification:

// Minimal verification payload — not designed to cause harm
<script>document.title='XSS-'+document.domain</script>

LFI/Path Traversal:

/page?file=../../../../etc/passwd
/page?file=....//....//....//etc/passwd  # filter bypass

SSRF:

# Probe internal metadata endpoints
http://169.254.169.254/latest/meta-data/  # AWS
http://metadata.google.internal/          # GCP

Authentication Bypass:

• Try default credentials (admin/admin, admin/password)
• Test password reset flow for token predictability
• Check for JWT alg:none vulnerability
• Test for SQL injection in login form

Phase 4: Post-Exploitation

Only proceed if explicitly in scope (e.g., "assume breach" engagement).

☐ Privilege escalation — what can we do with initial access?
☐ Lateral movement — what other systems are reachable?
☐ Data access — what sensitive data is accessible?
☐ Persistence — could an attacker maintain access? (document only, don't install)
☐ Evidence of prior compromise — are there other actors here?

Minimum footprint principle: Take only what you need to prove access. Do not modify production data, do not escalate beyond what's needed to demonstrate the finding.

Linux PrivEsc Quick Checks

sudo -l                          # What can we run as sudo?
find / -perm -4000 2>/dev/null   # SUID binaries
cat /etc/crontab                 # Cron jobs
env                              # Environment variables with secrets?
ls -la /home/                    # Other users' home dirs

Windows PrivEsc Quick Checks

whoami /priv                     # Current privileges
net localgroup administrators    # Who's admin?
schtasks /query /fo LIST /v      # Scheduled tasks
reg query HKLM\SOFTWARE\...      # Registry for stored creds

Phase 5: Cleanup & Documentation

After testing:

1. Remove any test files, payloads, or accounts created during testing
2. Document everything you accessed
3. Compile findings for sentinel:sentinel-report

Exploitation Ethics

Never:

• Exceed authorized scope
• Access or exfiltrate real user data beyond what proves the finding
• Install persistent backdoors (document that you could, don't do it)
• Test during business-critical hours without pre-approval
• Conduct DoS testing without explicit written authorization

If you find evidence of prior compromise by a third party:

• Stop active testing
• Notify the client immediately
• Document what you observed

Integration

• For vulnerability root cause analysis: sentinel:sentinel-workflow (systematic root-cause tracing)
• After testing is complete: sentinel:sentinel-report — ask save folder; default .md + offline HTML; write files (not chat-only)
• For code-level confirmation of findings: sentinel:sentinel-audit