Fullz

A fullz is not a leaked password. That distinction sounds pedantic and it decides which of your logs the fraud will appear in. A credential lets somebody into an account that already exists, and it shows up in authentication telemetry: an impossible login, a new device, a failed MFA prompt. A fullz lets somebody open a new one in another person's name, and it shows up nowhere near authentication, because from the system's point of view nothing suspicious happened. A real-looking person applied for something.

What is actually in one

The word is a contraction of "full information", and the completeness is the product. A record advertised as fullz is expected to carry enough of one person to satisfy an onboarding form without a human ever asking a follow-up question:

• Legal name, date of birth and current address, usually with a previous address
• A national identifier: a Social Security number, a national ID number, a tax number, whatever the target country's institutions key on
• Phone number and email, ideally ones the person still uses, because a one-time code has to land somewhere reachable
• Banking or card details, sometimes with the issuing branch
• Answers to the security questions a bank still asks: mother's maiden name, first school, first car
• In the more expensive listings, a photograph of an identity document, which puts the record close to a KYC pack

Sellers price by completeness and by country. That is a structural fact rather than a claim about any particular market: a record missing the national identifier cannot be used for the thing fullz are bought for, so it is worth less than one that has it.

Assembled, not leaked

Here is the part that changes how you investigate. A fullz record is usually not lifted whole from one breach. It is stitched together. A name and address from a marketing database, a national identifier from an old healthcare or payroll compromise, a phone number from a stealer log taken off the person's own laptop, a security answer from a forum profile they filled in a decade ago. The seller's work is the correlation, not the theft.

This is why the instinct to find "the breach that leaked this" so often fails. There may not be one. A record can be complete without any single source of it having been complete, and the sources can be years apart and in unrelated sectors. Treating a fullz listing as evidence of one incident sends an investigation looking for something that never happened.

What it is reliable evidence of is that somebody found your customers worth assembling. That is a statement about targeting, and it is worth reacting to on its own.

What it is bought for

New-account fraud, mostly. Credit applications, loan applications, mobile contracts, cryptocurrency exchange onboarding, government benefit claims. Anywhere identity is proven by knowing facts about a person rather than by holding a credential belonging to them.

The second use is quieter and worse for the victim: a fullz makes social engineering nearly frictionless. Someone who can recite your date of birth, your last address and the last four digits of your account is not a stranger to a call centre. They are you, having a bad day and needing a password reset.

Where a defender should be looking

The detection surface is onboarding, not authentication. If your fraud programme watches logins and your identity programme watches applications, fullz-driven fraud lands in the second one and the first one will stay green throughout.

• Watch new-account and application flows for identity data that is correct but behaviourally odd: a correct address paired with a device that has never been near it, an applicant whose details are perfect and whose typing cadence says the form is being pasted
• Treat the appearance of your customer base in fullz listings as an upstream signal, not as the incident. The fraud you can see is downstream of a leak that already happened, possibly not at you
• Do not assume a single source. Correlate across the sectors your customers also transact in before concluding your own systems leaked anything
• Ask the boring question about your own onboarding: which fields do you actually verify, and which do you merely collect? A fullz is priced to defeat the second list

The uncomfortable conclusion is that the cost of an identity is set by how many institutions accept knowledge of it as proof of it. That number is not yours to change alone, but the part of it inside your own onboarding flow is.

Connected terms

Read elsewhere

• MITRE ATT&CK T1589.001: Gather Victim Identity Information: Credentials