2026-04-22 05:28:08 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文揭示MicrosoftEntra条件访问策略中存在一个隐藏的基于时间条件，允许拥有条件访问管理员权限的攻击者创建时间后门，在特定日期或小时自动禁用安全策略。该后门在Azure门户、MicrosoftGraph和PowerShell模块中均不可见，且无法被What-If工具检测。文章通过探索IbizaAPI展示了具体操作方法，并指出这种隐蔽性对租户身份安全构成严重威胁。 综合评分： 85 文章分类： 漏洞分析,云安全,渗透测试,红队,安全运营

cover_image

Entra条件访问策略中的时间后门

Dubito Dubito

云原生安全指北

2026年4月21日 08:35 江苏

在小说阅读器读本章

去阅读

注：本文翻译自 Reversec 的文章《It’s Just a Matter of Time: Backdooring Conditional Access Policies》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

摘要

Microsoft Entra 中的条件访问（Conditional Access）策略包含一个隐藏的、基于时间的条件。该条件在 Azure 门户或 Microsoft Graph 中均不可见。最低拥有 Conditional Access Administrator（条件访问管理员）角色的攻击者即可添加此条件，从而创建一个基于时间的后门。该后门能在每周的特定日期或小时悄无声息地禁用安全策略。此更改对门户中的管理员不可见，What-If（假设分析）工具也不会报告，且在使用 Microsoft.Entra 等管理 PowerShell 模块的命令行输出中也会缺失该条件。

一、介绍

对于少数必须管理 Microsoft Entra 租户的人来说，条件访问（Conditional Access）策略被视为特定租户内身份安全的基石。你可以创建各种强大的策略，将访问组织的权限限制在少数受信任的设备上。这也是在整个资产范围内强制实施多因素身份验证（MFA，Multi-Factor Authentication）等控制措施的主要途径。此外，如果用户主体不满足特定标准，通过这种方式明确阻止其访问也非常有效。如果你曾在测试策略时不小心锁定了自己的测试账户，不得不使用应急备用账户来恢复，那么你就能切身体会到它的威力有多大！

顾名思义，条件访问策略使用一组已知的条件来定义策略何时应该生效、何时不应该生效。每个使用 Entra 的人都很熟悉这些条件，例如“请求源自哪个 IP 地址”、“是否是合规设备”或“是什么设备类型”。由于攻击者的滥用，安全社区在某种程度上已更擅长构建和理解这些条件的工作机制细节及其潜在漏洞。但是，如果我们习惯的这些条件并非全部可能的情况呢？那么，让我们直接深入探讨核心问题吧……

二、在 Ibiza 的适时停留

也许我们不应该直接深入，而是稍微绕个路，先铺垫一下背景。正如之前相关研究所揭示的，Azure 门户 (portal.azure.com) 会使用多种不同的 API 对 Azure 资源和 Entra 租户对象执行操作。其中有一个 API 被称为 Ibiza API，托管在 main.iam.ad.ext.azure.com。在众多功能中，该 API 允许用户在不直接使用 Microsoft Graph 的情况下对租户执行许多操作。关于这一鲜为人知且文档匮乏的 API，可以参考该领域其他专家的以下演讲和网站（由 Aled Mehta 创建）。他解释了 Ibiza API 的概念、如何进行身份验证，以及他如何尝试探索更多相关内容：

• https://www.youtube.com/watch?v=1Z8BA83X0YE
• https://nodoc.cloud/

三、闲着不妨探索一下这些 API

在项目交付间隙的休息时间里，我决定深入探索条件访问策略。这有助于我更好地理解这一安全控制机制，并根据我们对某些策略有效性的具体测试，提供更具针对性的建议，以应对攻击者尝试不同手段入侵环境的情况。起初，我使用 Microsoft Graph API 和相关的 PowerShell 命令集来查询策略并尝试对其进行操作。总体而言，这有助于我深入理解策略的定义方式。我也成功梳理出了一些有用的高层指导，即如何在组织中构建策略，使得多个策略部分重叠，从而即使某个策略被绕过，仍有其他策略能够捕获非预期的操作。

然而，由于我也一直在摆弄 Ibiza API，我决定看看能否使用该 API 来查询策略信息。于是，我利用 https://nodoc.cloud/ 中描述的认证方法，生成了一个可用于 Ibiza API 的有效访问令牌。使用 az CLI 时所需的具体命令如下：

az account get-access-token --resource 74658136-14ec-4630-ad9b-26e160ff0fc6

拿到有效令牌后，我接着研究条件访问策略能做些什么。通过查阅已记录的方法，我发现可以通过以下 HTTP GET 请求列出租户中的所有策略：

GET /api/Policies/Policies?top=445&nextLink= HTTP/1.1
Accept:&nbsp;application/json
Authorization:&nbsp;Bearer&nbsp;[REDACTED]
X-Ms-Client-Request-Id:&nbsp;123
Host:&nbsp;main.iam.ad.ext.azure.com

这条请求返回了租户中每个策略 ID 的详细分解：

HTTP/1.1&nbsp;200&nbsp;OK
[为简洁起见已编辑]
Date:&nbsp;Tue,&nbsp;31&nbsp;Mar&nbsp;2026&nbsp;21:47:46&nbsp;GMT
Content-Length:&nbsp;1894

{
&nbsp; "items":&nbsp;[
&nbsp; &nbsp; ...[为简洁起见已编辑]...
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; "policyId":&nbsp;"8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244",
&nbsp; &nbsp; &nbsp; "policyName":&nbsp;"Block Bad Person",
&nbsp; &nbsp; &nbsp; "applyRule":&nbsp;true,
&nbsp; &nbsp; &nbsp; "policyState":&nbsp;2,
&nbsp; &nbsp; &nbsp; "usePolicyState":&nbsp;true,
&nbsp; &nbsp; &nbsp; "baselineType":&nbsp;0,
&nbsp; &nbsp; &nbsp; "createdDateTime":&nbsp;"2026-03-31T21:42:34.9803608+00:00",
&nbsp; &nbsp; &nbsp; "modifiedDateTime":&nbsp;null
&nbsp; &nbsp; }
&nbsp; &nbsp; ...[为简洁起见已编辑]...
}

接着，我想到可以通过 policyId 查询特定策略以获取更多详细信息。对应的 HTTP 请求如下：

GET /api/Policies/8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244 HTTP/1.1
X-Ms-Client-Request-Id:&nbsp;123
Authorization:&nbsp;Bearer&nbsp;[REDACTED]
Host:&nbsp;main.iam.ad.ext.azure.com

这返回了一些更有意思的内容——策略的完整描述！以下是这个示例策略的完整输出。该策略旨在将一名特定用户完全拒于租户门外：

HTTP/1.1&nbsp;200&nbsp;OK
[为简洁起见已编辑]
Date:&nbsp;Tue,&nbsp;31&nbsp;Mar&nbsp;2026&nbsp;21:50:20&nbsp;GMT
Content-Length:&nbsp;3815

{
&nbsp; "usersV2":&nbsp;{
&nbsp; &nbsp; "allUsers":&nbsp;2,
&nbsp; &nbsp; "included":&nbsp;{
&nbsp; &nbsp; &nbsp; "allGuestUsers":&nbsp;false,
&nbsp; &nbsp; &nbsp; "roles":&nbsp;false,
&nbsp; &nbsp; &nbsp; "usersGroups":&nbsp;true,
&nbsp; &nbsp; &nbsp; "roleIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "externalUsers":&nbsp;null,
&nbsp; &nbsp; &nbsp; "groupIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "userIds":&nbsp;[
&nbsp; &nbsp; &nbsp; &nbsp; "58845d0a-eccd-4c44-96b4-c8a61fe8e3e9"&nbsp;#被策略阻止的特定用户的&nbsp;User ID
&nbsp; &nbsp; &nbsp; ]
&nbsp; &nbsp; },
&nbsp; &nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; &nbsp; "allGuestUsers":&nbsp;false,
&nbsp; &nbsp; &nbsp; "roles":&nbsp;false,
&nbsp; &nbsp; &nbsp; "usersGroups":&nbsp;false,
&nbsp; &nbsp; &nbsp; "roleIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "externalUsers":&nbsp;null,
&nbsp; &nbsp; &nbsp; "groupIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "userIds":&nbsp;[]
&nbsp; &nbsp; }
&nbsp; },
&nbsp; "templateId":&nbsp;null,
&nbsp; "servicePrincipals":&nbsp;{
&nbsp; &nbsp; "allServicePrincipals":&nbsp;1,&nbsp;#策略适用于所有应用程序
&nbsp; &nbsp; "included":&nbsp;{
&nbsp; &nbsp; &nbsp; "ids":&nbsp;[]
&nbsp; &nbsp; },
&nbsp; &nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; &nbsp; "ids":&nbsp;[]
&nbsp; &nbsp; },
&nbsp; &nbsp; "filter":&nbsp;null,
&nbsp; &nbsp; "includeAllMicrosoftApps":&nbsp;false,
&nbsp; &nbsp; "excludeAllMicrosoftApps":&nbsp;false,
&nbsp; &nbsp; "userActions":&nbsp;null,
&nbsp; &nbsp; "stepUpTags":&nbsp;null,
&nbsp; &nbsp; "networkAccess":&nbsp;null
&nbsp; },
&nbsp; "controls":&nbsp;{
&nbsp; &nbsp; "controlsOr":&nbsp;true,
&nbsp; &nbsp; "blockAccess":&nbsp;true,&nbsp;#对任何匹配策略的请求强制执行显式阻止
&nbsp; &nbsp; "challengeWithMfa":&nbsp;false,
&nbsp; &nbsp; "requireAuthStrength":&nbsp;null,
&nbsp; &nbsp; "compliantDevice":&nbsp;false,
&nbsp; &nbsp; "domainJoinedDevice":&nbsp;false,
&nbsp; &nbsp; "approvedClientApp":&nbsp;false,
&nbsp; &nbsp; "claimProviderControlIds":&nbsp;[],
&nbsp; &nbsp; "requireCompliantApp":&nbsp;false,
&nbsp; &nbsp; "requirePasswordChange":&nbsp;false,
&nbsp; &nbsp; "requiredFederatedAuthMethod":&nbsp;0
&nbsp; },
&nbsp; "sessionControls":&nbsp;{
&nbsp; &nbsp; "appEnforced":&nbsp;false,
&nbsp; &nbsp; "cas":&nbsp;false,
&nbsp; &nbsp; "cloudAppSecuritySessionControlType":&nbsp;0,
&nbsp; &nbsp; "signInFrequencyTimeSpan":&nbsp;{
&nbsp; &nbsp; &nbsp; "type":&nbsp;0,
&nbsp; &nbsp; &nbsp; "value":&nbsp;0,
&nbsp; &nbsp; &nbsp; "authenticationType":&nbsp;0,
&nbsp; &nbsp; &nbsp; "frequencyInterval":&nbsp;0
&nbsp; &nbsp; },
&nbsp; &nbsp; "signInFrequency":&nbsp;0,
&nbsp; &nbsp; "persistentBrowserSessionMode":&nbsp;0,
&nbsp; &nbsp; "continuousAccessEvaluation":&nbsp;0,
&nbsp; &nbsp; "resiliencyDefaults":&nbsp;0,
&nbsp; &nbsp; "secureSignIn":&nbsp;false,
&nbsp; &nbsp; "secureApp":&nbsp;false,
&nbsp; &nbsp; "networkAccessSecurity":&nbsp;null
&nbsp; },
&nbsp; "conditions":&nbsp;{
&nbsp; &nbsp; "minUserRisk":&nbsp;{
&nbsp; &nbsp; &nbsp; "lowRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "mediumRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "highRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "noRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "minSigninRisk":&nbsp;{
&nbsp; &nbsp; &nbsp; "noRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "lowRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "mediumRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "highRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "signInRiskDetections":&nbsp;{
&nbsp; &nbsp; &nbsp; "anonymousIPAddress":&nbsp;false,
&nbsp; &nbsp; &nbsp; "unfamiliarFeatures":&nbsp;false,
&nbsp; &nbsp; &nbsp; "realTimeThreatIntel":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "servicePrincipalRiskLevels":&nbsp;{
&nbsp; &nbsp; &nbsp; "lowRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "mediumRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "highRisk":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "devicePlatforms":&nbsp;{
&nbsp; &nbsp; &nbsp; "all":&nbsp;1,&nbsp;#包含所有设备类型
&nbsp; &nbsp; &nbsp; "included":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "android":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "ios":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "windowsPhone":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "windows":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "macOs":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "linux":&nbsp;false
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "android":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "ios":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "windowsPhone":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "windows":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "macOs":&nbsp;false,
&nbsp; &nbsp; &nbsp; &nbsp; "linux":&nbsp;false
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;true
&nbsp; &nbsp; },
&nbsp; &nbsp; "locations":&nbsp;{
&nbsp; &nbsp; &nbsp; "includeLocationType":&nbsp;0,
&nbsp; &nbsp; &nbsp; "excludeAllTrusted":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "namedNetworks":&nbsp;{
&nbsp; &nbsp; &nbsp; "includeLocationType":&nbsp;1,&nbsp;#包含所有网络位置
&nbsp; &nbsp; &nbsp; "excludeLocationType":&nbsp;2,
&nbsp; &nbsp; &nbsp; "includeTrustedIps":&nbsp;false,
&nbsp; &nbsp; &nbsp; "excludeTrustedIps":&nbsp;false,
&nbsp; &nbsp; &nbsp; "includedNetworkIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "excludedNetworkIds":&nbsp;[],
&nbsp; &nbsp; &nbsp; "includeCorpnet":&nbsp;false,
&nbsp; &nbsp; &nbsp; "excludeCorpnet":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;true
&nbsp; &nbsp; },
&nbsp; &nbsp; "clientApps":&nbsp;{
&nbsp; &nbsp; &nbsp; "specificClientApps":&nbsp;false,
&nbsp; &nbsp; &nbsp; "webBrowsers":&nbsp;false,
&nbsp; &nbsp; &nbsp; "mobileDesktop":&nbsp;false,
&nbsp; &nbsp; &nbsp; "exchangeActiveSync":&nbsp;false,
&nbsp; &nbsp; &nbsp; "onlyAllowSupportedPlatforms":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "clientAppsV2":&nbsp;{
&nbsp; &nbsp; &nbsp; "webBrowsers":&nbsp;false,
&nbsp; &nbsp; &nbsp; "mobileDesktop":&nbsp;false,
&nbsp; &nbsp; &nbsp; "modernAuth":&nbsp;false,
&nbsp; &nbsp; &nbsp; "exchangeActiveSync":&nbsp;false,
&nbsp; &nbsp; &nbsp; "onlyAllowSupportedPlatforms":&nbsp;false,
&nbsp; &nbsp; &nbsp; "otherClients":&nbsp;false,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "time":&nbsp;{
&nbsp; &nbsp; &nbsp; "all":&nbsp;0,
&nbsp; &nbsp; &nbsp; "included":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "type":&nbsp;0,
&nbsp; &nbsp; &nbsp; &nbsp; "timezoneId":&nbsp;null,
&nbsp; &nbsp; &nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/1/2026 12:00:00 AM"
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "day":&nbsp;[0,1,2,3,4,5,6],
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/1/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "allDay":&nbsp;false
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "isExcludeSet":&nbsp;false
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "type":&nbsp;0,
&nbsp; &nbsp; &nbsp; &nbsp; "timezoneId":&nbsp;null,
&nbsp; &nbsp; &nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/1/2026 12:00:00 AM"
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "day":&nbsp;[0,1,2,3,4,5,6],
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/1/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "allDay":&nbsp;false
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "isExcludeSet":&nbsp;false
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "deviceState":&nbsp;{
&nbsp; &nbsp; &nbsp; "includeDeviceStateType":&nbsp;0,
&nbsp; &nbsp; &nbsp; "excludeDomainJoionedDevice":&nbsp;false,
&nbsp; &nbsp; &nbsp; "excludeCompliantDevice":&nbsp;false,
&nbsp; &nbsp; &nbsp; "filter":&nbsp;null,
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;false
&nbsp; &nbsp; }
&nbsp; },
&nbsp; "clientApplications":&nbsp;{
&nbsp; &nbsp; "allServicePrincipals":&nbsp;0,
&nbsp; &nbsp; "filter":&nbsp;null,
&nbsp; &nbsp; "includedServicePrincipals":&nbsp;null,
&nbsp; &nbsp; "excludedServicePrincipals":&nbsp;null
&nbsp; },
&nbsp; "isAllProtocolsEnabled":&nbsp;false,
&nbsp; "isUsersGroupsV2Enabled":&nbsp;false,
&nbsp; "version":&nbsp;1,
&nbsp; "isFallbackUsed":&nbsp;false,
&nbsp; "policyId":&nbsp;"8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244",
&nbsp; "policyName":&nbsp;"Block Bad Person",
&nbsp; "applyRule":&nbsp;true,
&nbsp; "policyState":&nbsp;2,&nbsp;#强制执行状态
&nbsp; "usePolicyState":&nbsp;true,
&nbsp; "baselineType":&nbsp;0,
&nbsp; "createdDateTime":&nbsp;"2026-03-31T21:42:34.9803608+00:00",
&nbsp; "modifiedDateTime":&nbsp;null
}

你可以滚动浏览并验证该策略：它匹配所有设备类型，旨在明确阻止 ID 为“58845d0a-eccd-4c44-96b4-c8a61fe8e3e9”的用户进行访问。我们可以尝试使用该账户登录来验证这一点。现在登录时，会收到条件访问错误提示：

乍一看，除了再次证明这些 API 对相同参数的命名约定毫无一致性之外，一切似乎都很正常。不过，观察力较强的人可能在浏览该策略时很快就注意到了某些怪异之处。没错，这也正是吸引我注意力的地方！

四、抱歉打扰，你知道“time”是什么吗？

在这个相当冗长的策略输出中，conditions 对象内部隐藏着一个非常陌生的 time 条件。

在我最初向 MSRC 报告此问题后不久，我发现了 Daniel Bradley 于 2023 年 11 月发布的博客。他在其中发现了基于时间的条件的存在[2]，但当时尚未找到实际应用该条件的方法。不过，在本博客发布时，Daniel 已于 2026 年 1 月发布了后续文章，成功通过 Graph API 使其生效[3]。请务必查阅这两篇文章！

那么，让我们仔细审视一下这个条件，看看它是如何运作的：

"time":&nbsp;{
&nbsp; "all":&nbsp;0,
&nbsp; "included":&nbsp;{
&nbsp; &nbsp; "type":&nbsp;0,
&nbsp; &nbsp; "timezoneId":&nbsp;null,
&nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/1/2026 12:00:00 AM"
&nbsp; &nbsp; },
&nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; "day":&nbsp;[0,&nbsp;1,&nbsp;2,&nbsp;3,&nbsp;4,&nbsp;5,&nbsp;6],
&nbsp; &nbsp; &nbsp; "startTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/1/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "allDay":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "isExcludeSet":&nbsp;false
&nbsp; },
&nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; "type":&nbsp;0,
&nbsp; &nbsp; "timezoneId":&nbsp;null,
&nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/1/2026 12:00:00 AM"
&nbsp; &nbsp; },
&nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; "day":&nbsp;[0,&nbsp;1,&nbsp;2,&nbsp;3,&nbsp;4,&nbsp;5,&nbsp;6],
&nbsp; &nbsp; &nbsp; "startTime":&nbsp;"3/31/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/1/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; "allDay":&nbsp;false
&nbsp; &nbsp; },
&nbsp; &nbsp; "isExcludeSet":&nbsp;false
&nbsp; },
&nbsp; "applyCondition":&nbsp;false
}

与其他所有已知条件的结构进行对比，该条件的定义似乎相当直观明了。通过测试得出的观察结果如下：

• 为激活该条件，应将 all 设置为 1。
• 基于时间的条件包含 included 和 excluded 集合定义，用于确定策略应在何时强制执行。若需启用其中一个或全部启用，还需将 type 设置为 1。
• 需要为集合定义一个 timezoneId，该字段应为字符串格式，例如 GMT Standard Time。
• 对于所选时区，需要选择 startDateTime 和 endDateTime 来界定按小时或按天策略生效的边界范围。这将确定策略的整体 dateRange。
• 需要定义策略在一周中的哪些 day（天）生效。取值范围从 0（周一）开始，到 6（周日）结束。在此阶段，可以选择任意需要评估的天数。
• 需要为每个已包含的 day 定义实际的 startTime 和 endTime，以确定策略在该天的生效时间段。典型例子是标准工作日时间，例如上午 09:00 到下午 05:00。或者，策略也允许将 allDay 键设置为 true，从而使条件在 24 小时内全天生效。

现在，我们对这个新条件有了更清晰的把握。然而，在这一阶段，我仍然感到困惑：这个看似核心的条件为何在网上几乎没有任何信息？不用说，我立刻采取了和其他研究人员一样的行动（由于过于急切地想测试策略效果，我差点封锁了自己的主管理员账户）。不过，在再次体会到应急备用账户的好处之后，我创建了一个名为 [email protected] 的测试用户，以便验证如何利用此条件在选定策略中有效植入“后门”。

五、等等，你是怎么绕过那条策略的？

攻击者通常希望在环境中实现不同级别的持久化，以确保即使初始访问权限被撤销，也能达成其目标。在传统环境中，攻击者会试图禁用某些限制性较强的条件访问策略，以便更轻松地访问环境。然而，禁用核心策略可能产生大量噪音，很可能会触发足够的警报，导致攻击者暴露行踪。

这正是该功能派上用场的地方。在我们开头提到的示例场景中，我们有一条显式阻止的条件访问策略。这条策略在很大程度上代表了组织中常见的安全边界，例如：

• 强制要求管理员使用安全密钥登录
• 仅允许从公司允许的 IP 地址范围访问租户
• 强制要求所有租户访问必须来自合规且受管理的设备

在我们的模拟场景中，攻击者试图利用 [email protected] 账户维持持久访问，但受到这条显式阻止控制的限制。假设攻击者在初始访问阶段已成功获取具有 Conditional Access Administrator（条件访问管理员）权限或更高级别角色的访问权限，他们便可以通过更新特定的条件访问策略，添加如下示例所示的 time 条件，从而绕过该策略：

"time":&nbsp;{
&nbsp; &nbsp; &nbsp; "all":&nbsp;1,&nbsp;#启用该条件
&nbsp; &nbsp; &nbsp; "included":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "type":&nbsp;1,&nbsp;#定义并启用包含集合
&nbsp; &nbsp; &nbsp; &nbsp; "timezoneId":&nbsp;"GMT Standard Time",&nbsp;#设置时区格式
&nbsp; &nbsp; &nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"4/2/2026 12:00:00 AM",&nbsp;#定义条件评估为真的起始日期
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/3/2027 12:00:00 AM"&nbsp;#定义条件不再评估为真的结束日期
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "day":&nbsp;[0,1,2,3,4,5,6],&nbsp;#设置为每周的每一天
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startTime":&nbsp;"4/2/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/2/2026 12:00:00 AM",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "allDay":&nbsp;true&nbsp;#设置是否全天生效
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "isExcludeSet":&nbsp;false
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "excluded":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; "type":&nbsp;1,&nbsp;#定义并启用排除集合
&nbsp; &nbsp; &nbsp; &nbsp; "timezoneId":&nbsp;"GMT Standard Time",&nbsp;#设置时区格式
&nbsp; &nbsp; &nbsp; &nbsp; "dateRange":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startDateTime":&nbsp;"4/2/2026 12:00:00 AM",&nbsp;#定义排除条件应被评估的起始日期
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endDateTime":&nbsp;"4/22/2026 12:00:00 AM"&nbsp;#定义排除条件的结束日期
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "daysOfWeek":&nbsp;{
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "day":&nbsp;[3,4],&nbsp;#设置排除条件在周四和周五生效
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "startTime":&nbsp;"4/2/2026 11:00:00 AM",&nbsp;#设置排除条件从&nbsp;GMT 时间&nbsp;11:00&nbsp;开始
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "endTime":&nbsp;"4/2/2026 01:00:00 PM",&nbsp;#设置排除条件在&nbsp;GMT 时间&nbsp;13:00&nbsp;结束
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "allDay":&nbsp;false
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "isExcludeSet":&nbsp;true&nbsp;#设置使用排除集合
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "applyCondition":&nbsp;true&nbsp;#设置条件为已应用

该策略包含了每周的所有天数，因此大多数情况下策略会正常评估……唯独在接下来的 20 天内，该策略不会在每周四和周五的 GMT 时间 11:00 至 13:00 之间被评估。

现在，当我们在 GMT 时间 11:00 至 13:00 期间尝试登录时，显式阻止策略被忽略，我们可以作为 [email protected] 成功进入租户。如下图所示：

查看登录事件（一旦日志生成后），我们可以看到，由于策略中被植入了时间排除后门，这条显式阻止策略未被评估：

如果试图查看该策略未被应用的原因，管理员很可能会感到困惑，因为该策略表面上看没有任何未满足的条件：

如果管理员在门户中查看策略定义，他们可能会注意到一些奇怪的蛛丝马迹。例如，他们可能会发现策略显示有三个活跃条件，但门户中仅有两个是可见的：

尝试使用 What if（假设分析）工具验证策略对用户的影响似乎毫无帮助。该工具暗示阻止策略应对该用户强制执行。这可能是因为策略是通过 Ibiza API 应用的，而该工具只能访问 Graph API 所报告的关于策略的信息：

最后，管理员很可能会尝试通过 Microsoft Graph 来验证策略。无论他们是直接使用 Graph Explorer 或自己的脚本，还是通过常用的管理 PowerShell 模块（例如 Microsoft.Entra）进行验证，结果同样无法为当前发生的情况提供合理解释。

尝试使用 Get-EntraConditionalAccessPolicy 命令集会提供另一个线索，表明出现了异常情况：

Get-EntraConditionalAccessPolicy -PolicyId 8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244
Get-MgIdentityConditionalAccessPolicy_Get: 1037: The policy you requested contains preview features. Use the Beta endpoint to retrieve this policy. &nbsp;Status: 400 (BadRequest) ErrorCode: BadRequest Date: 2026-04-02T09:13:58 &nbsp;[为简洁起见已省略剩余部分]

在花了几分钟安装 Microsoft.Entra.Beta 并运行 Get-EntraBetaConditionalAccessPolicy 后，我们确实得到了结果。但该结果实际上并未显示任何额外信息，更重要的是，其中完全没有策略中存在的 time 条件的任何痕迹。这表明 Graph 所能提供的关于该策略的信息仅限于此：

Get-EntraBetaConditionalAccessPolicy -PolicyId 8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244 | ConvertTo-Json -Depth 100 -EnumsAsStrings

{
&nbsp; "Conditions": {
&nbsp; &nbsp; "AgentIdRiskLevels": null,
&nbsp; &nbsp; "Applications": {
&nbsp; &nbsp; &nbsp; "ApplicationFilter": {
&nbsp; &nbsp; &nbsp; &nbsp; "Mode": null,
&nbsp; &nbsp; &nbsp; &nbsp; "Rule": null
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "ExcludeApplications": [],
&nbsp; &nbsp; &nbsp; "GlobalSecureAccess": {},
&nbsp; &nbsp; &nbsp; "IncludeApplications": [
&nbsp; &nbsp; &nbsp; &nbsp; "All"&nbsp;#策略应用于所有应用程序
&nbsp; &nbsp; &nbsp; ],
&nbsp; &nbsp; &nbsp; "IncludeAuthenticationContextClassReferences": [],
&nbsp; &nbsp; &nbsp; "IncludeUserActions": [],
&nbsp; &nbsp; &nbsp; "NetworkAccess": {}
&nbsp; &nbsp; },
&nbsp; &nbsp; "AuthenticationFlows": {
&nbsp; &nbsp; &nbsp; "TransferMethods": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "ClientAppTypes": [
&nbsp; &nbsp; &nbsp; "all"
&nbsp; &nbsp; ],
&nbsp; &nbsp; "ClientApplications": {
&nbsp; &nbsp; &nbsp; "AgentIdServicePrincipalFilter": {
&nbsp; &nbsp; &nbsp; &nbsp; "Mode": null,
&nbsp; &nbsp; &nbsp; &nbsp; "Rule": null
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "ExcludeAgentIdServicePrincipals": null,
&nbsp; &nbsp; &nbsp; "ExcludeServicePrincipals": null,
&nbsp; &nbsp; &nbsp; "IncludeAgentIdServicePrincipals": null,
&nbsp; &nbsp; &nbsp; "IncludeServicePrincipals": null,
&nbsp; &nbsp; &nbsp; "ServicePrincipalFilter": {
&nbsp; &nbsp; &nbsp; &nbsp; "Mode": null,
&nbsp; &nbsp; &nbsp; &nbsp; "Rule": null
&nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; },
&nbsp; &nbsp; "DeviceStates": {
&nbsp; &nbsp; &nbsp; "ExcludeStates": null,
&nbsp; &nbsp; &nbsp; "IncludeStates": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "Devices": {
&nbsp; &nbsp; &nbsp; "DeviceFilter": {
&nbsp; &nbsp; &nbsp; &nbsp; "Mode": null,
&nbsp; &nbsp; &nbsp; &nbsp; "Rule": null
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "ExcludeDeviceStates": null,
&nbsp; &nbsp; &nbsp; "ExcludeDevices": null,
&nbsp; &nbsp; &nbsp; "IncludeDeviceStates": null,
&nbsp; &nbsp; &nbsp; "IncludeDevices": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "InsiderRiskLevels": null,
&nbsp; &nbsp; "Locations": {
&nbsp; &nbsp; &nbsp; "ExcludeLocations": [],
&nbsp; &nbsp; &nbsp; "IncludeLocations": [
&nbsp; &nbsp; &nbsp; &nbsp; "All"&nbsp;#包含所有位置
&nbsp; &nbsp; &nbsp; ]
&nbsp; &nbsp; },
&nbsp; &nbsp; "Platforms": {
&nbsp; &nbsp; &nbsp; "ExcludePlatforms": [],
&nbsp; &nbsp; &nbsp; "IncludePlatforms": [
&nbsp; &nbsp; &nbsp; &nbsp; "all"&nbsp;#包含所有设备类型
&nbsp; &nbsp; &nbsp; ]
&nbsp; &nbsp; },
&nbsp; &nbsp; "ServicePrincipalRiskLevels": null,
&nbsp; &nbsp; "SignInRiskLevels": [],
&nbsp; &nbsp; "UserRiskLevels": [],
&nbsp; &nbsp; "Users": {
&nbsp; &nbsp; &nbsp; "ExcludeGroups": [],
&nbsp; &nbsp; &nbsp; "ExcludeGuestsOrExternalUsers": {
&nbsp; &nbsp; &nbsp; &nbsp; "ExternalTenants": {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "MembershipKind": null
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "GuestOrExternalUserTypes": null
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "ExcludeRoles": [],
&nbsp; &nbsp; &nbsp; "ExcludeUsers": [],
&nbsp; &nbsp; &nbsp; "IncludeGroups": [],
&nbsp; &nbsp; &nbsp; "IncludeGuestsOrExternalUsers": {
&nbsp; &nbsp; &nbsp; &nbsp; "ExternalTenants": {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "MembershipKind": null
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; "GuestOrExternalUserTypes": null
&nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; "IncludeRoles": [],
&nbsp; &nbsp; &nbsp; "IncludeUsers": [
&nbsp; &nbsp; &nbsp; &nbsp; "58845d0a-eccd-4c44-96b4-c8a61fe8e3e9" # 策略应用于一个特定用户
&nbsp; &nbsp; &nbsp; ]
&nbsp; &nbsp; }
&nbsp; },
&nbsp; "CreatedDateTime": "2026-03-31T21:42:34.9803608Z",
&nbsp; "DeletedDateTime": null,
&nbsp; "Description": null,
&nbsp; "DisplayName": "Block Bad Person",
&nbsp; "GrantControls": {
&nbsp; &nbsp; "AuthenticationStrength": {
&nbsp; &nbsp; &nbsp; "AllowedCombinations": null,
&nbsp; &nbsp; &nbsp; "CombinationConfigurations": null,
&nbsp; &nbsp; &nbsp; "CreatedDateTime": null,
&nbsp; &nbsp; &nbsp; "Description": null,
&nbsp; &nbsp; &nbsp; "DisplayName": null,
&nbsp; &nbsp; &nbsp; "Id": null,
&nbsp; &nbsp; &nbsp; "ModifiedDateTime": null,
&nbsp; &nbsp; &nbsp; "PolicyType": null,
&nbsp; &nbsp; &nbsp; "RequirementsSatisfied": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "BuiltInControls": [
&nbsp; &nbsp; &nbsp; "block"&nbsp;#匹配策略时强制执行显式阻止
&nbsp; &nbsp; ],
&nbsp; &nbsp; "CustomAuthenticationFactors": [],
&nbsp; &nbsp; "Operator": "OR",
&nbsp; &nbsp; "TermsOfUse": []
&nbsp; },
&nbsp; "Id": "8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244",
&nbsp; "ModifiedDateTime": "2026-04-02T08:24:58.4061247Z",
&nbsp; "SessionControls": {
&nbsp; &nbsp; "ApplicationEnforcedRestrictions": {
&nbsp; &nbsp; &nbsp; "IsEnabled": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "CloudAppSecurity": {
&nbsp; &nbsp; &nbsp; "CloudAppSecurityType": null,
&nbsp; &nbsp; &nbsp; "IsEnabled": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "ContinuousAccessEvaluation": {
&nbsp; &nbsp; &nbsp; "Mode": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "DisableResilienceDefaults": null,
&nbsp; &nbsp; "GlobalSecureAccessFilteringProfile": {
&nbsp; &nbsp; &nbsp; "IsEnabled": null,
&nbsp; &nbsp; &nbsp; "ProfileId": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "PersistentBrowser": {
&nbsp; &nbsp; &nbsp; "IsEnabled": null,
&nbsp; &nbsp; &nbsp; "Mode": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "SecureSignInSession": {
&nbsp; &nbsp; &nbsp; "IsEnabled": null
&nbsp; &nbsp; },
&nbsp; &nbsp; "SignInFrequency": {
&nbsp; &nbsp; &nbsp; "AuthenticationType": null,
&nbsp; &nbsp; &nbsp; "FrequencyInterval": null,
&nbsp; &nbsp; &nbsp; "IsEnabled": null,
&nbsp; &nbsp; &nbsp; "Type": null,
&nbsp; &nbsp; &nbsp; "Value": null
&nbsp; &nbsp; }
&nbsp; },
&nbsp; "State": "enabled",
&nbsp; "ObjectId": "8d7b8e12-f0e8-4190-a8e5-dd4de9bc0244",
&nbsp; "AdditionalProperties": {
&nbsp; &nbsp; "@odata.context": "https://graph.microsoft.com/beta/$metadata#identity/conditionalAccess/policies/$entity"
&nbsp; }
}

至此，我们可以有把握地说，攻击者已为自己创造了一个充足的机会窗口。即使其初始访问途径被阻断，他们也能重新进入租户。而不幸的是，如果管理员在某些情况下注意到特定时间段内的登录事件出现异常行为，他们很可能会对正在发生的事情感到困惑不解。

六、我能花点时间修复这个问题吗？

遗憾的是，答案是否定的。你无法在租户中关闭这一功能，因为它似乎是条件访问服务中相当核心的一部分。目前看来，查看确切策略的最可靠方法就是使用本文中展示的 Ibiza API。请注意，只要用户在租户中拥有 Conditional Access Administrator（条件访问管理员）或更高级别的权限，该条件就可能被添加到任何策略中。不过，即便我们无法阻止这种情况发生，至少我们或许可以对此进行监控。

七、如何监控此类问题？

好消息是，至少在策略中添加 time 条件的更改行为仍会记录在审计日志中！唯一的问题是，由于结构原因，查看变更的 Update policy（更新策略）事件解析起来有些困难。不过，我尝试（在一位友好机器人的协助下）编写了两个 KQL 查询，以帮助组织解析其日志中的相关事件，从而判断策略是否被添加了 time 条件。

第一个查询会显示所有的 Update policy（更新策略）事件，并尝试使其更易于人工阅读。这样管理员便能轻松查看策略的新旧状态：

AuditLogs
|&nbsp;where&nbsp;OperationName&nbsp;==&nbsp;"Update policy"
|&nbsp;extend InitiatedBy_UPN&nbsp;=&nbsp;tostring(InitiatedBy.user.userPrincipalName)
|&nbsp;extend InitiatedBy_App&nbsp;=&nbsp;tostring(InitiatedBy.app.displayName)
|&nbsp;extend Actor&nbsp;=&nbsp;iff(isnotempty(InitiatedBy_UPN), InitiatedBy_UPN, InitiatedBy_App)
|&nbsp;extend TargetPolicy&nbsp;=&nbsp;tostring(TargetResources[0].displayName)
|&nbsp;extend TargetPolicyId&nbsp;=&nbsp;tostring(TargetResources[0].id)
|&nbsp;mv-expand ModifiedProp&nbsp;=&nbsp;TargetResources[0].modifiedProperties
|&nbsp;extend
&nbsp; &nbsp; PropertyName&nbsp; =&nbsp;tostring(ModifiedProp.displayName),
&nbsp; &nbsp; OldValue&nbsp; &nbsp; &nbsp; =&nbsp;tostring(ModifiedProp.oldValue),
&nbsp; &nbsp; NewValue&nbsp; &nbsp; &nbsp; =&nbsp;tostring(ModifiedProp.newValue)
//&nbsp;去除转义后的 JSON 包装引号，使值显示为干净的 JSON 格式
|&nbsp;extend
&nbsp; &nbsp; OldValue&nbsp;=&nbsp;iff(OldValue startswith&nbsp;'"'&nbsp;and&nbsp;OldValue endswith&nbsp;'"',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;substring(OldValue,&nbsp;1, strlen(OldValue)&nbsp;-&nbsp;2),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;OldValue),
&nbsp; &nbsp; NewValue&nbsp;=&nbsp;iff(NewValue startswith&nbsp;'"'&nbsp;and&nbsp;NewValue endswith&nbsp;'"',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;substring(NewValue,&nbsp;1, strlen(NewValue)&nbsp;-&nbsp;2),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NewValue)
|&nbsp;project
&nbsp; &nbsp; TimeGenerated,
&nbsp; &nbsp; Actor,
&nbsp; &nbsp; OperationName,
&nbsp; &nbsp; Result,
&nbsp; &nbsp; TargetPolicy,
&nbsp; &nbsp; TargetPolicyId,
&nbsp; &nbsp; PropertyName,
&nbsp; &nbsp; OldValue,
&nbsp; &nbsp; NewValue,
&nbsp; &nbsp; CorrelationId
|&nbsp;sort&nbsp;by&nbsp;TimeGenerated&nbsp;desc, CorrelationId&nbsp;asc, PropertyName&nbsp;asc

以下 KQL 查询旨在仅标记出其中包含 time 条件的 Update policy（更新策略）事件。该查询通过在日志条目中查找字符串“TimeRanges”来实现，但在大规模运行时可能会稍慢一些。我猜想经验丰富的 KQL 用户可能能够优化它，但我确实希望确保安全团队至少能有一些工具用于快速威胁狩猎。因此，我还是将其包含在此处：

AuditLogs
|&nbsp;where&nbsp;OperationName&nbsp;==&nbsp;"Update policy"
|&nbsp;extend InitiatedBy_UPN&nbsp;=&nbsp;tostring(InitiatedBy.user.userPrincipalName)
|&nbsp;extend InitiatedBy_App&nbsp;=&nbsp;tostring(InitiatedBy.app.displayName)
|&nbsp;extend Actor&nbsp;=&nbsp;iff(isnotempty(InitiatedBy_UPN), InitiatedBy_UPN, InitiatedBy_App)
|&nbsp;extend TargetPolicy&nbsp;=&nbsp;tostring(TargetResources[0].displayName)
|&nbsp;extend TargetPolicyId&nbsp;=&nbsp;tostring(TargetResources[0].id)
|&nbsp;mv-expand ModifiedProp&nbsp;=&nbsp;TargetResources[0].modifiedProperties
|&nbsp;extend
&nbsp; &nbsp; PropertyName&nbsp; =&nbsp;tostring(ModifiedProp.displayName),
&nbsp; &nbsp; OldValue&nbsp; &nbsp; &nbsp; =&nbsp;tostring(ModifiedProp.oldValue),
&nbsp; &nbsp; NewValue&nbsp; &nbsp; &nbsp; =&nbsp;tostring(ModifiedProp.newValue)
|&nbsp;where&nbsp;NewValue has "TimeRanges"
//&nbsp;去除双重序列化的包装引号以便更清晰地显示
|&nbsp;extend
&nbsp; &nbsp; OldValueClean&nbsp;=&nbsp;iff(OldValue startswith&nbsp;'"'&nbsp;and&nbsp;OldValue endswith&nbsp;'"',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; substring(OldValue,&nbsp;1, strlen(OldValue)&nbsp;-&nbsp;2),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; OldValue),
&nbsp; &nbsp; NewValueClean&nbsp;=&nbsp;iff(NewValue startswith&nbsp;'"'&nbsp;and&nbsp;NewValue endswith&nbsp;'"',
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; substring(NewValue,&nbsp;1, strlen(NewValue)&nbsp;-&nbsp;2),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; NewValue)
|&nbsp;extend NewValueJson&nbsp;=&nbsp;parse_json(parse_json(NewValueClean))
|&nbsp;project
&nbsp; &nbsp; TimeGenerated,
&nbsp; &nbsp; Actor,
&nbsp; &nbsp; OperationName,
&nbsp; &nbsp; Result,
&nbsp; &nbsp; TargetPolicy,
&nbsp; &nbsp; TargetPolicyId,
&nbsp; &nbsp; PropertyName,
&nbsp; &nbsp; OldValue&nbsp; =&nbsp;OldValueClean,
&nbsp; &nbsp; NewValue&nbsp; =&nbsp;NewValueClean,
&nbsp; &nbsp; CorrelationId
|&nbsp;sort&nbsp;by&nbsp;TimeGenerated&nbsp;desc, CorrelationId&nbsp;asc

八、事件时间线

Reversec 与微软进行了接洽。以下是该案例处理过程的简要时间线：

• 2025 年 3 月 2 日 – 向 MSRC 提交报告
• 2025 年 3 月 3 日 – 分配案例编号
• 2025 年 3 月 3 日 – Reversec 补充了关于无法使用标准方法观察策略的额外背景信息
• 2025 年 3 月 11 日 – Reversec 请求更新进展
• 2025 年 3 月 11 日 – MSRC 回复称正在调查中
• 2025 年 3 月 28 日 – Reversec 请求更新进展
• 2025 年 4 月 21 日 – Reversec 请求更新进展
• 2025 年 4 月 28 日 – MSRC 确认该行为符合预期设计，不被视为安全问题。

完整回复如下：

再次感谢您向微软提交此问题。希望您一切顺利，并对此次的延迟表示歉意。我们确定此行为并非漏洞。因为基于时间的条件是 Conditional Access（CA，条件访问）中的一项安全功能，旨在根据一天中的时间或日期来限制对资源的访问。此功能目前处于私有预览阶段。我们不认为发现和使用基于时间的条件属于安全漏洞，原因如下：1) 它只能由 CA Administrators（条件访问管理员）启用；2) 向现有或新的 CA 策略添加基于时间的条件始终会记录在 CA 审计日志中。这些日志对租户内所有具有相应权限的管理员均可见。

总体而言，综合考虑各方面因素，与 MSRC 打交道的处理时间线还不算太糟。我也理解他们的观点，因为从技术上讲，这确实符合预期行为。然而，我仍然认为该条件缺乏可见性是一个非常现实的问题。即使审计日志事件包含了策略更新和 time 条件，但要解析这条日志条目并将其用于告警（以防有人真的在企业环境中利用它）也是极具挑战性的。

九、结论

条件访问策略是组织花费大量时间和精力才能正确配置的机制之一。因此，管理员和安全专业人员了解可应用于特定策略的所有可能条件至关重要。恶意滥用这种基于时间的条件确实需要相当高的权限。所以，只要组织将 Conditional Access Administrators（条件访问管理员）视为高权限角色，可被攻击者盯上的用户数量就可能有限，并且这些用户应受到其他附加控制的保护。

我能看到基于时间的条件对于某些企业的价值所在。例如，某些企业可能希望只允许在特定工作时间内访问其系统。我完全支持为组织提供能够使其日常工作更高效、更安全的工具。然而，我确实希望微软能优先考虑至少在 Graph Beta 端点中也公开详细的策略信息。这样一来，管理员就能更轻松地弄清楚特定策略中究竟定义了哪些内容，而无需针对这一特定场景去依赖 Ibiza API。即使某个功能处于私有预览阶段，当该功能自动出现在向全球所有租户提供的核心服务中时，也应保持一定程度的可见性一致性。

引用链接

[1] 《It’s Just a Matter of Time: Backdooring Conditional Access Policies》: https://labs.reversec.com/posts/2026/04/its-just-a-matter-of-time-backdooring-conditional-access-policies [2] 发现了基于时间的条件的存在: https://ourcloudnetwork.com/enabling-time-based-restrictions-in-conditional-access/ [3] 通过 Graph API 使其生效: https://ourcloudnetwork.com/configuring-time-based-conditional-access-policies/

交流群

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito Dubito《Entra条件访问策略中的时间后门》