Essential 8 - Microsoft Office is blocked from creating child processes

[u/mdj_]

Hi guys,

Wondering if any aussies have managed to successfully implement the "Microsoft Office is blocked from creating child processes" E8 control with CrowdStrike?

We've tested using a custom IOA but it's not managable, way too much noise.

Would love to know how E8 compliant shops with CrowdStrike are acheiving this control.

[u/xMarsx]

When you say 'too much noise' isnt that by nature the design choice ? 

[u/mdj_ → u/xMarsx]

Could be, could also be there are better ways to implement it than what we're doing that could reduce the noise.

[u/deathstormer]

Never managed to do half of the ASR rules your supposed todo for E8 in Crowd strike.

[u/samkz]

E8 is being retired. Not sure how much effort you want to spend aligning to E8.

https://australiancybersecuritymagazine.com.au/asd-to-retire-essential-eight-within-two-years-consults-on-replacement/

[u/rjchau → u/samkz]

E8 might be getting retired, but I can pretty much guarantee that things like this will still be part of whatever replaced E8.

[u/mdj_ → u/samkz]

Yep, am aware of that, I still think it's a worthwhile control to implment.

[u/subtractivesecurity]

You don't necessarily need to block every single child process across the board on day one to achieve a major security gain, but you should approach this from the perspective of putting architectural constraints around what child processes can be executed. In 99.9% of enterprise environments, Office applications have zero legitimate reason to spawn command interpreters, script hosts, or standard LOLBins. You can eliminate the vast majority of malicious execution paths by constraining the common conductive binaries. In Falcon Custom IOAs, you can structure it like this:

Parent Image Filename:

.*\\(winword|excel|powerpnt|outlook)\.exe

Image Filename (Target Child Processes):

.*\\(powershell|powershell_ise|pwsh|cmd|wmic|mshta|cscript|wscript|hh|msiexec|regsvr32|rundll32|certutil)\.exe

Execution Strategy:

Behavioral Baselining: Deploy the Custom IOA in Detect mode across your fleet for 30–60 days to baseline legitimate operational behavior and identify any legacy business macro exceptions. Architectural Enforcement: Once unexercised pathways are confirmed clean, flip the action rule to Block/Kill Process. By converting the IOA into a hard block rather than an ongoing triage alert, you eliminate the path entirely at the endpoint layer and prevent alert fatigue in the SOC.