Summary MDE Incident #ASRmageddon

Pirate,

here is more information about the big MDE incident of Friday 13.01.23. #ASRmageddon.

Management Summary:
On Friday, January 13, 2023, some customers running Microsoft Defender for Endpoint (MDE) experienced “false-positive” detections by ASR (Attack Surface Reduction) rules in the context of Office macro blocks after a signature update. These detections led to the deletion of files (ink, exe, etc.). The incorrect detection logic/signature was fixed in Security Intelligence version 1.381.2164.0 (and newer). With this updated version, the problem no longer occurs. For devices that were affected before the fix, the links and exe files must be explicitly restored. For customers who do not configure the ASR rule “Block Win32 API calls from Office macros” to “Block” mode, there is no false positive / “data loss”. 

There are now several good summaries on the general incident, the content sequence, the best detection methods for (still) affected endpoints, and scripts for link recovery.

[Recommended] Incident summary and FAQ from Microsoft:

https://github.com/microsoft/MDE-PowerBI-Templates/blob/master/ASR_scripts/ASR_rule_Block_Win32_API_calls_from_Office_Macro_issue_Q%26A.md

Summary of the incident and recommended actions from the community:

Microsoft recovery script (ATTENTION this is the updated version from tonight). (Attention this script requires elevated admin rights):

https://github.com/microsoft/MDE-PowerBI-Templates/blob/master/ASR_scripts/AddShortcuts.ps1

[Recommended] Script to recover from the community (does NOT require elevated admin rights):

https://github.com/InsideTechnologiesSrl/DefenderBug/blob/main/RestoreLinks.ps1

Hunting queries to detect still affected clients from Microsoft:

This query finds all device events for which AsrOfficeMacroWin32ApiCalls has been called in “block” mode and outputs them:

DeviceEvents

| where Timestamp >= datetime(2023-01-13)

| where ActionType contains "AsrOfficeMacroWin32ApiCallsBlocked"

| extend JSON = parse_json(AdditionalFields)

| extend isAudit = tostring(JSON.IsAudit)| where isAudit == "false"

| summarize by Timestamp, DeviceName, DeviceId, FileName, FolderPath, ActionType, AdditionalFields

| sort by Timestamp asc

This query finds all device events where AsrOfficeMacroWin32ApiCalls has taken effect and outputs them:

DeviceEvents| where Timestamp > datetime(2023-01-13)

| where ActionType contains "AsrOfficeMacroWin32ApiCallsBlocked"

| summarize by Timestamp, DeviceName, DeviceId, FileName, FolderPath, ActionType, AdditionalFields

| sort by Timestamp asc

This query finds all device events where AsrOfficeMacroWin32ApiCalls has taken effect and prints them out

DeviceEvents

| where Timestamp >= datetime(2023-01-13)

| where ActionType contains "AsrOfficeMacroWin32ApiCallsBlocked"

| summarize deviceCount = dcount(DeviceId)

| extend IsMoreThanTenThousand = iif(deviceCount> 10000, True, False)

[Recommended] Hunting queries to detect still affected clients from the community:

This query finds all device events where AsrOfficeMacroWin32ApiCalls for .lnk files was grabbed in “block” mode and outputs them:

DeviceEvents

| where Timestamp >= datetime(2023-01-13)

| where ActionType contains "AsrOfficeMacroWin32ApiCallsBlocked"

| where FileName contains ".lnk"

| extend JSON = parse_json(AdditionalFields)

| extend isAudit = tostring(JSON.IsAudit)

| where isAudit == "false"

| summarize by Timestamp, DeviceId, FileName, FolderPath, ActionType, AdditionalFields, isAudit

| sort by Timestamp asc

Troubleshooting

[Recommended] If applications are still blocked we recommend the following PowerShell Commands:

Updates the signature of Microsoft Defender AV/ASR via PowerShell:

cd %ProgramFiles%\Windows Defender 

MpCmdRun.exe -removedefinitions -dynamicsignatures 

MpCmdRun.exe -SignatureUpdate

The malicious signature starts from and including: 1.381.2140.0

The happy build (problem solved) starts from and including: 1.381.2164.0

[Recommended] The script fetches a selection of log files that execute rules for possible blocking by ASR and writes it to the variable “$mplog”.

“C:\ProgramData\Microsoft\Windows Defender\Support\” with a name starting with: “MPLog*”.

The second line prints lines in the log where there were blocked files.

$mplog = gci "C:\ProgramData\Microsoft\Windows Defender\Support\MPLog*" | Sort-Object -Property -CreationTime | Select-Object -First 1 | ForEach-Object{$_.FullName}

select-string -Path $mplog -Pattern Blocked.File.*OnOpen

Avoiding these incidents in the future:

To limit the extent of such “malicious” signatures in the future, we recommend rolling out signatures via rings. This ensures that a signature update is not immediately rolled out to the entire environment.
My MVP buddy Fabian Bader has written an excellent post that describes this process:

Link to the explanation of how Microsoft’s update channels work:

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/deployment-rings?view=o365-worldwide

[Recommended] Link explaining how update channels work from the community:

https://cloudbrothers.info/en/gradual-rollout-process-microsoft-defender/

Cheers

*Cpt