Obviously, the title of this post is a joke. We should be detecting mimikatz as a priority. What I’d like to explore though is how to go a little bit further…

I was playing a lot with sysmon config recently, and spotted that there are at least two underutilized events that are most of the time omitted from the publicly available sysmon configs. And if they are included, they typically focus on mimikatz.

These are:

• ProcessAccess
• ImageLoaded

After a short discussion on Twitter, I decided to write a post about these two.

The ProcessAccess is an event that is triggered when process tries to get access to another process, and succeeds. Once you get the access granted, the process handle is given to your process, and you can use it in subsequent calls to allocate virtual memory, write to memory, read from memory, etc. – you pretty much can do whatever you want with that process.

Not so fast though.

The rights you are granted depend on many things. If you want to know more, go to MSDN and read about it, for our discussion we just need to focus on two things:

• ProcessAccess event logs _granted_ access events; it means they were successful.
• ProcesAccess is very noisy; this is because lots of processes abuse inter-process communication, and often request too many rights than they really need. See examples below:

This is why sysmon logs for the ProcessAccess event are very frustrating. There are just too many of them!

The good news is that we can do two things:

• Focus on specific use cases, e.g. access to lsass.exe
• Filter down the rest and look for some interesting cases.

The first one has been documented in many papers, mainly focused on mimikatz detection. The second one is what I will describe briefly below:

Assuming that you log every ProcessAccess event at first, you can try to add exclusions:

• GrantedAccess – exclude all that don’t include PROCESS_VM_WRITE and/or PROCESS_VM_READ; unfortunately, there is a lot of combinations and you need to build a number of rules to cover it all as sysmon doesn’t offer bitmask condition
• CallTrace – this is handy, you can immediately cherry-pick anything that includes the string ‘UNKNOWN’ (meaning that the sysmon can’t resolve the address of code from where the OpenProcess function was called to a specific image on the system)
• SourceImage – you can exclude the system processes; this is a bit of a stretch, because if malware is using some trick to inject code into e.g. svchost.exe, it means that any code injections originating from svchost.exe won’t be seen in sysmon logs; you have been warned
• TargetImage – this is a tough one for exclusions; probably most of the system binaries are safe, but are they… malware can launch any of them in a suspended state and inject code into them; again, you have been warned

What about the ImageLoaded?

This is a tricky one. We don’t want to see OS libs, we don’t want to see clean libs. We only want to see suspicious libs.

Some configs look specifically at these:

• mimilib.dll
• WinSCard.dll
• samlib.dll
• System.Management.Automation

Some analysts suggest looking for vbe*.dll loaded into Office programs to detect Macros being executed.

Still, these focus on a very narrow set of use cases i.e. mimikatz PowerShell libraries, Office Macros.

But there is always more.

What about these?

• nspr4
• nss3
• nssutil3
• plc4
• plds4
• softokn3
• sqlite3
• Pstorec
• *hook*
• KillProcDLL
• SelfDel
• airpcap
• ndisnpp
• NPPTools
• wpcap

Many of these are related to malicious activity one way or another. Some are from old malware, some only work on Windows XP or Windows 7, but it doesn’t change a thing. Even an old commodity malware needs to be detected, if accidentally executed, no? Same for functionality that some of these libraries offer – network sniffing, generic hooking, password decryption, killing processes, self deletion, etc.

And in an extreme case, we could build a baseline of all DLLs executed on all monitored systems over a period of time, and then build exclusion rules for all of them. Any new DLL could be highlighted.

There is no simple way to put together a config that will cater for all cases, but I think we need more rules that go beyond the mimikatz detection.

Any suspicious process that we can spot quickly by seeing it establishing access to other process it is us discovering a precursor to code/data injection. Any process that loads a blacklisted DLL needs to be inspected pronto.