Exploit Prevention Expert Rule AAC Examples

[Former Member]

Does anyone have AAC rule examples of *_TYPEs other than the ones listed in the offical documentation (https://docs.mcafee.com/bundle/endpoint-security-10.6.0-threat-prevention-product-guide-epolicy-orch...)?

I really appreciate how powerful these rules are but I cannot quite understand how some *_TYPEs are meant to be used and what values/flags they expect. For example, it's unclear how we're expected to use DLL_LOADED.

Thanks!

[Daveb3d]

I've not done anything with DLL_LOADED, but I've used various other ones, like NT_ACCESS_MASK, DESCRIPTION, PROCESS_CMD_LINE, VTP_TRUST and others.

For example, Include NT_ACCESS_MASK { -v "0x0020" } would block the call PROCESS_VM_WRITE on the target process, which would protect against shellcode injections and most reflective injections. 

My first guess at this was something like....

Target { Match PROCESS {
Include OBJECT_NAME { -v "DLLName" }
Include DLL_LOADED { -v "1 }

}

}

So this would identify not the DLL being accessed, but the modual itself loaded.  But I don't think this will work either.  The docs call it a "name-value bitmask."  I reached out to somebody to find out.  I'll post the answer as soon as I find out.

Dave

[Daveb3d · Accepted solution]

So I was pretty far off in my rule use, as I expected.

The DLL_LOADED is actually looking at what modules are or aren't loaded in a parent process.  

Include OBJECT_NAME { -v "Process.exe }
Include DLL_LOADED -name "LoadedModuleName(without .DLL on it)" { -v 0x1 }

It would then look for the process executing content either with or without this module loaded.

Hopefully this helps..  I can see some good use cases around loading Powershell related DLLs and then performing certain activity.

Dave

[Former Member]

Thanks David, I ended up using the SECTION type instead as I believe loading a library would also require loading a file-backed memory object.

It would be great if there was some kind of cheat sheet with Tcl snippets and how to use them. It'd also be great if we could understand the underlying kernel APIs that each type is abstracting (although perhaps this is asking for too much)

[Daveb3d]

Yes, for that purpose section will work as well.

I agree with your assessment.  I'll mention it to the PM.

Dave