Are you the victim of a targeted attack?

Author: No Comments Share:

You are constantly inundated with warnings about targeted attacks and Advanced Persistent Threats (APTs). But how can you determine if your organization is actually being targeted or is just encountering the “run of the mill” malware that permeates the internet?

It is not an easy task to answer this question today as most organizations are not structured to address this problem and lack the tools needed to figure this out in a timely way. Most security practitioners are too busy dealing with the routine tasks and tools they have inherited to spend the time needed to develop these new skills.  Many organizations do not have the skilled practitioners they need, and the security skill-set is expensive and hard to retain.  This places enterprise security and compliance at risk – due really to an inability to understand and see what is going on in the enterprise infrastructure and an inability to see what attackers are after, where they are coming from, and how they are penetrating the enterprise infrastructure.   We at Bromium are out to change this.

We have described Bromium LAVA elsewhere so I won’t be spending time covering the same ground again. Rather I wanted to share some insights I have gained on how to put LAVA to practical use. Some of these insights have come from working with our customers and some have come from many hours of lab time I have spent putting Bromium LAVA and vSentry through its paces with some of the nastiest malware available today.

How can you tell the difference between a targeted and an un-targeted attack? There are no specific signatures or fingerprints for malware being used in a targeted attack. Rather it is who is receiving the malware, how and when it is being received as well as what specific form the malware takes.

First and foremost you must be in a position to see the malware at the point of attack – the endpoint itself. Trying to detect targeted attacks from the network or any common “choke point” is doomed to failure for a number of different reasons:

•    Encrypted Attacks: More and more network traffic is being passed through connections encrypted by HTTPS to try and provide increased security. The only current network technology that enables inspection of this type of traffic is an HTTPS proxy. Unfortunately proxies have severe constraints on the level of inspection they can provide as perimeter proxies must process traffic for hundreds or thousands of clients. Moreover they are ultimately limited in their ability to decide how any piece of code will behave – because they cannot run it in the actual target environment.  While many “known attacks” can be detected by AV scanning or domain reputation lists of one kind or another, targeted attacks that employ polymorphism will generally be able to avoid these types of defenses. LAVA is a capability that is included within vSentry, so it is automatically deployed on every enterprise endpoint.  As a result it “sees” (the effects of) malicious code after it has arrived at the endpoint and been decrypted, and once it begins to execute.

•    Obfuscated attacks: Attackers are well versed with the typical network security tools in place like Network IPS or Next Generation Firewalls. These devices all have limitations on their ability to de-obfuscate attacks on the wire due to the time constraints they operate under. Network security devices that slow down connectivity are generally not tolerated on production networks, so these devices have limits placed on them. As with encrypted attacks, obfuscated attacks are transparent to LAVA as malicious code must be de-obfuscated by the targeted application or system service to actually attack the system.

•    Pre-Screening: Most network security devices must use some form of pre-screening of the network traffic they process to avoid being overwhelmed by the sheer amount of traffic on a network segment. Pre-screening may by be done by domain reputation, pattern scanning (AV), protocol screening or some other technique, but the net result is that a determined attacker can get past these defenses by understanding what is not scanned and ensuring their attack code falls into these cracks. As with the other points we have already covered, inspecting malware at the actual point of attack ensures that LAVA will always be in position to detect attacks.

Secondly you must be able to see the entire execution sequence of unknown code to be able to determine that it is truly malicious and what it is trying to do. Virtually all other malware detection systems are under the gun to detect malware as early as possible in order to block it from running in the system. The first thing most malicious code does is attempt to detect and disable any defenses installed on the endpoint. Techniques such as Host IPS must be tuned to a hair trigger to detect potentially malicious code, which leads to false positives and impacts productivity or risk being disabled in the early stages of an attack.

LAVA is in a unique position to observe the entire life-cycle of malicious software as vSentry ensures that malware cannot escape from the microVM or shut LAVA down. This ability allows you to not only detect malware, but to determine the intent of the malware. Whether an attack is attempting to locate a specific file on a system or is being used as a staging platform to scan the internal network for database vulnerabilities or password files provides insights that have not been available without tens or hundreds of hours of work by highly trained forensic experts.

LAVA Complete Trace.jpg

Third, you must be able to identify specific attackers and recognize and correlate every time a specific attacker attempts to target a system in your network. The hallmark of an Advanced Persistent Threat is the persistence component. An attacker has a specific goal in mind and will continue to try different techniques to reach that goal. Many tools attempt to provide this type of correlation, most notably SEIM systems that try to correlate data from a wide range of third party sensors. The problem till now has been the quality of the information provided by the sensors available for correlation and the ability of attackers to evade existing detection techniques. The shortcomings of the traditional detection mechanisms outlined above have resulted in SEIM detection rates being a very hit or miss proposition.

LAVA overcomes these shortcomings by providing the reliable, granular detection data needed to effectively correlate seemingly unrelated events into actionable intelligence that can be acted on in time to protect the organization.

Let’s examine the following example of LAVAs capabilities to get a feel for the big picture:

1.    LAVA detects an unknown form of malware in an engineering executives’ laptop early on a Monday morning and raises an alert to the security team. The malware has dropped a file on the system that is attempting to scan the local file system for spread sheets. LAVA has generated an MD5 hash unique to the scanner which is not identified as malicious by any of the industry standard malware detection web sites. The address and DNS name of the malicious web site that was used to download the scanner is recorded as well. An outbound encrypted communications channel was established to a different IP address.

2.    The scan of the executives local file system fails of course as vSentry has isolated the file system on the laptop from the malware running in the microVM so no spread sheets are found.

3.    The next day LAVA detects an attack against the executive admins system. The malware identified is trying to scan the admins system for spreadsheets as well. The MD5 hash of the scanner matches the file detected on the executives     system the day before as does the IP address of the malicious web site and the outbound communications channel although the DNS entry has changed.

4.    The attack on the admins system fails as well of course with no spread sheet files found by the scanner.

5.    Later that afternoon the same malicious file is detected on the system of the executives senior manager and with the same results, no spread sheet files are found.

Now the security team now has the following information available for its use:

1.    There is an ongoing attack from a single source against multiple users that all belong to the same Active Directory group, “Engineering Management”.

2.    The attacker has been able to determine the specific individuals on the engineering team that would most likely have access to sensitive intellectual property and is able to target them successfully.

3.    The attacker is looking specifically for spread sheets and is not attempting to steal passwords, credit cards etc.

4.    The attacker is establishing an encrypted back channel to a specific IP address to harvest the information he is trying to acquire.

Based on this information the security team takes the following actions:

1.    An alert is sent to senior management identifying that a targeted attack is underway and is attempting to harvest information from the leadership of the engineering team.

2.    The engineering team is informed that they are the target of an organized attack and are instructed to report any unusual contacts or activity not associated with their computer systems to security as the attacker may attempt to use social engineering techniques to gain access to the data they can’t get by standard cyber-attack methods.

3.    The security team implements an audit of their public facing systems to determine if the engineering teams’ organizational structure has been exposed to potential attackers. It is found that the engineering web page on the public facing web site has been compromised via SQL injection exposing the internal org chart. Security remediates the vulnerable engineering web page as well as some other pages identified during the audit.

4.    The IP addresses for both the command and control and the malicious download server are blocked at the perimeter firewall to shut down any further attacks from those sources and the firewall is configured to monitor and report any outbound connection attempts to these system. This will enable security to identify any other compromised systems within the network.

5.    The MD5 hash of the previously unknown file scanner is added to the network IPS system to determine if the file is being propagated within the organization.

vSentry and LAVA enables you to not only detect if you are the victim of a targeted attack but allows you to take concrete steps towards protecting your organization from these types of attacks. vSentry’s advanced isolation capabilities not only defeat direct attacks but enable LAVA to provide you with actionable information not only on the tactics and techniques an attacker is using, but more importantly the goals of the attacker and the strategy they have put in place against you.

Previous Article

vSentry for XP, RDS and VDI is here!

Next Article

Oh, let’s hack back!

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *