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:

1. Rogue processes
2. Evidence of persistence
3. Suspicious traffic Activity and user-role mismatches
4. 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:

  • FireEye Redline
  • Microsoft Sigcheck
  • Didier Stevens Authenticode tools
• 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.
• RDP files. If RDP sessions have been used, files that define connection configurations might exist.
• 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.

ABOUT EVENTTRACKER

EventTracker offers a dynamic suite of award winning products for SIEM and event log management. SC Magazine BestBuy EventTracker Enterprise processes hundreds of millions of discrete log messages to deliver vital and actionable information, enabling organizations to identify and address security risks, improve IT security, and maintain regulatory compliance requirements with simplified audit functionality. Security Center offers instant security alerts and a real-time dashboard for viewing every incident in the infrastructure, and Compliance Center is a monitoring and early threat detection tool.

Complementing these products is SIEM Simplified(SM), our award winning services offering to augment IT resources in smaller enterprises. Our experienced staff assume responsibility for all SIEM-related tasks including daily incident reviews, daily/weekly log reviews, configuration assessments, incident investigation support and audit support.

Our customers span multiple sectors including financial, communications, scientific, healthcare, banking and government, with solutions currently deployed at over 850 global customer sites.

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.

DISCLAIMER & COPYRIGHT

Monterey Technology Group, Inc. and EventTracker make no claim that use of this white paper will assure a successful outcome. Readers use all information within this document at their own risk. Ultimate Windows Security is a division of Monterey Technology Group, Inc. ©2006-2016 Monterey Technology Group, Inc. All rights reserved.

This article by Randy Smith was originally published by EventTracker

http://www.eventtracker.com/webinars/top-5-indicators-of-evil-on-windows-hosts-endpoint-threat-detection-and-response/