Implementing Behavioral Baselines in Security Monitoring
  • 03 Apr 2024
  • 8 Minutes to read
  • Dark
    Light
  • PDF

Implementing Behavioral Baselines in Security Monitoring

  • Dark
    Light
  • PDF

Article Summary

Introduction

In this article, we delve into the concept of implementing organisational-specific behavioural baselines, underscoring the critical importance of IT and security teams working in tandem like never before. The aim is to establish these baselines to identify and intercept suspicious activities before they are recognised as malicious.

Given the diversity of endpoints and the range of users within an organisation, the system and user behaviours observed on these endpoints can significantly vary. While endpoints are typically managed through a Mobile Device Management (MDM) solution, there is also the distribution of organisational software and system activities related to device management to consider.

What are behavioural baselines?

The concept of behavioural baselines leverages endpoint security solutions to go beyond merely identifying known threats or malicious activities linked to recognized malware. It involves setting standards for the types of activities that should be expected on endpoints, focusing specifically on those initiated by known or trusted processes.

Endpoints are inherently equipped with various binaries and tools intended for use by IT administrators or authorized software. However, adversaries can also exploit these to execute arbitrary and malicious code.

The primary objective is to detect and analyse the usage of specific binaries or tools when they are utilized in unauthorised or illegitimate ways across endpoints. This approach aims to refine our security measures by differentiating between normal and potentially malicious activities, enhancing our overall defensive strategy.

The relevancy of IT and Security teams bundling knowledge and forces

While IT and security teams often try to collaborate, the depth of their partnership is not always as comprehensive as it should be. Security teams diligently monitor threats and anomalies across the device fleet but may lack a thorough understanding of the tooling and activities employed by IT teams for device management and security.

For a more effective approach, both teams should work closely together, ensuring transparency regarding the tools used and the activities undertaken by IT teams. Similarly, security teams should offer insights into the types of behaviours they are monitoring.

Only through such cooperation can we progress toward establishing robust behavioral baselines. This partnership is crucial for identifying suspicious activities early and maintaining the security and integrity of the organisation’s digital environment.

In a previous article we’ve covered how to achieve tailored event monitoring on macOS and explained the techniques which we’ll be using in this article as well.

You can find the previous article here: Tailored event monitoring on macOS

Building out baselines

To effectively distinguish between legitimate behavior and potentially suspicious activity, it's important to have a comprehensive understanding of the activity occurring on the endpoints within an organisation. 

This involves conducting a thorough inventory of the tools and utilities employed across the organisation. For example, this inventory would include software used by various departments for daily operations, administrative tools utilised by IT teams for system maintenance, and security tools deployed to protect against and monitor for threats. By cataloging these tools and understanding their normal usage patterns, we can establish a baseline of expected and suspicious activities.

As example

  • Generating User Notifications:

    • Tools like osascript and swiftdialog are commonly employed to generate user notifications on macOS. Monitoring the usage of these tools can help in identifying unauthorised or suspicious activities, as malicious actors can exploit them to mislead users or gather sensitive information.

  • Retrieving Hardware Related Data:

    • Utilities such as system_profiler are instrumental in fetching detailed information about the hardware configuration of a device, including its serial number, or detecting if it’s a physical device or a virtual machine. This can be used legitimately for tasks like setting the hostname automatically. However, it's vital to ensure that this capability is not misused to extract sensitive information for malicious purposes, as malware authors could use this to decide that the malware only executes on physical devices.

  • Elevating User Privileges:

    • Applications like Privileges.app or the Jamf Connect.app facilitate the programmatic promotion and demotion of user privileges. While these applications are designed to manage user access rights efficiently, it's crucial to monitor their usage closely. Unauthorised elevation of privileges is a common tactic used by attackers to gain access to restricted areas of the system or perform actions that would otherwise be beyond their reach.

As the macOS platform becomes an increasingly popular target for malware authors and adversaries, it's crucial to have robust detection mechanisms in place. These mechanisms are essential for identifying suspicious activities that could indicate the initial stages of an attack. Common techniques such as Credential Access or Reconnaissance are often employed in Infostealers or several other types of malware.

Taking the example of user notifications created using osascript, let's break down the steps necessary to detect potentially malicious activity:

  • Monitoring the Execution: Track the execution of osascript commands across the system. Since osascript can be used for legitimate purposes, the focus should be on identifying unusual or unexpected usage patterns.

  • Analyzing Command Arguments: Pay close attention to the arguments passed to osascript. Malicious scripts often have distinctive patterns that are not common in regular usage.

  • Contextual Awareness: Consider the context in which osascript is being used. For instance, an osascript command that is triggered shortly after an application download might warrant closer inspection.

  • Alert Configuration: Set up alerts for patterns that deviate significantly from the norm. This could include unusual execution times, scripts that access sensitive information, or scripts that attempt to modify system settings without user interaction.

  • User Education: Inform users about the potential misuse of system tools like osascript and advise on best practices for security. Encouraging users to report unexpected notifications or behavior can also aid in early detection.

By focusing on these aspects, IT and security teams can enhance their ability to detect and respond to early indicators of malicious activity, specifically those utilising legitimate tools like osascript for malicious purposes.

Detecting such behavior with a custom analytic rule could be outlined as follows, using a Process Event as sensor type:


$event.process.signingInfo.appid == "com.apple.osascript" AND
$event.type  == 1 AND
$event.process.responsible.signingInfo.teamid != "483DWKW443" AND
($event.process.commandLine CONTAINS "the clipboard" OR $event.process.commandLine CONTAINS "Keychain" OR $event.process.commandLine CONTAINS "password" OR $event.process.commandLine CONTAINS "credentials")


In the following video, we will demonstrate a Swift macOS application that invokes AppleScript to display a notification, which is then used to capture the user's password.

And once such behavior has been detected an Alert will be generated in Jamf Protect containing relevant data about the activity.

Jamf Protect Alert

If we aim to construct these detections or queries within a SIEM (Security Information and Event Management) system using telemetry data, the approach would involve crafting a KQL (Kusto Query Language) query. Here's example to illustrate how this might look:

JamfProtect
| where EventVendor == "Jamf" and 
  EventType == "ProcessCreated" and 
  TargetProcessName == "/usr/bin/osascript" and 
  ParentProcessName != "/usr/local/bin/jamf"

Returned results of the query in Microsoft Sentinel

One more example

As highlighted previously, one notable example involves the use of binaries such as system_profiler, sysctl, or ioreg to gather hardware or software information. This could include collecting device identifiers like serial numbers, unique UUIDs, or determining whether the endpoint is a physical device or a virtual machine.

While legitimate applications often execute these binaries to access specific data not readily available when programming in Swift, adversaries might also exploit these tools to extract particular information for malicious purposes.

For instance, an adversary might use the obtained data in the following ways:

  • Serial Number or UUID: These unique identifiers can be used to log a device's details onto a Command and Control (C2) server, or to associate a targeted victim with their specific endpoint.

  • Physical Device or Virtual Machine: Determining whether the endpoint is a physical or virtual machine can help an adversary avoid detection. By identifying virtual machines, they can prevent the malware from executing, thus bypassing some security measures designed to catch malware in controlled environments.

This nuanced approach by adversaries underscores the importance of closely monitoring the use of system binaries that can reveal critical information about endpoints.

Imagine we're keen on tracking usage of the system_profiler command, particularly when it's used with the SPHardwareDataType argument. 

Executing this command reveals detailed information about the device's hardware, such as:

Hardware:
    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: Mac15,6
      Model Number: Z1AU0021AN/A
      Chip: Apple M3 Pro
      Total Number of Cores: 11 (5 performance and 6 efficiency)
      Memory: 18 GB
      System Firmware Version: 10151.101.3
      OS Loader Version: 10151.101.3
      Serial Number (system): KABQDFP4XC0
      Hardware UUID: 6ECB95EE-767C-4282-BA9D-477F44247015
      Provisioning UDID: 00006030-001E301C0115001C
      Activation Lock Status: Disabled

As previously noted, it's common for legitimate software to utilise the system_profiler command to access specific information about the system. This is an important factor to consider in building an detection to ensure we can distinguish between normal, expected use and potential malicious activity.

Detecting the execution of system_profiler with specific arguments by software not signed by Apple or with a valid Developer signing certificate can be accomplished through the implementation of a custom analytic, as outlined below:

$event.process.signingInfo.appid == "com.apple.system_profiler" AND
$event.type  == 1 AND NOT
$event.process.responsible.signingInfo.signerType IN {0, 1, 2} AND
(ANY $event.process.args == "SPHardwareDataType")

Breaking down the provided analytic condition, we're applying a series of filters to hone in on specific events that might indicate unauthorized use of system_profiler with potentially malicious intent:

  1. Application ID: The first condition checks for events where the appid matches com.apple.system_profiler. This ensures we're only focusing on activities directly related to the system_profiler application.

  2. Event Type: We then narrow down the events to those categorised as process creation events ($event.type == 1). This step is crucial for capturing instances where system_profiler is being executed.

  3. Signature Verification: The third condition excludes responsible processes that are signed by Apple, distributed through the App Store, or signed by a recognised developer (AND NOT $event.process.responsible.signingInfo.signerType IN {0, 1, 2}). This helps to filter out legitimate software, focusing on processes that might be unsigned or improperly signed—potentially indicative of malicious software.

  4. Argument Specification: Finally, we specify that the process arguments must include SPHardwareDataType. This requirement ensures that the detection is fine-tuned to catch instances of system_profiler being used to gather specific hardware information, which could be sensitive in nature.

What’s next?

Going forward, the plan involves assembling a detailed inventory of trusted corporate tools. Optionally, employing Jamf Pro for its Software Inventory collection, alongside Jamf Protect's Telemetry feature to monitor all process executions, provides a solid foundation for beginning the development of behavioral baselines.

This will be accomplished by leveraging the examples previously discussed, in addition to exploring further examples available in our open-source repository.


Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.