Compromised Client Credential Monitoring
Account Takeover Starts With a Leaked Login.
When a customer’s device is infected, every login saved in its browser goes into an infostealer log, including the one for your portal.
The platform finds the leaked credentials that open your services and records each one with the exact URL, the username and the service behind it. Your fraud and identity teams work each record through tracked states.
SourceInfostealer log · saved logins
Targetlogin.acme.example
Your service
https://login.acme.example · j.(masked) · email
Target service · MFA by default
State marked_as_resolved
https://login.acme.example · c.(masked) · username
State marked_as_resolved
Filter target.domain eq acme.example · state eq newly_detected
Action search:mark-resolved
Not a match
https://mail.other.example · (masked) (not a match)
https://social.example · (masked) (not a match)
https://portal.other.example · (masked) (not a match)
The Leak Happens Somewhere Else.
Your authentication can be sound and customer accounts still get taken over. The credentials come from places you don’t control.
Source
Infected Customer Devices
A personal machine your security team never sees. The infostealer on it takes your login along with all the others.
Reuse
Passwords Used Twice
A password leaked from another service works on yours when the customer reused it.
Impact
Fraud That Looks Legitimate
A takeover with a valid password looks like a normal sign-in. It tends to surface later, as a chargeback, a support ticket or a complaint.
Each Login Is Tied to Its Service.
| URL | The exact address the login was saved for, such as a sign-in page on one of your domains |
|---|---|
| Username and type | The identifier, marked as an email address or a username |
| Target service | The domain, host and service the URL belongs to, with its platform |
| Category | A main and sub category for the target service |
| Risk tier | The risk tier of the target service, where one is assigned |
| MFA by default | Whether the target service requires MFA by default |
| Added date | When the record was added |
| State | Where the record stands in your workflow |
Fields as documented in the Compromised Client Credential Search reference.
login.acme.example
Client credential
-
1Your service CTIthe URL the login was saved for:
URLhttps://login.acme.example
-
2A customer’s login CTItaken from an infected device:
Usernamej.masked · email
-
3Filter on ittarget.domain eq acme.example:
Target servicedomain acme.example · host login.acme.example
The record tells you which account and which service. The response is yours.
Record openednewly_detected
What Fraud Teams Do Next.
The record tells you which account and which service. The response is yours, and it usually looks like this.
Force a Reset
Invalidate the password on the affected account and require a new one at the next sign-in.
Revoke Sessions
End active sessions for the account. The infection may have taken its cookies along with the password.
Add Friction
Step up authentication or hold high-risk transactions on the account until the customer confirms.
Tell the Customer
If the login came from an infected device, the other logins on it are exposed too. The cleanup happens on their side.
Each Record Carries a State You Can Change by Filter.
New records arrive as newly_. From there your team resolves them, accepts the risk, ignores them or marks them false positive, and the state is kept on each record for search and export.
Actions apply by filter, so one request can resolve all credentials for one service, or ignore all records for a host you have already retired. A revert returns records to their previous active state.
| newly_detected | Found, not yet reviewed |
|---|---|
| unresolved | Open |
| marked_as_resolved | Marked fixed by your team |
| risk_accepted | Known and accepted |
| ignored | Set aside |
| marked_as_false_positive | Not a real exposure |
Work the Queue From Your Tools.
Search, export and all state changes are in the CTI API. Bulk actions take the same filter as search, so what you review is exactly what you change.
curl -X POST \
"https://api.deepinfo.com/v1/cti/compromised-client-credentials/search" \
-H "apikey: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d @filter.jsoncurl -X POST \
"https://api.deepinfo.com/v1/cti/compromised-client-credentials/search:mark-resolved" \
-H "apikey: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d @filter.json{
"filters": {
"must": [
{ "name": "target.domain", "type": "eq", "value": "acme.example" },
{ "name": "state", "type": "eq", "value": "newly_detected" }
]
}
}Query This Data Through the API
Credentials and dark web findings stay in the platform. The domain and vulnerability data around them is open through the API.
Questions About Compromised Client Credential Monitoring
Where do client credentials come from?
From leaked credential data, including infostealer logs from infected customer devices. Each record keeps the URL the login was saved for, which is what ties it to your service.
Do we need to review every record by hand?
No. State changes take a search filter, so all records for one service, host or domain can be resolved, ignored or risk-accepted in one request, and reverted the same way.
Does the platform close a record on its own?
No. Records stay active as newly_ or unresolved until your team closes them: marked as resolved, risk accepted, ignored or false positive.
Can we see how the exposure has grown?
Yes. Client credential statistics return the total number of records, the date of the first exposure and a count per year, through the CTI API.
Can we export the records?
Yes. Each search has an export twin that returns all matching records without pagination, as CSV or JSON.
See Which Customer Logins Are Already Out There.
Book a demo and we’ll scope client credential monitoring to your login domains and walk through the workflow with your fraud team.