Push-Bombing, Dormant Accounts, and a Domain-Admin Service Account
You are the security architect at a 480-person SaaS company. Employees authenticate to a cloud identity provider with a password plus push-based MFA. Last month three executives each received more than 20 push prompts in a single evening; one of them approved, and the attacker registered a new MFA device before the account was disabled.
Three other facts sit alongside that incident. The help desk performs 12–15 MFA resets a day, mostly for contractors. A legacy on-premises scheduling application authenticates to Active Directory through a shared LDAP bind account that holds domain administrator rights, because "the vendor said so," and its password is stored in a plaintext configuration file on the application server. And the last quarterly access review found 74 enabled accounts belonging to people who have left, 9 of which logged in during the quarter.
Contractors work from personal phones, and the largest contractor agreement - 60 people - ends in 30 days. Engineering wants FIDO2 passwordless for all administrators within 90 days.
1. Which of these risks do you address first, and why is it more urgent than the others?
Read the worked answer
Separate evidence of ongoing compromise from latent exposure, because they demand different clocks.
Within 24 hours: the 9 dormant accounts that logged in. Latent risk can be scheduled; a login from a leaver's account is a signal that someone may already be inside. Pull sign-in logs for those 9 - source IP, device, what they touched. If any login is unexplained, treat it as an active incident: disable the accounts, revoke sessions and refresh tokens, force credential reset, and check for mail rules, OAuth grants, and new MFA devices. The other 65 get disabled this week.
Next: the domain-admin LDAP bind account. It is the highest-blast-radius credential you own. A domain admin password in a plaintext config file means anyone who reaches that application server owns the domain. The leaver accounts might be an intrusion; this guarantees that one small compromise becomes a total one.
Why not MFA first? MFA is the right long-term fix and the push-bombing incident justifies it, but the attacker already succeeded once and the pattern will repeat. Hardening MFA reduces future probability; killing the DA service account and closing live sessions reduces present capability. Do both in the same month, but sequence by what an adversary can do today.
2. Design MFA hardening that works for contractors on personal phones without a company device, and that addresses push bombing.
Read the worked answer
The requirement is not "stronger MFA" in the abstract; it is resistance to prompt fatigue plus no dependence on a company-issued phone.
Kill push fatigue structurally. Enable number matching, so the user must type a code shown on the sign-in screen - a blind approve does nothing. Add an application name and geographic context to the prompt. Rate-limit and then suppress repeated prompts after N denials, and alert the SOC on prompt storms. Disable legacy "approve/deny only" push entirely; keeping it while adding number matching defeats the purpose.
Handle contractors without corporate hardware. FIDO2 security keys are the strongest option and cost roughly the price of a lunch - buy a pool, issue them against a deposit, and recover them at contract end. Where a contractor genuinely cannot use a key, TOTP in an authenticator app on the personal phone is acceptable; SMS is not. Bind access to conditional policies: compliant or registered device where possible, impossible travel and risky-IP blocks, session lifetime limits, and access that expires automatically with the contract.
Reduce the reset volume. Most of the 12–15 daily resets are users losing a factor. Self-service factor recovery with identity proofing, plus a second registered factor per user, cuts that queue and removes the help-desk social-engineering path.
Sequence it: number matching first (days), FIDO2 for admins and the contractor pool next (weeks), conditional access tightening continuously.
3. The legacy scheduling application cannot do modern authentication and requires LDAP. What do you do about the shared domain-admin bind account?
Read the worked answer
The goal is to make the credential both less powerful and less useful to steal.
Reduce privilege. Determine the minimum the application reads - usually a handful of attributes under one OU. Create a dedicated service account with read-only delegated rights scoped to exactly that subtree, deny interactive logon, and mark it sensitive and non-delegatable. Domain admin is almost certainly unnecessary; the vendor's claim should be tested in a lab, not accepted.
Reduce exposure. Move the password into a secrets manager and have the application fetch it at start-up rather than reading a plaintext file. Rotate on a schedule and immediately on any suspicion. Restrict the bind to the application server's IP at the network layer - an LDAP bind attempt from anywhere else should fail. Alert on binds outside business hours, from new source IPs, or with unusually broad queries.
Reduce the lifetime of the problem. Put a dated migration plan in front of the vendor: SAML or OIDC against your identity provider, or an LDAP proxy that presents modern auth to the app. If the vendor will not commit, that is a procurement and risk-acceptance issue, not an infrastructure one.
Do not simply change the password and declare victory - the same plaintext file will hold the new one by Friday.