使用Intune自定义属性追踪Microsoft Defender PUA策略变更

本文探讨了如何利用Bash脚本和Intune自定义属性监控macOS设备上Microsoft Defender PUA策略的意外变更,提供了详细的脚本实现、日志收集和故障排除方案,以增强终端安全可见性。

使用Intune自定义属性追踪Microsoft Defender PUA策略变更

在瞬息万变的终端安全战场上,Microsoft Defender for Endpoint是抵御网络威胁浪潮的警惕守护者。但即使是最好的守护者有时也可能有点……健忘。当macOS设备上的Microsoft Defender PUA(潜在不需要的应用程序)策略设置开始神秘更改时会发生什么?在我之前的文章中,我们探讨了“使用Microsoft Intune的高级macOS保护”,而本文正是基于这一原则展开的。

变化的PUA策略之谜

在您拉响安全警报之前——请别担心!我们已在多个租户中测试,此问题仅出现在一个特定租户中,这强烈表明是独特的配置问题,而非普遍存在的漏洞或安全风险。所以无需取消您的周末计划或翻出2012年的“世界末日”播放列表。调查仍在进行中,但本文介绍的方法可能有助于其他面临类似配置谜题的人!

特别感谢我的合作伙伴(也是我的个人“神探加杰特”)Melvin Luijten在调查中提供的帮助!

问题描述

设想这样一个场景:您已在macOS设备群中配置并部署了Microsoft Defender for Endpoint PUA策略。一切运行顺利,直到有一天,您碰巧注意到某些设备的设置与您通过Intune部署的设置不同。您并未进行任何策略更改,然而设置却自行发生了漂移。就像发现您的家具在一夜之间被重新摆放了一样!

经过一番调查,我们发现某些macOS设备上的Microsoft Defender PUA策略偶尔会在“审核”和“关闭”模式之间切换,而没有任何管理员干预。这台“机器中的幽灵”不仅仅是好奇,它代表着重大的安全隐患。是我们的策略遭到破坏了吗?是Defender for Endpoint本身存在问题?还是Intune配置配置文件的问题?

挑战

问题很清楚,但解决方案却不那么明确。Intune本身不提供设备级别的详细策略变更历史跟踪,因此我们需要一种方法来:

  • 监控每台设备上的当前PUA策略状态
  • 跟踪配置变更发生的时间
  • 将此信息报告回Intune以实现可见性

换句话说,我们需要一个轻量级的数字私家侦探,就像福尔摩斯一样,但没有烟斗。

从终端,您可以运行命令 mdatp threat policy list 来查看当前状态。本文将更新更多关于调查此行为时应检查哪些日志文件的信息。

我知道您在想什么:“可能有几十种解决方案可以用花哨的UI和彩色仪表板来解决这个问题。”您说得对!但那样有什么乐趣呢?

我正致力于提高我的Bash脚本技能(这段旅程在“我是命令行向导!”和“为什么这不行?我恨电脑。”之间摇摆不定)。所以,面对神秘变化的PUA配置时,我首先想到的显然是“这听起来是写更多Bash脚本的完美借口!”

在您开始爬上屋顶高呼更好的替代方案之前,我承认确实有其他方法。您可以滚动到本文末尾查看我考虑过的一些替代方案。我也邀请您分享您将如何应对这一特殊问题的见解。

是的,我们正在与微软合作,进一步调查这种奇怪的Microsoft Defender PUA策略变更。在此期间,我有点忘乎所以了……

双脚本解决方案

为了应对这一挑战,我开发了一个双脚本系统,它们协同工作以提供全面的PUA策略变更跟踪:

  • 增强型MDATP策略检查器:监控Defender的PUA策略并记录变更。就像是您福尔摩斯身边的华生。
  • 自定义属性脚本:将这些变更报告给Intune,以实现集中可见性。像是Inspector Lestrade,但他实际上会倾听(对于那些没看过《神探夏洛克》的人——这可能是个代沟问题……)。

让我们分解每个组件的工作原理以及它们如何协作来解决我们的谜题。

增强型MDATP策略检查器:侦探

我们这个二人组中的第一个脚本负责检查Microsoft Defender PUA策略的当前状态并维护变更历史。可以把它想象成不断收集线索的侦探,但没有电视剧侦探常见的咖啡因成瘾和混乱的个人生活。

它做了什么

此脚本执行多项功能:

  • 验证Microsoft Defender进程是否正在运行
  • 定位并验证MDATP命令行工具
  • 检索当前的Microsoft Defender PUA策略配置
  • 记录当前状态和变更历史

脚本核心

核心功能围绕着运行 mdatp threat policy list 命令并分析其输出,就像进行数字测谎测试一样:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
#-------------------------------------------------------------------------------
# Function: analyze_pua_configuration
# Purpose: Analyze the PUA configuration from the threat policy
# Uses global variable PUACHECK
#-------------------------------------------------------------------------------
analyze_pua_configuration() {
    log "INFO" "Analyzing PUA configuration"
    
    if echo "$PUACHECK" | grep -q "Threat type: potentially_unwanted_application"; then
        # PUA policy exists, determine the action setting
        if echo "$PUACHECK" | grep -q "Action: audit"; then
            log "INFO" "PUA status: Audit (PUAs are detected but not blocked)"
            
            # Store for historical tracking
            echo "$(date +"%Y-%m-%d %H:%M:%S") - PUA_ACTION=audit" >> "$POLICY_FILE"
            echo "audit" > "$CURRENT_POLICY_FILE"
            
            if [ "$DEBUG" -eq 1 ]; then
                echo "=== Enhanced MDATP Policy & Health Checker Completed Successfully ==="
            fi
            
            echo "PASSED: PUA in Audit Mode"
            return 0
        elif echo "$PUACHECK" | grep -q "Action: block"; then
            log "INFO" "PUA status: Block (PUAs are actively blocked)"
            
            # Store for historical tracking
            echo "$(date +"%Y-%m-%d %H:%M:%S") - PUA_ACTION=block" >> "$POLICY_FILE"
            echo "block" > "$CURRENT_POLICY_FILE"
            
            if [ "$DEBUG" -eq 1 ]; then
                echo "=== Enhanced MDATP Policy & Health Checker Completed Successfully ==="
            fi
            
            echo "PASSED: PUA in Block Mode"
            return 0
        else
            log "WARNING" "PUA status: Unknown (policy exists but action is undefined)"
            
            # Store for historical tracking
            echo "$(date +"%Y-%m-%d %H:%M:%S") - PUA_ACTION=unknown" >> "$POLICY_FILE"
            echo "unknown" > "$CURRENT_POLICY_FILE"
            
            if [ "$DEBUG" -eq 1 ]; then
                echo "=== Enhanced MDATP Policy & Health Checker Completed with Warnings ==="
            fi
            
            echo "FAILED: PUA status Unknown"
            return 1
        fi
    else
        log "WARNING" "No PUA configuration found"
        
        # Store for historical tracking
        echo "$(date +"%Y-%m-%d %H:%M:%S") - [WARNING] No PUA configuration found" >> "$POLICY_FILE"
        echo "NOT_CONFIGURED" > "$CURRENT_POLICY_FILE"
        
        if [ "$DEBUG" -eq 1 ]; then
            echo "=== Enhanced MDATP Policy & Health Checker Completed with Warnings ==="
        fi
        
        echo "FAILED: PUA Not Configured"
        return 1
    fi
}

此代码片段显示了脚本如何提取PUA策略操作(审核/阻止/关闭)并以两种不同的方式存储:

  • 在历史日志中,维护所有检查的记录
  • 在当前状态文件中,仅包含最新值

您可以从我的GitHub存储库下载完整的脚本。

日志文件

脚本维护多个日志文件,每个都有特定用途。就像为回收准备了单独的容器:一切各得其所,井井有条:

  • 主日志 (${SCRIPT_NAME%.*}.log):包含所有常规脚本执行信息。日常日记。
  • 错误日志 (${SCRIPT_NAME%.*}_error.log):仅包含错误信息,便于故障排除。“出错事项”精彩集锦。
  • 策略历史日志 (pua_policy.log):所有策略状态和变更的历史记录。
  • 当前策略文件 (current_pua_policy.txt):仅包含最新的策略状态。

为了防止这些日志无限增长,脚本实施了日志轮换,将超过1MB的文件移动到.old扩展名。

注意:目前,它只会保留1个.old文件用于历史目的。这些脚本本意是作为故障排除机制使用,但也可以根据需要长期运行。

自定义属性脚本:报告员

第二个脚本是我们的报告员,将侦探的发现转化为Intune管理员的可操作情报。

它做了什么

这个自定义属性脚本:

  • 从第一个脚本创建的日志文件中读取当前策略状态
  • 将其与先前状态进行比较以检测变更
  • 将信息格式化为Intune的自定义属性系统
  • 维护变更发生时间的记录

脚本核心

此脚本最关键的部分是其变更检测和报告逻辑:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# Format output for Intune Custom Attribute
debug "Formatting output for Intune Custom Attribute"
if [ "$PREVIOUS_STATE" = "INITIAL_CHECK" ]; then
    debug "Initial check - reporting current state only"
    echo "PUA_Policy=$CURRENT_STATE"
elif [ "$CURRENT_STATE" != "$PREVIOUS_STATE" ]; then
    debug "State change detected - reporting change"
    echo "PUA_Policy=Changed from $PREVIOUS_STATE to $CURRENT_STATE on $(date '+%Y-%m-%d')"
else
    debug "No change in state - reporting with last change date"
    echo "PUA_Policy=$CURRENT_STATE (unchanged since $(date -r "$PREVIOUS_STATE_FILE" '+%Y-%m-%d'))"
fi

if [ "$DEBUG" -eq 1 ]; then
    echo "=== MDATP Custom Attribute Script Completed ===" >&2
fi

这种优雅而简单的逻辑处理三种不同的场景:

  • 首次运行:仅报告当前状态。“你好,世界!”
  • 检测到变更时:报告变更内容及时间。“情况复杂了。”
  • 无变更时:报告当前状态以及上次修改时间。“历经多年,婚姻依旧。”
  • 报告出现的任何错误

弹性回退机制

如果我们的主要数据源出现问题怎么办?自定义属性脚本包含一个智能回退机制:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# First check if the current policy file exists and has content
    if [ -f "$CURRENT_POLICY_FILE" ] && [ -s "$CURRENT_POLICY_FILE" ]; then
        local current_state=$(cat "$CURRENT_POLICY_FILE")
        debug "Found current policy file with state: $current_state"
        echo "$current_state"
        return
    fi
    
    debug "Current policy file not found, checking policy log file"
    
    # Fallback to parsing the log file if current policy file is unavailable
    if [ ! -f "$POLICY_FILE" ]; then
        debug "Policy log file not found, returning NOT_CONFIGURED"
        echo "NOT_CONFIGURED"
        return
    fi

这确保了即使某个日志文件不可用或损坏,脚本也能保持弹性。

脚本如何协同工作

此解决方案的妙处在于这两个脚本如何像精心编排的舞蹈一样协作,但闪片更少,Bash命令更多(反正我不跳舞):

  • 增强型MDATP脚本定期运行(例如每15分钟/1小时/3小时),检查Defender的PUA配置并记录结果
  • 自定义属性脚本由Intune在收集自定义属性时执行,读取第一个脚本创建的日志并报告变更。通常这大约每8小时发生一次。

这种任务分离创建了一个系统,其中:

  • 繁重的工作在设备本地完成(检查Defender PUA状态并不难,但嘿,正因为我们可以……)
  • 只有汇总的结果报告回Intune
  • 完整的历史记录保留在macOS设备本地,用于故障排除
  • 这些日志也可以使用Intune收集

要是我们所有的监控系统都这么贴心就好了……

在Intune中看到的内容

部署脚本后,管理员将在Intune控制台的“设备 > macOS > 自定义属性 > [pua_custom_attribute_script]”下看到以下内容:

这提供了以下可见性:

  • 每台设备上的当前策略状态
  • 策略何时发生了变更
  • 脚本本身是否正常工作

使用Intune远程收集macOS日志:无需访问权限!

您知道可以使用Microsoft Intune远程收集macOS设备的日志吗?这一强大功能非常适合在您没有物理访问权限时,或者当您坐在椅子上太舒服而不愿穿过办公室时,对设备进行故障排除。

  1. 登录Microsoft Intune管理中心
  2. 导航到“设备 > macOS > 脚本”并选择一个macOS Shell脚本
  3. 在“设备状态报告”中,选择目标设备
  4. 选择“收集日志”
  5. 输入要收集的路径
    • 例如:/Library/Logs/Microsoft/IntuneScripts/mdatp/pua_policy.log
  6. 点击“确定”以启动收集

日志将在Intune管理代理下次签入时收集,这通常每8小时发生一次。 当日志在Intune中可用时,您可以通过点击“下载日志”来收集它们。

额外信息

收集日志时,Intune会自动包含其自身代理的日志,来自:

  • /Library/Logs/Microsoft/Intune
  • ~/Library/Logs/Microsoft/Intune

这些额外的日志(名为IntuneMDMDaemon日期-时间.log和IntuneMDMAgent日期-时间.log)可用于故障排除管理代理本身。 如果您指定的任何文件无法找到或具有不正确的扩展名,您将在下载中一个名为LogCollectionInfo.txt的文件中找到它们。祝狩猎愉快!

调试模式:窥探内部机制

两个脚本都包含一个有用的调试模式,可以通过简单的环境变量激活。

1
sudo DEBUG=1 bash ./enhanced_mdatp_pua.sh

在调试模式下,您将看到大量信息打印到控制台:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
=== Enhanced MDATP Policy & Health Checker Started (Debug Mode) ===
[INFO] Enhanced MDATP Policy & Health Checker started
[INFO] Checking if Microsoft Defender for Endpoint processes are running
[INFO] Process [wdavdaemon_enterprise] is running
[INFO] Process [wdavdaemon_unprivileged] is running
[INFO] Process [wdavdaemon] is running
[INFO] Microsoft Defender is running properly (all processes verified)
[INFO] Current user: root
[INFO] PATH environment: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
[INFO] Searching for mdatp location...
[INFO] mdatp location from which: /usr/local/bin/mdatp
[INFO] Found mdatp at: /usr/local/bin/mdatp
[INFO] Checking for Microsoft Defender command-line tool (mdatp)
[INFO] Microsoft Defender command-line tool (mdatp) is available at /usr/local/bin/mdatp
[INFO] Retrieving threat policy information
[INFO] Successfully retrieved threat policy information
[INFO] Analyzing PUA configuration
[INFO] PUA status: Audit (PUAs are detected but not blocked)
=== Enhanced MDATP Policy & Health Checker Completed Successfully ===
PASSED: PUA in Audit Mode

这种详细输出非常适合故障排除和了解在设备上物理工作时流程每一步具体发生了什么。

如果……会发生什么?

未部署增强脚本

如果仅部署自定义属性脚本,它将报告:

1
PUA_Policy=No information available yet – MDATP checker has not run

这使得识别脚本未完全部署(尚未)的设备变得容易。这也可能意味着第一个脚本没有首先运行,而自定义属性脚本却运行了。我们未在这些脚本中使用锁文件检查。

未部署自定义属性脚本

如果仅部署增强脚本,您在Intune的自定义属性中将看不到任何信息,但本地日志仍会保留在设备上,供需要时手动检查。

Defender出现问题

增强脚本包含错误检查。如果Defender进程未运行或MDATP工具不可用,这将在日志和自定义属性中反映出来:

1
PUA_Policy=DEFENDER_ERROR

考虑的替代方案

是否有其他方法来监控Defender策略?是的,但每种都有局限性,就像饮食选择一样——技术上巧克力蛋糕有替代品,但它们真的同样令人满意吗?

  • Microsoft Defender for Endpoint(高级搜寻)门户:显示当前合规状态,但缺乏详细(历史)变更跟踪。
  • Microsoft Sentinel:可以收集和分析Defender日志,但需要额外的许可和设置复杂性。
  • 第三方监控工具:通常成本高昂,并且可能与Intune集成得不够紧密。

此解决方案通过使用您已经部署的技术,以最小的开销提供有针对性的监控,从而填补了这一空白。

总结

通过实施此双脚本解决方案,我们从对Defender PUA策略不确定的状态转变为拥有完全的可见性和变更跟踪。当策略意外变更时,我们可以看到:

  • 哪些设备受到影响
  • 变更何时发生
  • 变更是什么(从何值变为何值)

怀疑或嫌疑:情节愈发复杂

随着我们调查的继续,我们已经缩小了策略变更谜团的一些潜在嫌疑范围。主要嫌疑人?也许是一个旧的(未分配的)策略配置可能与较新的设置配合不佳?

我们正在研究可能像数字幽灵一样困扰我们当前设置的旧配置。尽管我们在设备上找不到这些旧策略的任何踪迹。特别令人困惑的是,这些神秘变更仅出现在macOS设备上,而Windows设备则完全不受影响。

我们已经彻底检查了证据,没有发现入侵或恶意软件的迹象。可以说,数字犯罪现场没有指纹。这强烈表明我们正在处理一个系统配置问题,而非恶意行为者。

进一步证实我们怀疑的是,我们已在多个租户中测试过,发现此现象仅出现在一个特定租户中,这强烈表明是独特的配置问题,而非普遍存在的漏洞或安全顾虑。所以无需拉响安全警报、取消周末计划,或准备自2012年以来一直精心策划的“世界末日”播放列表。

此案仍然悬而未决,我们的调查工作仍在继续。本文中描述的监控脚本已成为我们警惕的助手,在我们深入研究macOS特定策略行为和潜在配置冲突时,保持监视并记录任何进一步的意外变更。

结论

像任何好的侦探故事一样,有时调查会走向意想不到的转折。随着我们发现更多线索并最终破解此案,我将更新这篇文章。在那之前,我们的脚本将站岗守卫,确保没有任何策略变更被忽视或未记录。

获取脚本

本文讨论的脚本可在我的GitHub存储库中找到。请随时根据您的环境和特定监控需求进行调整。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计