Attacks/Breaches
6/16/2015
12:00 PM
Giora Engel
Giora Engel
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

Is Your Security Operation Hooked On Malware?

It may seem counterintuitive, but an overzealous focus on malware may be preventing you from detecting even bigger threats.

Whether the goal of a malware attack is ad-clicks, creating a botnet, or doing something more damaging, no one can dispute that preventing and combating these infestations are an important focus for security groups. But too often, this battle can overshadow an even bigger threat to an organization: a targeted data breach, which takes a very different orientation and set of tools.

For the most part, in the context of a targeted attack, malware is optional, and if used, it is just a side tool rather than the main component. Attackers will engineer their way inside a network with or without malware, and once inside they are more apt to use utilities, a command line interface, and other administrative functions to progress the data breach. This process is rarely automated and certainly not autonomous, which leads to:

Mistake #1: Focusing breach detection on malware detection
Because a successful targeted data breach is an iterative process in which the attacker bypasses prevention technologies, he will, by definition, bypass the security tools that deal with malware, even if he uses malware. Most of the activity will involve reconnaissance to understand the network and lateral movement to get closer to important assets.

More challenging is whether, if you detect malware, how do you know that you uncovered a targeted attack? By just looking at malware, it is difficult to see if it might be connected to some larger attack. Also, in some cases, identifying and removing malware gives a security team a false sense of security; it keeps them busy and productive while making them think they are doing all they can to detect an active breach.

How to avoid Mistake #1

  • Focus on breach detection activities that indicate the necessary behaviors of the attacker, not technical artifacts, like malware. In order to detect active breaches, conduct ongoing behavioral analysis of computers and users rather than sandboxing and IOC (indicators of compromise) detection. Sandboxing is simply malware detection, and IOCs are simply signatures of known malware.
  • If malware or a malicious tool is indeed detected, don’t end the investigation there. Many targeted attacks will use relatively simple Remote Access Tools (RATs) and malware variants such as Zeus. Ask the right questions of what is special about the computer or its owner. Where else is this malware, tool, or utility used? What information or resources are accessible from this asset? The key to differentiating between mass malware and more targeted attacks is asking the right questions. On one hand you don’t want to waste precious resources on investigating simple malware, and on the other hand, if you suspect that it is targeted, you should try to understand it early in the process to enable further investigation.

Mistake #2: Focusing the remediation process on malware removal
If a security professional actually discovers suspicious behavior, simply removing malware or re-imaging a machine won’t achieve a lot. In many cases when a breach is discovered, it’s difficult to understand the full extent of it. Generally, security organizations rush to reimage the computer or remove the malware as quickly as possible. Some even measure the time it takes and try to optimize it. If indeed you are facing a targeted attack, then this practice doesn’t change the fact that the attacker controls your network. An attacker inside the network would usually have multiple footholds. Removing one will inform the attacker, as a side effect, that you are aware of him and destroy any evidence that you have.

How to avoid Mistake #2

  • Instead of focusing on removing the malware and re-imaging the machine, focus on the significance of the endpoint, its owner, and the detected behavior. Record the machine’s purpose, its owner, the relevant malware or program that was part of the behavior, and take a snapshot of the machine before removing the malware or re-imaging it. After the remediation is completed, keep tracking the case (user/machine/related assets).
  • Remediation should start with triage and investigation of the suspicious behavior. It needs to be based on both network context, which gives breadth and complete visibility, and also on the endpoint context, which provides the depth and root cause analysis. Most breach detection programs implemented in organizations today will find suspicious network activity but won’t have any endpoint context, which leads to blind decisions of reimaging the machine.

It’s time to start responding to data breaches with new tools and new thinking. Don’t let malware prevention tactics become the basis of post-intrusion detection.

Giora Engel, vice president, product & strategy at LightCyber is a serial entrepreneur with many years of technological and managerial experience. For nearly a decade, he served as an officer in an elite technological unit in the Israel Defense Forces, where he initiated and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
felixonline
100%
0%
felixonline,
User Rank: Strategist
6/18/2015 | 11:50:52 PM
Re: An attacker inside the network would usually have multiple footholds
Agreed. As security professionals, we should be focusing on data and using that construct to develop our security response. However I am also finding (through personal experience and peer networking) that cyber attacks are increasingly motivated by factors that don't always have sensitive data as their ultimate target. Merely operating in a particular geography or having a particular view on a debatable subject is enough reason to be targeted. A threat-led security posture is now emerging as the approach that takes into account the full spectrum of exposures including those to sensitive data and equally assets (e.g. critical infrastructure). Asset centricity v/s data centricity has been a subject of debate for a long time however I don't think it is one over the other rather a holistic approach that takes all elements into consideration.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/18/2015 | 10:53:56 AM
Re: An attacker inside the network would usually have multiple footholds
I agree all the point made here. Once you are inside there are additionally opportunities to pass through inner layers. That is why we need to go with a layered security approach, and architect our networks to support that.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/18/2015 | 10:50:42 AM
Re: Very relevant
I agree. I also think it is more about training both end-users and security folks. We know we have tons of security measures put in place in different layers of our network, we still see malware.  
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/18/2015 | 10:48:02 AM
Re: Spokes of a Wheel
Agree, it is all about analyzing. Understanding where we are strong and where we are lacking. Malware you have in your network is the result and a little bit late result. :--))
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
6/18/2015 | 10:44:17 AM
Both
I think we need to focus on both breach detection and malware detection. They are not separate things. Second point, re-imaging the machine is not the solution, we need to get signature/detail of malware and find out a way to prevent from it.
Ulf Mattsson
50%
50%
Ulf Mattsson,
User Rank: Moderator
6/17/2015 | 1:53:41 PM
An attacker inside the network would usually have multiple footholds
I agree that "An attacker inside the network would usually have multiple footholds. Removing one will inform the attacker, as a side effect, that you are aware of him and destroy any evidence that you have."

I also agree to "conduct ongoing behavioral analysis of computers and users" since the attacker may try to steal specific sensitive data. This can be done at the data/application layer since current security monitoring approaches a labor intensive and can't really tell you what normal looks like in your own systems. Less than 14% of breaches are detected by internal security tools according to the annual international breach investigations report from Verizon.

I think that we need to focus on protecting sensitive data itself. The Ponemon Institute published an interesting survey related to the recent spate of high-profile cyber attacks. According to the survey database security was recommended by 49% of respondents, but the study found that organisations continue to allocate the bulk of their budget (40%) to network security and only 19% to database security. Ponemon concluded that "This is often because organizations have traditionally spent money on network security and so it is earmarked in the budget and requires no further justification."  

I found great advice in a Gartner report, covering solutions for Data Protection and Data Access Governance. The title of the report is "Market Guide for Data–Centric Audit and Protection." The report concluded that "Organizations that have not developed data-centric security policies to coordinate management processes and security controls across data silos need to act." I think that it is time to be more data-centric.

Ulf Mattsson, CTO Protegrity
felixonline
100%
0%
felixonline,
User Rank: Strategist
6/17/2015 | 10:16:53 AM
Very relevant
A really good article. I think IOCs have somehow transformed into Indicators Often Chased. I have often found an irresistible urge (in the community) to fix the symptoms (e.g. block outbound traffic to a known bad IP address or disable tools used to achieve pseudo persistence etc.) rather than focusing on exactly the areas Giora has highlighted. Having a multi-step approach to remediation keeping the holistic view in mind will go a long way in preventing incidents from recurring and determining extent of compromise (e.g. gain insight into more such kill chains operating within the organisation). Cyber incident exercises should cover these elements and train security folks to ensure their processes are equipped and capable of providing a richer response to cyber attacks.
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
6/16/2015 | 3:10:29 PM
Spokes of a Wheel
Good article. Malware is just one risk vector plaguing information security professionals today. I like to think of it as spokes on a wheel. Everyone has its own importance and none should be focused on to the point where other spokes/risk vectors are neglected. Obviously, certain vectors will take precedence based on trend and cost but they should all be considered as relative when analyzing your information security posture.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: just wondering...Thanx
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.