5 Ways Attackers Can Evade A SIEM

January 06, 2016

In today’s Whiteboard Wednesday, Joe Busch, Sales Engineer for Rapid7, will discuss the common tactics attackers can use to evade a SIEM.

Joe will walk you through the pros and cons of today’s SIEM technology and the common tactics that attackers use today to remain undetected from SIEM tools.

If you are interested in detecting today’s most common attacks, check out our user behavior analytics solution, InsightIDR. InsightIDR detects today’s common attacks automatically, allows you to investigate incidents quickly, and helps you monitor behavior from endpoint to the cloud.

Watch this week’s video to learn more.

Video Transcript

Welcome to this week's Whiteboard Wednesday. My name is Joe Busch. I am a security sales engineer here at Rapid7. This week we're going to be talking about five ways attackers can evade a SIEM. Let's start by talking about what SIEMs do well. SIEMs aggregate data. Their job is to pull data from all of the different security event sources inside of your environment, whether that's a firewall, active directory, an IDS, antivirus, or whatever it might be, pull all that data together, and keep a long term record of it. SIEMs are very good at that.

Show more Show less

The second thing a SIEM does really well is rules-based detection. SIEMs often give the ability to write different rules for detections amongst those different sources to detect if there's abnormalities inside of the firewall or correlated with authentications inside of active directory. These are the two things SIEMs do really well. Attackers know this. When attackers start thinking about how they're going to avoid a SIEM, we do a couple of different things. First of all, the big thing to keep in mind is that attackers are actively avoiding your logging capabilities in a SIEM. They know it's out there. They know how it works.

It's different from other detections that may happen inside your network. When you're thinking from an operations perspective, you're monitoring file servers and other performance metrics on your database servers. They're not trying to hide from you. An attacker is trying to hide from you. They know how the detections work, so that's what they're trying to do. They're doing two specific things when they try to hide from you. The first is they're trying to avoid getting logged in the first place. If an attacker can avoid making an impact in that SIEM, the SIEM can't use any of its rules to detect it. Kind of a basic obvious concept.

There are a couple of different ways that they do that. First, social engineering continues to remain king. If I can convince a user to let me into the network, that's the best way for me to go about things, whether that's stealing credentials or convincing them to run some malware for me. If I can get a shell on a system, systems are not being monitored for those active shells in most cases, and systems are also not being monitored for the outbound traffic in most cases. If I get a shell on a system from malware, great, I'm set. Nobody's watching at that point.

The second thing is once we've established a foothold on the network, attackers stay local. By staying local, I mean they use local accounts and local credentials and local hashes to move around the network as much as possible. Why do they do this? Well, SIEMs are really great at aggregating all this data, but the majority of SIEMs are not configured to pull local logs from the different systems. There's an enormous amount of data here. This east to west traffic is basically completely under the radar. SIEMs aren't tracking it and, again, we can't do detection on things that we're not tracking.

Third, attackers will go into the cloud. If I'm able to glean credentials from you, instead of going through your local systems, I may go after your cloud infrastructure instead, whether that's in AWS or Salesforce or NetSuite or something like that. If you've got valuable data out in the cloud, sometimes it's easiest for the attacker to just pull that information straight from there and start monetizing it. No need to go on the local systems at all. Since that information is not hitting your perimeter, once again, the SIEM's not detecting it. It's not getting logged.

Now, inevitably, the advanced attackers are going to move through your network in ways that are going to get logged. They're going to make an impact somewhere. Some sort of centralized information is going to get detected as they move throughout in their inevitable goal to own your network. There are a couple of things attackers do to then avoid getting detected. The first is they'll use known existing infrastructure, like service accounts, to try and match patterns that are already existing on the network. If I use a service account, many service accounts for security tools and patch management tools and other management tools already have permission to move throughout the entire network.

If it's typical for that account to already be accessing a system, we're unlikely to set off alarms by using a service account. It's normal behavior. The second thing and kind of a broader theme here is attackers will go low and slow, so our turtle here. Low and slow really means let's get on a system and let's stop and let's observe what's happening. What accounts are coming in and out of the system? What systems are being accessed from there? If we mimic back behavior and follow those accounts around and follow to those different systems, we're matching the baseline in the network already. We're not going to be raising any flags and we're avoiding being detected by any rules that might be out there. Staying low and slow is extremely critical for an attacker to avoid being detected by SIEMs.

Rounding things up, SIEMs are great at aggregating data, they have good rule based detection, but, attackers know how to defeat them. Using things like social engineering and local accounts helps us to avoid getting logged. Being just smart and working slowly and methodically helps us stop being detected. That's it for this week's Whiteboard Wednesday. Hope to see you next week.

See InsightIDR in Action

Ride along with Rapid7 as we detect attacks, find intruders, and investigate alerts in a guided demo.

Request Demo