Monthly Archives: March 2018

Host activity monitoring

20,000 Leagues Under The Sand – Part 2

read part 1

As a newbie sandboxer, the biggest obstacle for me was finding a way of getting in-depth information on what actions were being performed by malware I wanted to test. In particular, I wanted to be able to drop some samples, go away and make lunch, then come back and be looking at some results. That meant stepping through it in a debugger was out, or at least a lesson for another day. You’ve probably already seen that I ended up using Sysmon, but let’s have a look at the alternatives for a moment.

Built in Windows logging

Filesystem forensics

  • The files in C:\Windows\Prefetch\ can show if executables were run
  • The AppCompatCache registry key and AmCache.hve hive contain more detailed information on program execution, though neither logs individual execution instances or command line options
  • You can diff the filesystem – have a clean copy, either of the Master File Table or of the entire structure – and compare to see what’s changed; this is a fairly intensive operation, especially if you intend to see if a known good file has been replaced with a malicious version
  • There are tools for parsing registry hives so identifying new/modified keys is possible

Creating your own API call logging

  • If you’re a good enough programmer to write code that logs API calls, this is the gold standard. I am not (yet) up to this. It is possible to monitor for most of the interesting events such as process and file creation, registry modification etc. using filter drivers. If you want to go a step further and monitor (or even intercept and change) system calls, you need to be looking at DLL injection. This is the method used by Cuckoo sandbox, among many others.

Building monitoring in to the virtualisation

  • Technically this is all just code simulating hardware running other code. If you’re smart enough to modify a hypervisor so that it can recognise and log API calls within its guests, go for it. Please excuse me for thinking you’re a bit mad though!

Options #1, #2 and #4 hold an additional advantage of being difficult or impossible for sandbox evasion techniques to pick up on.

And then we get to Sysmon, which is in effect a version of #3, but it has a big advantage: somebody else did all the work for us! Hooray for Mark Russinovich and Thomas Garnier. Many sandboxes do API call monitoring; sometimes it can be a little bit excessively detailed (hello Cuckoo) but as far as understanding what malware is doing goes, it’s the bee’s knees. Let’s have a look at what you can get out of it.

Sysmon ProcessCreate event output

Sysmon Process Created event

We’ll ignore for now how much my UI leaves to be desired. Here is perhaps the most commonly of interest event to you: Process Created. In this event you have a wealth of data including not only the location of the executable, launch command and parent processes, but the MD5 and SHA256 hashes of the file. You can also get the import hash here too – though I’d forgotten to turn it on for this run. You can see what ran, from where, by whom, and how it was run, in a glance.

Sysmon File Created event output

Sysmon File Created event

Next up we can log the act of creating a file; in this case a trojan makes new copy of itself which is placed in C:\Users\<username>\System\Library\mshost.exe.

Sysmon Registry Value Set event data

Sysmon Registry Value Set event

You can also monitor for interesting things happening in the registry. This is one of the primary methods by which malware achieves “persistence”, i.e. the ability to remain active on the system it infects. Here we can see a new entry being created in one of the user’s Run keys.

Sysmon Network Connection output

Sysmon Network Connection event

In a final example, Sysmon allows you to detect initiation of network connections; not only do we have the network level data of the destination IP and port captured, but the destination hostname is also identified.

In just four event types, Sysmon is able to record the malware starting, hiding itself, achieving persistence, and contacting its Command and Control server. This is the power of logging API calls. But wait – there’s more! This only scratches the surface of what Sysmon can do. It is also capable of identifying:

  • A process changing the creation time of a file
  • Process termination
  • Loading of drivers
  • Loading of additional modules in to existing processes
  • Creation of threads within other running processes
  • Raw access to the disk (as opposed to using the file system APIs)
  • Access to another process’s memory
  • Creation of alternate data streams
  • Use of named pipes (a method of communicating between processes)
  • Use of Windows Management Instrumentation

As you can see, it’s a fantastic tool which would be pretty hard to top if you decided to try doing this yourself. If you are thinking of experimenting with malware – or looking for something to help you keep a closer eye on your systems in general – I can’t recommend it enough.

In part 3 I will discuss the use of IDS and packet capture tools to get detailed information on the malware’s communication.

20,000 leagues under the sand, part 1

Greetings, malware junkies!

Welcome to the first part in my mini epic documenting my journey of discovery into the world of sandboxing. If you come here expecting groundbreaking advances in the field, you may be disappointed. If however you want to see some of the ideas a newbie had so that you don’t have to think of them yourself, you might be in the right place. Also maybe seeing the dumb mistakes I made so you can avoid ’emĀ 😊

This series is not intended to be a technical instruction manual on sandbox creation. What I intend to do is introduce and discuss the core problems and issues and outline potential approaches for solving them. Along the way I will give specific examples with some detail from the solutions I created for my own sandbox.

A long time ago in a SOC far, far away…

I started my project a little over a year ago, having spent at least that long watching someone else do this roll-your-own sandbox thing with no small amount of awe. Although I was fair with python and could bumble my way around Linux, Snort rules, pcaps and the like, the idea of reproducing this kind of feat even on the most modest scale seemed like a pipe dream. I saw malware go in, and not just pcaps and Snort alerts come out, but a wealth of host activity like file creation, shell commands, remote threads… you name it, it was there. I had the barest scraps of understanding about the Windows API and far less than that about how one might go about tracking something using it.

Without having had this project to look up to, I might have set my sights a little lower, but I was hooked and I wanted to do All Of The Things. I had a laundry list of features in mind based on the aforementioned project and other sandboxes I was beginning to learn about, including but not limited to:

  • Host activity logging
  • Full network capture
  • NIDS alerting
  • AV detection
  • Cross referencing samples on lots of IOCs
  • Screen capture
  • User behaviour simulation
  • Countering sandbox evasion

You might be forgiven for thinking I was a little mad with ambition. No, you’d definitely be forgiven, I was bananas.

However, around Christmas 2016, the biggest obstacle suddenly got a lot smaller when I realised that I already knew of a tool that could do most of the things that my lack of C/C++/WinAPI coding knowledge was preventing, a tool that was continually praised by a twitter account I follow whom I’m sure you have never heard of – Sysmon. I was (perhaps a little optimistically) certain that I could find ways to get my code working for all of the other components I wanted, so when that realisation hit I immediately started coding. If I had known how much of my time it would eat, I might have had second thoughts…

Anyway, from this moment my pet project was born. It’s clunky, ugly, and unreliable, but I’ve learned a lot! Folks, may I presentĀ The Antfarm.

In my next post I will talk about my starting place for this somewhat chaotic adventure: how one can detect and log actions and events on a host that may be malicious.

part 2 – Host activity monitoring