Quick & Dirty Sysmon Replacement aka Process Hacker logging

Sysmon is great, no doubt. However… very often an overkill.

Yes, you’ve read this right. I say: who cares about registry writes, process access, driver or module loads, etc. ? What if we just want to log running processes?

Process Hacker comes to our rescue.

The recent versions of this tool include a very handy logging capability that is available not only from a GUI level (CTRL+L keyboard shortcut), but also helps to write stuff that is ‘happening’ directly to a log file – yes, as it happens.

I find it very useful as it helps to monitor unusual activity of the system w/o engaging the full-blown capabilities of Sysmon (performance!). And yes, I do know how weird it sounds… Sysmon cures everything…

How do we set our Process Hacker instance to deliver all this goodness?

We first run Process Hacker with our Admin creds. Then we open Hacker \ Options menu item:

Then choose one of the ‘Notification’ options and either leave it as it is (log everything) or we write down our own rules that can either include or exclude certain paths….

In the below example we include all the process names:

and then we exclude notepad*.exe:

We can include/exclude both processes and services. This is awesome. It’s simple, it’s working.

And if you are curious where the information about these is stored, look for a `ProcessHacker.exe.settings.xml`file that lists the following:

  <setting name="ProcessHacker.ExtendedNotifications.LogFileName">LOGFILEPATH</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ProcessList">PROCESSLIST</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ServiceList">SERVICELIST</setting>

where PROCESSLIST/SERVICELIST has a form of:

  • \e<pattern for exclusion
  • \i<pattern for exclusion

That’s it really… Nothing ground breaking, but a very handy tool for quick & dirty investigations. I find it most useful to detect ‘funny’ Windows 10 services that start ‘out of nowhere’. I then… usually kill them. One by one, you may eventually kill’em all…

Oh yeah.. it may help with malware analysis too 😉 but somehow.. the analysis techniques and priorities changed a lot over last few years…

Bringing down the house, a.k.a. losing 20+-years old attachment to the email attachments

It’s been 20+ years since we observed the first mail worms out there (VBS files, SHS files, Macro viruses). I think it’s time to start thinking of reasonable measures that can stop these infections/propagation efforts. It’s easy to talk about macroviruses hidden in attachments, same as we did in1999, but it’s shocking to discuss this in 2018. And the problem is much wider – it’s any attachment that can be processed in a way that is undesirable…

The solution is simple:

  • Disable all email attachments, by default.
  • Enable email attachments only as per business need.
  • Encourage non-attachment file exchange+formal protocol for file exchange (email/slack/microsoft teams/skype for business conversation prior to sending, so it’s expected, whitelisting senders, etc.).
  • And for every email attachment that actually passed through the first line of defense checks, run through a sandbox, observe behavior, block if malware.

It’s a pretty simple algorithm. One that may actually work. And AFAIK it’s been utilized for at least 5 years in many setups.

Yet… day by day, month, by month, we discover new file extensions that can sneak in through a poor man’s blocking device which is ‘block files with the extension xyz’. Again, instead of blocking everything by default, we only block using a small number of file extensions. This is a wishful thinking.

Why do we do it this way?

I have no idea. It seems to be a standard.

Even if we all know the good ol’ firewall rules of thumb: first block everything by default, and then enable as per need, via a formalized process, we still let attachments fly.

But it’s 2018. The era of a smarpthone, Dropbox, and other cloud solutions.

Coming back to blocking… let me repeat: if we can block _all_ email attachments, and then only allow some per business needs we are already establishing some control over the environment that has not been a subject to such scrutiny. This is good news.

So…. In case you are wondering… why block all, for good?

Well… what about the fact that an email is an archaic way of communication?  And email attachments are even more archaic. To send one via email vs. to upload it to cloud is a great test of sender’s capabilities/access to modern solutions. It’s almost like sending via fax vs. email 10 years ago. Email attachments should simply die, peacefully, but quickly.

Plus, blocking by extensions is a whack-a-mole game. Every day you can find users installing new cool tools that ‘takes care’ of many new file extensions (see examples below) + they are often real vulnerabilities, 0days are not impossible.
So, even if you block 200 file extensions, there could be still one that you don’t know about, and which may help to exploit or bypass some security control.

And so that we are more specific – with regards to programs ‘handling’ more than they should….there is a Winzip registering handling ‘by default’ for these files extensions:

There is Winrar for these as well:

And it’s just a tip of the iceberg.

One could e.g. send .ace files, .vmdk files. As long as these popular archivers are installed and associated with the respective file extensions, any sort of trickery using these files is actually very feasible.

And to expand on this: Office, Acrobat, Libre, Office-wannabes and clones, Flash, Adobe products, programming editors, file managers, even sysinternals tools add a lot of Registry entries that will be accessed anytime the program-specific file will be opened e.g. via a double click in Windows Explorer. Again, so many opportunities for an abuse.

It’s actually a lost battle, if you want to chase after each new file extensions, the only way to tackle it is to block everything seen as an attachment by default, and manage exclusions as per need. While it doesn’t resolve all issues, it helps to mitigate many.

And.. why not… maybe there is a need for non-technical people to convey business in 2018 using other, more secure means than e-mail; e.g. ones that are company specific, and can be as simple as using a private cloud to exchange files, instead of emailing them. Dunno, this is a new way of thinking of it (despite this being a subject for discussions for many years), so there is no ‘good, one-and-only’ solution as of now. Since we know what the problem is, perhaps one comprehensive solution will eventually emerge….

Blocking attachments by a file extensions can be a good defense-in-depth approach, but real-life case scenarios teach us that it is a reactive way to react to techniques that are at least 20 years old. I think we can do better… And on that note, a file extensions is nothing when compared to analysis of an internal structure of the attached file. Sending a CSV file with an extension XLS, or RTF with an extension .docx will make Office application open these files no matter what, and in a format they ‘feel’ the most ‘comfy’ with. Internal conversions may happen on the way. Some of them may require manual confirmation, but still, who out of all users understands the quirks of file formats? Especially these that involve macros (again, this is a common occurrence of non-malicious macros)?

And by an example… When we see a csv file extension in the attachment …. Is it a CSV file, a Word Document, an Excel, or even an Access file? Is it written using the old document-writing routine (OLE compound file), or a new one – the zip archive format (Office 2007+). Is it malicious? or shows traces of possibly malicious activity? Is it handled properly by an assigned application?

Despite Windows 10 being really “security-conscious”, the 3rd party tools will imho remain a big problem that can’t be tackled w/o some dramatic changes to the way we do things today. Perhaps starting with a ‘simple’ thing like dropping by default email attachments… or at least quarantining all of them.