In the previous blog, we wrote about how to get started with QRadar User Behavior Analytics (UBA) by enabling use cases related to account access anomalies. In the second phase of implementation we recommend you deploy use cases related to user access behavior, network, and flow anomalies.
Identifying user behavior based on how they access their systems, or corporate assets, or use network resources can help detect potential threats and compromised accounts.
Below are 37 use cases, grouped by user behavioral anomalies that might interest you are are relevant to your environment. Based on these uses cases our clients have found the following anomalies:
- Employees using Tor services to access external websites that were banned by company policy.
- A non-executive employee accessed resources meant for executives that contained sensitive financial information
- Based on geo anomalies found employees taking work laptops out of the country when on vacation
Amazon accounts accessed domestically and from abroad minutes apart
- Found multiple user accounts being accessed from the same IP address indicating potentially compromised credentials
Part 1. User access use cases
- User Accessing Account from Anonymous Source – Indicates that a user is accessing internal resources from an anonymous source such as TOR or a VPN.
- User Access Login Anomaly – Indicates a sequence of login failures on a local asset. The rule might also indicate an account compromise or lateral movement activity. Ensure that the Multiple Login Failures for Single Username rule is enabled. Adjust the match and time duration parameters for this rule to tune the responsiveness.
- Pass the Hash – Detects Windows logon events that are possibly generated during pass the hash exploits.
- Possible TGT Forgery – Detects Kerberos TGTs that contain Domain Name anomalies. These possibly indicate tickets that are generated by using pass the ticket exploits.
- Windows access with Service or Machine Account – Detects any interactive session (RDP, local login) that is initiated by a service or machine account in Windows Server.
- Repeat Unauthorized Access – Indicates that repeat unauthorized access activities were found.
- Unauthorized Access – Indicates that unauthorized access activities were found.
- Orphaned or Revoked or Suspended Account Used – Indicates that a user attempted to log in to a disabled or an expired account on a local system. This rule might also suggest that an account was compromised.
Critical / risky assets
- User Access – Failed Access to Critical Assets – This rule detects authentication failures for systems located in the Critical Assets reference set.
- User Accessing Risky Resources – Indicates that a user accessed an external resource that is deemed to be inappropriate or risky, or that shows signs of infection.
- First Privilege Escalation – Indicates that a user executed privileged access for the first time. This reporting rule can be disabled to allow the tracking of user behaviors for base-lining purposes.
- Suspicious Privileged Activity (First Observed Privilege Use) – Indicates that a user executed a privileged action that the user never executed before. Observations are kept in “UBA: Observed Activities by Low Level Category and Username” map-of-sets.
- Suspicious Privileged Activity (Rarely Used Privilege) – Indicates that a user executed a privileged action that the user has not executed recently. Observations are kept in “UBA: Recent Activities by Low Level Category and Username” map-of-sets. The sensitivity of this event can be modified by changing the TTL (time-to-live) of the Reference Map-of-Sets for “UBA: Recent Activities by Low Level Category and Username”. Increasing the TTL reduces the sensitivity. Decreasing the TTL increases the sensitivity.
- Recent User Activity Update (privileged) – Updates the last seen value for a user on the observations that are kept in “UBA: Recent Activities by Low Level Category and Username” map-of-sets.
- User Behavior, Session Anomaly by Destination Found – This is a CRE rule that supports the identical respective ADE rule: UBA: User Behavior, Session Anomaly by Destination (ADE rule) which indicates that a user is accessing significantly different destination IP addresses than were accessed by the user in the past. The event is not necessarily an indication of compromise. The change in behavior might indicate a significant change in the user’s job responsibilities or work habits.
- User Event Frequency Anomaly – Categories Found – This is a CRE rule that supports the identical respective ADE rule: UBA: User Event Frequency Anomaly – Categories (ADE rule) which uses the Anomaly Detection engine to monitor the category distribution of a user’s events. It will alert on unusual frequency changes.
- Critical Systems Users Seen Update – Updates the last seen value in the “Critical Systems Users Seen” reference collection for Destination IP/Username matches that already exist.
Time and Geo
- User Geography, Access from Unusual Locations – Indicates that users were able to authenticate in countries that are unusual for your network.
- User Anomalous Geography – Indicates that multiple locations or sources are using the same user account simultaneously.
- User Geography Change – A match indicates that a user logged in remotely from a country that is different from the country of the user’s last remote login. This rule might also indicate an account compromise, particularly if the rule matches occurred closely in time.
Part 2. Network and flow use cases
Network and flow events and data can also be powerful indicators of user behavior anomalies and potential exploits by external actors. Take for example if multiple send servers send emails with the exact same subject line; this would indicate a potential phishing attempt aimed at employees. It can also identify risky behavior that could lead to a potential exploit.
- Detect Persistent SSH session – Detects SSH sessions that are active for more than 10 hours.
- D/DoS Attack Detected – Detects network Denial of Service (DoS) attacks by a user.
- Network Traffic: Capture, Monitoring and Analysis Program Usage – Indicates that a process is created and the process name matches one of the binary names that are listed in the reference set “UBA : Network Capture, Monitoring and Analysis Program Filenames”. This reference set lists the binary names of network packet capturing software. The reference set is pre-populated with the names of some common network protocol analysis software filenames.
- QNI – Access to Improperly Secured Service – Certificate Expired – QRadar Network Insights (QNI) detected an SSL/TLS session which uses an expired certificate. Servers and clients use certificates when establishing communication using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Certificates are issued with an expiration date that indicates how long the certificate remains valid.
- QNI – Access to Improperly Secured Service – Certificate Invalid – QRadar Network Insights (QNI) has detected an SSL/TLS session that uses an invalid certificate. Servers and clients use X.509 certificates when establishing communication using Secure Sockets Layer (SSL). Certificates are issued with a Not Before date that indicates the earliest date the certificate is valid.
- QNI – Access to Improperly Secured Service – Self-Signed Certificate – QRadar Network Insights (QNI) detected an SSL/TLS session that uses a self-signed certificate. A self-signed certificate in a public-facing or production server application might allow a remote attacker to start a man-in-the-middle attack.
- QNI – Access to Improperly Secured Service – Weak Public Key Length – QRadar Network Insights (QNI) detected an SSL/TLS session that uses a certificate with a low public key bit count of less than 2048. A server that provides a weak Public Key Certificate (less than 1024 bits) can represent a security risk. According to NIST publication 800-57, the recommended minimum RSA key beginning in 2011 is 2048 bits.
- QNI – Observed File Hash Associated with Malware Threat – This rule triggers when flow content includes a file hash that matches known bad file hashes included in a Threat Intelligence data feed. Indicates that someone has transferred malware over the network.
- QNI – Observed File Hash Seen Across Multiple Hosts – This rule triggers when the same file hash associated with malware is seen being transferred to multiple destinations.
- QNI – Potential Spam/Phishing Attempt Detected on Rejected Email Recipient – This rule triggers when rejected email events sent to a non-existing recipient address are seen in the system. This can indicate a spam or phishing attempt. Configure the BB:CategoryDefinition: Rejected Email Recipient building block to include QIDs relevant to your organization. It is pre-populated with the following QIDs that are good for monitoring: Microsoft Exchange; Linux OS [running sendmail]; Solaris Operating System Sendmail Logs and Barracuda Spam and Virus Firewall.
- QNI – Potential Spam/Phishing Subject Detected from Multiple Sending Servers – This rule triggers when multiple sending servers send the same email subject in a period of time which may indicate spam or phishing.
With threat information sharing, threat intelligence feeds can help provide additional information in identifying risky behavior. Using information in IBM X-Force Exchange threat feeds, you can now identify when a user engages in risky behavior such as accessing questionable content via a risky url or if a local user / host is connecting to a malware or spam sending host server.
Use cases based on information from x-force threat intelligence
- X-Force Risky IP, Anonymization – This rule detects when a local user or host is connecting to an external anonymization service.
- X-Force Risky IP, Botnet – This rule detects when a local user or host is connecting to a botnet command and control server.
- X-Force Risky IP, Dynamic – This rule detects when a local user or host is connecting to a dynamically assigned IP address.
- X-Force Risky IP, Malware – This rule detects when a local user or host is connecting to a malware host.
- X-Force Risky IP, Spam – This rule detects when a local user or host is connecting to a spam-sending host.
- X-Force Risky URL – This rule detects when a local user is accessing questionable online content.
By enabling and tuning the above use case rules, you can now advance your QRadar UBA app to identify more advanced and complex anomalies related to risky user behavior.
Authors: Milan Patel and Rohan Ramesh