UEBA Essentials Hunting Guide

Document created by RSA Information Design and Development on Mar 7, 2018Last modified by RSA Information Design and Development on Oct 8, 2018
Version 32Show Document
  • View in full screen mode
 

This document contains the following sections:

Summary

The purpose of UEBA Essentials and user-hunting is to detect or bring focus to suspicious user (and entity) behavior to find potential insider threats, lateral movement by external attackers, or general abuse or misuse of user accounts (policy). To flush out use cases and build effective detection and hunting content, we need to drill down into each of these, to determine actions and behaviors that attackers are likely to attempt.

Consider some fundamental questions to ask:

  • What fundamental techniques and behaviors are common across a nearly all intrusions?
  • What is the evidence that these techniques leave behind?
  • What do all attackers do?
  • What are "normal" behaviors that I expect from my accounts and entities?
  • What does my network look like, and where are my sensitive machines located?

Once you have an idea of the questions you need to ask and the behavior on which you want to focus, it's time to hunt, and leverage that hunting across user and entity behaviors. This is the aim of the UEBA Essentials Hunting Guide and related content.

Taking what you've learned by looking through the Packets Hunting Guide, the same methodology is leveraged here. Hunt through meta data to find interesting pieces of behavior: capture that knowledge as Application Rules, so you don't have to perform the same queries and drills multiple times. Then aggregate the atomic events into behaviors and express those behaviors as an RSA Correlation Rule. This leads to higher-fidelity alerts as well as providing a way to hunt through behaviors and discover more complex activity throughout an environment.

It takes a combination of the right visibility (the right data from the right devices), context, and an understanding of what it is you're looking for to find suspicious user behavior and validate it as either malicious or benign. It's important to collect the data you need to satisfy the use cases that you're interested in. This allows you the best opportunity to get the best detection possible and not be distracted by non-essential information.

This document walks through and provides suggestions on how to frame hunts, which data to gather, and how Live Content and product Dashboards help automate the process of user behavior analysis.

Deploying the UEBA Essentials bundle downloads all of the content and content dependencies of the UEBA Essentials Pack to the service appropriate for each content type.

For details on UEBA Essentials in RSA® NetWitness® Platform, see the following topics:

Intrusion Behaviors

To gauge the breadth of an incident, as well as to determine its impact, you need to understand what an attacker did after gaining entrance into your organization. It is important to note that events (logs, network sessions, processes) should not be considered isolated nor independent from one another. Instead, there must be a way to associate behaviors in order to gain insight into a compromised computer system.

User and Entity behavior is one method of looking into internal breach activity. To understand the types of activity you should look for, we leverage the Mitre ATT&CK framework. This allows us to bucket individual detection methods (rules, alerts, and models) into techniques, and then roll those up into tactics. This provides the additional benefit of understanding and identifying detection gaps in your environment, and being able to have a discussion around investigation techniques related to various attacker activities.

The following Coverage & Requirements Matrix shows how the content offered by RSA NetWitness lines up with the various ATT&CK Techniques, and how various techniques can be chained together to look for interesting combinations of behavior.

                     
ATT&CK TacticsATT&CK Technique IDsATT&CK TechniquesRequired Data Sources

Defense Evasion

Persistence

Privilege Escalation

Credential Access

Lateral Movement

Command and Control

Collection

Execution

Command and Control

Launch

T1098

T1169

T1035

T1110

T1078

T1136

T1089

T1105

T1070

T1039

T1050

T1076

PRE-T1146

PRE-T1149

 

Account Manipulation

sudo

Service Execution

Brute Force

Valid Accounts

Create Account

Disabling Security Tools

Remote File Copy

Indicator Removal on Host

Data from Network Shared Drive

New Service

Remote Desktop Protocol

Spear phishing messages with malicious links

Unconditional client-side exploitation/Injected Website/Driveby

RSA NetWitness Packets (or other Packet capture)

RSA NetWitness Endpoint

Windows Registry

File monitoring

Netflow/Enclave netflow

Process command-line parameters

Process monitoring

Anti-virus

Process use of network

Windows event logs

API monitoring

Authentication logs

Process Monitoring

Services

Network protocol analysis

Proxy logs

Mailserver/mail gateway logs

DNS resolution logs; Passive DNS data

Bro HTTP|SSL|DNS|SMTP logs

Network Data

Data Gathering

While UEBA Essentials is primarily based on log visibility, you can also gain insights by analyzing network traffic. The following protocols give insight into activity centered around usernames: HTTP, FTP, SNMP, SMTP, Telnet, POP3, IMAP, SIP, Kerberos, FTP, DCERPC, LDAP, and RADIUS as well a few others. While some information is more application specific (for example, determining failed or successful logins), some interesting insights can still be gained through network traffic analysis. In RSA NetWitness, the greatest level of network user visibility involving corporate-issued usernames revolves around HTTP (proxy authentication), Email, and Kerberos traffic. However, do not ignore the other protocols.

Data Filtering

Filtering network data is as important as filtering log data. If you are not able to decrypt encrypted traffic, consider filtering SSL, SSH, GRE, IPSEC, and ESP traffic by keeping only the associated metadata. If you want a little more visibility into SSL than just metadata, you keep the handshake part of the protocol (including the certificate exchange), and use the truncate=app option. Likewise if you'd like to keep the first X bytes of any type of a session, you can use truncate=X (where X is the number of bytes you want like to keep).

Sometimes keeping a bit of raw data in addition to the meta can help with that extra bit of context needed in an investigation. There is a line that you walk with filtering: too much and you may lose context, too little and you wind up wasting resources that could be better used. Just as in data gathering, data filtering is all about knowing your visibility points and workflow, and using those to drive filtering, just as you would use data ingest to drive use cases.

Logs

Data gathering

Perhaps the most important step of detecting any compromise or related activity is insuring you have the correct visibility and data. In this section, we examine some of the types of data that you should be collecting, and where you should be collecting it from, so as to have a greater chance of discovering an incident. Equally as important as bringing data into the system, is filtering out the data you don't need. User analysis is greatly impacted by visibility and data quality, and with any kind of analysis the motto "garbage in, garbage out" holds true.

Microsoft has several documents, from a log perspective, describing the types of data that you should consider bringing into the RSA NetWitness platform. We'll start here to make sure a baseline is established and then expand upon the other types of visibility that are beneficial when analyzing or looking for suspicious user behavior.

Data Filtering

Some events will be naturally noisy or excessive (ex.: 4688, 4689, 5156, 5158); these events need to be filtered or managed by their individual messages or field names in order to be used effectively. In some cases, this filtering can be achieved using capabilities of the RSA NetWitness platform, and in others it may need to be done using logging configurations directly on the client or server.

Additionally if you learn something from the output of any investigation, you should capture that intelligence so you (hopefully) don't have to perform the same analysis again. When you believe a username to be benign or not interested in activity from it? Add it to the User Whitelist Context Hub List. Find a suspicious username floating around and want to keep an eye on it? Add it to the User Blacklist Context Hub List. By adding usernames to various Context Hub Lists you can tune ESA rule behavior by ignoring or highlighting user behavior throughout the environment. While it requires a few more steps, the same type of workflow can be accomplished with feeds for domains, IPs, systems, and so on. An example of how feeds and content can work together as part of the analysis process (filtering and highlighting) check out the Lateral Movement Content Pack, which also intersects user behavior.

Use Cases

If you want to succeed and survive against contemporary adversaries, you're going to have to get past the traditional prevention-based models. To mount a successful defense in today's security landscape, you need to evolve beyond traditional security measures. The days of setting up shop in your SOC and getting down to the business of responding to queues of alerts are, simply put, outmoded and obsolete. Today, successful SOC teams concern themselves with hunting: stated simply, proactively seeking out the ways in which adversaries would seek to do harm, or otherwise affect their goals.

To help you understand and get started hunting, we have developed the NetWitness Hunt Card. The Hunt Card model provides a simple means of helping junior analysts to understand a particular type of threat, and a structured plan to help them go hunt against it. At the same time, Hunt Cards provide a template for senior analysts to document threats, plan hunts, and provide guidance to their junior analysts, thereby accelerating the development of their experience, effectiveness, and expertise. Each hunt card is made up of 9 sections, each with a distinct role in defining and documenting your hunts.

Hunt Card Template

Let's take a look at a Hunt Card template, and talk a bit about the role of each section:

                                         

Hunt Card Title or Focus

 

Card title, for example Lateral Movement: RDP

 

Activity Profile

One-line, executive summary of the use case

Knowledge Profile

One of:

  • Known Known
  • Known Unknown
  • Unknown Known
  • Unknown Unknown

Hypothesis or Axiom

  • Hypothesis if U-vectored, or
  • Axiom if K-vectored

Attackers may be leveraging a C2 channel that utilizes custom encoding or encryption techniques over commonly used ports

Data

Datasets include:

  • Enumerate data dependencies…
  • NetWitness for packets session meta
  • Proxy logs, Web-server logs
  • DNS resolution logs; Passive DNS data
  • Bro HTTP|SSL|DNS|SMTP logs

Related NetWitness Content:

  • Content Element Header: Lua parsers
  • Bulleted list if more than 1
  • Singular content elements get no header
  • <display name> application rule
  • Packs

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Bulleted list of ATT&CK™ tactics
  • Lateral Movement

ATT&CK™ Technique(s):

  • Bulleted list of ATT&CK™ techniques
  • T1076

Look for:

  • Where possible, provide a high level example, then reinforce with product-specific examples: NW meta, Key-Value pairs, alerts
  • Anomalies in network data:

    • Protocol mismatch
    • tcp.dstport = 443 && service != 443

  1. Leverage investigative drills to identify, isolate, and filter legitimate sessions;
  2. Investigate any remaining sessions to classify and categorize anomalous behaviors

Feedback

Derivative Intelligence:

  • Bulleted list of derivative intelligence produced by this hunt card
  • IOCs / IIOCs, rules, parsers, etc.

Next Steps:

  • Basic guidance, and what to do with derivative intelligence
  • May reference a Run Card or Orchestrator playbook

Related Hunt Cards

  • Bulleted list of related hunt cards
  • C2 Utilizing a common protocol on a common port
  • C2 Utilizing a custom protocol on a standard port
  • C2 Utilizing a common protocol on an uncommon port
  • C2 Utilizing a custom protocol on uncommon port

Related Analytic (Mitre CAR)

Link to the Mitre Cyber Analytic Repository (CAR), if available.

Notes on each section:

  • Hunt Card Title and Focus. This is fairly straightforward. It is just a unique name assigned to each of your hunt cards, so that everyone can easily understand what we're hunting.
  • Activity Profile. The activity profile is nothing more than a very high-level description of the intended purpose of the hunt card.
  • Knowledge Profile. See Knowledge Profile below.
  • Hypothesis or Axiom. See Hypothesis or Axiom below.
  • Data. The Data block in your hunt card lays out an inventory of the data sources required to support your axiom or hypothesis, and enumerates any related content that may contribute to the hunt.
  • Techniques and Patterns. The Techniques and Patterns block begins with a mapping to Mitre's ATT&CK™ Tactics and Techniques. The ATT&CK model is extremely beneficial as a means for thinking about how threats manifest, particularly against behaviors of known adversaries. Additionally, this block provides general guidance, as well as specific examples, of how to conduct your hunt using the RSA NetWitness platform.
  • Feedback. Successful hunts produce derivative intelligence that should be fed back into systems and processes for continuous improvement of an organization's operational security mission. The Feedback block outlines the derivative intelligence most likely to be produced, and goes on to provide general guidance on how to incorporate the intelligence, as well as next steps based on the results of the hunt.
  • Related Hunt Cards. As indicated with the ATT&CK mappings earlier in the hunt card, every hunt happens within the scope of a phase in the attack lifecycle. As such, there are always related events, and related hunts. These hunts may be related within a stack, such as a number of different techniques within the lateral movement tactic, or they may be related to phases left and right of the current hunt. The Related Hunt Cards block outlines those related cards to help establish where a hunt exists within the attack lifecycle, and where to look next.
  • Related Analytic (Mitre CAR). In addition to the ATT&CK™ mappings already mentioned, we map the related Cyber Analytics Repository (CAR) analytic where one exists. The CAR is a knowledge base of analytics developed by Mitre based on the ATT&CK™ model.

Knowledge Profile

The Knowledge Profile is useful in helping to think about how you can approach threats, and how to structure your hunts.

 

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we donʼt know. But there are also unknown unknowns. These are things we do not know we donʼt know." Donald Rumsfeld
 

While the comment is infamous, and has been widely debated, the fact remains that with a single addition it outlines a matrix that provides us with an infinitely useful state table for knowledge upon which action can be based. That addition is the 'Unknown Known—the things that we don't know we know, and it gets added to the other three outlined states. Let's examine each of these states of knowledge in a little more detail:

  • Known Known

    No real rocket science here; this is the realm of things where we have a good understanding of the elements required for detection. We understand the TTPs, the signatures of the related activity, and the required data. In short, we know everything that we need to know in order to build detection capabilities for threats that have a KK knowledge profile.

  • Known Unknown

    With a KU knowledge profile, we get into prime hunting territory. Known Unknown means that there's something we know that we don't know. In other words, a Question exists. We provide a good example of a KU knowledge profile below in the User Login Activity Monitoring Hunt Card: We know the body of valid accounts, but we don't always know when a particular login is legitimate or compromised.

  • Unknown Known

    Use cases or hunts with a UK profile characterize the latent or tacit knowledge in your enterprise–the information that's there, but that has yet to be understood and integrated as intelligence. Gaining command of your UK domain will make an adversary’s job much more difficult, as it will become much more difficult for them to hide and move about within your environment.

  • Unknown Unknown

    Use cases with a UU profile are not typically best for hunting, at least not before some analytical groundwork has been done. By definition, threats profiled UU are those threats that we don't even know exist. Because we don't know that they exist, it is very difficult to define and start asking questions. While senior analysts are often capable of finding these sorts of threats using structured analytic techniques, these are the types of problem that are perhaps best served by data science and machine learning models.

The four knowledge profiles outlined above give us a fairly complete set of ways that we can categorize what we do and do not know about our environment, the security landscape, and the threats that populate it. Conveniently, these profiles can be grouped as K-vectored (the Knowns) and U-vectored (the Unknowns).

Hypothesis or Axiom

Every hunt starts with a proposal regarding some sort of activity that may or may not be discoverable in your environment. Building upon the foundation we laid with Knowledge Profiles, we subdivide hunts and their associated proposals as K-vectored and U-vectored.

  • K-vectored hunts are based on one of the Known knowledge profiles, and thus have an associated Axiom. Within formal systems, Axioms are propositions that are assumed to be self-evidently true. Axioms are well suited to automation within a rules-based system.
  • U-vectored hunts are based on the Unknown knowledge profiles, and thus have an associated Hypothesis. Hypotheses are propositions based upon speculation or conjecture, typically requiring deductive or inductive proof. U-vectored hunts benefit greatly from the involvement of a senior analyst with an analytical mindset. However, they can often be refined to a point of being operationalized and run by mid-tier or junior analysts.

Hunt Card Examples (Log-based)

User Login Activity Monitoring Example

                                         

User Login Activity Monitoring

 

 

 

Activity Profile

Monitor user login activity for improved situational awareness.

Knowledge Profile

Known Unknown

Axiom

Enterprises should have a clear understanding of valid accounts, but do not know whether a particular login activity leveraging a valid account is legitimate, or is leveraging compromised credentials.

Monitoring logon and log-off events is a critical factor in development of good situational awareness. Generated events or alerts on unusual activity can be good indicators, or may serve to corroborate related hypotheses.

Data

Datasets include:

  • Windows Event logs
  • Authentication logs

Related NetWitness Content:

  • Log parsers: parsers that populate ec_activity = Logon
  • Event Stream Analysis rules:

    • Logins across multiple servers
    • Multiple Successful Logins from Multiple Diff Src to Same Dest
    • Lateral Movement Suspected Windows
  • Lateral Movement Content pack

More information:

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Defense Evasion
  • Persistence
  • Privilege Escalation

ATT&CK™ Technique(s):

  • Valid Credentials
  • This hunt card may be applied broadly to any number of monitoring tactics, dependent upon specific use case
  • Use cases may include monitoring for any or all remote connections, and building baselines and timelines for users and accounts

Look for:

  • User login sessions:

    • Logon events: EID 4624/518
    • Logoff events: EID 4634/538
    • Focus on Logon types 2,3,9, 10
  • Unusual remote login activity
  • Anomalies in user behavior patterns

Feedback

Derivative Intelligence:

  • Improved overall situational awareness
  • Compromised accounts and credentials
  • Compromised hosts
  • Attack paths

Next Steps:

  • Consider instrumenting to monitor all remote login activity.
  • Deploy dashboards and reports to provide layered coverage of user login activity.
  • Create baseline behavioral patterns for users; these baselines can be used as an indicator of unusual activity as well as to corroborate activity seen elsewhere.

Related Hunt Cards

  • Simultaneous logins on a host
  • User logins across multiple hosts or servers

Related Analytic (Mitre CAR)

CAR-2013-10-001: User Login Activity Monitoring

Simultaneous Logins on a Host Example

                                         

Simultaneous Logins on a Host

 

 

 

Activity Profile

Simultaneous logins may be an indicator of compromise (IOC)

Knowledge Profile

Known Unknown

Axiom

Within typical enterprise environments, it is relatively uncommon to see multiple users logged into a single system at the same time. There are exceptions to this, which should be understood and accounted for by whitelisting systems and users after sufficient vetting.

Under normal circumstances, multiple users logged into a single machine at the same time, or even within the same hour, can indicate compromised credentials.

Data

Datasets include:

  • Windows Event logs
  • Authentication logs

Related NetWitness Content:

  • Log parsers: parsers that populate ec_activity = Logon
  • Event Stream Analysis rules:

    • Multiple Successful Logins from Multiple Diff Src to Same Dest
    • Lateral Movement Suspected Windows
  • Lateral Movement Content pack

More information:

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Defense Evasion
  • Persistence
  • Privilege Escalation

ATT&CK™ Technique(s):

  • Valid Credentials (T1078)

Look for:

  • User login sessions:

    • Logon events: EID 4624/518
    • Logoff events: EID 4634/538
    • Focus on Logon types 2,3,9, 10
  • Group users by hostname
  • Window logins by earliest time and latest time
  • Identify systems with multiple logins where grouped users >1 and time window <= 1 hr

Note: Certain users or classes of users may need to be whitelisted after sufficient vetting.

Feedback

Derivative Intelligence:

  • Compromised accounts and credentials
  • Compromised hosts
  • Attack paths

Next Steps:

  • Leverage intelligence derived from this hunt card to drive additional hunting hypotheses or response actions
  • Lateral Movement Playbook

Related Hunt Cards

User logged in to multiple hosts

Related Analytic (Mitre CAR)

CAR-2013-02-008: Simultaneous Logins on a Host

User Logins Across Multiple Hosts or Servers Example

                                         

User Logins Across Multiple Hosts or Servers

 

 

 

Activity Profile

Simultaneous logins may be an indicator of lateral movement.

Knowledge Profile

Known Unknown

Axiom

It is not typical to see “normal” user accounts simultaneously logged into multiple systems. While certain administrative or “power users” may exhibit this behavior, most users tend to use only one or two systems in the course of normal business.

User accounts that log into multiple systems (especially within a brief span of time) may indicate compromised accounts and credentials. Related remote login sessions across multiple systems may indicate lateral movement.

Data

Datasets include:

  • Windows Event logs
  • Authentication logs

Related NetWitness Content:

  • Log parsers: parsers that populate ec_activity = Logon
  • Event Stream Analysis rules:

    • Logins across multiple servers
    • Lateral Movement Suspected Windows
  • Lateral Movement Content pack

More information:

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Defense Evasion
  • Persistence
  • Privilege Escalation

ATT&CK™ Technique(s):

  • Valid Credentials (T1078)

Look for:

  • User login sessions:

    • Logon events: EID 4624/518
    • Logoff events: EID 4634/538
    • Focus on Logon types 2,3,9, 10
  • Group users by hostname
  • Window logins by earliest time and latest time
  • Identify systems with multiple logins where grouped users >1 and time window <= 1 hr

Note: Certain users or classes of users may need to be whitelisted after sufficient vetting.

Feedback

Derivative Intelligence:

  • Compromised accounts and credentials
  • Compromised hosts
  • Attack paths

Next Steps:

  • Leverage intelligence derived from this hunt card to drive additional hunting hypotheses or response actions
  • Lateral Movement Playbook

Related Hunt Cards

Simultaneous logins on a host

Related Analytic (Mitre CAR)

CAR-2013-02-012: User Logged in to Multiple Hosts

Hunt Card Examples (Packet-based)

Phishing Messages with Malicious Links Example

                                         

Phishing Messages with Malicious Links

 

 

 

Activity Profile

Email messages that include malicious links are designed to convince users to click on links in order to deliver malware payloads.

Knowledge Profile

Known Unknown

Axiom

Email messages containing malicious links, designed to deliver malware payloads, remain one of the most significant and consistent threats faced by enterprises today. Criminal actors leverage a wide variety of email-based techniques to entice users to malicious sites and affect the establishment of initial beachheads within environments.

Links to malicious sites embedded in the body of an email continue to lead to a significant number of incursions; effectively detecting these techniques is a critical capability in reducing the impact of attacker successes, reducing attacker free-time, and mitigating the impact of credential compromise and lateral movement.

Data

Datasets include:

  • RSA NetWitness for packets session meta
  • Proxy logs
  • Mailserver/mail gateway logs
  • DNS resolution logs; Passive DNS data
  • Bro HTTP|SSL|DNS|SMTP logs

Related NetWitness Content:

  • Lua parsers:

    • Mail_lua
    • SMTP_lua
    • HTTP_lua
  • ESA Rules:

    • Malware Dropper
    • PunyCode Phishing Attempt

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Launch

ATT&CK™ Technique(s):

  • PRE-T1146

Look for:

  • Mail sessions that have a PunyCode hostname, a mismatch between the hostname in a link, and the text in the same link containing an IDN homograph.

    • host: www.xn--80ak6aa92e.com
    • ioc: homograph detected
    • service: www.apple.com
  • The suspected phishing attempt is followed by HTTP(S) traffic with the same hostname in the certificate or in the host.
  • Download of pdf, java, rtf, or Microsoft Office file, followed by download of EXE file within 5 minutes. (Indicative of a two-stage malware dropper.)

More information:

Dissecting PunyCode - Not All Characters are Created Equal

Feedback

Derivative Intelligence:

  • malicious mail hosts
  • malicious email addresses
  • subject lines
  • related URLs
  • domains
  • IP addresses
  • file names
  • file hashes
  • created processes

Next Steps:

Basic guidance/Run card or phishing playbook

Related Hunt Cards

Phishing Messages with Malicious Attachments

Related Analytic (Mitre CAR)

NA

Client-side Exploitation: Drive-by (RIG) Example

                                         

Client-side Exploitation: Drive-by (RIG)

 

 

 

Activity Profile

Identify and detect RIG EK activity based on network traffic analysis.

Knowledge Profile

Known Known

Axiom

While the widespread use of Exploit Kits has been in steady decline since the demise of the Lurk Group and Angler in June of 2016, the RIG EK ascended to the throne and has managed to remain a relatively persistent threat. It has evolved rapidly, and been able to adapt to new threat trends, such as ransomware, information stealing, and most recently, coin-mining. As of January 2018, RIG remained the market leader in the EK landscape.

Looking at RIG operations over time, it is easy to see that the actors behind the related campaigns are financially motivated. Effective detection of RIG can provide not only a tactical advantage against the direct threat of the EK itself, but may provide valuable insight into shifts in operational cadences and the overall threat landscape.

Data

Datasets include:

  • RSA NetWitness for packets session data

Related NetWitness Content:

  • Lua parsers:

    • HTML_lua
    • HTML_threat
  • RIG Exploit Kit application rule
  • RIG Exploit Kit Event Stream Analysis rule
  • Known Threats Pack bundle

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Launch

ATT&CK™ Technique(s):

  • PRE-T1149

Look for:

  • Output from RIG Exploit Kit application rule

    • ioc = rig exploit kit
    • inv.category = threat
    • inv.context = attack phase, exploit
  • ESA Alert = ‘RIG Exploit Kit’

More information:

Feedback

Derivative Intelligence:

  • Malicious URLs
  • domains
  • IP addresses
  • file names
  • file hashes
  • created processes

Next Steps:

  • Basic guidance/Run card
  • Patch management
  • User education
  • Improved endpoint protection
  • Exploit Kit playbook

Related Hunt Cards

NA

Related Analytic (Mitre CAR)

NA

Lateral Movement RDP Example

                                         

Lateral Movement RDP

 

 

 

Activity Profile

Detect abuse of lateral movement using RDP.

Knowledge Profile

Known Known

Axiom

Lateral movement is perhaps the keystone tactic in contemporary attacker methodologies. Following a quick entry via vectors such as phishing or web application compromise, Lateral movement is the pivotal step in reinforcing and expanding an attack. Remote Desktop Protocol (RDP) is just one technique that adversaries may employ for lateral movement. However, once they have obtained valid credentials, this is often the preferred means of establishing interactive access to assets.

The clandestine use of legitimate tools (such as RDP) provides good cover for adversaries, and can often be very difficult to detect. That said, it pays to focus on these tactics, as lateral movement is where adversaries spend the majority of their time, and is coincidentally when they are most vulnerable. The ability to detect and isolate adversarial use of RDP can be particularly important, not only in detecting the presence of an adversary in your network, but also in understanding and controlling the scope of an incursion.

Data

Datasets include:

  • RSA NetWitness for packets session data
  • Netflow logs
  • Windows security logs

Related NetWitness Content:

  • Lua parsers:

    • RDP_lua
    • traffic_flow
    • traffic_flow_options
  • RDP over Non-Standard Port application rule
  • ESA Rules:

    • RDP Traffic from Same Source to Multiple Different Destinations
    • RDP Inbound Traffic

Techniques and Patterns

ATT&CK™ Tactic(s):

  • Lateral Movement

ATT&CK™ Technique(s):

  • T1076

Look for:

  • Network connections to default RDP port (3389/tcp)
  • Network connections with RDP traffic to non-standard ports
  • Windows security logs

    • EID 4624
    • EID4634
    • EID4647
    • EID 4778
  • Network connections from mstsc.exe
  • Execution of rdpclip.exe
  • Leverage investigative drills to identify, isolate, and filter legitimate sessions
  • Investigate any remaining sessions to classify and categorize anomalous behaviors

Feedback

Derivative Intelligence: IOCs/IIOCs, rules, parsers, etc.

Next Steps: Basic guidance/Run “card”

Related Hunt Cards

NA

Related Analytic (Mitre CAR)

CAR-2013-07-002: RDP Connection Detection

Appendix

Network Parsers

These network parsers generate username or email meta.

Username

  • dcerpc.lua
  • ftp.lua
  • http.lua
  • imap.lua
  • irc_verbose.lua
  • kerberos.lua
  • ldap.lua
  • ntlmssp.lua
  • pop.lua
  • proxy_block.lua
  • qq.lua
  • radius.lua
  • sip.lua
  • smb.lua
  • socks.lua
  • fingerprint_job.lua

Email Addresses

  • http.lua
  • mail.lua
  • sip.lua
  • smtp.lua
  • vcard_lua.lua

UEBA Essentials Content Pack

As part of the ongoing development of content to combat threats, RSA develops content bundles. These consist of a grouped set of content (rules, parsers, feeds) that can be deployed as a group from RSA Live. For details, see Deploying a Bundle.

Note the limitations of the UEBA Essentials content pack:

  • It only works out-of-the-box with RSA NetWitness Platform versions 11.1 and later.
  • Deployment of some ESA Rules to NW releases prior to v11.1 will result in a failure to deploy due to Context Hub list dependencies.
  • To see the affected ESA Rules, refer to VERSIONS SUPPORTED section of the Description field for a specific rule in RSA ESA Rules.

Related Materials

You are here
Table of Contents > Use Cases > RSA UEBA Essentials Hunting Guide

Attachments

    Outcomes