Part 1 – Identifying a system talking to a malicious site found in a spear phish email

Spear phishing is a form of social engineering and undoubtedly one of the most successful and prolific attack vectors an adversary will use to compromise a target.  With the hardening of the perimeter, the user has frequently become the most vulnerable piece of the attack surface.  In this example of a spear phish attack, we will concentrate on a payload which consist of a link to a malicious executable.

This post covers how a Cyber Threat Analyst can leverage the ThreatQ Platform, in conjunction with our Splunk ‘Operation’, to investigate and track these types of incidents.  Using these Operations, we can answer critical questions such as if any users have interacted with the spear phish payload.  Usually this would take several tools, but the ThreatQ Platform allows it to be completed quickly in a single interface.

Storing spear phish events in the ThreatQ Platform also allows for tracking them over time looking for commonalities which will improve your intelligence about who may be attacking your organization and provide insights into Adversary attribution – if that’s important to you.

The Attack

The scenario is pretty common.  Someone in your organization will receive an email that appears to be legitimate but is a bit off.  If you’re lucky, they will forward this email to a security mailbox instead of clicking on the link contained within.  Once the email has made its way to the analyst, either by the user forwarding or the analyst finding through investigation, it’s time to dive in and start the research.

ThreatQ allows emails to be imported in a number of ways:  copied and pasted, dragged and dropped (including Microsoft Outlook MSG files), or imported automatically from a mailbox via an IMAP/POP3 Connector.   We also can support other custom scenarios where the email may come from another security product.  Below, you can see the initial import screen for the manual method.

Once the spear phish email has been added, the analyst can assign more metadata to it and then is presented with a screen showing everything that was extracted from the spear phish email, including attachments.  Our QA screen allows the analyst to add or prune the attributes, attachments, and indicators for items which are not relevant.  For instance, the first identified IP address (016.11.29.06) is part of the “ESMTPS id” value so we can delete it or potentially whitelist it if we anticipate seeing it frequently in the future.  The interface will highlight the extracted information in the original source material making it simple to understand the context of the information.

When the analyst is satisfied, they can create the spear phish Event.  When they do, all of the indicators will be created, or if they already exist, the indicator’s new information will be appended.  The indicators will also be ‘linked’ to the new event, making it very simple to pivot between each piece of information.  The above email will look like the images below once created – notice the original raw data is maintained for future reference as well.

The analyst can now start taking action on this spear phish event.  By switching the indicators over to Active status, they will automatically be deployed to the security infrastructure.  Once an Indicator is set to Active, any configured Exports will provide it to the security infrastructure to be blocked or alerted upon.  Or, if some of the domains are benign they can be Whitelisted.

A deeper investigation can now commence…the spear phish extracted ~15 indicators that warrant research but let’s start with the below IP address and URL.

The Investigation

Often times an Analyst will be investigating a suspicious email and asked to answer a number of questions about it including:

• is it malicious or legitimate?
• what does it do?
• how many employees got it?
• did anyone click on it?

The TQ Platform can help answer these questions in short order by putting all the tools the analyst needs within the same interface.  Let’s start with the most critical question: did anyone click on it?

The TQ Platform includes a feature called Operations.  These are actions (synonymous with orchestration but focused around indicator workflows) which can be performed on indicators within the system, such as further data enrichment.  A number of pre-made Operations are included by default in the system or savvy users can create operations with only a little knowledge of Python required.

To discover if an employee has visited the malicious spear phish site, an analyst would normally have to search their SIEM or drown in DNS logs.  But when using ThreatQ an analyst can easily complete the task through an operation.  In our example, we will use Splunk software as the SIEM. The Splunk Operation leverages their REST API to run a search over the last X amount of days.  The length of time is configurable as to not cause long running searches on busy Splunk instances.

Checking for the URL yielded no hits in the Splunk software, however,  in our hypothetical use case we don’t have web proxy logs so we move on to the next investigation effort.  Let’s dig a little deeper and truncate the URL to focus on the FQDN and it’s resolved IP Address instead 82.118.16.98 (as seen in the screen capture below).  We can obtain this by pivoting to the related FQDN indicator and running the Nslookup Operation on it which leverages basic DNS resolution.

By adding this IP Address in the system it will automatically be related to the original FQDN indicator.  We can now pivot to it and run the Splunk Operation again to see if any systems have sent traffic to the host in question. Looking for the IP Address instead of the URL, we discovered there was traffic from an internal system to this hostile server.

This proactive investigation approach because we pivoted from the URL to its FQDN and then to the host IP address. While running these steps took up several pages, in real time only a few clicks would have been done to get to this information.  Now that we know someone may have visited the site, we should figure out what malicious payload it is hosting.  In Part 2 of this post we will explore how to analyze the malicious site more closely.