कोई त्रुटि नहीं। कोई विसंगति नहीं। गिनने के लिए कोई विफल प्रमाणीकरण नहीं। हमलावर का एक्सेस क्रेडेंशियल *तीन सेकंड पुराना* है और इसे सर्वर द्वारा, अनुरोध पर, रीसेट के बाद जारी किया गया था।

यहाँ पूरी भेद्यता है:```python
def _revoke_for_security_change(self, user, kind, device_id):
    if device_id:
        revoke_credentials(user, device_id=device_id)   # ← the finding

यह कोई बेवकूफ़ी भरा नियम नहीं है। यह सस्ता है, एक फ़ील्ड चाहिए, समस्या की परिभाषा जैसा पढ़ा जाता है, और यह **साधारण मामले के बारे में सही है** — रीसेट के बाद चोरी हुए *access* टोकन का उपयोग करने वाला हमलावर पकड़ा जाता है।
`test_the_naive_rule_catches_the_simple_case` यह दावा करता है कि यह काम करता है।

दोनों नियम एक ही क्रेडेंशियल के बारे में एक ही सवाल पूछते हैं। वे जवाब देने के लिए अलग-अलग फ़ील्ड पढ़ते हैं, और दोनों फ़ील्ड असहमत हैं:

![दो पंक्तियाँ, प्रति फ़ील्ड एक। credential.issued_at 10:00:03 पढ़ता है, बदलाव के तीन सेकंड बाद, और निष्कर्ष निकालता है कि क्रेडेंशियल साफ़ दिखता है। lineage.root_issued_at 09:00:00 पढ़ता है, बदलाव से एक घंटा पहले, और अलर्ट करता है।](https://raw.githubusercontent.com/het-p301204/afterlife/main/docs/figures/two-fields.svg)

**तीन सेकंड बाद, या एक घंटा पहले — एक ही क्रेडेंशियल, एक ही क्षण में।** naive नियम हमलावर के नियंत्रण वाला फ़ील्ड पूछता है, और एक `POST /refresh` उसे रीसेट कर देता है।

इसे request log पर चलाएँ, जहाँ यह क्वेरी वास्तव में लिखी जाती है, क्योंकि request logs ही आपके पास होते हैं:```text
NAIVE DETECTOR (NAIVE-001), over the request log

  Result: NO ALERT

  Six requests were served to the attacker after the reset. Every one of them
  carried at-004, minted at 10:00:03 -- three seconds *after* the password
  change. By its own timestamp it is the newest credential on the account.

यही अंतर है जो रात 3 बजे मायने रखता है। भोला नियम उस एक क्षण को पकड़ लेता है जब श्रृंखला सीमा पार करती है, फिर शेष 29 दिनों तक निशान खो देता है — और जिस क्रेडेंशियल का वह नाम लेता है वह *पहले ही घुमाया जा चुका है और सर्वर द्वारा निरस्त कर दिया गया है*। उसे निरस्त करने से कुछ हासिल नहीं होता। `lin-001` वह वस्तु है जिसे आपको खत्म करना है।

**और भोला नियम टेलीमेट्री से वंचित नहीं था।** यह उसी इवेंट स्ट्रीम, उसी वंशावली इंडेक्स, उसी सहनशीलता, उसी डुप्लिकेशन-हटाने और उसी सीमित स्थिति का उपयोग करता है। यह एक विधि को ओवरराइड करता है:```python
class Correlator:                                  # AFTERLIFE-001
    def _age_reference(self, facts):
        return facts.root_issued_at

class NaiveCorrelator(Correlator):                 # NAIVE-001
    def _age_reference(self, facts):
        return facts.issued_at

**यह क्रम इस रिपॉज़िटरी की सबसे उपयोगी चीज़ है।** AFTERLIFE-003
उसी क्षण सक्रिय होता है जब परिवर्तन लागू होता है, हमलावर के कुछ भी छूने से तीन सेकंड पहले, क्योंकि इसके लिए आवश्यक साक्ष्य पहले से ही पूर्ण होते हैं: लॉग बताता है कि कौन-कौन से वंश (lineages) प्रवेश के समय सक्रिय थे, और यह नहीं बताता कि उन्हें रद्द (revoked) किया गया था।

इसे किसी पीड़ित या शोषण की आवश्यकता नहीं है। यह किसी भी उपयोगकर्ता द्वारा किए गए पहले पासवर्ड रीसेट पर ही दोष की रिपोर्ट कर देगा — जो इसे वह बनाता है जिसे आप स्टेजिंग में चलाते हैं, जहाँ प्रतीक्षा करने के लिए कोई हमलावर नहीं होता। AFTERLIFE-001 आपको बताता है कि उल्लंघन (breach) जारी है; AFTERLIFE-003 आपको बताता है कि आपका कंटेनमेंट नियंत्रण टूटा हुआ है।

![दो अलर्ट कार्ड। AFTERLIFE-003 10:00:00 पर verdict no_containment, watermark not recorded, scope none, और lin-001 surviving की रिपोर्ट करता है। AFTERLIFE-001 10:00:03 पर credential rt-002 की रिपोर्ट करता है जिसमें एक root ने परिवर्तन से एक घंटा पहले जारी किया था।](https://raw.githubusercontent.com/het-p301204/afterlife/main/docs/figures/findings-vulnerable.svg)

`application recorded watermark: no` वह फ़ील्ड है जो किसी घटना प्रतिक्रियाकर्ता (incident responder) को लक्षण के बजाय *दोष* की ओर इंगित करता है।

### नियम जिस वॉटरमार्क का उपयोग करते हैं वह वह नहीं है जिसकी अनुप्रयोग रिपोर्ट करता है

क्रेडेंशियल-परिवर्तन इवेंट में एक `revocation_watermark` फ़ील्ड होता है — वह `credentials_valid_after` मान जो अनुप्रयोग ने लिखा था। **कमज़ोर कार्यान्वयन में यह `null` होता है, क्योंकि अनुप्रयोग ने कभी इसे लिखा ही नहीं।** यही बग है।

इसलिए उस फ़ील्ड पर आधारित कोई नियम उसी मामले के प्रति अंधा रह जाएगा जिसे पकड़ने के लिए वह अस्तित्व में है। नियम इवेंट के स्वयं के `timestamp` पर आधारित होते हैं, जो सत्य है चाहे अनुप्रयोग ने अपना काम किया हो या नहीं, और अनुपस्थित फ़ील्ड को साक्ष्य के रूप में रिपोर्ट करते हैं।

### गुण```text
  deduplication        6 accepted requests on the stale lineage -> 1 alert
  event order          shuffled stream -> same alert  (1 alert)
  duplicate telemetry  log replayed twice -> 1 alert  (24 duplicate events discarded)
  false positives      the fixed implementation's log -> 0 alerts
  bounded state        caps at 256 activity/user, 2000 users, 20000 credentials

**[`docs/console-preview.html`](https://github.com/het-p301204/afterlife/blob/main/docs/console-preview.html)** लिखता है — एक
स्व-निहित 74 KiB फ़ाइल जिसमें दोनों रन अंतर्निहित हैं। कोई सर्वर नहीं, कोई नेटवर्क नहीं, कोई
फ़ॉन्ट लाने की आवश्यकता नहीं; इसे फ़ाइलसिस्टम से खोलें। या लाइव संस्करण चलाएँ:```bash
python -m console

The application runs **in-process** under the demo, the console और tests। No
ports, no dev server, no Docker। The clock pinned है, so every run
deterministic है और committed telemetry, console, figures और reports सभी
runs के बीच byte-identical हैं — जिसे CI `git diff --exit-code` के साथ check करता है।

### Server-side enforcement

A credential एक **row** है, string नहीं। JWT जो client hold करता है वह `cid` carry करता है —
एक lookup key — और row decide करती है कि credential alive है या नहीं।

Expiry को row के `expires_at` के against check किया जाता है, न कि `exp` claim के against जो
holder ने present किया। Both temporal claims PyJWT को `verify=False` के साथ handed हैं,
जिसका यहाँ मतलब है *"the server checks this itself"*, और [`app/auth.py`](https://github.com/het-p301204/afterlife/blob/main/app/auth.py)
हर request पर ऐसा करता है। Client को कभी vote नहीं मिलता कि उसका own
credential अभी भी valid है या नहीं।

---

## Attack timeline```mermaid
flowchart TD
    A["Account compromised<br/><i>phishing · XSS · stolen backup</i>"] --> B["Attacker holds refresh credential rt-001<br/>lineage lin-001, root sess-001 @ 09:00"]
    B --> C["Legitimate password change @ 10:00<br/>HTTP 200 · password hash updated"]
    C --> D{"device_id supplied?"}
    D -->|"yes"| E["revoke_credentials(user, device_id)<br/>rt-001 revoked"]
    D -->|"no — the exploit"| F["nothing revoked<br/>no watermark written"]
    E --> G["Attacker refresh → 401<br/><b>contained</b>"]
    F --> AF3["<b>AFTERLIFE-003 · HIGH</b> @ 10:00:00<br/>containment did not run<br/><i>no attacker action required</i>"]
    F --> H["POST /refresh rt-002 → 200<br/>mints at-004 @ 10:00:03"]
    H --> I["GET /me at-004 → 200<br/>well-formed · correctly signed · <b>no anomaly</b>"]
    I --> J["at-004.issued_at > watermark<br/>NAIVE-001: no alert"]
    I --> K["lineage lin-001 root @ 09:00 < watermark<br/><b>AFTERLIFE-001 · HIGH</b>"]
    F --> L["attacker holds and never spends<br/>AFTERLIFE-001 silent — correctly<br/><b>state audit: dormant survivor</b>"]

    style F fill:#7f1d1d,color:#fff
    style H fill:#7f1d1d,color:#fff
    style I fill:#7f1d1d,color:#fff
    style J fill:#78350f,color:#fff
    style K fill:#14532d,color:#fff
    style AF3 fill:#14532d,color:#fff
    style L fill:#1e3a5f,color:#fff
    style E fill:#14532d,color:#fff
    style G fill:#14532d,color:#fff

`at-004` तीन सेकंड पुराना है। इसका वंश एक घंटे पुराना है। दोनों तथ्य सत्य हैं,
और इनमें से केवल एक ही अनुरोध लॉग में दिखाई देता है।

दो अपरिवर्तनीय नियम इसे एक साथ बनाए रखते हैं, और दोनों का परीक्षण किया गया है:

1. **केवल प्रमाणीकरण एक वंशावली बनाता है।** `Store.open_session` एकमात्र स्थान है जहाँ
   `lineage_id` उत्पन्न होता है, और यह सत्र को उसका स्वयं का
   `root_credential_id` बना देता है।
2. **मिंटिंग रूट को नीचे कॉपी करती है।** `TokenService.mint` वंशावली फ़ील्ड्स को
   पुनर्गणना करने के बजाय पैरेंट से पढ़ता है, इसलिए एक क्रेडेंशियल उस लॉगिन से अधिक ताज़ा वंशावली प्राप्त नहीं कर सकता जिससे वह उतरा है।

धारक-प्रस्तुत टोकन जानबूझकर अपना वंशावली रूट **नहीं** वहन करता। यदि वह करता, तो धारक इसके बारे में झूठ बोल सकता था।

---

## स्थिति ऑडिट

AFTERLIFE-001 तब सक्रिय होता है जब एक पुरानी वंशावली *उपयोग* की जाती है। यह एक डिटेक्शन नियम के लिए सही ट्रिगर है, और यह एक छेद छोड़ देता है: **जिस पुरानी वंशावली को किसी ने छुआ नहीं है, वह इसके लिए अदृश्य है।** एक हमलावर जो एक क्रेडेंशियल चुराता है, रीसेट को विफल होते देखता है, और फिर प्रतीक्षा करता है, सहसंबंधित करने के लिए कोई गतिविधि उत्पन्न नहीं करता।

इसलिए लैब वह प्रश्न भी पूछता है जो एक नियम नहीं पूछ सकता: *क्या हुआ* नहीं, बल्कि *क्या अभी भी जीवित है*।```text
  scenario: dormant-survivor   (the attacker holds the credential and never spends it)

  AFTERLIFE-001   silent   — correct; nothing was accepted
  AFTERLIFE-003   HIGH     — the change revoked nothing
  state audit     1 stale lineage, 1 dormant

# Scan a single target
scanner scan --target example.com

# Scan multiple targets from a file
scanner scan --input targets.txt --output results.json

# Use a custom configuration file
scanner scan --config /path/to/config.yaml

# Run with verbose output
scanner scan --target example.com --verbose

# Scanner configuration
server:
  url: "http://localhost:8080"
  timeout: 30

scan:
  threads: 10
  timeout: 60
  retries: 3

output:
  format: "json"
  directory: "./results"

# Start a scan
curl -X POST http://localhost:8080/api/v1/scan \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target": "example.com"}'

# Get scan status
curl http://localhost:8080/api/v1/scan/SCAN_ID \
  -H "Authorization: Bearer YOUR_TOKEN"

| `--no-color` | Disable colored output |
| `--debug` | Enable debug mode |
| `--verbose` | Enable verbose mode |
| `--silent` | Enable silent mode |
| `--version` | Show version and exit |
| `--help` | Show help and exit |```text
VULNERABLE
  server state   1 lineage(s) outlived the change   (0 dormant)
  telemetry      1 lineage(s)   -- the same question, asked of the log instead of the database
    lin-001 root 2026-09-11T09:00:00.000Z  7 credentials  in use

FIXED
  server state   clean
  telemetry      clean

न तो `device_id` पर निर्भर करता है। इसे संदर्भ के रूप में दर्ज किया जाता है और ब्लास्ट रेडियस में इसका कोई योगदान नहीं है।

**वॉटरमार्क ही आर्किटेक्चरल गारंटी है।** प्रति उपयोगकर्ता एक टाइमस्टैम्प, `credentials_valid_after`, प्रत्येक अनुरोध पर क्रेडेंशियल के स्वयं के जारी होने *और* उसके lineage रूट दोनों के विरुद्ध तुलना किया जाता है:```python
watermark = user.credentials_valid_after
if credential.issued_at      < watermark:  reject  # the obvious case
if credential.root_issued_at < watermark:  reject  # the refresh chain

| file | यह क्या pin करता है |
|---|---|
| [`test_fixed_mode.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_fixed_mode.py) | **वह regression suite जो कभी red नहीं होनी चाहिए** — revocation event से पहले जारी कोई भी credential उसके बाद स्वीकार नहीं किया जाता, जिसमें एक stale lineage से उत्पन्न credential भी शामिल है |
| [`test_vulnerable_mode.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_vulnerable_mode.py) | vulnerability **मौजूद है**, deterministic है, 30 दिन तक रहती है, और conditional के कारण होती है — `device_id` control यह साबित करता है कि revocation path optional है, dead नहीं |
| [`test_lineage.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_lineage.py) | एक refresh chain एक lineage और एक root रखती है; केवल login एक lineage बनाता है |
| [`test_detector_afterlife001.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_detector_afterlife001.py) | 7 detection cases, 9 false-positive cases, 2 blind spots, सभी 24 event orderings, bounded state, malformed input |
| [`test_detector_rulepack.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_detector_rulepack.py) | AFTERLIFE-002 और AFTERLIFE-003 — हर verdict, grace window, rotation-is-not-death, expiry exclusion, और engine की ordering |
| [`test_naive_detector.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_naive_detector.py) | NAIVE-001 **उसी विशिष्ट तरीके से** fail होता रहता है जिसका दावा यह README करता है — जिसमें यह भी शामिल है कि उसके पास आवश्यक data था |
| [`test_audit_and_console.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_audit_and_console.py) | वह dormant survivor जिसे कोई rule नहीं देख सकता; दोनों audit sources का सहमत होना; console का अपना कोई verdict न निकालना; offline preview का कुछ भी fetch न करना; इस README का हर figure in bounds, stylesheet-free और byte-stable होना |
| [`test_scenarios.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_scenarios.py) | वे matrix rows जो एक argument रखती हैं |
| [`test_privilege_changes.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_privilege_changes.py) | MFA, role change और account recovery, दोनों modes |
| [`test_telemetry.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_telemetry.py) | redaction contract, और जारी किए गए literal bearer strings के लिए log का grep |
| [`test_app.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_app.py) | forged signatures, गलत credential types, server state से expiry |
| [`test_infrastructure.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_infrastructure.py) | config, clock, tailer partial lines, दोनों CLIs, हर demo command |

Suite का सबसे मजबूत test है
`test_no_bearer_string_or_password_ever_reaches_the_log`: यह पूरा attack चलाता है
और फिर log file में application द्वारा दिए गए actual credentials खोजता है, साथ ही
दोनों passwords, और signing key भी। Field names के लिए नहीं — values के लिए।

---

## Blind spots

स्पष्ट रूप से बताए गए हैं, क्योंकि इन्हें छिपाना lab को बेईमान बना देगा। प्रत्येक का एक test है।

> **यदि application credential-change events emit नहीं करता, तो pack post-reset
> activity को विश्वसनीय रूप से correlate नहीं कर सकता।** कोई anchor नहीं है, इसलिए
> activity के "after" होने के लिए कुछ नहीं है — और यह पहले AFTERLIFE-003 को चुप करा
> देता है, जो वह rule है जो आपको बताता कि control टूटा हुआ था।
>
> **यदि application issuance/lineage metadata retain नहीं करता, तो detector यह
> निर्धारित नहीं कर सकता कि कोई fresh access token किसी पुराने credential से
> उत्पन्न हुआ था या नहीं।** तीन सेकंड पहले mint किया गया credential, एक महीने पुरानी
> chain द्वारा तीन सेकंड पहले mint किए गए credential से अलग नहीं पहचाना जा सकता।

ये **optional logging preferences नहीं हैं। ये security detection requirements हैं।**
Log volume कम करने के लिए `auth.token.issued` हटाना logging को सस्ता नहीं बनाता;
यह एक detection बंद कर देता है।

Unresolvable activity को **counted** किया जाता है, चुपचाप drop नहीं किया जाता —
`stats()["activity_with_unresolved_lineage"]` तब non-zero होता है जब भी detector से
ऐसे credentials के बारे में पूछा गया जिन्हें telemetry ने कभी describe नहीं किया।
एक rule जो इसलिए चुप है क्योंकि कुछ गलत नहीं है और एक rule जो इसलिए चुप है क्योंकि
वह blind है, बाहर से एक जैसे दिखते हैं, और वह संख्या यही अंतर है।

यह भी सत्य है, और यह भी documented है:

* **Detector किसी request को refuse नहीं कर सकता।** यह एक log tail करता है। यह
  आपको बताता है कि containment fail हुआ; यह contain नहीं करता।
* **Audit एक scan है, detection नहीं।** यह dormant-survivor gap को बंद करता है,
  लेकिन यह तब चलता है जब कोई इसे चलाता है। यह page नहीं कर सकता।
* **Fix reset के *बाद* चुराए गए credentials में मदद नहीं करता।** Containment एक
  point in time है, कोई property नहीं।
* **AFTERLIFE-003 observed containment verify करता है, architectural completeness
  नहीं।** एक device-scoped revocation जो संयोग से सब कुछ cover कर लेती है, उसे LOW
  finding मिलती है, HIGH नहीं। Bug अभी भी वहीं है; उस account पर उसने काटा नहीं।
  एक test पूछ सकता है "दो devices के बारे में क्या?"; एक log केवल वही report कर सकता
  है जो वास्तव में हुआ।
* **अन्य persistence password change के बाद पूरी तरह जीवित रहती है** — OAuth grants,
  API keys, mail-forwarding rules, recovery contacts।

पूरी चर्चा: **[docs/limitations.md](https://github.com/het-p301204/afterlife/blob/main/docs/limitations.md)**।

---

## Running the lab```bash
python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate

pip install -r requirements.txt -r requirements-dev.txt

pytest -q

| `-s` | `--server` | Server URL (default: `http://localhost:8080`) |
| `-t` | `--token` | API token for authentication |
| `-o` | `--output` | Output file path |
| `-f` | `--format` | Output format: `json`, `yaml`, `table` |
| `-v` | `--verbose` | Enable verbose output |
| `-q` | `--quiet` | Suppress non-essential output |
| `-h` | `--help` | Show help message |
| `-V` | `--version` | Show version information |

### उदाहरण

```bash
# List all projects
kitploit-cli projects list

# Get details of a specific project
kitploit-cli projects get --id 12345

# Create a new scan
kitploit-cli scans create --target https://example.com --profile full

# Export results to JSON
kitploit-cli scans results --id 67890 --format json --output results.json

server: http://localhost:8080
token: your-api-token-here
output_format: table
verbose: false

| `--no-color` | Disable colored output |
| `--debug` | Enable debug mode |
| `--verbose` | Enable verbose mode |
| `--silent` | Enable silent mode |
| `--version` | Show version |
| `--help` | Show help |```bash
python scripts/lab.py fixed

या पूरी कहानी एक साथ, अंत में सीख के साथ:```bash
python scripts/lab.py all

<details>
<summary><b>बाकी सब कुछ</b> — डिटेक्टर CLI, मैट्रिक्स, रिपोर्ट, आंकड़े, सर्वर</summary>

<br>

कमिट किए गए साक्ष्य को पैक के माध्यम से रीप्ले करें। किसी एप्लिकेशन रन की आवश्यकता नहीं — डिटेक्टर पूरी तरह से डाउनस्ट्रीम है, और यह प्रमाण है:```bash
python -m detector --once --timeline --events evidence/vulnerable-persistence.jsonl

| `-s` | `--server` | Server URL (default: `http://localhost:8080`) |
| `-t` | `--token` | API token for authentication |
| `-o` | `--output` | Output file path |
| `-f` | `--format` | Output format: `json`, `yaml`, `table` |
| `-v` | `--verbose` | Enable verbose logging |
| `-q` | `--quiet` | Suppress non-error output |
| `-h` | `--help` | Show help message |
| `-V` | `--version` | Show version information |

### उदाहरण

```bash
# Scan a single target
scanner scan --target example.com

# Scan multiple targets from a file
scanner scan --input targets.txt --output results.json

# Use a custom configuration
scanner scan --config /path/to/config.yaml --verbose

server:
  url: http://localhost:8080
  token: your-api-token
  timeout: 30s

scan:
  concurrency: 10
  rate_limit: 100
  retries: 3

output:
  format: json
  directory: ./results

| `--no-color` | Disable colored output |
| `--debug` | Enable debug mode |
| `--verbose` | Enable verbose mode |
| `--silent` | Enable silent mode |
| `--version` | Show version |
| `--help` | Show help |```bash
python -m detector --audit --events evidence/vulnerable-persistence.jsonl

जिस घटना रिपोर्ट को एक प्रतिक्रियाकर्ता को सौंपा जाएगा, और इस README में दिए गए आंकड़े:```bash
python scripts/report.py

# Scan a single target
scanner -t example.com

# Scan multiple targets from a file
scanner -f targets.txt -o results.json

# Use a custom server with authentication
scanner -s https://api.example.com -t YOUR_TOKEN -v

server: http://localhost:8080
token: your-token-here
timeout: 30
threads: 10

लाइव कंसोल, और लैब API हाथ से — दोनों केवल लूपबैक:```bash
python -m console

# Scan a single target
scanner scan --target example.com

# Scan multiple targets from a file
scanner scan --input targets.txt --output results.json

# Use a custom configuration
scanner scan --config custom-config.yaml --verbose

server:
  url: "http://localhost:8080"
  token: "your-api-token"
  timeout: 30

scan:
  threads: 10
  timeout: 60
  retries: 3

output:
  format: "json"
  directory: "./results"

{
  "target": "example.com",
  "options": {
    "depth": 3,
    "timeout": 60
  }
}

{
  "id": "scan-12345",
  "status": "running",
  "created_at": "2024-01-15T10:30:00Z"
}

{
  "id": "scan-12345",
  "status": "completed",
  "results": [
    {
      "type": "vulnerability",
      "severity": "high",
      "description": "SQL injection detected"
    }
  ]
}

कमिट किए गए टेलीमेट्री को पुनः उत्पन्न करें (पिन किया गया क्लॉक, रन के बीच बाइट-समान):```bash
python scripts/lab.py evidence

| `--no-color` | आउटपुट में रंग अक्षम करें |
| `--debug` | डिबग मोड सक्षम करें |
| `--verbose` | वर्बोज़ आउटपुट सक्षम करें |
| `--quiet` | चुप्पी मोड सक्षम करें |
| `--version` | संस्करण जानकारी दिखाएं |
| `--help` | सहायता संदेश दिखाएं |```powershell
./make.ps1 demo

Fake, local, और इस repository में केवल यही credentials हैं।

---

## Security notes

**इस repository में जानबूझकर vulnerable code मौजूद है।**
`app/auth.py:_revoke_for_security_change` जब `AFTERLIFE_MODE=vulnerable` होता है तो जानबूझकर revoke करने में विफल रहता है।

Vulnerable path **default नहीं है**। `AFTERLIFE_MODE` का default `fixed` है, और `test_the_default_mode_is_the_safe_one` इसे pin करता है — ऐसा lab जिसका टूटा हुआ व्यवहार कुछ भी configure करना भूल जाने पर मिलता है, आखिरकार किसी असली चीज़ में copy हो जाएगा।

किसी भी mode में इसे network पर expose करना सुरक्षित नहीं है: bearer credentials response bodies में लौटाए जाते हैं, `GET /lab/credentials` किसी user की credential state के बारे में server का पूरा दृश्य dump कर देता है, `GET /lab/audit` design से unauthenticated है, `POST /security-change` स्वयं को `admin` grant कर लेगा, और कहीं भी TLS, rate limiting, CSRF protection या account lockout नहीं है। सब कुछ `127.0.0.1` पर bind होता है, और `python -m app` तथा `python -m console` दोनों किसी अन्य address को अस्वीकार करते हैं।

इस repository में कोई असली credential, key या secret मौजूद नहीं है। Signing key literal string `afterlife-lab-signing-key-not-a-secret-do-not-reuse` है; credential database का default `:memory:` है; telemetry उन values को बदल देती है जिनके key names credentials जैसे दिखते हैं और credentials को id तथा fingerprint से संदर्भित करती है। विवरण और reporting प्रक्रिया: **[SECURITY.md](https://github.com/het-p301204/afterlife/blob/main/SECURITY.md)**।

---

## Documentation

| | |
|---|---|
| [docs/detection.md](https://github.com/het-p301204/afterlife/blob/main/docs/detection.md) | rule pack: सभी तीन rule cards, state audit, आवश्यक telemetry, false positives, severity rationale, response runbooks |
| [docs/tradeoffs.md](https://github.com/het-p301204/afterlife/blob/main/docs/tradeoffs.md) | चार revocation architectures, JWT tension, और CVSS चर्चा |
| [docs/limitations.md](https://github.com/het-p301204/afterlife/blob/main/docs/limitations.md) | हर blind spot, fix क्या ठीक नहीं करता, audit क्या बंद करता है, और lab के अपने compromises |
| [docs/console-design.md](https://github.com/het-p301204/afterlife/blob/main/docs/console-design.md) | console mortality register क्यों है, palette और type निर्णय, और क्या हटाया गया |
| [docs/console-preview.html](https://github.com/het-p301204/afterlife/blob/main/docs/console-preview.html) | console, एक self-contained file में baked |
| [docs/figures/](https://github.com/het-p301204/afterlife/blob/main/docs/figures) | इस README के figures, payload से generated |
| [report/AFTERLIFE-report.md](https://github.com/het-p301204/afterlife/blob/main/report/AFTERLIFE-report.md) | vulnerable run के लिए एक generated incident report |
| [SECURITY.md](https://github.com/het-p301204/afterlife/blob/main/SECURITY.md) | local-only boundary, lab credentials, redaction contract |
| [evidence/](https://github.com/het-p301204/afterlife/blob/main/evidence) | sanitized sample telemetry, उससे उत्पन्न alerts, और state audit |

---

## Research references

2026-09-11 को primary sources के विरुद्ध verified। **VERIFIED** का अर्थ है कि vendor की स्वयं की advisory पढ़ी गई; **REPORTED** का अर्थ है कि विवरण vendor के बजाय किसी vulnerability database से आया है।

**Standards and classifications**

* [OWASP Top 10:2025 — A07 Authentication Failures](https://top10.owasp.org/2025/A07_2025-Authentication_Failures) — ठीक इसी विफलता का वर्णन करता है: ऐसे applications जो "correctly invalidate user sessions or authentication tokens" नहीं करते। इसकी CWE mapping में नीचे दिए गए तीनों शामिल हैं।
* [RFC 9700](https://datatracker.ietf.org/doc/rfc9700/) — *Best Current Practice for OAuth 2.0 Security* (BCP 240, January 2025)। इस lab के दो आधार: rotated refresh token का reuse चोरी का संकेत देता है (AFTERLIFE-002), और **revocation को पूरे token family को invalidate करना चाहिए, केवल वर्तमान token को नहीं** — जो AFTERLIFE-001 की thesis है, IETF practice के रूप में codified।
* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) — credential और security परिवर्तनों के बाद session invalidation
* [CWE-613: Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) — *"permits an attacker to reuse old session credentials or session IDs for authorization"*। नीचे दिए गए तीनों CVEs इसी class में filed हैं।
* [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)
* [CWE-384: Session Fixation](https://cwe.mitre.org/data/definitions/384.html) — adjacent: एक session identifier जो authentication state परिवर्तन के बाद भी जीवित रहता है

**The pattern this lab reproduces**

* **VERIFIED** — [GHSA-hvp3-26wx-g2w4](https://github.com/strapi/strapi/security/advisories/GHSA-hvp3-26wx-g2w4) / [CVE-2026-22706](https://github.com/advisories/GHSA-hvp3-26wx-g2w4), *Strapi: Password Reset Does Not Revoke Existing Refresh Sessions*. `@strapi/admin` और `@strapi/plugin-users-permissions` ≤ 5.33.2; 5.33.3 में fixed। CVSS v4.0 **2.1 (Low)**, `AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N`. Published 2026-05-13.
  Vendor advisory बताती है कि refresh-token invalidation step caller-supplied `deviceId` पर conditional था, और patch हर password change तथा reset पर सभी refresh tokens को invalidate करता है, चाहे `deviceId` दिया गया हो या नहीं। वही conditional है जिसे `_revoke_for_security_change` model करता है, और वही patch है जिसे fixed mode implement करता है।
  Vendor context: [Strapi security disclosure, May 2026](https://strapi.io/blog/security-disclosure-of-vulnerabilities-cve-2025-64526-cve-2026-22599-cve-2026-22706-cve-2026-22707-and-cve-2026-27886).

**The same class, different mechanisms**

* **REPORTED** — [CVE-2026-1163](https://nvd.nist.gov/vuln/detail/CVE-2026-1163), parisneo/lollms. Password reset पर session invalidation *बिल्कुल नहीं*, 31-दिन के default session lifetime के साथ। इस bug का सरल संस्करण — और वही जिसे naive detector वास्तव में पकड़ लेगा।
* **REPORTED** — [CVE-2026-40934](https://nvd.nist.gov/vuln/detail/CVE-2026-40934), Jupyter Server ≤ 2.17.0 (fixed 2.18.0)। Cookie-signing secret एक static file में persist किया जाता है और password change पर कभी rotate नहीं होता, इसलिए reset से पहले जारी किए गए cookies उसके पार cryptographically valid बने रहते हैं। इसी परिणाम तक पहुँचने का तीसरा रास्ता: यहाँ *credential* इसलिए valid है क्योंकि *key* कभी नहीं बदली, जो [docs/tradeoffs.md](https://github.com/het-p301204/afterlife/blob/main/docs/tradeoffs.md) में Option D का failure mode है।

तीन products, तीन mechanisms — एक conditional parameter, एक missing call, एक unrotated key — एक परिणाम: reset सफल हुआ और attacker बना रहा।

---

<div align="center">

**The attacker is not detected because their request looks malicious.**

उनकी हर request well-formed थी, सही ढंग से signed थी, और एक ऐसा credential लेकर आई थी जो server ने अभी उनके लिए mint किया था।

**They are detected because a credential lineage that should have died at a security event was accepted after it.**

<br>

<sub>MIT · a local lab · nothing here is safe to deploy</sub>

</div>