You are browsing the archive for Compromise Detection.

Can we stop detecting mimikatz please?

February 3, 2019 in Compromise Detection, Sysmon

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.

Update: After I posted this on Twitter, The Cyber provided a very important comment:

One thing to mention that even with a small list of things to look for in the sysmon config for image loads and process access, it can still be taxing to some systems. They never be suitable sources for hunting on a mass scale

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.

Trivial Anti-BlueTeam trick for 32-bit systems

December 6, 2018 in Anti-*, Compromise Detection, EDR, Incident Response

I love evasion tricks of any sort. Sometimes they can be very elaborate, and sometimes… incredibly trivial, almost stupid really. Such is the trick I am describing below. It works on 32-bit Windows only, and that’s because it relies on a folder structure that is (exclusively) present on 64-bit systems.

If we look at logs from various process monitoring tools we can notice that they omit a very important info. They don’t tell us what is the architecture of the logging system. Unless it is somehow self-evident (e.g. ‘bitness’ is a part of a host naming convention) there is no way to tell whether the process is executed on a 32- or 64- box.

These 3 folders are present on 64-bit systems only:

  • c:\windows\syswow64\
  • c:\windows\sysnative\
  • c:\Program Files (x86)\

Nothing (apart from access rights) stops us from re-creating them on a 32-bit system.

Imagine seeing the following paths in the logs indicating that calc.exe or iexplore.exe was launched on a system:

  • c:\windows\syswow64\calc.exe – from a 64-bit system
  • c:\windows\syswow64\calc.exe – from a 32-bit system
  • c:\windows\sysnative\calc.exe – from a 64-bit system
  • c:\windows\sysnative\calc.exe – from a 32-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 64-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 32-bit system

For all logs from 32-bit systems it’s obvious that they are fake.
How can you tell the difference though if your logs don’t tell you the architecture of the system where they come from?

This opens up a lot of opportunities for an impersonation.

Threat hunting efforts that rely on full paths for analysis purposes (whitelisting, LFO, etc.) could be easily fooled to accidentally exclude, or include bad processes that are executed from locations that pretend to be ’64-bit legitimate’.
And since most of the orgs are mixed 32/64 environments, the logs from all systems will be inevitably clustered together, and detection rules will be applied to them as a whole.

Admittedly, a malicious svchost.exe executed from c:\windows\syswow64\svchost.exe is definitely less suspicious than one starting from %APPDATA%:

Now, could this be a bad process?

  • c:\Program Files (x86)\Windows Defender\MpCmdRun.exe