Offensive Security Analyst

Offensive Security Analyst

When to Use

• Plan or execute authorized penetration tests, red-team exercises, or exploit validation
• Confirm rules of engagement, in-scope assets, test windows, and emergency stop conditions
• Perform reconnaissance, vulnerability validation, PoC development, and attack-path chaining within scope
• Prioritize exploitable findings by impact and likelihood
• Write remediation-focused offensive security reports and retest plans

When NOT to Use

• Investigate SOC alerts, logs, or suspicious activity → defensive-security-analyst
• Define security strategy, policy, or GRC program direction → cybersecurity
• Add CI/CD or supply-chain security controls → devsecops
• Implement enterprise security tooling and guardrails → information-security-engineer
• Test LLM prompts, agent tools, or AI jailbreak resistance → ai-redteam

Related skills

Core Workflows

1. Engagement scope and authorization

Do not test without written authorization.

1. Confirm signed SOW/ROE: in-scope assets, methods, windows, contacts 2. Define out-of-scope (prod data destruction, social engineering, DoS unless approved) 3. Set severity rubric aligned with customer 4. Establish emergency stop and escalation path 5. Use isolated lab or designated test tenants when possible

See `references/engagement_scope.md` for ROE checklist and severity rubric.

2. Reconnaissance and enumeration

passive OSINT → asset inventory → service/version ID → auth surface mapping → prioritize targets

Document everything: source, timestamp, tool, raw output hash or path.

See `references/recon_enumeration.md` for recon phases and asset tracking.

3. Vulnerability assessment and validation

1. Run scans appropriate to scope (authenticated where allowed) 2. Validate each finding manually—no report-only scanner noise 3. Classify: exploitable, conditional, informational 4. Map to CWE/CVE and ATT&CK where applicable 5. Note compensating controls that block exploitation

See `references/vulnerability_assessment.md` for validation criteria and false positive filters.

4. Exploitation and attack paths

PoC requirements:

• Minimal steps to demonstrate impact
• Evidence: request/response, screenshot, command output
• Clear preconditions (role, network position, config)
• Stop at agreed impact (e.g., proof of RCE without lateral movement unless scoped)

Chain findings into attack paths: initial access → privilege → objective.

See `references/exploitation_chain.md` for PoC template and chaining worksheet.

5. Post-exploitation (when in scope)

Only within ROE:

• Credential access proof (hashed, not exfiltrating real secrets unnecessarily)
• Lateral movement to agreed segment
• Data access proof without excessive collection

Document cleanup: accounts created, shells, persistence removed before closeout.

6. Reporting and remediation

Per finding:

Deliver executive summary + technical appendix; schedule retest for critical/high.

See `references/reporting_remediation.md` for report structure and retest checklist.

When to load references

• Scope, ROE, authorization → references/engagement_scope.md
• Recon and enumeration → references/recon_enumeration.md
• Scanning and validation → references/vulnerability_assessment.md
• PoCs and attack paths → references/exploitation_chain.md
• Reports and retest → references/reporting_remediation.md

Engagement scope

Table of contents

1. Authorization checklist 2. ROE elements 3. Severity rubric

Authorization checklist

• [ ] Signed contract or letter of authorization on file
• [ ] Named technical and business contacts
• [ ] In-scope IP/domains/apps listed explicitly
• [ ] Out-of-scope documented (third parties, prod PII, physical, DoS)
• [ ] Testing window and timezone confirmed
• [ ] Emergency stop procedure agreed

ROE elements

Severity rubric

Align rubric with customer risk appetite before testing starts.

Exploitation and attack paths

Table of contents

1. PoC template 2. Attack path worksheet 3. Safety stops

PoC template

### [Finding ID] Title
**Severity:**
**Asset:**
**Preconditions:** (auth level, network position)

#### Steps
1.
2.

#### Evidence
- [screenshot / request file / hash]

#### Impact
[what an attacker gains]

#### Cleanup
[artifacts to remove]

Attack path worksheet

Safety stops

Stop and escalate when:

• Out-of-scope system reached
• Unexpected production impact
• Real PII accessed beyond proof minimum
• ROE boundary unclear

Do not deploy ransomware, wipers, or mass DoS unless explicitly in scope (rare).

Reconnaissance and enumeration

Table of contents

1. Phases 2. Asset inventory 3. Enumeration targets

Phases

Stay within ROE rate limits and scope lists.

Asset inventory

Track per asset:

• Hostname / URL
• IP or endpoint
• Owner (if known)
• Environment (prod/stage/dev)
• Auth required (Y/N)
• Notes

Enumeration targets

• Default credentials on admin panels
• Exposed admin interfaces and debug endpoints
• API versioning and undocumented routes
• TLS/certificate transparency for shadow IT
• Subdomain takeover candidates (dangling DNS)

Reporting and remediation

Table of contents

1. Report structure 2. Executive summary 3. Retest checklist

Report structure

1. Executive summary 2. Scope and methodology 3. Risk rating methodology 4. Findings summary table 5. Detailed findings (one section per issue) 6. Attack narrative (optional, for red team) 7. Appendices (tools, raw scan configs redacted)

Executive summary

Include:

• Overall risk posture (sentence)
• Count by severity
• Top 3 themes (e.g., auth, injection, cloud IAM)
• Remediation priority order
• Positive observations (controls that worked)

Retest checklist

For each fixed critical/high finding:

• [ ] Customer states fix deployed and version/build ID
• [ ] Analyst reproduces original steps
• [ ] Confirm exploit no longer succeeds
• [ ] Update status: Open → Remediated → Verified
• [ ] Note partial fixes explicitly

Vulnerability assessment

Table of contents

1. Validation criteria 2. False positive filters 3. Classification

Validation criteria

A finding is reportable only if:

1. Reproduced by analyst (not scanner-only) 2. Impact explained in customer context 3. Affected asset is in scope 4. Steps are repeatable by customer engineering

False positive filters

Discard or downgrade when:

• Version match without vulnerable code path
• Self-XSS without victim interaction chain
• Missing security header with no demonstrated exploit
• Theoretical issue requiring improbable user action
• Compensating control blocks exploit (note as informational)

Classification

Map to CWE/CVE when available; link to ATT&CK technique for narrative reports.