Less Aggressive Attack

​

Less Aggressive Attack — Safety-First Offensive Operations

​

When to Use This Skill

• “don’t break anything”, “be careful”, “safety first”, “non-destructive testing”
• “don’t affect real users”, “keep it clean”, “read-only where possible”
• “don’t alter any data”, “no damage”, “safe engagement”, “careful with production”
• “just prove the finding, don’t exploit it fully”, “confirm access, don’t use it”
• Any explicit instruction to prioritize not causing harm over achieving maximum coverage or impact

• Standard engagements where the user has not flagged safety as a constraint
• Lab environments, isolated sandboxes, or CTF challenges where destruction is acceptable and expected
• Engagements where the user explicitly wants to test the full blast radius of a vulnerability
• Any situation where the user has clearly accepted the risk of destructive interaction

​

The Core Discipline

• The goal is to prove that a vulnerability exists — not to demonstrate how much damage it could do
• Access confirmed is a finding. Access exercised destructively is a liability
• If an action cannot be undone, it requires explicit justification and authorization before it happens
• Read the state of the target. Do not change it unless change is the only way to prove the finding
• An engagement that causes unintended damage is not a successful engagement — it is an incident

​

Phase 1 — Confirm Access, Not Damage

• Whether access exists — reading a resource confirms access without altering it
• Whether a vulnerability is reachable — confirming a path, parameter, or surface is sufficient
• Whether credentials or tokens are valid — a single authentication attempt confirms validity
• Whether a misconfiguration is present — reviewing configuration reveals exposure without triggering it
• Whether a trust boundary is crossable — confirming the condition under which it can be crossed does not require crossing it destructively
• Whether data is accessible — confirming that data can be read is a finding; extracting the full dataset is not required

​

Phase 2 — Gate to State-Changing Action

• Observation cannot confirm the finding and direct interaction is the only path
• The engagement scope explicitly authorizes the action type being considered
• The action is targeted, bounded, and reversible — or the scope accepts it as irreversible
• The impact if the action behaves unexpectedly has been assessed and is acceptable

• One confirmation, not a full exploitation chain
• One data point proven, not the full blast radius demonstrated
• One account tested, not the full scope of affected users verified at scale
• One state change made, documented, and if possible reverted — not an unrecoverable alteration

​

Safety Risk Budget

​

The Non-Destruction Lines

• Alter, delete, corrupt, or overwrite data that was not created specifically for the engagement
• Cause an availability impact — resource exhaustion, service disruption, cascading failure, account lockout at scale
• Deploy any payload that can propagate, escalate, or execute beyond your ability to stop it
• Take an irreversible action without explicit, documented authorization from the engagement owner
• Touch systems, accounts, or data outside the defined engagement scope — regardless of whether access is technically possible
• Demonstrate the full exploitation chain when the existence of the vulnerability is already confirmed
• Take an action whose behavior changes depending on environment state in ways you cannot predict

• Document what was confirmed through safe means
• State clearly that the full impact was not exercised and why
• Recommend controlled testing conditions under which it could be safely validated
• Deliver the finding as confirmed with a clear confidence level — do not fabricate confirmation

​

Action Reversibility Framework

Is the action reversible without engagement owner intervention?
    YES → Is the reversal guaranteed, or only likely?
        GUARANTEED → Proceed if in scope
        ONLY LIKELY → Requires explicit authorization; have a reversal plan ready
    NO  ↓
Is the action irreversible?
    → Who has authorized this specific action type?
    → What is the impact if it behaves unexpectedly?
    → Is the finding provable any other way?
        YES → Use the reversible path instead
        NO  → Escalate to engagement owner before proceeding

​

What Safe Proof Looks Like

​

Escalation and Stop Conditions

• An action produces an unexpected response suggesting broader impact than anticipated
• A system behaves in a way that suggests the action may have triggered something outside the planned scope
• A finding reveals that continuing requires crossing a safety line that was not anticipated
• Any data or system state has been altered in a way that was not planned and authorized
• Real user behavior, operations, or data is affected in any way