Americas

  • United States

Asia

Oceania

roger_grimes
Columnist

Catch attackers even when they don’t use malware

How-To
Sep 15, 20156 mins
Data and Information SecurityNetwork MonitoringSecurity

Many advanced hackers opt to skip the malware and use common admin tools. To detect those sneaks, monitor your network for unusual activity

A big paradigm shift is under way in the malware world. Less malware is being used in the biggest, most sophisticated attacks.

Instead, malicious intruders are using the legitimate tools built into various operating systems to do their dirty work. Legitimate tools, including remote management tools and scripting engines, are far harder to detect than single-purpose malware.

This is nothing new. In the early days of computing, legitimate tools offered the most common path to hacking. Computer viruses and Trojan horse programs didn’t show up in force until the late 1980s, and back then, they were more of a nuisance as opposed to a real threat.

Even in their heyday, malware and other nefarious tools have mainly been used to pry the door open: to steal logon credentials, to guess passwords, to dump password hashes, or to install backdoor and remote access programs. Once the bad guys were in, they would generally turn to common admin tools such as Remote Desktop to move from computer to computer.

Today, admins and their arsenals of security software have gotten pretty good at detecting rogue programs. Yes, antivirus software is close to useless for detecting brand-new malware, but it does a great job of detecting malware on day two — and it certainly does well in detecting common attack tools. Defenders are also successfully using application control (such as whitelisting) programs to prevent installation of unauthorized software.

A stealthier approach

Attackers realize they can get away with more maliciousness longer by using as many legitimate tools and scripting commands as possible.

Many times, the initial compromise “malware” is nothing but a legitimate remote management tool designed to dial home and let the intruder in. You can find entire PowerShell attack kits, for example, and malicious gangs that excel at using them.

Today, most hackers can do everything they need without ever using a rogue tool. They’re fully aware of little-known, little-used, and powerful utilities hiding in plain sight. They know every feature of the tool and every syntactic command-line parameter, which enables them to use it silently and gracefully. You have to give these hackers credit: They’re better at using the management tools than many admins.

Detecting rogue behavior

How do you detect maliciousness when only legitimate tools are used? By looking for anomalous activity.

Simply, anomalous activity is any activity outside of your normal range or expectation. This of course implies that you know what normal is; establishing that baseline is probably the hardest part of the defense.

Start by trying to protect your most critical resources and the connections to those critical resources. Collect activity baselines over a long period of time — at least several weeks, if not several months. Then define threshold values to indicate suspicious activity that needs to be investigated.

Sometimes the threshold value will be 1 — a single occurrence is suspicious. A prime example would be a domain admin connecting to a particular server when domain admins should never connect to anything but domain controllers. Two other examples: employing a remote connection method or running a legitimate executable not commonly used by the company.

More often, alerts are triggered when a “certainty threshold” is exceeded. The most obvious example would be invalid password attempts. Every company has users who enter incorrect passwords and PINs on a daily basis. Some companies have tens of thousands of these a day, all legitimate. The trick is to figure out how many in a particular time period would be too many for legitimate, normal activity. Typically, you’ll want a lower threshold on guesses made against highly privileged accounts or critical assets.

To summarize, anomalous behavior should be defined as unexplained occurrences or changes in:

  • Location
  • Occurrence
  • Timing
  • Duration
  • Source
  • Patterns

I’ve already provided a few examples, but add these anomalies to your list as well:

  • Unauthorized connections from user accounts and computers that would not normally connect
  • Unexpected times of activity (such as typing or unexpected executions on a computer whose user has gone home for the day and isn’t logged in remotely)
  • Multiple connections using the same account in different locations
  • Unexpected origins or destinations
  • Unexpected network connection pathways (server to server, server to client, client to client, client to server, and so on)
  • Higher than normal bandwidth or file access activity
  • Use of rarely accessed admin utilities
  • Disablement of antivirus detection software
  • Unexpected reboots or restarts
  • Unexpected stops in activity
  • Large amounts of data being transferred to foreign location
  • Unexpected transfers during the night
  • Unexpected modification of local, critical files
  • Unexpected SSL/TLS connections
  • Unexpected archive or encrypted file packages

In addition to setting up thresholds and alerts, it’s critical that you log command lines and scripts — including every line of every script. Today, Microsoft Windows can do that using built-in event monitoring, but non-Windows systems may require modification or third-party tools.

Another excellent detection method is to use honeypots. Every company should have fake systems distributed throughout its environment. Because they’re fake, no person or system (after filtering out the broadcast and normal connections) should ever connect. One unexpected connection means something needs to be investigated.

Automate your monitoring

You need to automate anomalous detection as much as possible. Every anomalous event should be investigated and either ruled in as malicious or ruled out. Sure, you’ll get lots of false positives at first. But keep fine-tuning your detection and alerting system to filter out false positives as you find them.

Alerts that occur on workstations and servers should also be sent to the user and their supervisor for review. It’s critical that any unexpected activity be sent to the supervisor of that employee. That’s a great way of catching rogue employees in illicit activities.

Trying to alert on anomalous activity using legitimate tools is difficult, but the days of being able to rely on malicious software detection alone are coming to an end. Already, many companies have learned this lesson the hard way. Make sure your company understands the new threat and builds its defenses accordingly.

roger_grimes
Columnist

Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author