Security, et al

5 Indicators of Endpoint Evil

Mon, 19 Sep 2016 16:16:12 GMT

With so much focus on security these days, you’d
think IT would be winning the battle against malware and other threats. But all
too often,
a lack of focus on certain areas of the
network leads to a decrease in an organization’s security posture and an
increase in risk.

The endpoint is such an area. Endpoints have more
than the ability to reach beyond the protective layers of
internal security—they’re allowed to do so.
End user behaviors such as working from outside the office,
connecting to unsecured WiFi networks, visiting potentially dangerous websites,
and opening email with malicious
attachments or links all make endpoints a particularly
vulnerable attack vector with access to your organization’s network.

According to a recent Ponemon report 80 percent of
organizations are seeing web-born malware attacks. Sixty-five percent have
experienced rootkit attacks and 55 percent have encountered spear
phishing—all on a frequent basis.

And when malware and endpoints mix, the attack
doesn’t stop with a single infected machine. Rather, that first infection turns
the machine into what is commonly known as
a beachhead. From there, malware is
designed to spread laterally throughout your network, in an effort to maximize
the chances of obtaining valuable credentials or data.

Although your thoughts might immediately go to
attack mitigation and prevention, most organizations—a whopping 70 percent,
according to the Ponemon study—have difficulty enforcing endpoint security
policies.
Rather, detection is a key aspect of any
strategy. The best approach is to use the endpoint as a sensor, collecting
state information, understanding which behavior is normal, and identifying what
isn’t.

In this whitepaper, we focus on five trouble
indicators, each of which provides additional context around what to look for
on your endpoints:

Rogue processes

Evidence of
persistence

Suspicious traffic
Activity and user-role mismatches

Unusual OS
artifacts

For each indicator, we tell you what to look for,
as well as which tools you can use to identify and gather intelligence around
the malicious code that might be lurking within your endpoints.

Indicator #1: Rogue Processes

Successful attackers depend on their malware to go
undetected. After all, malicious remote administration tools (RATs) are
designed to provide access to the command prompt, file system, registry,
hardware, remote control, and more, with the purpose of
providing many ways to find, extract, hold hostage, or destroy your
organization’s critical information. If RATs were easy to find, the attack
wouldn’t stand a chance—so attackers use several methods to
obfuscate their presence.

Evil Methods

Process looks
good … on the surface. The process name (such as explorer.exe) is
right, but the parent process, logon user, or file path is incorrect. You need
to look not just
at the process in question, but also at the process that
started it. If that process is not standard, it could indicate that the child
process is a rogue process. Another method that attackers use is
a clever misspelling of the file name. For example, a rogue
file might be named scvhost.exe instead of svchost.exe—a spelling that is so
close, you would probably need to compare file names to confirm the
misspelling.

Suspicious DLL
execution. Dynamic Link Libraries (DLLs) contain modular code to help
support a main application. Attackers often take advantage of the fact that
parts of the core Windows OS heavily utilize DLLs:

rundll32.exe. Known as a command
line utility program, rundll32.exe is responsible for running DLLs by invoking
a function that is exported from a specific 16-bit or 32-bit DLL module.

svchost.exe. Svchost is a generic
Windows OS program that hosts approved Windows services. Malicious applications can be formed as DLLs
specifically made to work with svchost.exe and trick it into running
them.

Other legitimate
processes. The use of DLLs is common, so rogue DLLs can also be
loaded into an otherwise benign application.

Rootkits. These are nasty stuff.
By definition, they take advantage of administrative (root) access, embed
themselves into an OS, and then intelligently evade detection.

Regardless of the tactic used, the goal of rogue
processes is either to make the process look legitimate or to use a legitimate
process to launch a malicious DLL, making it more difficult to identify and
track via the security log.

Detecting Rogue Processes

Ideally, you have a centralized way to collect
relevant process information across your network and automatically identify
rogue processes—capabilities that are available via solutions like
EventTracker.
Here is the kind of analysis required to catch rogue
processes.

Analyze event ID
4688. This event is generated each time a new process is created. The
event provides relevant information that you can use to identify rogue
processes. As Figure 1 shows, this information includes the name of the user
account that launched
the process, the date and time the program started, the
process ID, the parent (creator) process ID, and the full path of the process
executable.

Note: Although this event shows
the Creator Process ID, there is no associated name or a full path to that
process, which is an important piece in determining whether a process is rogue.
The parent (creator)process can be determined by manually searching for an
earlier 4688 event with
a New Process ID that matches this Creator Process ID value.

After enabling Audit process
events via Group Policy, your endpoints will log a massive number of
events, so although this is a valuable way to get information, you’ll also need
to wade through a sea of data. Furthermore, the event is not generated when
DLLs are loaded, only when new processes are started.
So if the rogue process is a DLL hiding in a file such as
svchost.exe, the event logs won’t contain any clue that it was invoked.
However, after you identify something amiss on a given machine, memory
forensics tools such as those from the Volatility Foundation
can
help provide further forensics detail when DLLs are injected
or rootkits installed.

Check for
unsigned code/Malware and viruses are often attached to legitimate
executables from known or somewhat known entities. Program files that are
signed declare the publisher and confirms that has not been modified by an
attacker. Since unsigned files don’t have this assurance, unsigned code
might indicate potential malware – you just can’t tell. Note
that Windows 8 and earlier default to allowing unsigned code to run.

Several tools can audit and analyze running
processes on a machine. Although not enterprise-caliber tools, these can be
useful in tracking down issues on a per-machine basis:

Check programs
against the National Software Reference Library (NSRL). This library
(available at http://www.nsrl.nist.gov) is a joint effort between the U.S.
Department of Homeland Security; federal, state, and local law enforcement; and
the National Institute of Standards and Technology (NIST) to collect software
from various sources and incorporate file profiles into a reference library to
be used in the investigation of crimes involving computers.

At the end of the day, the trick to detecting rogue
processes is to know what should and should not be running on your Windows
endpoints. If you’re using a golden image, this exercise should be relatively
simple: compare the running processes with a known list. But if every machine
is somewhat different, you might need to start with a basic list of what should
be running and then use the methods here to detect what falls out of the
norm.

Detecting Rogue Processes with
EventTracker

Even with the appropriate auditing policies turned
on, you will need to do a fair amount of detective work to get a complete
picture of which processes are running and whether they are rogue.
EventTracker’s sensor collects pertinent information—including process, file,
creator, hash, and signer details—and intelligently present it as a single
event, as shown in Figure 2. This approach creates centralized details that are
easily available for security information and event management (SIEM) solutions
to
digest and act on.

In addition, other events, such as Exchange message
tracking, provide critical details. In the example that Figure 3 shows, you can
use the originating IP address, email subject, sender and recipient addresses,
and more to identify how rogue processes might be entering the
organization.

Moreover, EventTracker automatically compares
program files against the National Software Reference Library, looks for
unsigned code and alerts you to these and other suspicious
indicators.

Indicator #2: Evidence of Persistence

An attacker doesn’t want to retain control of your
endpoints for a short period; their malicious code needs ample time to permeate
your network to give them the greatest chance of finding just the right
credentials and give them access to valuable information. Attackers need to
ensure that their code can live on so that they can resume control even after
the closing of a process, a logoff, or a reboot.

Evil Methods

This list, though not exhaustive, represents many
ways that attackers ensure their malicious code remains actively running and in
existence on the endpoint.

Tasks.
Use of the AT command or scheduling tasks to run every minute or at logon, can
cause an endpoint to continually relaunch a malicious process.

Tampering with
services. Replacing service path settings in the registry or
replacing a service executable can launch malicious processes at boot up. In
addition, new services are created with generic but official-looking names such
as Windows Services Update, to throw you off the scent. MSInfo is a good
starting point to identify those services that aren’t required.

Auto-run registry
settings. The Run and RunOnce
settings found in several locations in the registry are perfect places to
nestle a reference to a malicious executable. MSInfo can play a role in
identifying what is configured to launch at bootup and logon.

DLL tampering or
interception. The basic premise is either to modify the DLL’s import
table to reference a malicious function or to modify the DLL code itself to
detour to your code and then return it to its normal function.

PowerShell
background jobs. A PowerShell process is spawned in the background
and runs the code necessary to keep the malicious process resident.

Local Group
Policy. Group Policy contains a place to configure both startup
scripts and logon scripts.

Browser add-ins
and plug-ins. Browsers have the potential for a lot of local access
to the endpoint, giving a browser the ability to re-infect a machine every time
it is opened.

Detecting Persistence

Look to the same methods that attackers use der to
find entries that are designed to guarantee persistence.
Note: Many malicious processes use more than one method to
redundantly ensure their survival. Finding references to a rogue process in any
of these locations is a indicator that it might be malicious.

Indicator #3: Suspicious traffic

Malicious code on an endpoint doesn’t exist simply
to sit there. It’s designed to replicate itself within the network and to
ultimately exfiltrate information from the network. Therefore, traffic
monitoring is another way to identify the existence of malicious
code.

You might think that you can simply use your
network monitoring sensors to pick up suspicious traffic. However, the reality
is that you need additional context only available on the endpoint, such as the
executable that is used to generate traffic, to ensure proper identification of
suspicious activity.

Evil Methods

If you find the following on your endpoints, they
could equate to suspicious network traffic:

Use of browser
ports by non-browsers. Ports 80, 443, or 8080 should represent web
services. Attackers use these ports to update code and exfiltrate data because
the ports are always left open on your firewall. Network packets show you only
which endpoint sent traffic over which port to which IP address; they won’t
show that the traffic was a rogue DLL called by svchost.exe that was used to
send data.

Use of browsers
over non-standard ports. Any browser not using standard ports, such
as 80, 443, or 8080, could indicate a valid process (your browsers) with a
malicious purpose.

Unexpected
traffic. Traffic might seem normal but become suspect when you
consider either the source or the target. A few examples include web traffic to
an IP address instead of a fully qualified domain name (FQDN); Remote Desktop
Protocol (RDP), FTP (File Transfer Protocol), or Secure Shell (SSH) sessions
from abnormal endpoints; and even outbound Simple Mail Transfer Protocol (SMTP)
sessions to an external host.

Detecting Suspicious Traffic

As mentioned earlier, just using a network sensor
lacks context. You need to know not only from which endpoint traffic
originated, but also from which process. There are a few steps you can take to
investigate suspicious traffic:

Monitor events
5154, 5155, 5156, and 5157. These events come from the Windows
Filtering Platform (WFP) and help to document the permitting and blocking of
inbound and outbound TCP or UDP connections. In each of these events, the
process ID, application path, source and destination IP
addresses, ports, and protocol are all documented, providing
you context around whether the combination of processes and ports adds up to
malicious or appropriate traffic.

Monitor outbound
DNS requests for unusual domain names. What determines “unusual”? Use
of a reputation service might be a good fit to help provide guidelines around
appropriate domain names.

The overarching goal is to use the combination of traffic
patterns, the processes that generate them and the type of endpoint to
establish suspicion. Without a third-party solution, you’ll need to look
granularly at specific endpoints, searching for these mismatches of processes
and traffic patterns.

Indicator #4: Activity and User-Role
Mismatches

An attacker will use any means necessary to spread
malicious code laterally throughout the organization and exfiltrate data—even
if it means doing so in a way that doesn’t fit the normal mode of operation for
the user of the endpoint. Therefore, look for anomalies in which activity
doesn’t align with the user’s role in the organization. For example, consider
traffic for a
given type of endpoint, such as an RDP session coming from
the desktop of a user in Accounting. If their workstation has never started an
RDP session in the past but suddenly does so now, you have a potential
candidate for an infected endpoint.

Evil Methods

As suspicious traffic can be indicative of
malicious code, so can the use of tools that are rarely, if ever, used by
non-IT users:

Utilities. Many of the tools that
IT considers foundational to configuring and supporting endpoints and networks
are all but a foreign language to regular users. This list includes (but is not
limited to) cmd.exe, rar.exe, at.exe, schtasks.exe, wmic.exe, powershell.exe,
winrm.vbs, net.exe, reg.exe, sc.exe, netstat.exe, and route.exe

Remote
sessions. We’ve talked about RDP from a traffic standpoint, but you
should also watch for it from an activity standpoint. Normal users (except thin
client and VDI users) usually have no need to connect to a server via RDP.

Unique mismatches
in your environment. You should devote some time to comparing the
usage difference between end-user and admin endpoints to determine which
applications (via processes) they normally run to create a profile.

Detecting Activity and User-Role
Mismatches

The simplest distinction to make is whether an
endpoint is normally used by a user or someone in IT. But in your organization,
the issue might be more complex than that; a user might be responsible for
initiating managed file transfers as part of their job, so an FTP session might
be in order. No matter the complexity of roles within your organization,
identifying roles and their corresponding profile of activity is the first step.

Next, identify which applications are being used. This
step is much more difficult to accomplish without at least a simple tool, such
as the old Process Monitor from Systernals with output to a CSV file.

Indicator #5: Unusual OS Artifacts

It’s very difficult for attackers not leave some
kind of trace in Windows of their presence. Knowing what to look for can help
you catchattackers at any point in the process.

The point here is to search out things not normally
found on end-user workstations. Here are a few examples:

Scripts. If PowerShell, VB
Script, or even a command prompt was used to execute a command script, scripts
might be left over, leaving clues as to what was executed.

Shared folders on an endpoint.
Because exfiltration of data is a large part of these attacks, simple shared
folders might be used to centralize obtained files so that they can be
exfiltrated from a single machine.

Shared folders access by an
endpoint. Looking at the previous artifact from the other
perspective, a given endpoint might have been used to connect to a central
share. A review in the registry of the following key can provide more detail on
which shares have been accessed:
KEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Shining the Spotlight on Endpoint Evil

Endpoints are here to stay for most organizations
and will continue to be a major risk area. Using the endpoint itself as a
security sensor—one that can provide information, detail, and context of
attempted breaches—can provide IT with the intelligence it requires to properly
detect and respond to attacks.

Much of the work highlighted in this paper requires
a massive amount of effort once you move past just a few endpoints. The only
way to catch attackers using these methods is to automate and EventTracker is
leading the way. EventTracker’s mature SIEM engine provides the centralized
analysis and point of management needed to handle thousands of endpoints.
Moreover, on the endpoint, EventTracker has advanced beyond the traditional
SIEM agent. EventTracker empowers your endpoints as
security sensors where you need them the most. Instead of
just forwarding event logs, EventTrackers sensor-agent watches system activity
in real-time on each and every endpoint looking for the indicators discussed in
this paper. With EventTracker you get visibility and alerting to a depth and
currency only possible with by leveraging agents on the endpoint.

EventTracker was founded in 1999 and is privately
funded and held. Our corporate headquarters are located in Columbia, Maryland
in the Baltimore-Washington high tech corridor, with research and development
facilities located in both Columbia and Bangalore, India.
www.eventtracker.com

ABOUT RANDY FRANKLIN SMITH

Randy Franklin Smith is an internationally
recognized expert on the security and control of Windows and AD security. Randy
publishes
www.UltimateWindowsSecurity.com and wrote The Windows Server 2008
Security Log Revealed—the only book devoted to the Windows security log. Randy
is the creator of LOGbinder software, which makes cryptic application logs
understandable and available to log-management and SIEM solutions. As a
Certified Information Systems Auditor, Randy performs security reviews for
clients ranging from small, privately held firms to
Fortune 500 companies, national, and international
organizations. Randy is also a Microsoft Security Most Valuable
Professional.