Predictable RNG → forge password-reset tokens

§ Context

Assumed environment: a self-hosted Node / Java / PHP app uses non-cryptographic RNG for security-sensitive tokens. Attacker can register accounts to obtain reset-token samples.

§ Steps

1. 01
   Account takeoverInitial Access

   T1078— Valid Accounts
2. 02
   Request password reset for victimInitial Access

   T1078— Valid Accounts
3. 03
   Collect several reset tokens from attacker accountsInitial Access

   T1078— Valid Accounts
4. 04
   Submit predicted token + new passwordPersistence

   T1098— Account Manipulation
5. 05
   Predict next token for victim accountCredential Access

   CR-WEAK-RNG— Predictable Random Number Generation
6. 06
   Reverse RNG internal state (mt-extractor)Credential Access

   CR-WEAK-RNG— Predictable Random Number Generation

§ References

• T1078Valid Accounts
• T1098Account Manipulation

§ Frequently asked

What is the "Predictable RNG → forge password-reset tokens" attack path?

App generates reset tokens via Math.random / Mersenne Twister seeded with time(). Capture a few legit tokens, recover the internal state, predict the next token for any user. It chains 6 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Account takeover (T1078) — a initial access primitive. Assumed environment: a self-hosted Node / Java / PHP app uses non-cryptographic RNG for security-sensitive tokens.

What is the final impact of this kill-chain?

The final step lands on Reverse RNG internal state (mt-extractor) (CR-WEAK-RNG), which falls under Credential Access. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques2

  Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)

  Identify an Okta admin via LinkedIn. Vish the helpdesk pretending to be that admin, get MFA reset. Sign in, plant attacker MFA factor, then push policy changes that disable MFA for chosen apps before mass-deploying ransomware.

• Shared techniques2

  Flash-loan governance attack → DAO admin

  Voting power = token balance at snapshot. Borrow enormous quantity via flash loan inside the snapshot tx, vote yourself in as admin, repay loan.

• Shared techniques2

  Vishing → helpdesk MFA reset → account takeover

  Pose as a panicked employee locked out before a meeting. Helpdesk resets MFA based on partial PII (employee ID + date of birth from LinkedIn). Attacker registers their own factor.

• Shared techniques2

  MFA fatigue / prompt-bombing → M365 admin compromise

  Attacker has the password (from breach / spray) but not MFA. Spam push approvals at 2 AM until the user taps yes out of habit — used in the Uber and 0ktapus breaches.