Incident Response

Not All Intrusions Involve Malware

There is no shortage of headlines these days detailing breaches, Advanced Persistent Threats (APTs), and other such attention grabbing topics. The details vary in each individual case of course, but most of these stories have one common thread: they all involve malicious code, also known as malware. Amidst all of the headlines, I am concerned that as a security community, we are losing sight of an important principle that is very important to remember: not all intrusions involve malware.

<p><span><span>There is no shortage of headlines these days detailing breaches, Advanced Persistent Threats (APTs), and other such attention grabbing topics. The details vary in each individual case of course, but most of these stories have one common thread: they all involve malicious code, also known as malware. Amidst all of the headlines, I am concerned that as a security community, we are losing sight of an important principle that is very important to remember: not all intrusions involve malware.</span></span></p>

There is no shortage of headlines these days detailing breaches, Advanced Persistent Threats (APTs), and other such attention grabbing topics. The details vary in each individual case of course, but most of these stories have one common thread: they all involve malicious code, also known as malware. Amidst all of the headlines, I am concerned that as a security community, we are losing sight of an important principle that is very important to remember: not all intrusions involve malware.

It is certainly true that the threat posed by malicious code is great. It is also true that we must absolutely seek to detect malicious code on our networks and move to contain it before any damage can occur within our organizations. But we must not forget that there are many ways into the heart of an organization that involve no malware at all. Some examples of these paths inward include, but are not limited to:

SSH Brute Force: Many organizations have servers that permit external login (from the Internet) via Secure Shell (SSH). There are many legitimate business reasons why an organization would need to permit this. That being said, when certain best practices around authentication and authorization are not followed (e.g., permitting root login remotely, not locking out accounts after N failed login attempts, etc.), it can lead to trouble. If an attacker can successfully guess a valid username and password to that server, that attacker is in. And once present on that server, that attacker looks like a legitimate user on a legitimate asset to the casual observer. The attacker would also be able to move laterally to anywhere within the organization that a legitimate user on that server would be able to move. No malware required.

SQL Injection: Public-facing web servers often run web applications that interface with databases. This is a legitimate and common business practice that can sometimes be done insecurely or sloppily, for a variety of reasons. When web applications are vulnerable, attackers can “inject” certain database commands into form submissions and other actions supported by HTTP. This can allow the attackers to view data, alter data, modify the contents of the website, and/or even compromise the system. From there, the attacker can move laterally and/or direct unsuspecting website visitors to external malicious websites, among other things.

Stolen Credentials: It is not uncommon for organizations to maintain trusted connections or VPN tunnels to and from trusted partner organizations. If an attacker can steal credentials from a trusted partner, that attacker can use those credentials to access the organization’s resources via the partner’s trusted connection. The difference between legitimate use of credentials by a partner and malicious use of those same credentials by an attacker is merely intent. As we know, intent can be extremely difficult to derive from the bits and bytes alone. It is the stuff of nightmares, but it does happen.

In light of this, it is important to remember to allot the appropriate resources to non-malware related intrusions. But what are some possible ways to incorporate this aspect into your security program?

Let’s begin that discussion by remembering the first four stages of the incident response/incident handling life cycle: Detection, Analysis, Containment, and Remediation. Since Detection comes first, it makes sense to begin the discussion there.

Detecting intrusion activity that does not involve malware is non-trivial. That being said, the journey begins by looking for the unknown unknowns. That involves the identification of network traffic or endpoint activity that falls outside the norms of what would be expected, and whose true nature is unknown. This is an important point – this is a step beyond the purely signature-based detection approach that many organizations are familiar with. Signatures are necessary for intrusion detection, but they are not sufficient. It is true that there are some approaches to detecting malware intrusions that have also moved beyond being solely signature-based. This is a good thing in my opinion, and it is an extremely complementary activity.

Advertisement. Scroll to continue reading.

Although the journey into the unknown unknowns takes us a step beyond signature-based detection, the idea of developing high fidelity content to populate the work queue remains the same. In the same way that an organization develops signature-based alert content to populate the work queue, that organization would also want to develop logic to look for interesting events from the unknown unknowns and populate the work queue with those.

Along these lines, some examples of interesting detection approaches for an organization’s network or endpoint data include:

• High volume of failed or attempted logins to a single endpoint or server

• High volume of failed or attempted logins from a single endpoint or server

• Large uptick in number of endpoints communicated with from a given endpoint

• Large uptick in volume of traffic from a given endpoint (percent change may be more helpful than absolute volume change)

• Outbound shell activity to unknown or previously unseen external hosts

• Activity to newly created domains

• Unusual “clustering” or “clumping” of specific source and destination ports (where a more uniform or random distribution might be expected)

These are just a few examples of interesting approaches, of which there are many of course. The idea of each approach is to produce “jumping off points” – events that launch an analyst into a focused investigation and an orderly workflow around each specific event. It is during this investigative process that the analyst will pull together endpoint, network, and other data in an attempt to build the narrative around what occurred. The analysis stage and the assembly of the narrative serve to allow for a conclusion to be drawn regarding the true nature of the traffic. The traffic should be qualified either as suspicious, malicious, benign, or unknown, and a determination should be made as to what, if anything, needs to be contained and remediated.

Although malware poses a constant and significant threat to organizations, it is not the only threat that those organizations face. Intrusions that involve malware must absolutely be detected and contained in a timely manner. At the same time, it is also helpful to remember that not all intrusions involve malware. As such, organizations should ensure that their security programs devote adequate time to detecting and responding to intrusions that do not involve malware. A mix of detection and response capabilities designed to identify both intrusions that involve malware and those that do not will serve an organization well.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version