A Privacy Stack for Protecting Your Data

Over the years, there have been a number of incidents that have raised my security-guy neck hairs. Every time something crops up, I get a bit more worried about where my data lives, and who is privy to it that I don’t know about.

Most recently, we have the dismantling of privacy rules that protect our information from being wantonly sold off by our ISPs, even more in depth searching at US borders, large scale sweeping up of people and associated electronic devices at occurrences of civil unrest, and the looming spectre of net neutrality coming to an abrupt end by removing their classification as common carriers. In short, everyone is spying on my everything and, unfortunately, all of this seems to be trending in a bad direction over time.

Worse, a large number of people respond to this by saying that they have “nothing to hide”, while engaging in daily practices that refute this like blinds on their windows, passwords kept from the public and, maintenance of various other “private” data and situations. So, what’s a reasonably technical guy to do?

How do you protect your data?

There are a number of ways that you can attempt to solve this issue. Very often, the first solution that you’ll hear bandied about is “encryption”, which can mean a number of different things in a number of different situations. There are a few distinct angles from which to look at the issue, and they are not mutually exclusive.

Add encryption, but where?

When encryption is mentioned, there are a few states of encrypting data:

  • Data at rest refers to data stored on some sort of medium. This would be the data stored on your laptop, cloud storage, USB drives, and so on.
  • Data in motion means data that is being transmitted from one place to another, meaning when it is transferred over a transport medium, whatever this might be.
  • Data in use covers data as it is being used by an application of some kind, i.e, an office-type tool, the operating system, a cloud service, etc.

When encryption is discussed, it needs to be appropriate and applicable to the type of data use that you are referring to.

Defense in Depth

Defense in depth is a common tenet of the security industry, and refers to overlapping layers of security, usually visualized as the layers of an onion. Each layer is a different layer of protection, with data typically represented at the very core. The idea of defense in depth is that the multiple overlapping layers all help to preserve security, and that the failure of any given layer will not result in a complete lapse of security since the other layers are still in place.

With these concepts in mind, let’s discuss a stack to help protect your personal privacy in a world of people trying to tear it down.

A Solution to Protect Your Data

Let’s look at this from the defense in depth and data-centric positions. Everyone strap in, as we’re about to quickly cover a lot of ground at a high level.


There are only a couple things you can do to protect data specifically; I’ll keep touching on this as we go along.

1. Encrypt all the things!

Anywhere that data is stored, it should be encrypted. This basically means that you should encrypt any storage media that you have control over, and you should try to control any of them that you feasibly can.

Specifically, you need to use strong encryption and you need to be in control of the keys. Using a cloud service provider to do encryption for you doesn’t really count here, even in the case where you control the keys. There have been several scenarios where such providers have been legally compelled to exploit flaws in their implementation to access data where they shouldn’t have been able to.

Ultimately, the method of encryption for stored data will depend on the device in question. In many cases, you need to worry about phones, laptops, and individual storage media (largely USBs). VeraCrypt, a project that replaced TrueCrypt when it died, is a great product for computer disk encryption.

Outside of the few outliers, phones are generally stuck with the encryption options they ship with, short of jailbreaking. You will want to ensure that this is enabled (Here’s how to encrypt an iPhone or an Android device).

2. Store Data in Places with Stringent Security Laws

You also need to think about where exactly your data is stored. Storing data inside of the US, or any of the other “Five Eyes” countries, may not be the best option. These countries have very extensive agreements on intelligence data sharing with each other, and some of the worst laws and regulations for safeguarding personal data.

Currently, Switzerland and Iceland are a few of the safer places to store data, but be sure to do your research as this is in a relatively consistent state of flux. Currently, neither of these countries are part of the EU, and both have stringent laws regarding data privacy.



From a browser perspective, you need to be careful which browsers to choose for privacy and security reasons. I tend to stick to the major browsers, both from a supportability/compatibility perspective, and from the standpoint of having some idea of what the browser manufacturers are up to, good or bad. This can limit you to variations of Internet Explorer, Chrome, and Firefox.

The other big consideration here is available browser plugins. This is a big thing that narrows your choices down quickly. IE has garbage plugin support. Chrome, while it has better support than IE, is still missing some key plugins. This really leaves you with Firefox. On top of good plugin support, Firefox also has a number of settings to tune its privacy features.

In Firefox, NoScript and PrivacyBadger are good plugins to use for both privacy and security. In addition to these, Panopticlick from EFF lets you test out your browser privacy settings, and makes sure you’re not leaking anything that you didn’t know about.

A note about browser plugins: You need to be very careful when choosing them, as some of the supposed security and privacy plugins are actually selling personal information that has been harvested from its users.


With email, you have a few things to worry about. While I don’t encrypt the text of my email as a matter of course, I do like to have the capability to do so, if needed. I also need to know that my email is stored in an encrypted fashion on disk.

As discussed above, you need to be sure that this data is stored in a reasonably safe location, from a legal perspective. Really, you have two choices here: run your own mail server, or choose a hosting company that provides all of these services. Ultimately, either of these options will cost money.

ProtonMail is a good choice for many. Yes, you can spin up your own service, and make a fairly safe and secure go of it, but running your own infrastructure is a ton of work.

ProtonMail is encrypted at rest, in transit, and at use. It has a reasonable set of nice features, such as no logging and encrypted message support, and the service is open source and hosted out of Switzerland. The folks that run ProtonMail are also launching a beta VPN product, a topic which we will come back to shortly.


Standard messaging applications—whether instant messenger, texting, or video calls—are full of potential security holes, and they are largely owned by a relatively small set of companies. Some of them—SMS texting, I’m talking to you—are so wildly insecure, it’s embarrassing. Additionally, a few of these “free” hosted services are actually mining your messaging content in order to better target ads at you. Okay if you like that sort of thing, but not great for those concerned with privacy.

Fortunately, there is a reasonable solution in the Signal product by Open Whisper Systems. Signal provides end-to-end encryption for voice, chat, and video traffic, as well as encryption on the local device, and enables self destructing messages.

Operating Systems

Choice of operating system is another major sticking point. As with browsers, there are really only a few major choices, without straying into the realms of the weird. You need a standard set of tools to carry out common tasks, although more and more of them are trending toward online tools.

Ultimately, you need to be able to use a reasonable set of software tools, and be able to talk to the hardware that you use regularly. Basically: Windows, OS X, or Linux. The choice here for me is easy: Linux.

A few years ago, it was much more difficult to use Linux as a dedicated platform. But these days, not so much. You can pick up almost any laptop, throw Debian or the fork of your choice on it (Ubuntu is mine), and away you go. I have made an attempt every now and then to switch to a RedHat derivative, but I find the support for hardware and software tools lacking.


From a host perspective, there are a few things that you’ll need to button down. Many work almost exclusively on laptops these days, but all of this is applicable across a variety of devices.

Disk Encryption

Disk encryption is one of the primary host concerns, specifically full disk encryption. On a Windows OS, doing this might be difficult due to the way that Windows 10 sets itself up across multiple partitions. FileVault for OS X is a bit more solid. A good solution for Linux is to encrypt it with LUKS, the disk encryption tool that ships with most distributions.

In addition to encrypting the disk on install, you will also want to set a couple options in the EFI/Bios settings; namely passwords for power on and for accessing the storage media. These are common to most desktops and nearly all recent laptops, and will prevent the device from booting up without entering both passwords.

Additionally, the storage media password will prevent the media from being accessed without entering your password, even when removed and inserted into another device. With these on and the disk encrypted, you should feel reasonably confident that the device won’t be accessed without your consent in some fashion.

Cameras and Fingerprint Readers

Two additional hardware-centric devices to deal with are fingerprint readers and cameras. Several recent cases have dealt with the fingerprint unlock feature that has become common on mobile devices. Particularly disturbing are court rulings that allow for not turning over passcodes for such devices, but compel you to use the fingerprint unlock features. In one particular case, a warrant was written allowing law enforcement to force the fingerprint-unlocking of every device located at the premises that fell within the scope of the warrant. So, as inconvenient as it might be, you may not want to use fingerprint unlocking. Considering that many laptops, tablets, etc, come equipped with fingerprint readers, this ruling will likely extend to them, as well.

Lastly, cameras are ubiquitous in laptops and mobile devices these days (not microwaves though), and may be a target for remote surveillance. Yes, this may sound a bit tinfoil-hatty, but it is a concern. Numerous items of malware that can access cameras have cropped up, and several privacy cases have come to light around unauthorized remote camera use, even people spying on schoolchildren.

There are many small stick-on devices made to cleverly cover cameras, and flip out of the way when they are needed, all while looking fashionable. A less expensive option is to cut the adhesive bit off of a sticky note, and trim it to size that works out well for your camera. It’s easily removable, doesn’t leave residue behind, and can be easily replaced.


The chief concern that most people have from a network perspective is the security of the communications medium—the topic almost always come back to this. On a hotel wifi, hooked up in the Starbucks, or sitting in the workplace, people are often concerned about others eavesdropping on them. The common answer to this? Use a Virtual Private Network (VPN) connection to encrypt your communications.

There are a HUGE number of possibilities for a VPN service, from low cost or free no-frills setups to spendy commercial services with all the bells and whistles. One decision to make is whether to build or buy.

A very brief round of googling will find you instructions on how to create your own VPN running on any number of cloud services, many of them built on Amazon Web Services (AWS). Building your own VPN has the advantage of you holding all of the control over how it runs.

You can dump logs, change IP addresses all the time, and any of a number of technical tweaks can be made at your whim. If you build on one of the cloud services, you will be burying your traffic among all of the other bits originating from that particular vendor. On the down side, you only have whatever frills that you build into it yourself, and you probably won’t want to pay for too many endpoints, so you’ll be stuck with your traffic exiting from a few (or one) specific geographic location.

If you go with a VPN service, you have almost the exact opposite problem. You probably have very limited control over how the service itself works and the features that you can use, but you may get some neat bells and whistles. Some of the commercial VPN services have endpoints all over the world, and you can make your traffic come from wherever you want. Want to watch some country-restricted content? No problem, just configure your VPN client.

With a commercial service, you do have to be concerned with what the folks running it are doing. Are they logging all of your traffic, and selling the logs off? In that case, you just shelled out $50 a month trying to avoid ISP spying only to end up right back in the same spot. There are a number of guides on the internet that can help you choose a safe and secure VPN service that won’t do bad things with your data. If you want a good place to ask a community of people that has been using VPNs for several years, and is really worried about being traced back, ask the pirates.

Ultimately, I went with a cheap OpenVPN setup in AWS. If you keep the traffic down to a reasonable level, you can run it on a very small system and stay inside the free tier, in which case it costs you nothing and you have full control over it. Additionally since this is OpenVPN, you can easily use it on your mobile devices. You can also have the entirety of the network traffic piped through it for your house, thus ensuring the privacy of your internet activities from your ISP.

A note on VPNs: Using one is by no means a silver bullet, but it’s a good start. You should also be sure to use secure protocols wherever available (HTTPS), and you can potentially use other mechanisms as well, such as Tor.

Are these measures good enough?

Are all the above measures a good enough solution to protect your personal privacy? This largely depends on what it is that you’ve been up to.

If you’re worried about general privacy and protecting your data from an ISP or other such companies, yes, this is likely a solid set of solutions.

If you’re worried about protecting your data from law enforcement, border patrol, and other similar agencies, probably yes. Beware, however, that not cooperating with law enforcement-type agencies may have consequences, such as being denied entrance to the country as planned.

If you have gained the attention of the NSA and/or other intelligence-agency types, I wish you the best of luck. If you have done something of sufficient magnitude to get the attention of those that have effectively unlimited resources and the will to use them, you have a much more worrisome set of issues.

Unfortunately, taking what might seem like extreme steps to protect your data is likely the new normal. This is one of those “genie out of the bottle” situations, and we are unlikely to see it reversed to any great extent any time soon. So don your tinfoil hat, protect all your data as best as you are able, and we will all hope for the best.

[Originally posted to https://blog.komand.com/privacy-stack-to-protect-your-data]

Investigating Our Technology — Internet of Things or Internet of Threats?

One cold winter afternoon as I sat in my office, cursing the air several degrees warmer around me due to slow internet connectivity, I thought to take a look at exactly the issue was. I had recently installed a new system of wireless access points which should be blanketing the entire house with a strong enough signal to make the air glow well out into the yard.

I logged into the controller for the APs, which helpfully provided all manner of statistics regarding the different devices connected, who was connected to to which AP, how the bandwidth was being used, and a dizzying array of other statistics (one of the selling points of these devices to a data nerd). Being a relatively technology-prone household, I was reasonably sure I would find the internet connection being choked out by several devices streaming at once, some large download running, or something similar, and would castigate the offender and perhaps adjust the rate limiting rules a bit to keep things a bit more sane in the future.

On digging into the data, I found an unfamiliarly-named device sending and receiving unusually large amounts of data almost continuously. Curious, I copied the MAC address from the wireless controller and looked it up on the internet  — Ubiquiti Networks Inc. This was one of the wireless video cameras set up to watch the house. Uh oh.

The IoT Problem

Why uh oh? In the fall of 2016, compliments of the Mirai botnet, hundreds of thousands of compromised Internet of Things (IoT) devices were used in distributed denial of service attacks against a variety of targets. These attacks were sufficiently powered to take down large swaths of the internet and even cause internet access issues across entire countries.

The issue that Mirai, and surely others to follow, took advantage of is that many of these IoT devices ship with a default set of credentials that is common across all devices of a model, or even all devices of a manufacturer. Mirai searches for these devices and recruits them into its botnet, using them to attack other targets on the internet.

This sort of widespread issue is rife for abuse, and this is exactly what happened. Worse yet, the source code for Mirai was publically released. Now we have an example of a very successful DDoS attack, source code for the attack’s tool, and a huge number of unpatched devices.

How huge? Some estimates say that in 2016 there were slightly less than 18 billion IoT devices. Yes, that’s billion with a b. Now we begin to see where the problem lies.

Worse yet, the DDoS attacks that were carried out using Mirai only had a bit over 100,000 devices to work with, according to some estimates. This is a small fraction of the devices out there and had a very significant impact.

A Little Research

The first stop in figuring out if my overly-chatty device was to do a bit of research. Not all IoT devices are problematic, and the list of devices being co-opted by Mirai and its variants was a relatively short one. From a little searching on the topic, there are a couple ways to go about searching for which devices are problematic; we can try interrogating the network for devices that that have issue, hoping to find them directly, or we can research a bit to find out if we might have a problem based on the particular hardware in general.

From a purely research perspective, finding the devices that might be problematic isn’t terribly difficult. A bit of brief googling turned up a list from the Krebs on Security website that were targeted by Mirai. The list did turn up a device from the same vendor as mine, but not the exact same device. The listed hardware did, however, have the same default credentials as mine. I always change the credentials on my devices when I stand them up, so this shouldn’t be a problem.

No really, I’m totally positive I changed them. I was standing several up at a time, surely I changed them all? Uh oh?

The next research bit before diving into the devices would be try out a couple of the multitude of IoT scanners that have popped up, all claiming to be able to suss out problem devices. After a bit of googling, I decided to try a couple of them; one a web-based scanner and one a script.

The web-based scanner was from Imperva, a well known security tool company. It has a simple ‘press go’ interface and automatically scans the address you are browsing from.


Its results, however, are not what I would call conclusive:


I take a certain amount of umbrage to statements, like the above, which imply that the absence of information means that the results are negative. Well, perhaps the next scanner will be better.

The second scanner, also from a well-known security company, is a script-based tool from Rapid7[1] and hosted on GitHub. This is a little more my speed. Furthermore, the tool is written in Perl, so cracking it open was like running into an old friend. Running the tool required a quick download of a few modules from CPAN, and away we go.


Unfortunately, no great results here either. After poking about in the configuration file that the script uses, it turns out that it was looking for devices from a specific list of vendors with the default administrative credentials set.

One of the devices in question was indeed still using the default login and password, but the script failed to figure out what the device was due to looking for a very specific bit of text in the source of the login screen. Nonetheless, I had a device on my network that very neatly fit the pattern for being abused by an IoT botnet, and this bore further investigation.


There are a number of routes that we can take to investigate a specific device and see what it is up to. In the absence of historical log data, we can scan it externally, try to get onto the device itself and see what we can see, and we can look at the traffic inbound to and outbound from the device.


One of the easiest and most informative tools that we can use to look at our device is Nmap. We can do a quick nmap -A against the device, which will give us OS detection, version detection, script scanning, and traceroute, resulting in:


So here we can see the expected web server, running lighthttpd on ports 80 and 443, rtsp running on port 554, presumably to support streaming video from the device, and Dropbear running an ssh server. One thing to notice here is the lack of a Telnet server immediately visible on port 23. It could be on another port, but this does put us out of the immediately dangerous spot as far as Mirai and other variants go.


If we can get on the system itself (where system = tiny golfball-sized IP camera running linux), we should be able to interrogate it and find out exactly what it is that is using up so much bandwidth.


Since we saw an SSH server running from the nmap scan, we can try to connect to that. Using the still default vendor credentials of ubnt for a username and password we can ssh ubnt@ and voilà:


So here we have a standard BusyBox linux, common to many embedded systems. This gives us a somewhat limited but common set of tools that we can use to check things out a bit further.


First and foremost, we can make use of netsat. Running netstat -anputw will give us a solid idea of who we are presently talking to. These options will list all UDP (u), TCP (t) and RAW (w)  connections on all sockets (a) with numeric hosts (n) and includes the associated program (p):


Nothing much of interest here. We can see the SSH connection from and the various camera specific connections to the recording back end on Nothing unusual talking or listening.

Poking About the System

While logged in, we have the opportunity to poke around the system in general. This device is a very typical stripped-down linux BusyBox. In /var/log/ there are system logs, as we might expect, which are largely full of the camera specific bits doing camera-specific things. We can also look at dmesg and learn a bit more about the specific hardware and environment:


One interesting thing to discover here, for gee whiz purposes, is that the system appears to be running on OpenWrt, which is somewhat cool for a consumer IP camera. Overall, nothing too interesting or unusual.

It is worth noting, for purposes of looking for signs of Mirai, that there would also not be anything here. Mirai maintains a connection through the open telnet server and does not, at this point, have a mechanism for persistence. It is also, however, worth noting, that putting such a mechanism in place would be fairly trivial and we should expect its arrival/discovery at any point.

Examining the Traffic

There are a couple bits that we can look at for purposes of examining the specific traffic externally to the device. We can look at packet captures and we can look at netflow data.

Packet Captures

In this case, I asked the pfSense box to pull a packet capture of all traffic destined to or from our questionable camera. Since the camera was attached to a wireless network and, from an infrastructure perspective, it would have been a bit of a pain to get monitoring in place an isolate traffic out for the particular device, this was by far the easiest route.

In our case, unfortunately (or fortunately, rather), nothing of interest. While this doesn’t mean that there would never be anything of interest, it does mean that the device is not spending all of its time actively attacking and/or communicating with odd devices on the internet.



In order to get a better idea of what exactly the device is doing, we can also look at the NetFlow data. We can pull NetfFow from a variety of places on the network. NetFlow was originally developed by Cisco and gives us  variety of information about the source and destination traffic on the network.

In my case, I have a pfSense firewall and can make use of the softflowd package to collect the netflow data. From there, I need to send it somewhere to aggregate and analyze the data. There are a huge number of tools available for this task, many of them commercial and either free or with a free trial period. I do, however like to use open source tools whenever possible, so we’ll go with ntop.

After configuring pfSense to send the data and analyzing it with nopt, again, a whole lot of… nothing. This is not unexpected after the data from the packet capture, but it does give us a greater level of detail on the nothing that we previously saw. Graphically detailed nothing is, on occasion, very useful when presenting investigative results to management, so this is a worthwhile exercise in learning how to collect data in this format.

Given a much longer period of time in which to collect the netflow data, we would likely see the odd unexpected connection occur, possibly for firmware updates or a phone home to the vendor. Nonetheless, we again have confirmation that the device is not doing anything terribly unexpected.


Ultimately, my device ended up not doing anything terribly suspicious, but I feel better for giving it the once over. The large amount of traffic that I was seeing was likely rtsp streaming back to the Network Video Recording (NVR) software on one of the other systems on my network.

Yes, it was overly chatty, yes it was bogging down the network, no it was not a compromised device trying to take down Amazon. I was reasonably sure that this was the case relatively early on, but working through the process and tooling to run down suspicious activity is a valuable exercise in and of itself.

The IoT world is a very dark and scary place with twisty and crooked little paths through it. We can find internet enabled anything, from toasters, to light bulbs, to cameras, and, being a relatively new phenomenon, the security around these devices is practically nil.

While the IoT security problem is clearly bigger than a breadbox, and we can expect to see DDoS attacks and the like from swarms of these devices for the foreseeable future, these issues do bring to mind the growing pains of another similar set of devices — wireless access points.

The early days of wireless access points saw them shipping with common default passwords, disabled encryption settings, and firmware rife with vulnerabilities, manufacturer backdoors, and other such bugaboos. While it did take some time for the industry to mature sufficiently for these problems to be mitigated across the majority of vendors, it did eventually happen. Now all we need to do is hold on long enough for this to happen for IoT, and hope the wheels don’t come off in the meanwhile.


Incident Investigation: It’s All About Context

When security operations centers or security teams have data output from our security devices or from threat intelligence sources, it all too often lacks any sort of reasonable context on which to base an investigation.

When we have Indicators of Compromise (IoCs) that define a particular type of attack, often largely IP addresses and file hashes, this can make a very difficult starting place; inefficient at best, paralyzing at worst. Data with no intelligence lacks context and we need context in order to succeed. Let’s use a real world example to demonstrate this.

Grizzly Steppe

A somewhat recent example that we can look to for contextual issues can be seen in the attacks that occurred during the 2016 US election, which came to be known by the code name Grizzly Steppe. These attacks, purported to have been carried out by the Russian Intelligence Services (RIS), attempted to influence the course of the election through exfiltration and exposure of sensitive information, undermining of confidence in the election process, and disruption of critical infrastructure, all backed by a variety of phishing attacks, malware, stolen credentials, and a host of other means.

In an effort to combat these attacks, the US Department of Homeland Security (DHS) and the Office of the Director of National Intelligence (DNI), released a Joint Analysis Report (JAR) in December of 2016. Accompanying the report was a file containing IoCs that might be used to detect the presence of the Grizzly Steppe attack groups, Fancy Bear (APT28) and Cozy Bear (APT29), in a given enterprise.

The Data, As Released

The IoC file contained:

  •      1 URL
  •      10 FQDNs
  •      876 IPv4 IP addresses
    • 1 YARA rule
  • 24 file hashes, 7 with accompanying file information

Unfortunately, much of the information was very general, and a large portion of the included IPs pointed to the address space of large cloud companies such as Google, Yahoo, and Twitter. While this is not necessarily incorrect, as the attackers were indeed making use of these services, it is not useful from an investigative standpoint.

If we were to query a security device, such as a Security Information Event Monitoring (SIEM) tool, with these IoCs, we would be returned an enormous number of results in most environments, as we would be asking for information about very common user activity. In particular, the results in the Grizzly Steppe IoC was so general that it would return literally millions of results when querying the common set of security devices in a large enterprise environment.

Given this, is there anything we can do to get to a place where we have something that our Incident Response team can actually sink their teeth into? Fortunately, yes there is.

Gaining a Little Context

In order to get something useful from the general information that we have, we can do a bit of analysis on it using various tools. Many of these analysis tasks are very similar in nature, so one we have tooling for our efforts, we can continue to reuse and refine it whenever we have reason to apply it again. Here we will be focusing on the IP addresses and file hashes.

IP Addresses

We can query Shodan about the IP information that we have, making use of the command line client. Let’s take a quick look at the first IP:

Shodan host

We can see a bit of basic information about that one — nothing much interesting there, but let’s look at all the rest of them. For this, we’ll want to use a script, and there are a host of existing examples that we can make use of. We’ll pull the IPs out of the IoC file into their own text file called hosts, and use a script from John Matherly, the developer of Shodan, to process the IPs and download the information:

python ./shodan-ip-download.py hosts hosts.json.gz


We will end up with a json formatted file, suitable for parsing with the Shodan command line tool, like so:

shodan parse –separator , hosts.json.gz

This will give us a CSV file which we can then browse at our leisure.

Upon doing so, one of the interesting points of information is that many of the IP addresses, about 20%, are Tor exit nodes.

File Hashes

To handle the file hashes, we can likely submit these to an anti-malware platform in our environment. However, it might be nice to know a bit more about them. After all, if the files listed in the IoC are malware, we’ll likely see new variants of them shortly, and it might be nice to have some idea what family we should be looking out for in general. For this, we can turn to VirusTotal.

For the very small number of files that we are dealing with, 24 as we mentioned earlier, we could just bang them through the VirusTotal search field, returning some interesting commentary:


This works, but doesn’t scale well. Fortunately, Didier Stevens has a Python tool to help us out with this very problem. We can provide the script with a list of all of the files hashes from the IoC file that we have, in a text file called samples, and it will dutifully ask VirusTotal (we’ll need an API key for this) about them, which will ultimately provide a CSV file back to us with all of the results:

./virustotal-search.py samples


Where do we go now that we have a bit more specific data? Now we go investigate a bit. We have a much more specific list of IP addresses to work with. Presuming that the use of Tor is not common in our environment, this is a good place to start.

From there, we can see what else the systems using Tor have been touching internally and investigate further. We also have a good set of malware, and potentially variants, to investigate. Both of these items are specific enough that we may get a more manageable set of results out of querying our SIEM.

Once we have a good look at the systems that have presented themselves as being outliers among normal system activity immediately, by communicating via Tor or displaying malware-like behaviors, in addition to catching the bad guys, we can also use these results to help refine our security tools. IDSs can be tuned, YARA signatures added to our anti-malware devices, and better querying and altering configured on our SIEMs. As we discussed earlier, through developing better tools for investigation, we ease the path for ourselves the next time we need to do this.


In our daily duties as security professionals, we need context in order to be successful. As the old saying goes, “garbage in, garbage out”. Fortunately, with a little elbow grease, some command line kung-fu, and just a quantum of clever, we can often get to a place of better context by processing the data through a few simple tools. Like a magician’s trick, it doesn’t seem like much once we know how it was done, but these are the tactics on which much of the security industry survives.

The next time you find yourself facing down a mountain of log file or a pile of useless-looking data, get a fresh coffee, roll up your sleeves, and see where you can get by crunching the data a bit to gain some context and hone in on the interesting bits.

[Originally posted to https://blog.komand.com/incident-investigation-its-all-about-context]