Safe password resets and account lockouts

A caller says she is Meera from finance: travelling, phone lost, a board call at 10:00, and she needs her password reset and her MFA moved to a new number now. Her employee ID, her manager’s name and her office are all correct, because they came from a social profile and a leaked list. CISA’s advisory on the group it calls Scattered Spider describes exactly this: callers who first learn a help desk’s reset steps, then ring as a chosen employee to have the password reset or the second factor moved to a device they control.

This lesson builds a reset that a prepared caller cannot pass, the script such callers follow and the temporary password that stops working at the first sign-in. Its second half is the other reset ticket a desk sees every day: an account that locks itself every half hour, where event 4740 names the computer behind it, and the difference between an Active Directory lockout and Microsoft Entra’s smart lockout.

A reset is safe only when a stranger could not pass the check

Every fact the caller gave about Meera was true, and none of it proved anything. CISA’s advisory lists where such details come from: social media, open-source information, commercial intelligence tools and leaked databases. Microsoft’s scam guidance adds that callers may spoof the caller ID to show a legitimate number. So the number on the screen is the caller’s choice, and the details are the caller’s homework.

One test sorts every possible check, and passwords, MFA and passkeys applies it to recovery methods: could a stranger who has researched the person complete this step? A call back passes it, because the desk ends the inbound call and rings the number in the HR directory, a record the caller cannot change. A manager who confirms the request on their own directory number passes it. An ID shown on a video call or at the desk, compared with the HR record, passes it. Reading out an employee ID does not.

How strong the check must be depends on the account, so the desk reads the account before it chooses. Step through one request from first contact to the record:

Two choices in the flow carry the weight. The look-up comes before the check: an administrator, a payroll or supplier-payment account or an executive’s account needs a second, independent confirmation on top of the call back, and a sign-in method or phone number changed in the last few days is a reason to slow down. And the desk, not the caller, picks every channel: the number rung, the person who confirms, the place the temporary password is given. That is half of the job; the other half, a user being able to check the desk, is in remote support security and scams.

Social engineering at the desk follows a script you can recognise

The call about Meera was the last of three. CISA’s advisory describes the order: social engineering spread over several calls, first to learn what a help desk needs before a password reset, then to collect those details about a chosen employee, and finally to persuade a technician to reset the password or move the MFA. Step through the three calls as one attacker makes them:

The first call did the damage, and it asked for nothing. A technician who explains the checks to an unknown caller has handed over the list of facts to collect. The safe answer to “what would you need from me?” is that the desk will verify them when they ask for a reset, together with the self-service reset page, and no list.

Once you have seen the script, its levers are easy to name. Each has a tell, and each has the same answer:

The last row is the one that completes a takeover. A new MFA method is half of an account, so registering one gets the same check as a password reset, and a request for both in one call is the strongest sign in the table. CompTIA’s A+ Core 2 objectives list impersonation and vishingSocial engineering by voice: a phone call in which the caller pretends to be someone else to get information, access or a change to an account. among the social-engineering attacks a technician should be able to tell apart. The calls that tested your desk last week are evidence too, so a technician who stops an attempt tells the security team, who can warn everyone the same caller may ring next.

The reset gives a random password that ends at the first sign-in

Some desks reset every account to the same password, Welcome@123, because “users change it anyway”. Until the user signs in, that password is known to the whole desk and to everyone who has ever been reset there, and it is one of the first a stranger would try.

Microsoft’s tools make the safe version the default. When an administrator resets a password in the Microsoft Entra admin center, Entra ID generates a temporary password, the administrator gives it to the user, and the user must change it during the next sign-in. Microsoft adds that this temporary password never expires on its own: days later it still works, until that first sign-in, so hand it over only on the verified call and check that it was used. In on-premises Active Directory the technician creates the password instead, so make it random and set the account to require a change at the next logon, for example with Set-ADUser -ChangePasswordAtLogon $true. Microsoft notes that a synced user’s password can be reset in the cloud only when password writeback is on and the domain is managed; otherwise the reset happens in Active Directory.

A lost phone is handled the same way. After the check, give a single-use Temporary Access PassA time-limited passcode that Microsoft Entra ID issues to one user so that they can sign in once and register new sign-in methods themselves., as joiners, movers and leavers does for a new joiner, so the user registers the new phone themselves; Microsoft’s authentication methods page also lets an administrator require the user to register MFA again and revoke their sessions. Where the user has already registered methods for self-service password resetself-service password reset: A Microsoft Entra ID feature that lets users change or reset their own password with registered authentication methods, without an administrator or help desk ticket. Also known by its initials: SSPR. More in “Cloud identity: Entra ID, SSO and device join”, the safest reset is the one the desk does not do.

The last row of the table comes from NIST SP 800-63B-4, which makes a notification part of every account recovery, to help the owner notice a recovery that was not theirs. A notice on a second channel costs a minute and turns a fraud that slipped past the check into one that is caught the same day.

A repeated lockout has a source, and event 4740 names the computer

The real Meera changed her password on Monday, and since then her account locks every half hour. Clearing the lockout each time only resets the clock: something is still trying her old password, and the job is to find it.

Active Directory decides when to lock with three Account Lockout Policy settings, and Microsoft’s pages give each one’s range and advice. The threshold is the number of failed attempts that locks the account, from 1 to 999; 0 means never, which is the default domain policy’s value, and Windows security baselines suggest 10 as a starting point. The duration is how many minutes the account stays locked, with about 15 advised, and 0 means locked until an administrator clears it. The reset counter setting is how many minutes after a failure the count starts again, and the baselines suggest 15. Microsoft also warns of the trade-off: a threshold lets an attacker lock every account on purpose, so the value is a balance between security and day-to-day work, not the lowest number possible. CompTIA’s hardening objective and CISA’s advice both ask for lockouts after a set number of failed attempts.

Three security events tell you where the failures come from:

The Logon Type of 4625 says what kind of thing failed: 2 is someone at the keyboard, 3 a network connection such as a mapped drive, 4 a scheduled task, 5 a service and 10 a remote desktop session. The usual culprits are a second computer still signed in, a mapped drive or a credential saved in Windows (cmdkey /list shows the saved ones), a scheduled task or a service set to run as the user, a remote desktop session left running, and a phone whose mail app still holds the old password. The program below reads a morning of sample events for Meera. Press Edit, add a lockout from another computer, and run it again:

"""Finds the computer behind a morning of account lockouts.

The rows are a sample written for this lesson in the shape of two Windows Security events: 4740 (an account was
locked out, logged on the domain controllers with the Caller Computer Name) and 4625 (a sign-in failed, logged on the
computer that refused it, with the Logon Type and the Sub Status). Press Edit, add a lockout from another computer or
change a time, and run it again.
"""

from collections import Counter

# 4740 rows: time (UTC+05:30), locked account, Caller Computer Name.
LOCKOUTS = [
    ("08:35", "meera.iyer", "FIN-LT-07"),
    ("09:05", "meera.iyer", "FIN-LT-07"),
    ("09:35", "meera.iyer", "FIN-LT-07"),
    ("09:52", "arun.das", "SALES-PC-03"),
    ("10:05", "meera.iyer", "FIN-LT-07"),
    ("10:35", "meera.iyer", "FIN-LT-07"),
]

# 4625 rows on the file server FS01, written out from bursts: (first minute, failures in the burst). Each failure
# names the account, the Workstation Name, Logon Type 3 (network) and Sub Status 0xC000006A (bad password). The
# sample domain's lockout threshold is 10, so each burst of 10 bad passwords ends in one lockout.
BURSTS = [("08:31", 10), ("09:01", 10), ("09:31", 10), ("10:01", 10), ("10:31", 10)]
FAILURES = [("meera.iyer", "FIN-LT-07", 3, "0xC000006A") for _, count in BURSTS for _ in range(count)]

LOGON_TYPES = {2: "interactive: someone at the keyboard", 3: "network: a share or drive it connects to",
               4: "batch: a scheduled task", 5: "service", 10: "remote desktop"}
SUB_STATUS = {"0xC000006A": "misspelled or bad password", "0xC0000234": "account locked out"}


def minutes(clock):
    hours, mins = clock.split(":")
    return int(hours) * 60 + int(mins)


ACCOUNT = "meera.iyer"
mine = [(t, caller) for t, account, caller in LOCKOUTS if account == ACCOUNT]
print(f"Lockouts of {ACCOUNT} (event 4740): {len(mine)}")
for caller, count in Counter(caller for _, caller in mine).most_common():
    times = [t for t, c in mine if c == caller]
    print(f"  {caller:<10} {count}  at {', '.join(times)}")
    gaps = [minutes(b) - minutes(a) for a, b in zip(times, times[1:])]
    print(f"  minutes between them: {', '.join(map(str, gaps))}")

source = Counter(caller for _, caller in mine).most_common(1)[0][0]
rows = [r for r in FAILURES if r[0] == ACCOUNT and r[1] == source]
print(f"Failed sign-ins for {ACCOUNT} from {source} (event 4625 on FS01): {len(rows)}")
for logon_type, count in Counter(r[2] for r in rows).items():
    print(f"  logon type {logon_type} ({LOGON_TYPES[logon_type]}): {count}")
for status, count in Counter(r[3] for r in rows).items():
    print(f"  sub status {status} ({SUB_STATUS[status]}): {count}")
print(f"Next: on {source}, find the connection to FS01 that still uses the old password, and remove it.")

Lockouts of meera.iyer (event 4740): 5
  FIN-LT-07  5  at 08:35, 09:05, 09:35, 10:05, 10:35
  minutes between them: 30, 30, 30, 30
Failed sign-ins for meera.iyer from FIN-LT-07 (event 4625 on FS01): 50
  logon type 3 (network: a share or drive it connects to): 50
  sub status 0xC000006A (misspelled or bad password): 50
Next: on FIN-LT-07, find the connection to FS01 that still uses the old password, and remove it.

All 5 lockouts name FIN-LT-07, 30 minutes apart, and the 50 failed sign-ins on the file server FS01 are network sign-ins with a bad password, 10 before each lockout, which is the sample domain’s threshold. FIN-LT-07 is the laptop Meera used before her new one: still switched on, still connecting to FS01 with the password she changed on Monday. Remove that saved connection, or sign the old laptop out, and the lockouts stop.

Smart lockout counts a wrong password once and knows familiar places

Microsoft Entra ID locks cloud sign-ins with its own rule, smart lockout, and Microsoft’s page explains how it differs from a counter. By default it locks an account after 10 failed attempts in public cloud tenants (three in Azure US Government), for one minute at first and longer after later failures; Microsoft does not publish how fast the period grows. It keeps separate counters for familiar and unfamiliar locations, so an attacker abroad can be locked out while the user at the office keeps working. And it tracks the last three bad password hashes, so the same wrong password typed again does not count again.

The model below runs one stream of failures through both rules: an old phone at the office retrying Meera’s previous password 30 times, then an attacker abroad trying 12 different passwords. It follows the rules Microsoft documents, not the service itself. Press Edit, give the phone two different old passwords, and run it again:

"""Runs one stream of failed sign-ins through two lockout rules: a classic counter and a simplified smart lockout.

Classic: every failure counts towards a threshold of 10, as an Active Directory lockout policy with a threshold of
10 does. Smart, as Microsoft documents it for Microsoft Entra ID: a threshold of 10, separate counters for familiar
and unfamiliar locations, and a wrong password that matches one of the last three bad passwords does not count again.
Microsoft does not publish every detail (how fast the lockout period grows, for example), so this is a model of the
documented rules, not the service. Press Edit and change the stream, then run it again.
"""

THRESHOLD = 10

# Meera's old phone retries her previous password 30 times from the office; an attacker abroad tries 12 different
# passwords. "where" is how a sign-in service would see the location: familiar or unfamiliar.
STREAM = [("phone", "familiar", "old-password")] * 30 + [
    ("attacker", "unfamiliar", f"guess-{n}") for n in range(1, 13)
]


def classic(stream):
    count = 0
    for n, (who, _, _) in enumerate(stream, start=1):
        count += 1
        if count == THRESHOLD:
            return f"locked at attempt {n} ({who}): the account is locked for everyone"
    return "never locked"


def smart(stream):
    counters = {"familiar": 0, "unfamiliar": 0}
    recent_bad = []  # the last three bad passwords seen
    locked = {}
    for n, (who, where, password) in enumerate(stream, start=1):
        if password not in recent_bad:
            counters[where] += 1
            recent_bad = (recent_bad + [password])[-3:]
        if counters[where] == THRESHOLD and where not in locked:
            locked[where] = f"locked at attempt {n} ({who})"
    lines = [f"{where} counter {counters[where]}: {locked.get(where, 'not locked')}" for where in counters]
    return "; ".join(lines)


print(f"{len(STREAM)} failed sign-ins: {sum(1 for s in STREAM if s[0] == 'phone')} from the phone, "
      f"{sum(1 for s in STREAM if s[0] == 'attacker')} from the attacker")
print("Classic counter:", classic(STREAM))
print("Smart lockout:  ", smart(STREAM))

42 failed sign-ins: 30 from the phone, 12 from the attacker
Classic counter: locked at attempt 10 (phone): the account is locked for everyone
Smart lockout:   familiar counter 1: not locked; unfamiliar counter 12: locked at attempt 40 (attacker)

The classic counter locks Meera at attempt 10, the phone’s tenth retry, and she is locked out everywhere. Smart lockout’s familiar counter stays at 1, and only the unfamiliar counter locks, at attempt 40, the attacker’s tenth guess. A locked user sees “Your account is temporarily locked to prevent unauthorized use”; Microsoft adds that choosing “I forgot my password” in self-service password reset resets the lockout duration to zero, while “I know my password” leaves the timer running.

Hybrid setups need the two rules to agree. With pass-through authentication the password is checked on-premises, so Microsoft says the hash tracking is not available, and it asks for the Entra threshold to be lower than the Active Directory one, with AD at least two or three times higher (its example is 10 in Entra and 20 in AD), and for the Entra lockout to last longer than the AD lockout. Entra then stops a password-spraying attacker before the on-premises accounts lock.

Practise: find the computers behind a lockout

The exercise turns the first half of the lesson’s lockout program into a function. Given a list of exported security events and an account name, it counts that account’s lockouts by Caller Computer Name, most frequent first, so the computer to visit is at the top. The sample tests check the ordering, other accounts and the failed sign-ins (event 4625) mixed into the export.

def lockout_sources(events, account):
    """Return [(caller, count), ...] for the 4740 lockouts of account, most frequent first.

    TODO: keep only lockout events (4740) of this account, compare names without regard to case, report callers
    in upper case with "(blank)" for a missing one, and sort by count, then by name. Right now it counts every
    event of the account under whatever caller it has, in no particular order.
    """
    counts = {}
    for event in events:
        if event["account"] == account:
            caller = event.get("caller")
            counts[caller] = counts.get(caller, 0) + 1
    return list(counts.items())

from lockout_sources import lockout_sources

MORNING = [
    {"event": 4740, "time": "08:35", "account": "meera.iyer", "caller": "FIN-LT-07"},
    {"event": 4740, "time": "09:05", "account": "meera.iyer", "caller": "FIN-LT-07"},
    {"event": 4740, "time": "09:20", "account": "meera.iyer", "caller": "FIN-PC-12"},
    {"event": 4740, "time": "09:35", "account": "meera.iyer", "caller": "FIN-LT-07"},
    {"event": 4740, "time": "09:52", "account": "arun.das", "caller": "SALES-PC-03"},
]


def test_the_computer_with_most_lockouts_comes_first():
    assert lockout_sources(MORNING, "meera.iyer") == [("FIN-LT-07", 3), ("FIN-PC-12", 1)]


def test_other_accounts_are_left_out():
    assert lockout_sources(MORNING, "arun.das") == [("SALES-PC-03", 1)]


def test_failed_sign_ins_are_not_lockouts():
    events = MORNING + [
        {"event": 4625, "time": "09:34", "account": "meera.iyer"},
        {"event": 4625, "time": "09:34", "account": "meera.iyer"},
    ]
    assert lockout_sources(events, "meera.iyer") == [("FIN-LT-07", 3), ("FIN-PC-12", 1)]


def test_an_account_with_no_lockouts_gives_an_empty_list():
    assert lockout_sources(MORNING, "priya.nair") == []

The self-check below picks its next question from your answers so far, the weakest concept first:

Interview questions

Warm-up (fresher): why does a help desk ring a caller back on the number in the HR directory before a reset, instead of trusting the number on its screen?

Because the number on the screen is the caller’s choice and the number in the HR directory is not. Microsoft’s scam guidance warns that callers may spoof the caller ID so it shows a legitimate number, and CISA describes attackers who arrive with the employee ID, the manager’s name and the office already collected from social media and leaks. A call back on the directory number is a check a prepared stranger cannot pass: the desk ends the inbound call, rings the number on record, and the stranger never answers it. If the person who answers says they did not call, nothing is reset and the attempt goes to the security team. For a high-risk account the desk adds a second, independent check, such as the manager confirming on their own directory number.

The two important questions below move the same rules into cases this lesson did not walk through. Decide what you would check first and whose agreement you would need, then compare with the first step on each question’s page:

Key takeaways

• A reset is safe only when its check could not be passed by a stranger who researched the person: ring back on the number in the HR directory, add a second independent check for high-risk accounts, and never treat caller ID or personal details as proof.
• Help-desk social engineering follows a script of several calls, using urgency, rank, true details and a switch of channel, so the desk never describes its checks to an unknown caller and gives MFA changes the same check as a password reset.
• The reset itself is a random temporary password that must change at the next sign-in, or a single-use Temporary Access Pass for new MFA, given on the verified channel and followed by a notice to the owner on a second channel.
• A lockout that keeps coming back has a source: event 4740 on the domain controllers names the caller computer, and the Logon Type of the failed sign-ins from it says whether a drive, a task, a service or a session holds the old password.
• Microsoft Entra smart lockout counts each new wrong password once, keeps separate counters for familiar and unfamiliar places and locks for a minute at first, so with pass-through authentication the Active Directory threshold is set two or three times higher than the Entra one.