How Does Intezer Investigate Alerts?

Malware News
1

Zooming In on the Investigation Stage of Intezer’s Autonomous SOC Process

While we’ve provided an overview of Intezer’s entire Autonomous SOC process in a separate article, this article aims to delve deeper into the investigation stage. This stage is critical and unique, as it enables Intezer to make smart decisions, provide recommendations for response, and effectively functions as the core technology that allows Intezer to reduce human involvement in the alert triage process.

Evidence Collection

Before any investigation can take place, Intezer collects all pieces of evidence associated with an alert to investigate them one-by-one. This can include files, command line parameters, process arguments, URLs, parent and child processes, memory images, and more. You can read more about the evidence collection stage in a separate article.

High-Level Investigation Process

The investigation process can be broken down into four main steps:

  1. Analysis – Analyze each individual piece of evidence that was collected, such as files, command lines, URLs, and memory images, using multiple techniques and technologies. This includes recursively unpacking artifacts to extract more relevant evidence.
  2. Correlation – For each individual artifact, we find any code, behavior, and techniques similarities with any known malicious or trusted artifact in Intezer’s continuously growing database, and with any known artifact in the organizational database.
  3. Decision Making – We then combine and summarize all analysis results to assign a clear verdict, classification (threat actor / malware family / trusted software vendor), and risk for each individual piece of evidence.
  4. Alert Triage Assessment – Finally, we build a cohesive alert-wide assessment, including a verdict (true / false positive), risk level, and recommended next steps for response. We form this assessment by leveraging AI models that combine the following information:
    1. Investigation results from each individual piece of evidence
    2. Raw information and metadata from the security tool that originally fired the alert
    3. All Indicators of Compromise (IOCs) and detection content from all evidence.

In the following sections, we will delve into each part of the high-level investigation process in more detail.

1. Analysis

The analysis stage is the first step in the investigation process. Here, each individual artifact associated with an alert is thoroughly examined. Artifacts can include a wide range of evidence, such as files, command lines, URLs, and memory images. 

The goal of the analysis stage is to understand the nature of each artifact and its potential implications. To achieve this, we employ multiple techniques and technologies, including:

  1. Sandboxing (dynamic analysis)
    1. Monitoring processes and process tree changes
    2. Monitoring network traffic including DNS, TCP, UDP and any associated IOC 
    3. Monitoring service creations
    4. Monitoring file system activity (read, deleted, written)
    5. Monitoring Windows registry activity (read, deleted, written)
    6. Monitoring memory manipulation and injection
  2. Disassembly of machine code and interpreter code
  3. Static code and behavior analysis (e.g. API calls)
  4. Memory analysis
  5. URL analysis – via reputation, behavior, phishing indicators, visual similarity, and more
  6. Configuration extraction
  7. Proprietary YARA rule repository
  8. String extraction
  9. File metadata and hash extraction
  10. Textual analysis using AI models (ChatGPT-like)

Example of a partial sandboxing/dynamic analysis report

Example of static code analysis which identified suspicious capabilities and correlated to certain types of known threats

Example of a disassembled module to machine code that was later correlated with a Formbook malware

In addition, one of the unique aspects of our analysis process is the use of recursive unpacking. Many threats attempt to hide their true nature by compressing, packing or encrypting their code. Recursive unpacking allows us to extract the hidden code and other items within these packed or encrypted artifacts, revealing more relevant evidence for further analysis.

Example of multiple unpacked modules, either injected in memory or dropped on disk

Analyzing Fileless Threats

In addition to file-based threats, a decent amount of alerts for most security teams are in fact fileless. That can include behavioral or ML-based alerts from EDR, living-off-the-land techniques such as command lines and Powershell scripts, and more. Intezer analyzes those types of alerts with the following methods:

  1. Analyzing the textual information from the alert (such as command line, process arguments) – for example, a “curl http://malicious.web.site” command would trigger a URL analysis
  2. Packaging and detonating a command line in a sandbox environment – such as analyzing a base64 encrypted powershell script within the command line
  3. Collecting and analyzing any scripts that were executed
  4. Conducting deep memory analysis on the suspected endpoint to identify any hidden code injections or other fileless threats

Example of a fileless alert fired by Crowdstrike’s Command and Scripting engine, which triggered an automated memory analysis that identified Meterpreter malicious code in memory

By thoroughly analyzing each individual artifact, we can gain a deep understanding of the alert and the potential threat it represents. This forms the foundation for the subsequent stages of the investigation process.

2. Correlation

In the correlation stage we compare all extracted data from the Analysis stage to known malicious or trusted artifacts. This can include correlating pieces of code, strings, behaviors, file paths and more. The correlation is done against three main sources:

  1. Intezer’s continuously growing global genetic database
  2. Information from the organization itself (private genetic database)
  3. Third party threat intelligence and reputation sources

The most unique and important aspect of our correlation process is the use of Intezer’s proprietary Genetic Analysis technology. This technology allows us to identify the ‘genes’ – small pieces of code – that an artifact shares with known malware, legitimate software, or other code. By identifying these shared genes, we can determine if an artifact is related to known threats or trusted software and helps to identify the origin of any unknown threat.

Example of a Genetic Analysis correlating thousands of pieces of code to other known Agent Tesla variants

The Genetic Analysis technology is particularly impactful because it allows us to identify even the smallest similarities between an artifact and known code. This means that even if a threat is new or has been modified to evade detection, we can still identify it based on its shared genes.

Example of strings extracted from a file which were correlated to known variants of Iron Ransomware

In addition to Intezer’s global genetic database which is constantly maintained by Intezer’s research team and numerous automatic software code-indexing processes, we also correlate artifacts with the organization-specific genetic database. This database is specific and private to each customer and it is populated automatically based on the organization’s data as well as customer’s manual private indexing.  This is particularly helpful for identifying internally-developed software for the purpose of reducing false positives. It can also be helpful to identify any similar variants of unique, targeted threats that are indexed by the customer.

Example of a Genetic Analysis which clearly identifies a file as a trusted Microsoft software

In addition to Genetic Analysis, Intezer also correlates every extracted piece of evidence with threat intelligence and reputation databases such as VirusTotal, and additional sources such as the MITRE ATT&CK framework to highlight any malicious techniques used.

Through the correlation stage, we can gain a deeper understanding of each artifact and its potential implications, providing valuable context for the subsequent decision-making stage.

3. Decision Making

The decision-making stage is where we take the insights gained from the analysis and correlation stages and use them to make informed decisions about each individual piece of evidence.

For each artifact, we assign a verdict. This verdict can categorize the artifact as malicious, trusted, or other categories based on the results of the previous stages.

In addition to the verdict, we also assign a classification to each artifact. This classification can identify the artifact as part of a known malware family, associated with a specific threat actor, or as a product of a trusted software vendor. This classification provides further context for the alert, helping to understand the potential source and purpose of the threat.

Calculating verdicts and classifications is usually not a trivial task, as each piece of evidence usually includes many different micro-artifacts with different classifications and verdicts of their own. For example, a certain file that was alerted upon in Crowdstrike can run Explorer.EXE and Powershell.EXE, and while they are a trusted Windows file, that should not impact the overall verdict of the original file. Automating this non-trivial task is critical for reducing human involvement in alert triage processes.

The decision-making stage is a crucial part of the investigation process. By assigning a verdict and classification to each piece of evidence, we can provide a clear and actionable assessment of each alert. This forms the basis for the triage assessment and the subsequent response stage.

4. Alert Triage Assessment

The alert triage assessment is the final step in the investigation process. Here, we use AI models to combine all the information gathered in the previous stages to build a cohesive alert-wide assessment.

The goal of the alert triage assessment is to provide a verdict (true/false positive), risk level, and recommended next steps for response. This assessment provides a clear and actionable summary of the alert, allowing your security team to respond effectively and efficiently, ensuring they have all the information they need to make informed decisions about each alert.

For calculating the overall assessment, our algorithm combines:

  1. Analysis results from each individual piece of evidence: These results, which include the verdict and classification assigned in the decision-making stage, provide a detailed understanding of each piece of evidence associated with the alert.
  2. Deep, raw information from the security tool that originally fired the alert: This information provides additional context for the alert, helping to understand the circumstances under which it was triggered.
  3. All Indicators of Compromise (IOCs) and detection content from all evidence: These IOCs and detection content provide actionable information that can be used to respond to the alert.

Once the alert triage assessment is complete, it can be seen either in Intezer’s alert page, inside your security tool that fired the alert, or alternatively via API. It also can drive next steps and automated remediation or other workflows, as described in the article about Intezer’s Autonomous SOC process.

Alert page which contains the full triage assessment

Learn more

Discover how Intezer can help you automate your alert triage and decision-making processes for security alerts. We invite you to schedule your demo now, and our dedicated team will provide prompt assistance, ensuring you gain valuable insights into the capabilities of Intezer.

The post How Does Intezer Investigate Alerts? appeared first on Intezer.

Article Link: How Does Intezer Investigate Alerts?