What is Rainbow Table?

What a rainbow table stores

Cracking a hash means finding an input that produces it. The plain way is to hash guesses until one matches, and that costs the same CPU time on every attack. The opposite extreme is to hash every possible password once, keep the results in a sorted list and look hashes up, which is instant and needs more disk than anyone owns. Martin Hellman described the middle path in 1980: a time-memory trade-off that stores only part of the precomputed work. Philippe Oechslin's 2003 paper, Making a Faster Cryptanalytic Time-Memory Trade-Off, is where rainbow tables come from. He demonstrated it on MS-Windows password hashes: 1.4 GB of tables cracked 99.9% of all alphanumeric password hashes (about 137 billion of them) in 13.6 seconds, against 101 seconds for the previous method.

A table stores chains, not passwords. A chain starts at one password, hashes it, applies a reduction function that turns the hash into a new candidate password (it is not an inverse of the hash, just a way to land on another plausible password), hashes that, reduces again, and repeats for a fixed length. Only the first and last password of each chain are kept. The rainbow part is that every column uses a different reduction function, so two chains that collide at different positions do not merge and waste space.

A table you can run in your head

Simulated example generated by SOCSimulator Research. The passwords are four-digit PINs and the hash is SHA-256. The reduction function reads the first 8 hex digits of the digest as a number, adds the column number and keeps the last four digits.

chain  start   after R1   after R2   after R3 (end)   stored
A      0420    1944       4236       4059             0420 ... 4059
B      1999    9734       2228       7838             1999 ... 7838
C      5150    8551       1405       9436             5150 ... 9436

Twelve passwords are covered and six numbers are stored. Now crack a hash whose SHA-256 starts with f513a0aa.

1. Assume the hash sits in the last column. Reduce it with R3 and you get 4237, which is not an end point.
2. Assume it sits one column earlier. Reduce it with R2 and you get 4236. Hash that, reduce with R3, and you land on 4059, the end of chain A.
3. Rebuild chain A from 0420. Its second password is 1944, and the SHA-256 of 1944 starts with f513a0aa. The password is 1944.

Sometimes an end point matches and the rebuilt chain does not contain the hash. That is a false alarm and the search moves on to the next column. Real tables use far longer chains over far bigger password spaces, but the mechanics are the same.

Why a salt ends the attack

The table only works if the same password always produces the same hash. A salt is a random value stored next to the hash and mixed into it, so one password hashes differently for every user. OWASP names two benefits: salting stops an attacker from using precomputed lookup tables such as rainbow tables, and it hides whether two users share a password.

Same password, four stored values (simulated, shortened):

The SHA-256 rows only illustrate the idea. OWASP says fast algorithms like SHA-256 are not suitable for password storage and recommends Argon2id, bcrypt or PBKDF2 with a unique salt per password.

The last row is the one that matters on Windows. Microsoft's NTLM specification defines the NT hash as NTOWFv1(Passwd, User, UserDom) = MD4(UNICODE(Passwd)). The function takes the user and domain as arguments, but its definition hashes only the password. The NT hash of Summer2026! is therefore identical on every account, every machine and every domain, so one table serves all of them, and two equal hashes in a dump mean two equal passwords.

What a SOC sees, and what it does not

Cracking is offline. No login is attempted, so there is no 4625, no lockout and no Entra ID error to alert on. Brute force against a live service writes a record for every miss. A rainbow table writes nothing. MITRE files it as T1110.002 Password Cracking and notes that hashes alone only get an attacker so far when pass the hash, a lateral movement technique, is not an option. A plaintext password works where a hash never will, such as a VPN portal or a cloud sign-in, and that is what cracking buys.

So you detect the steps on either side of it.

Before: stealing the hashes. This is where a hunt and your EDR earn their keep.

• A process opening lsass.exe. The Sysinternals documentation says Sysmon Event ID 10 (ProcessAccess) exists to detect tools that read the memory of processes like Lsass to steal credentials.
• A copy of the Active Directory database. MITRE T1003.003 describes attackers accessing or creating a copy of Ntds.dit, which lives by default in %SystemRoot%\NTDS\.
• DCSync, where an attacker asks a domain controller to replicate password data. The request needs the Replicating Directory Changes and Replicating Directory Changes All rights, and event 4662 records them by GUID. It is only written if the domain object has an audit entry (SACL) for the operation.

// DCSync: replication rights used by an account that is not a domain controller
SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4662
| where Properties has_any ("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
                            "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2")
| where SubjectUserName !endswith "$"
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName,
    SubjectLogonId, AccessMask
| order by TimeGenerated desc

The two GUIDs are the rights GUIDs Microsoft publishes for DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Domain controllers replicate with their machine accounts, which end in $, so a user account asking for them deserves a look. The query follows the documented SecurityEvent schema and has not been run against a live workspace by SOCSimulator.

After: using the cracked password. The first use is an ordinary successful sign-in, from an address the account has not used before. That is the case password spraying, credential stuffing and MFA already cover: a second factor is what turns a cracked password into a nuisance.

Defending your own hashes

• A unique random salt per password and a slow hash, as OWASP recommends. Both are on whoever builds the application, not on the SOC.
• Where the format is fixed, as with the NT hash, length and uniqueness are the only levers. Each extra character multiplies the search space by 95 for printable ASCII: 95^8 is about 6.6 × 10^15 and 95^12 is about 5.4 × 10^23. A table is built for one password space and says nothing about a longer one.
• Limit who holds replication rights and who can read LSASS (least privilege), because stealing the hashes is the part you can see.