The alert everybody files as a success
Somewhere in your authentication logs this month there is an event that reads like this: the password was accepted, the second factor was not satisfied, and the login was refused.
Almost every organisation reads that as good news. MFA did exactly what it was bought to do.
But look at the first half of it again. The password was accepted. Somebody typed it correctly. That much is not in question — and it is the half of the event nobody goes back to.
The second factor held. The first one didn’t. Only one of those facts gets acted on.
Often there is a dull explanation. A flat battery, a mistyped code, a prompt that timed out, somebody who started signing in and wandered off. But a correct password followed by a failed second factor is also one of the strongest early indications available that the first factor is no longer private — and which of the two it is depends entirely on what surrounds it. Filed under MFA working, nobody ever asks.
Why that one event carries so much weight
Because of what comes before it. A password is phished in March, or reused from a breach at a company you have never heard of, or bought in a list alongside forty thousand others — and then nothing happens at all.
The account works. The real user signs in every morning. There is no failed logon to investigate and no anomaly to score, because a stolen password behaves exactly like a real one right up until somebody tries to use it.
Most compromised credentials are found at the very end of that line, when they are finally used to do something visible. The giveaway sign-in is usually the only earlier opportunity there is.
When somebody else already knows it leaked
There is one thing that can see into that dormant stretch, and it isn’t your own data. Threat intelligence feeds collect credentials as they surface — dark web and deep web dumps, paste sites, the output of an infostealer — and a good feed will tell you that accounts in your domain appear in one.
Mirket integrates that intelligence. The question is what to do with it, and this is where most programmes lose.
A feed produces a list. Several hundred credentials matched to your domain, arriving as a report. Somebody now has to work out which are still current, which were rotated a year ago, which belong to people who have left, and which were never yours to begin with. The team triages, and most of what they triage turns out to be nothing — not because the intelligence was wrong, but because a leaked credential only matters if it still works and somebody still tries it.
Mirket doesn’t hand the list to a person. It arms the authentication. A credential known to be compromised is blocked at the moment somebody signs in with it. The intelligence stops being a ticket and becomes a condition on a login.
- The action lands where the risk is A leaked credential nobody attempts costs nobody any attention. One that is attempted is stopped in the attempt rather than investigated afterwards.
- The triage step disappears A list can't tell you which entries matter. A sign-in can — somebody is using this credential, now, against your environment. Entries nobody tries never become work.
- Nobody has to be awake The block happens in the authentication path, so it holds at three in the morning on a Sunday exactly as well as it does during a shift.
The cost of being wrong stays small and familiar: if the blocked credential really did belong to the person, they set a new password. That is the same asymmetry that makes the rest of the automatic responses safe to leave on.
Read the phase off the authentication result
Mirket doesn’t infer the stage of an attack from behaviour. It reads it from what the authentication actually returned.
Each phase is a different problem. Phase 1 is somebody looking for valid usernames. Phase 2 is somebody trying passwords against a name they have. Phase 3 is a sign-in where the right password was supplied — and whether the login then succeeded or the second factor stopped it, the first factor has stopped doing any work.
Phase 3 is the one worth acting on
When the first factor succeeds and the second doesn’t, Mirket can raise identity breach suspected. The word suspected is doing real work there. What the event establishes is narrow and certain: the password was valid. How far that should be read as compromise is decided by everything around it — the origin, the account’s own history, and whether anything else fired at the same time.
- What the event establishes The password was correct, and whoever supplied it did not complete the second factor. That may be the owner having a bad morning. It may be somebody who only ever had the first half.
- What it justifies Treating that password as a candidate for reset on the strength of this event alone, rather than waiting for a second system to confirm a breach later.
The other half of phase 3 is the login that did succeed, from an origin that should give pause — a known-malicious address, a Tor exit node. There the credential and the second factor are both in play, and the response is correspondingly heavier.
The routes that never fail a password at all
The phases above assume somebody is trying to authenticate and getting part of the way. Two of the most effective takeovers skip that entirely — and each is visible for a different reason.
Becoming the second factor
The cleanest way past a second factor is to own one. Somebody holding a working password starts an enrolment — registering a new device against an account that belongs to somebody else — and if it completes, they hold both halves. Nothing about their next sign-in looks unusual, because by then nothing about it is unusual.
So enrolment is guarded as an event in its own right. An enrolment attempt made by somebody other than the person it was issued to raises an alarm, including the case where a registration link sent by email is picked up and used by a second party. What a legitimate re-enrolment has to satisfy is on Secure Self-Service.
Taking the session instead of the credential
The other route never touches the password. A relay page sits between the user and the real sign-in, the user authenticates perfectly, and what the attacker walks away with is the session that comes out of it — already past both factors. No failed login is produced anywhere, because nothing failed.
What gives it away is where that session is used next. A session established from one machine and then presented from a different origin, on a device that doesn’t match the one it was issued to, is a detection in its own right — and one of the few that matters more when everything before it went right.
Where it came from changes the reading
The same authentication stage means different things depending on where it arrived from, so origin is scored as its own dimension. Mirket classifies each source into families:
- Known-malicious Addresses already attributed to attack infrastructure. Highest confidence of the reputation families.
- Tor An exit node. Very few legitimate workforce sign-ins arrive this way.
- VPN and proxy Deliberately anonymised — and also what a lot of ordinary people use. Weighed, not assumed.
- Cloud and hosting A datacentre or hosting range. Ordinary for a service, unusual for a person at a laptop.
- Low reputation Suspicious without attribution. Scored with lower confidence, deliberately.
So password correct, MFA blocked, from a known-malicious address and password correct, MFA blocked, from a cloud range are two different detections with two different weights — rather than one alert with a severity dropdown.
When the two factors disagree about where you are
Origin is usually read once, from wherever the sign-in arrived. But a Mirket sign-in has two halves and each of them has a location: the machine typing the password, and the phone approving it.
When those two sit in different countries at the same moment, the story doesn’t hold together — even if both halves succeed. Either the password is being used by somebody who isn’t holding the phone, or the phone isn’t with the person it belongs to. It is one of the few checks that gets sharper rather than weaker when the login works.
The detections that ignore the origin entirely
Three families of detector fire on pattern alone, whatever the source address looks like.
| Volumetric | A single source probing several unknown usernames · repeated consecutive failures against one account · a success arriving immediately after a burst of failures. Thresholds, not judgement |
| Deception | A planted decoy password has no legitimate authentication purpose, so a single submission is hard to account for innocently. It carries the highest certainty score in the system, and points to credentials having been harvested somewhere earlier |
| Behavioural | A clustering model learns each account’s own pattern: an unusual ratio of second-factor failures, a sudden spread of source addresses, or two sign-ins separated by more distance than the time between them allows |
The last two are the subject of User Behaviour Analytics, which covers how a per-account baseline is built and why a decoy needs no baseline at all.
What the identity does once it is inside
Everything above is about getting in. The second half of the job is noticing an identity being used badly afterwards — and because this is an authentication-layer engine, it is worth being exact about what that does and doesn’t reach.
Privilege escalation is visible, because Mirket challenges it. Where the platform protects privilege elevation, raising rights is itself an authentication event: a user signed in under one account who tries to act as another — runas and UAC on Windows, sudo or su on Linux — meets a second factor. So somebody who has taken over one account and then reaches for a more powerful one produces exactly the shape the engine reads: an elevation to an account this identity has never elevated to, failing the challenge.
Lateral movement is visible as far as it authenticates. One identity appearing across the systems that authenticate through the platform, from a spread of origins it has never used, or in two places that cannot both be true, is the shape of a credential in more hands than one.
What isn’t visible is anything that never authenticates. Mirket does not inspect network traffic and does not watch file access. At the identity layer it complements network and endpoint detection rather than replacing either, and it shouldn’t be bought as though it did.
Two scores, because there are two questions
Every detection carries a threat score and a certainty score, and they are deliberately not blended.
| Threat | If this detection is right, how bad is it? A decoy password being used is as bad as it gets. A blind username probe is not |
| Certainty | How sure is the detection itself? A decoy hit is about as certain as this gets. A low-reputation address is a hint |
The pair decides the response. High threat with high certainty can be acted on without a person in the path. High threat with low certainty raises the authentication requirement instead of blocking, because the cost of being wrong is one extra prompt rather than an outage. Low threat with high certainty is recorded and left to policy.
A single blended number cannot express that, which is why a lot of detection ends up either ignored or over-enforced.
The answer is the reset, not the alert
This is where credential detection differs from most detection. The thing that has gone wrong is an object, and objects can be replaced. An alert replaces nothing.
- Force a password reset The direct answer when the credential itself is the problem — which, in phase 3, it usually is. The old value stops being a credential the moment the new one is set.
- Isolate the account Shut it out of the platform entirely while somebody looks. The right call when the picture is worse than a single suspect password.
- Raise the requirement Ask for a tougher method next time instead of resetting — proportionate when the signal is serious but the confidence behind it is not.
The argument for automating it is entirely about timing. Between the giveaway and the successful use there is a window, and it is the only part of a stolen credential’s life anybody can do anything about. A response that waits for somebody to read a queue spends that window in the queue.
Scoped to one account, which is what makes it usable
A response that hurts gets switched off. The reason a forced reset can be left on automatic is that it lands on one person and nobody else notices.
That user sets a new password themselves through Secure Self-Service, after passing a second factor — no ticket, no waiting for somebody in another time zone. The forbidden-password controls apply to the replacement, so the new one isn’t a variation on the old.
And if the detection turns out to have been the owner with a flat battery, the cost of being wrong is that somebody set a new password. That asymmetry is the whole reason this can run without a human in the path.
The passwords that can’t be compromised
Detection exists because passwords do, and the number of credentials that can be stolen is not fixed:
| A password that is never typed | On Windows and Linux logon, SSH and sudo, users can authenticate with a Mirket method instead of a password — nothing to phish at the keyboard. Passwordless Authentication |
| A password nobody knows | Through PAM, the credential for a target system is injected into the session rather than shown, so the administrator never holds it. Privileged Password Vaulting |
| A password that changes before it’s worth anything | Service accounts authenticate with a scoped virtual credential while the real one rotates on a schedule, without touching the application. Service Account Password Rotation |
Detection is what you need for everything left over — which, in most estates, is still most of it.
Where this runs
This is an ITDR capability, and ITDR is a service. The detections feed on sign-in activity the workforce modules generate, which means they apply wherever those modules run as a service — nothing to install, nothing to forward, no schema to reconcile.
Choose to run everything on your own hardware and that activity never leaves your estate, which is the point of choosing it. The consequence is that this layer has nothing to read. Deployment puts both options side by side.
What changes with Mirket
| Before | With Mirket |
|---|---|
| A blocked MFA login is filed as a success | The valid first factor is read as a signal in its own right, and scored in context |
| A stolen credential surfaces when it is finally used for something | It surfaces at the first authentication event that reveals it |
| Detection depends on somebody noticing a pattern | The phase is read from the authentication result itself |
| All suspicious origins look alike | Malicious, Tor, VPN, cloud and low-reputation are weighed separately |
| One risk number against one threshold | Threat and certainty are scored apart, and the response follows the pair |
| Retiring one password means raising a ticket | A forced reset fires on that account automatically |
| A reset means a call to the help desk | The user sets a new one themselves after a second factor |
| Leaked-credential intelligence arrives as a list to triage | It is applied in the authentication path and blocks the sign-in |
Frequently asked questions
What is account takeover detection?
Spotting the point at which somebody other than the account's owner may have what they need to sign in. Mirket reads that from the authentication result itself rather than from behaviour inside an application — the moment worth reading is when the first factor is accepted, because that is the point at which the password has demonstrably worked for whoever supplied it.
Why is a blocked MFA login a warning rather than a success?
Because the password was correct. The block is the second factor doing its job, but the attempt still got through the first one. Sometimes that is innocent — a flat battery, a mistyped code, a prompt nobody answered. Sometimes it is the earliest indication available that a password is no longer private. Filed as MFA working, it is never revisited either way.
How can you tell a password has been stolen if nobody has used it yet?
You usually can't, and no product should claim otherwise. What can be caught are the moments a stolen copy surfaces — a sign-in where the password is accepted but the second factor isn't, a burst of prompts nobody asked for, an attempt arriving from an origin the account never uses, or a planted decoy being submitted. The aim is to reach the password while it is still only a copy.
What does Mirket actually read?
Authentication events the platform is already producing — RADIUS, Outlook Web Access, ADFS and the self-service portal. It is an authentication-layer detection engine: every detection is keyed to a sign-in attempt. There is no separate collector and no log shipping to configure.
Does the origin of the attempt change the result?
Yes, substantially. The same authentication stage reached from a known-malicious address, a Tor exit node, a VPN or proxy, a cloud-hosting range, or a merely low-reputation address produces a different pair of scores. An anonymised origin settles nothing by itself — plenty of ordinary people use a VPN — but it changes how much the rest of the attempt has to account for.
How does Mirket detect password guessing and enumeration?
With volumetric rules that do not depend on the origin at all: a single source probing several unknown usernames, repeated consecutive failures against one user, and a success arriving straight after a burst of failures. Each has a threshold rather than a judgement.
Which detection is the most reliable?
Anything involving a planted decoy. A honeypot password has no legitimate authentication purpose whatsoever, so somebody submitting one is hard to account for as ordinary use, and it points to credentials having been collected somewhere they shouldn't have been. User Behaviour Analytics covers how the bait is placed and why it scores the way it does.
Does Mirket use machine learning?
Yes. Every account carries its own learned model of how it normally authenticates, and the risk scores are produced by that model rather than read off a table. It also catches the attacker who deliberately stays quiet — someone pacing their attempts to sit under whatever number a counter is watching. User Behaviour Analytics covers what the model learns and what it does with it.
Can Mirket detect privilege escalation?
Yes, because elevation is an authentication event here. Where Mirket protects privilege elevation, a user signed in as one account who tries to act as another — runas or UAC on Windows, sudo or su on Linux — has to satisfy a second factor. An elevation to an account that identity has never elevated to, failing that challenge, is the pattern a compromised account produces when it reaches for more.
Can Mirket detect lateral movement inside the network?
As far as it authenticates. Mirket sees one identity being used across the systems that authenticate through the platform — appearing from a spread of origins it has never used, or in two places that cannot both be true. It does not inspect network traffic or file access, so it complements network and endpoint detection rather than replacing either.
Can somebody bypass MFA by enrolling their own phone?
That is the attempt the enrolment controls exist for. An enrolment made by somebody other than the person it was issued to raises an alarm — including a registration link sent by email and then used by a second party. It is worth guarding precisely because a successful one leaves nothing else to detect.
What about a stolen session cookie, where the user authenticated correctly?
A relayed sign-in produces no failure anywhere, so there is nothing wrong with the authentication itself to find. What is detectable is the session afterwards: one established from a particular machine and then presented from a different origin, on a device that doesn't match the one it was issued to.
Does Mirket check the phone as well as the computer?
Both halves of a sign-in carry a location, and they are compared. A password typed in one country while the approval comes from a phone in another is a contradiction worth raising even when both halves succeed. The condition of the handset counts as well: a jailbroken or rooted phone no longer offers the protection it did on the day it was enrolled, and the score reflects that.
Why does each detection carry two scores instead of one?
Because severity and confidence move independently. A decoy credential being used is both extreme and about as certain as this gets; a sign-in from a low-reputation address may be worth noticing while settling very little. Blending them into a single number forces one threshold to serve two purposes. How the pair drives the response is on Adaptive Authentication.
Why force a password reset rather than raise an alert?
Because the password is the thing that has gone wrong, and an alert doesn't change it. A detection waiting in a queue arrives after somebody has had another attempt at the second factor. Where the signal is strong but not certain, the response can instead be a tougher requirement on the next sign-in.
Does a forced reset lock the user out?
It requires them to set a new password, which they can do themselves through Secure Self-Service after passing a second factor. Scoping the response to one account is what keeps it usable — a reset that needs a help-desk call simply gets postponed.
What if the detection is wrong and the user was legitimate?
They set a new password. That is the cost of being wrong in this direction, and it is deliberately small — which is what makes it safe to automate. Being wrong in the other direction leaves a valid credential in circulation, and that cost is not small.
Can Mirket tell me if our passwords appear in a breach dump?
Mirket integrates threat intelligence that includes leaked credentials from dark web and deep web sources, and it applies that intelligence where it counts: a credential known to be compromised is blocked at the point somebody signs in with it. That is deliberately different from being handed a list to work through — an entry nobody ever attempts never becomes work for anybody.
Doesn't threat intelligence generate a lot of false positives?
A list does, because a list cannot tell you which of its entries still matter. Much of what a team works through turns out to be a password already rotated, an account that no longer exists, or a record that was never theirs. Applying the same intelligence at the sign-in removes the triage step entirely — the only entries that ever surface are the ones somebody actually tried to use, and those are not false alarms by definition.
Why is ITDR only available as a service?
Because there is nothing for it to read otherwise. Every detection on this page is keyed to an authentication event, and those events only reach Mirket's own detection pipeline when the workforce modules are running as a service. Run them on your own servers and the sign-in records stay there, which is a legitimate choice — it simply leaves this layer out. Deployment sets out both shapes.
Related
Solutions — User Behaviour Analytics & Deception · MFA Fatigue Attacks · Adaptive Authentication · Passwordless Authentication
Products — Identity Threat Detection & Response · Secure Self-Service
Industries — Finance · Healthcare · Retail