I85PREP
⌘ K
OSEP study materials
OSEP study resources

Valid Password, Number Matching, and a 48-Hour Window

OSEP · Put your knowledge to work in context.

All case studies

Valid Password, Number Matching, and a 48-Hour Window

During an assumed-breach engagement you recover a cleartext password for m.santos (Finance) from an infostealer log. The tenant enforces MFA with number matching, and Conditional Access requires MFA for all users but does not require compliant or hybrid-joined devices. External Teams federation is disabled, and the mail gateway rewrites and sandboxes links. Smart lockout blocks after 10 bad attempts. The scope forbids password spraying that could lock accounts and forbids exploiting unpatched software. You have 48 hours and need a session that can read SharePoint Finance sites without generating a sign-in risk that trips Identity Protection. You control one low-privilege test account in the same tenant.

1. Select an initial-access technique from: device-code phishing, illicit consent grant, MFA fatigue, password spray, and external Teams message. Justify your choice using the tenant controls and required access.

Read the worked answer

Choice: device-code phishing.

Reasoning against the alternatives:

  • Password spray is explicitly out of scope and smart lockout makes it dangerous; you already have one valid password, so spraying adds risk without adding access.
  • MFA fatigue fails against number matching: the user must match a number, so blind push approval is not available.
  • Illicit consent grant depends on user consent being allowed and on an app permission that grants SharePoint file access; many tenants now require admin consent or block user consent, and it creates a durable app registration that is easy for the blue team to spot.
  • External Teams message is dead because federation is disabled.
  • Device-code phishing fits the control gap: the user authenticates in their own browser, so MFA is satisfied on a device the tenant already trusts, and number matching is not a barrier because the user initiated the flow. Because Conditional Access does not require a compliant device, the token issuance is not blocked by device state. The main precondition to verify is that the tenant has not blocked the device-code authentication flow.

This is a judgement call: device-code phishing gives a refresh token for the user, which can be used against SharePoint/Graph without another MFA prompt. The tradeoff is that the sign-in comes from your IP and may be scored as risky, so pair it with a residential proxy near the user's normal location and keep the session low-noise.

2. What three things do you test with the controlled test account before touching m.santos, and what result makes you abandon this path?

Read the worked answer
  1. Does device-code flow issue a token at all under Conditional Access? Initiate the flow with a public client that supports device code and complete it as the test user. If CA blocks the flow or returns an authentication-strength/device-state error, the path is dead.
  2. What scopes are granted without admin consent? Request the SharePoint/Graph file scopes you need. If the token only carries User.Read or requires admin consent, a token alone will not read Finance sites, and you would need a different post-auth step.
  3. Does a successful auth from a new network trigger a block, forced password reset, or extra verification? Use a proxy in the user's country/ASN. If the test account gets blocked or forced to reset, the same will happen to m.santos and the operation burns the credential.

Abandon criteria: abandon if device-code flow is explicitly blocked, if the token cannot reach SharePoint data without admin consent, or if a new-ASN sign-in forces a password reset. In those cases the valid password becomes a liability rather than an asset.

3. Identity Protection flags the sign-in as anonymous IP and forces a password reset. What fallback stays within scope?

Read the worked answer

Do not retry the password or attempt MFA fatigue; a forced reset means the credential is likely to be rotated and repeated attempts increase the chance of a lockout or an incident.

Fallback: replay the existing session material from the infostealer log. Infostealer logs commonly contain browser cookies and refresh tokens, not just passwords. If a SharePoint/Office refresh token or session cookie for m.santos is present, import it into a clean browser profile and access SharePoint directly. This avoids a new authentication entirely, so MFA and number matching are not re-evaluated.

If no session material exists, the remaining in-scope option is a low-volume device-code attempt against a different user whose sign-in geography you can match, or a helpdesk/social-engineering path if the scope allows it. A password spray is not a fallback here; it violates the lockout constraint and adds little because you already have one valid credential.