Malware and Advanced Threat Protection: A User-Host-Process Model

Last updated at Mon, 11 Mar 2024 18:02:23 GMT

In today's big data and data science age, you need to think outside the box when it comes to malware and advanced threat protection. For the Analytic Response team at our 24/7 SOC in Alexandria, VA, we use three levels of user behavior analytics to identify and respond to threats. The model is defined as User-Host-Process, or UHP. Using this model and its supporting datasets allows our team to quickly neutralize and protect against advanced threats with a high confidence rate.

What is the User-Host-Process Model?

The UHP model supports our incident response and SOC analysts by adding context to every finding and pinpointing anomalous behavior. At its essence, it asks three main questions:

• What users are on the network?
• What hosts are they accessing?
• What processes are users running on those hosts?

This model also includes several enrichment sources such as operating system anomalies, whitelisting and known evil to help in the decision-making process. Once these datasets are populated, the output from the model can be applied in a variety of different ways.

For example, most modern SIEM solutions alert if a user logs in from a new, foreign country IP address. If you need to validate the alert armed only with log files, you'd be hard-pressed to confirm if the activity is malicious or benign.  Our Analytic Response team uses the UHP model to automatically bring in contextual data on users, hosts, and processes to help validate the alert. Here are artifact examples below:

• User Account Information
  • Account created, Active Directory, accessed hosts, public IPs...
• Host Information
  • Destination host purpose, location, owner, operating system, service pack, criticality, sensitivity...
• Process Information
  • Process name, process id, parent process id, path, hashes, arguments, children, parents, execution order, network connections...

With this supporting data, we build a profiles for each user or artifact found. Circling back to our example “user logged in from a new IP address in a foreign country”, we can add this context:

• Does the user typically log in and behave in this way?
  • Day/time of login, process execution order, duration of login
• How often does the user run these particular processes?
  • Common, unique, rare
• How common is this user's authentication onto this system?
• How often have these processes executed on this system?

Armed with UHP model data, we have a baseline of user activity to aid in threat validation. If this user has never logged in from this remote IP, seldom logs into the destination system, and their process execution chain deviates from historical activity, we know that this alert needs further investigation.

Analyzing Malware, the UHP Way

Adhering to a UHP model means that for every executable, important metadata and artifacts are collected not only during execution, but also as a static binary. When you're able to compare binary commonality, arguments, execution frequency and other lower level attributes, you now have additional context to make nuanced decisions about suspected malware.

For example, for the question, “How unique is a process?”, there are several layers to the question. Let's look at four:

• Process commonality on a single asset
  • Single host baseline
• Process commonality at an organizational level
  • Across all of my assets, how many are running this process?
• Process commonality at an industry/sector level
  • Across organizations in the same vertical, how common is this process?
• Process commonality for all available datasets.
  

To be most effective, the User, Host, and Process model applies multiple datasets to a specific question to aid in validation. So in the event that the “U” or user dataset finds no anomalies, the next Host layer is applied.  Finally, the Process layer is applied to find anomalies.

Use Case: (Webshell)

Rapid7 was called to assist on an Incident Response engagement involving potential unauthorized access and suspicious activity on a customer's public facing web server. The customer had deployed a system running Windows Internet Information Services (IIS) to serve static/dynamic content web pages for their clients.

We started the engagement by pulling data around the users in the environment, hosts, and real-time process executions to build up the UHP model. While in this case, User and Host models didn't detect any initial anomalies, the real-time process tracking, cross process attributes, baselines and context models was able to identify suspicious command-line execution from the parent process w3wp.exe. This process happens to be the IIS process responsible for running the webserver. Using this data, we pivoted to the weblogs, which identified the suspicious web shell being accessed from a remote IP address. From there we were able to thoroughly remediate the attack.

Summary

The Analytic Response team uses models such as UHP to help automate alert validation and add context to findings. Adding in additional datasets from external sources such as VirusTotal, NSRL and IP related tools helps infuse additional context to the alerts, increasing analyst confidence and slashing incident investigation times. For each of our Analytic Response customers, we take into account their unique user, host, and process profiles. By applying the UHP model during alert triage, hunting and incident response, we can quickly identify and protect against advanced threats and malware in your enterprise quickly and accurately.