1. A sign-in log entry shows ConditionalAccessStatus == "notApplied". What does this mean?
Conditional access evaluated the sign-in and determined that no additional controls were needed
The user is excluded from all conditional access policies by design (such as a break-glass account)
No conditional access policy's conditions matched this sign-in — it was not evaluated by any policy
Conditional access is not enabled in this tenant
"notApplied" means no policy matched this sign-in's conditions (user assignment, application target, device platform, location, etc.). This can be intentional (break-glass accounts excluded from all policies) or a gap (an application or user group not covered by any policy). The gap-finding query in EI1.5 identifies these cases. In a Zero Trust architecture, every sign-in should be evaluated by at least one policy.
2. Where would you find evidence of an attacker replaying a stolen refresh token?
SigninLogs — the token replay appears as a new interactive sign-in
AADNonInteractiveUserSignInLogs — the token refresh from the attacker's device appears as non-interactive activity
AuditLogs — the token replay generates an audit event for "Token replayed"
AADServicePrincipalSignInLogs — refresh tokens are service principal credentials
Token replay uses an existing token without re-authenticating — no interactive sign-in occurs. The stolen token's refresh generates non-interactive events in AADNonInteractiveUserSignInLogs. The key indicator is non-interactive activity from an IP address different from the user's recent interactive sign-in IP. This is why monitoring both tables is essential, and why the concurrent session detection query in EI1.10 is a critical detection pattern.
3. A sign-in shows AuthenticationDetails with PrimaryMethod "Password" and MFAMethod "Microsoft Authenticator (push notification)". How would you classify this authentication strength?
Phishing-capable — the push notification can be intercepted by AiTM or exploited through MFA fatigue
Phishing-resistant — the Authenticator app provides strong second-factor authentication
Weak — push notifications are equivalent to SMS and should be blocked
Strong — Microsoft Authenticator with push notification is the recommended MFA method
Password + Authenticator push is phishing-capable. The AiTM proxy forwards the password to the real Entra ID, triggers the push notification, and captures the session token after the user approves. Number matching improves this (the attacker cannot see the number), but the session token capture still succeeds because the authentication completes through the proxy. Only FIDO2, passkeys, WHfB, and CBA are phishing-resistant because they cryptographically verify the domain.
4. What is the primary difference between RiskLevelDuringSignIn and RiskLevelAggregated?
RiskLevelDuringSignIn uses real-time detections while RiskLevelAggregated uses offline detections only
RiskLevelDuringSignIn is set by Identity Protection while RiskLevelAggregated is set by conditional access
RiskLevelDuringSignIn applies to interactive sign-ins while RiskLevelAggregated applies to non-interactive sign-ins
RiskLevelDuringSignIn assesses this specific sign-in while RiskLevelAggregated reflects the user's overall risk considering all recent activity
RiskLevelDuringSignIn is a per-event assessment — how suspicious is this specific authentication attempt. RiskLevelAggregated is a per-user assessment — what is the overall risk level of this account based on all recent detections, not just this sign-in. A user with multiple medium-risk sign-ins may have an aggregated risk of "high" even if each individual sign-in was only "medium." Both are used in conditional access risk policies, but they serve different purposes.
5. Why is monitoring AADServicePrincipalSignInLogs critical for identity security?
Service principals generate more sign-in volume than users, so they are the primary log source
Service principal sign-ins are evaluated by conditional access, so monitoring them verifies policy enforcement
Service principals authenticate with credentials that cannot use MFA, their activity does not appear in user sign-in logs, and most organizations do not monitor them — making them an ideal attack vector
Service principal sign-in logs contain the application permissions granted to each application
Service principals authenticate with client secrets or certificates that cannot use MFA. Their sign-ins appear only in AADServicePrincipalSignInLogs — not in the user sign-in logs that most organizations monitor. An attacker who steals a service principal credential can access resources without any user context, without triggering user-targeted conditional access, and without appearing in the logs that security teams typically review. This is the blind spot described in EI1.3 and the persistence mechanism exploited in EI0.8 Case Study 3.
6. What KQL operator do you use to parse the ConditionalAccessPolicies array and create one row per policy evaluation?
parse_json — it converts the array string into individual objects
mv-expand — it expands each array element into a separate row
extend — it adds a new column for each policy in the array
project — it selects the policy fields from the array
mv-expand takes an array and creates one row per element — if a sign-in was evaluated by 5 conditional access policies, mv-expand produces 5 rows, each containing one policy's evaluation details. parse_json converts the string to a JSON object (often used before mv-expand), but it does not expand the array. This pattern — mv-expand CAPolicy = parse_json(ConditionalAccessPolicies) — is used throughout EI1.5 and is essential for conditional access policy verification.
7. What is the primary advantage of baseline-driven anomaly detection over static threshold rules?
Baselines detect user-specific anomalies — a sign-in from Belgium is anomalous for a UK-only user but normal for a user who travels to Belgium regularly
Baselines are simpler to implement because they do not require threshold tuning
Baselines eliminate false positives entirely because they perfectly model normal behavior
Baselines detect attacks faster than threshold rules because they evaluate in real time
Baseline detection adapts to each user's established patterns. A static rule "alert on sign-in from Belgium" generates false positives for users who regularly travel there and misses anomalies for users in countries not on the block list. A baseline-driven rule "alert on sign-in from a country this user has never used" catches Belgium as anomalous for the UK-only user while ignoring it for the frequent traveler. Baselines are more complex to implement (you need historical data) and do have false positives (users who genuinely change behavior), but they are significantly more precise than static rules.
8. A sign-in shows AuthenticationDetails where authenticationStepResultDetail is "MFA requirement satisfied by claim in the token". What does this mean?
The user completed MFA using a token-based method like FIDO2
The conditional access policy was satisfied because the user had a valid access token
MFA was required but the token was not valid, so the sign-in failed
The user completed MFA in a previous session and the claim carried over — no active MFA challenge occurred on this specific sign-in
This value means MFA was not actively completed during this sign-in. The user satisfied MFA in a prior session (possibly hours ago), and the MFA claim was carried in the token. This is normal behavior when sign-in frequency allows it — but it means this specific sign-in was not actively verified. A sign-in from an unusual IP that shows "claim in the token" for MFA satisfaction is more suspicious than one where MFA was actively completed, because the active completion proves the user was present at that moment.
9. You need to correlate a risky sign-in with the administrative actions the user took afterward. Which KQL pattern do you use?
union SigninLogs, AuditLogs and filter by UserPrincipalName
mv-expand the SigninLogs to extract audit events from the sign-in record
Use a let statement to define the risky users from SigninLogs, then join with AuditLogs on the actor's UPN, filtering to audit events after the sign-in time
Query AuditLogs and filter by RiskLevelDuringSignIn
The cross-table correlation pattern from EI1.10: define the risky sign-ins as a let subquery, then join with AuditLogs on the user identity, filtering to audit events that occurred after the risky sign-in time. Union would stack the tables but not correlate specific events. AuditLogs does not contain RiskLevelDuringSignIn — that field exists only in the sign-in logs. The join pattern preserves the temporal relationship between the sign-in event and the subsequent administrative actions.
10. Which sign-in log field identifies the specific credential (client secret or certificate) a service principal used to authenticate?
AppId — the application registration identifier
ServicePrincipalCredentialKeyId — the specific credential key identifier
ServicePrincipalId — the service principal object identifier
ClientAppUsed — the client application type
ServicePrincipalCredentialKeyId identifies which specific credential was used — the Key ID of the client secret or the thumbprint of the certificate. This is critical for investigation: if a service principal has multiple credentials and the sign-in used a credential you do not recognize, an attacker may have added their own credential to the service principal. Monitoring for new credential key IDs is one of the service principal detection patterns from EI1.3.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
