Demystifying attack surface reduction rules - Part 2

Hi Antonio Vasconcelos, Rob Mallicoat ,

Overview:

It is not in anyone's best interest to have rules enabled in Audit mode for very long - so what we are trying to achieve is get a good set of base rules that are somewhat typical in most organizations so that these ASR and Exploit Guard rules can be added from day one to speed up the maturity/adoption/security of the solution. The way we are looking at this is twofold:

1. Get a list of typical exclusions that can be added to ASR/ExploitGuard and add them as we enable Audit mode   
2. Identify outliers that are typically not encountered within the first week and simply change from Audit to Enabled
3. By this method we are effectively starting to improve from both ends of the extreme and working thru the rules to get to an adequate hardened position in a responsible manner ASAP

Just checking on some aspects of the ASR Rules?

GUID's for Rules:

The GUID’s used are just for the rule base on the client - it seems that the GUID string to reference the rules from inside Intune are different, I noticed this after creating a security baseline for Win 10 MDATP and then exporting it from Intune and realised that none of the GUID’s appear to have any match - is this due to the differences between client and Intune?

I was hoping to create a preferred benign “audit” starting point for customers, and then progressively work up more secure baselines that would act as templates for customers, now I am doubting how this might be achieved?

Strange Logs? from ExploitGuard:

Also noted that there is some curious anomalies where we are seeing a series of 7 tasks based on powershell but creating logging into “C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1”  and this seems to represent 10% of the 10,000 logs exported via the MDATP Console - but it did very much look like some efforts of the MDATP client behavior?

The reason for highlighting this is I can see evidence of the exact same behavior in two tenants.

Question: Is this normal behaviour for the MDATP Client - if so, why do we need to now create an ASR Rule to reduce the noise?

Surely this is something that should baked into the installation by default? I am making an assumption that this is benign and can be safely ignored?

Full listing of command line entry:

powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -Command "& {$OutputEncoding = [Console]::OutputEncoding =[System.Text.Encoding]::UTF8;$scriptFileStream = [System.IO.File]::Open('C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1', [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read, [System.IO.FileAccess]::Read);$calculatedHash = Get-FileHash 'C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1' -Algorithm SHA256;if (!($calculatedHash.Hash -eq '258a27019b0ed2b15c067fe83a56c6a24738d678e9bcd0ccc159a033d2d7c898')) { exit 323;}; . 'C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1' }"

Hope this makes sense, regards,

Dave C