MFA Fatigue, Service Accounts and Break-Glass in a Hybrid Estate
Meridian Public Services has 2,400 staff on hybrid Active Directory and Entra ID. All users are licensed for Microsoft Authenticator push, but number matching is not enabled. Last month 14 users received 20-40 push prompts in a 25-minute window; three approved, and one account then created an inbox rule forwarding finance mail to an external address. The SOC had no alert for repeated denied MFA prompts. Separately, an on-premises radiology scheduling application uses LDAP binds with a service account whose password has not changed in nine years; the account is in Domain Users but is a local administrator on two application servers. Two cloud-only break-glass accounts exist, but their credentials sit in the same password vault as a shared TeamViewer account, and one was used six months ago with no ticket. The CISO wants stronger resistance without breaking clinical scheduling, which runs 24/7.
1. Explain what happened in the push-prompt incident and rank the controls you would deploy. Why is number matching not sufficient on its own?
Read the worked answer
The attacker already had valid passwords, probably from password reuse or a prior phishing page, and triggered repeated push prompts to wear a user down. The approval is a human decision, so the weakness is user judgement under fatigue, not the cryptography of the push. Three approvals out of 14 targeted users is enough; the inbox rule shows the attacker obtained a session and used it for business email compromise rather than lateral movement.
Rank controls by risk reduction. First, phishing-resistant FIDO2 security keys for administrators, finance and anyone who can approve payments or change mail rules; FIDO2 binds the credential to the origin, so a relayed or fake prompt fails. Second, conditional access requiring a compliant, managed device and blocking legacy authentication, which cuts off the token replay path. Third, enable number matching plus additional context such as application and location; this reduces accidental approval but does not stop a user who is talked through the prompt in real time, nor an adversary-in-the-middle proxy that relays a genuine prompt. Fourth, rate-limit and alert on bursts of denied or ignored prompts, and give users a one-click report button that feeds the SOC. Fifth, revoke sessions and refresh tokens, not just reset the password, because the inbox rule implies an active session.
The detection gap matters as much as the authentication gap: 20-40 prompts in 25 minutes should have produced an alert and a helpdesk call to the user. Add that use case before the next rollout phase.
2. What would you do about the nine-year-old LDAP service account, given the application must run 24/7?
Read the worked answer
Treat it as a privileged credential and remove the excess rights first, because the local administrator membership on two servers is the larger exposure. If the application supports a group managed service account, migrate to gMSA so the password is rotated automatically and never known to a person. If it does not, move the credential into a privileged access vault with automated rotation, restrict logon to the two application servers and to the service identity, and remove interactive logon rights.
For the 24/7 constraint, rotate in a controlled sequence: confirm how the password is stored and where it is used (scripts, connection strings, scheduled tasks), update all consumers in a maintenance window agreed with radiology, restart the service during a low-activity period, and keep a rollback credential in the vault for one cycle. A nine-year-old password is likely embedded in more places than the team remembers, so discovery comes before rotation.
Add monitoring: alert on LDAP binds from hosts other than the two application servers, on anomalous bind volumes, and on use of the account outside service hours. Put the account in a tier that cannot log on to domain controllers or administrative workstations. Review whether the application truly needs LDAP simple bind; if it can move to Kerberos or modern authentication, that removes the stored password problem entirely and should be on the roadmap, not left as a permanent exception.
3. Design the break-glass arrangement and the controls that make it safe. What does the unticketed use six months ago tell you?
Read the worked answer
Break-glass accounts must be reachable when everything else fails, so they should be cloud-only, excluded from conditional access and from any dependency on on-premises federation, and protected by the strongest credential available, ideally a FIDO2 key. Use two accounts, each with a sealed physical credential held by a different named custodian, so no single person or single vault compromise grants both. They must never share storage with general administrative credentials such as the TeamViewer account; that co-location means one vault breach yields both the everyday remote-access path and the emergency path.
Make use safe through detection and process, not through secrecy. Alert to the SOC on any sign-in, page the on-call security lead, require a ticket within 30 minutes and review the session logs afterwards. Test one account quarterly by signing in and performing a low-risk action, then rotate the credential; test the other in the following quarter. Document the emergency use case and who can authorise it.
The unticketed use six months ago is an unexplained privileged event. It could be a forgotten test, an engineer solving a real outage, or misuse. Pull the sign-in logs, correlate with change records and the engineer's activity, interview the custodians, and rotate both credentials. If there is no legitimate explanation, treat it as a potential incident and review what the account did. The fact that one use went unrecorded means the process is already not working.