Based on the exhibit, what is the MOST likely scenario?
Exhibit
Refer to the exhibit. Exhibit: Event Log Entry: Time: 2023-10-05 14:23:17 Event ID: 4625 Source: Security User: SYSTEM Logon Type: 3 Account Name: jdoe Account Domain: CORP Failure Reason: Unknown user name or bad password. Workstation Name: WS-001 IP Address: 192.168.1.50 Event Log Entry: Time: 2023-10-05 14:24:05 Event ID: 4624 Source: Security User: SYSTEM Logon Type: 3 Account Name: jdoe Account Domain: CORP Workstation Name: WS-001 IP Address: 192.168.1.50 Event Log Entry: Time: 2023-10-05 14:25:10 Event ID: 4648 Source: Security User: jdoe Logon Type: 2 Account Name: jdoe Account Domain: CORP Target Server: FILE-SRV-01 Additional Info: A logon was attempted using explicit credentials. Workstation Name: WS-001 IP Address: 192.168.1.50
Trap 1: A user is performing a scheduled task that requires authentication.
A scheduled task authenticates non-interactively, so it cannot produce the interactive sign-in pattern shown in the exhibit. This option is tempting because scheduled tasks genuinely generate authentication events, and they would be the right answer if the log showed a service account signing in silently at a fixed interval.
Trap 2: A user forgot their password and successfully logged in after…
A forgotten password followed by a successful retry would show repeated failed authentications from one account, then a success — not the exhibit's pattern. This option is tempting because password-reset lockouts are common helpdesk events, and retry-then-success genuinely fits a single-user mistake scenario, but the exhibit's evidence points elsewhere.
Trap 3: A system administrator is testing password policies.
A password-policy test would generate lockout and reset events, not the exhibit's pattern of privileged role assignments followed by resource creation across subscriptions. Policy testing is legitimate when validating complexity, expiry or lockout thresholds in a lab tenant. Here the sequence indicates credential compromise and privilege escalation, not policy validation.
- A
A user is performing a scheduled task that requires authentication.
Why it fails: A scheduled task authenticates non-interactively, so it cannot produce the interactive sign-in pattern shown in the exhibit. This option is tempting because scheduled tasks genuinely generate authentication events, and they would be the right answer if the log showed a service account signing in silently at a fixed interval.
- B
A user forgot their password and successfully logged in after retrying.
Why it fails: A forgotten password followed by a successful retry would show repeated failed authentications from one account, then a success — not the exhibit's pattern. This option is tempting because password-reset lockouts are common helpdesk events, and retry-then-success genuinely fits a single-user mistake scenario, but the exhibit's evidence points elsewhere.
- C
An attacker brute-forced the password and then used the credentials to access a file server.
Repeated failed authentications followed by a successful logon and subsequent file-server access match credential brute forcing: the attacker guesses the password, then uses the valid account to reach data. The sequence links authentication abuse directly to the file access.
- D
A system administrator is testing password policies.
Why it fails: A password-policy test would generate lockout and reset events, not the exhibit's pattern of privileged role assignments followed by resource creation across subscriptions. Policy testing is legitimate when validating complexity, expiry or lockout thresholds in a lab tenant. Here the sequence indicates credential compromise and privilege escalation, not policy validation.