Guide · Compromised credentials
Responding to compromised credentials: the seven steps
A “compromised credentials” alert arrives, from a monitoring service, a partner or an article. Here, in order, is what a security team must do in the following hours. A “compromised credentials” alert arrives, from a monitoring service, a partner or an article. Here, in order, is what a security team must do in the following hours, and what can wait.
- Guide
- Guide
- Steps
- 7 ·9 min read
- Published
- Last updated
In one sentence
Faced with compromised credentials, you qualify the leak, contain the access, look for reuse and origin, check whether it was already used, then notify and document.
A compromised credential is not an incident in itself: it is a key in circulation. The incident begins when someone uses it. The whole response therefore consists of shortening the time between circulation and revocation, and checking that the key has not already turned in the lock.
The steps below apply to a work address as well as to a service account; they distinguish two very different origins, a third-party database breach and an information-stealer log, because the second means a device is infected.
Steps
The seven steps, in order
- 01
Qualify the alert
Record the source, the collection date and the type of leak. Check whether the credential is still active, whether a password appears in the leak and whether it complies with your current policy. A password in an old format, on a disabled account, does not call for the same response as a compliant password on an administrator account.
The collection date matters more than the publication date: an old breach republished in a combolist is not a new exposure.
- 02
Contain the access
Reset the password, revoke open sessions and application tokens, force re-enrolment of the second factor if the attacker may have registered one. Do it for the account concerned and for every account using the same password.
- 03
Look for reuse
A password leaked from a third-party service has often been reused on email, the VPN, a partner extranet or a legacy application without a second factor. Ask the person, check the service accounts they administer and forgotten historical access.
- 04
Determine the origin
Third-party breach: the risk is reuse. Information-stealer log: a device was infected, and everything typed on it (passwords, cookies, forms) is exposed. In that second case, isolate the device, reinstall it and change every password used on it, personal ones included.
- 05
Check whether it was already used
Re-read the authentication logs since the collection date: logins from unusual countries or providers, failures followed by a success, mailbox forwarding rules created, devices added, OAuth tokens granted. A discreet forwarding rule is the most frequent sign of an account already exploited.
- 06
Notify and document
If personal data may have been accessed, the GDPR requires notifying the supervisory authority within 72 hours of becoming aware. Depending on your status, NIS2 provides for an early warning within 24 hours. Inform your cyber insurer as the policy requires. Record the timeline: the auditor, and if need be the investigation, will use it.
- 07
Prevent the next one
Password manager deployed, phishing-resistant second factor on sensitive access, service accounts inventoried, and continuous monitoring of leaks tied to your domains so that the next alert arrives before use, not after.
Third-party breach or stealer log: two different situations
A third-party breach exposes what the compromised service stored: an address, often a hashed password, sometimes a cleartext one. The risk lies in that password being reused elsewhere. The response is a password change wherever it was used.
An information-stealer log exposes what an infected device saw: every credential typed, every session cookie, the forms saved in the browser. The credential is only a symptom; the problem is the device, often a personal one, on which the person logged in to your services.
What external monitoring brings to each step
Qualification is where time gets lost. Continuous monitoring delivers the alert already tied to an identity, dated, deduplicated, with the leak type and whether a password was present: step 1 is done before the alert arrives.
It also makes it possible to tell a third-party breach from a stealer log at once, and to see the other credentials and sessions exposed from the same device, turning an isolated reset into a complete treatment.
Frequently asked questions
Should we reset the password if the leak is old?
Yes, if the exposed password is still valid or may have been reused. The age of the leak says nothing about the age of the password. If the account is disabled and the password has changed since, document and close.
Does the second factor protect us completely?
It blocks simple reuse of a password, not the replay of a session cookie stolen from an infected device, nor legacy applications that lack it. Check both cases.
Should we tell the person concerned?
Yes, and quickly: only they know where the password was reused, and whether the device concerned is personal. Say it without blame; reuse is the norm, not the exception.
How long should we keep the evidence?
At least as long as your incident-management policy and sector obligations require. Keep the timeline, the extracted logs and the decisions taken, not the password itself.
Know before use, not after
An exposure assessment shows, on your real domains, which credentials already circulate and which ones still open an access.
Bespoke offering: one price per service, no public price, no packages.