Entra sign-in frequency weakened
A Conditional Access policy's SIGN-IN FREQUENCY was changed.
What it detects
A Conditional Access policy's SIGN-IN FREQUENCY was changed.
Sign-in frequency is what puts an expiry on a stolen token. With it set to a day, a session lifted from a browser dies within a day whatever else the attacker does; set to never, the same token is a permanent credential that no password reset touches, because it is not a password.
This is the quietest possible privilege escalation. Nothing is granted, no account is created, no role changes — an existing policy stays in place and keeps reporting as enabled, while the control it was bought for stops applying. A tenant reviewing its CA posture sees a green policy list.
The pack already alerts on CA policies created, changed or deleted BY CMDLET. This covers the directory-side spelling — Update policy., one of the commonest operations in any tenant — which the cmdlet list does not reach and which cannot be alerted on wholesale.
It reads ModifiedProperties directly rather than the message. The message folds audit properties for grepping, and a JSON-object value is deliberately elided there as <changed> to keep it readable, so the policy body — the only place the session control appears — is reachable only through ext:.
MITRE ATT&CK mapping
False positives and triage
Identity teams tune sign-in frequency deliberately, usually loosening it after users complain about re-authentication. That makes the WHO and the DIRECTION the question, not the event. A change by a named identity admin, during hours, with a ticket, that TIGHTENS the interval is housekeeping. Escalate a change that lengthens or removes the interval, one made by an account that has not touched Conditional Access before, or one that lands close to other identity findings on the same actor — the sequence "sign in, weaken the policy, keep the token" is the whole technique. Pull the policy's previous value from the same record: the before/after is in ModifiedProperties and answers the direction question outright.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/entra_signin_frequency_weakened.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_signin_frequency_weakened
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1556, T1484, T1550.001]
description: |
A Conditional Access policy's SIGN-IN FREQUENCY was changed.
Sign-in frequency is what puts an expiry on a stolen token. With it set to a day,
a session lifted from a browser dies within a day whatever else the attacker
does; set to never, the same token is a permanent credential that no password
reset touches, because it is not a password.
This is the quietest possible privilege escalation. Nothing is granted, no
account is created, no role changes — an existing policy stays in place and
keeps reporting as enabled, while the control it was bought for stops applying.
A tenant reviewing its CA posture sees a green policy list.
The pack already alerts on CA policies created, changed or deleted BY CMDLET.
This covers the directory-side spelling — `Update policy.`, one of the commonest
operations in any tenant — which the cmdlet list does not reach and which cannot
be alerted on wholesale.
It reads `ModifiedProperties` directly rather than the message. The message folds
audit properties for grepping, and a JSON-object value is deliberately elided
there as `<changed>` to keep it readable, so the policy body — the only place the
session control appears — is reachable only through `ext:`.
match:
provider_any: [Office365, AzureAD]
event_action_contains_any:
- "Update policy"
- "Add policy"
ext:ModifiedProperties_contains_any:
- "SignInFrequency"
- "signInFrequency"
- "sessionControls"
- "persistentBrowser"
correlation_keys: [user_name]
false_positive_guidance: |
Identity teams tune sign-in frequency deliberately, usually loosening it after
users complain about re-authentication. That makes the WHO and the DIRECTION the
question, not the event. A change by a named identity admin, during hours, with a
ticket, that TIGHTENS the interval is housekeeping. Escalate a change that
lengthens or removes the interval, one made by an account that has not touched
Conditional Access before, or one that lands close to other identity findings on
the same actor — the sequence "sign in, weaken the policy, keep the token" is the
whole technique. Pull the policy's previous value from the same record: the
before/after is in `ModifiedProperties` and answers the direction question
outright.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.