January 2025 (1)

Zscaler's Nanolog Streaming Service (NSS) is a family of products that enable Zscaler cloud communication with third-party security solution devices for exchanging event logs.

Zscaler Cloud NSS allows you to instantly stream logs from Zscaler Internet Access (ZIA) directly into a compatible cloud-based security information and event management (SIEM) system without the need to deploy an NSS virtual machine (VM) for Web or Firewall.

The new integration includes:

• Ingestion of the data to the data lake

• Mapping to Hunters’ Web Requests schema

• Mapping the data to IOC Search

Learn more here

Detector ID: edr_anomalous_ssm_startsession_command_execution

AWS SSM (Systems Manager) is a service that enables you to manage, automate, and gain operational insights into AWS resources. Notably, SSM also provides the ability to run shell commands on EC2 instances. While this ability could be used in a legitimate manner by system administrators, a threat actor could leverage this to execute malicious commands.

There are several ways to execute code on instances using SSM, this detector focuses on the “StartSession” API which allows you to get a pseudo-terminal on the instance.

By monitoring and analyzing anomalies in the commands run using this API we can detect potentially malicious actions.

The detector is implemented using the "detect-changes" template to detect commands that are not usually run using this API.

Detector ID: aws_console_login_by_federated_user

The AWS Security Token Service (STS) GetFederationToken API provides temporary credentials for a federated user session. Temporary credentials issued by GetFederationToken are independent of the base IAM user's long-term credentials. Disabling or deleting the base user's access keys does not revoke the federated session, allowing attackers to maintain access even after the base IAM user that they have exploited is disabled.

Federated users can access the AWS management console via a dedicated federation endpoint, even if the base IAM user does not have a password, typically required for console access. Furthermore, No MFA is required for this process, even if the base IAM user is configured with MFA

The detector will alert when detecting all console logins done by federated users, and as these instances are rare, this detector has a high confidence score.

Detector ID: edr_manual_credentials_gathering_using_aws_imds

The AWS Instance Metadata Service (IMDS) is an endpoint (accessible at http://169.254.169.254/) that provides information about an instance, including temporary security credentials, instance details, and network configurations.

While IMDS is designed for legitimate applications to securely access instance metadata, attackers often exploit it to harvest credentials associated with the instance's IAM role. These credentials can then be used to access AWS resources, potentially leading to privilege escalation and lateral movement.

This detector detects manual attempts to gather credentials through the IMDS by searching for a command line containing the IMDS endpoint address (http://169.254.169.254/), while eliminating automatic metadata queries (typically performed by legitimate applications).

Detector ID: gsuite_phishing_by_container_bound_script

Google Workspace users can share access to Drive objects such as documents, sheets, and forms via email delivery or a shared link. Shared link URIs have parameters like view or edit to indicate the recipient’s permissions. The copy parameter allows the recipient to copy the object to their own Drive, which grants the object with the same privileges as the recipient. Specific objects in Google Drive allow container-bound scripts that run on Google’s Apps Script platform. Container-bound scripts can contain malicious code that executes with the recipient’s privileges if in their Drive. Adversaries may leverage container-bound scripts to gain initial access to the user’s organization or account.

The detector is looking for a File Copy from Google Drive followed by OAuth permission granting, which might indicate a potential attack.

Detector ID: aws_access_key_compromised_policy_attatched

When an AWS secret, such as an access key, is exposed on a public platform like GitHub, Amazon promptly identifies the compromised key and enforces the AWSCompromisedKeyQuarantine policy on the associated IAM user. This policy significantly restricts the user’s privileges, initiates an analysis of logs to assess the extent of the exposure and mitigate potential damage, and notifies the account owner of the incident.

Although the AWSCompromisedKeyQuarantine policy greatly limits the attacker's capabilities, there remain certain API calls that the attacker can still access. These accessible calls may facilitate lateral movement within the environment, potentially compromising additional resources or escalating their access. Therefore, it is imperative that the AWS account owner is promptly informed of the policy's activation and takes immediate steps to verify that no damage has occurred.

This detector will issue an alert whenever the policy is applied to ensure the account owner is aware of the event and remains vigilant in monitoring API calls and other AWS services that are not covered by the policy.

Detector ID: network_traffic_internal_port_scanner

This detector has been improved to detect all firewall traffic sources, regardless of case sensitivity. This way all leads are generated and covered by the system.

To minimize noise from certain high-volume third-party alerts, we will implement the following changes:

• Wazuh Alerts: Suppress the rule: Agent event queue is full. Events may be lost. This alert is generated every minute when the queue is full and will no longer generate leads.

• Checkpoint Smart Defense Alerts: Filter out Informational severity alerts

• ADAudit Plus Alerts: Filter out the events File (or) Folder deleted, and Logon Failure. These events are considered raw data rather than actionable leads.

While they will no longer generate leads or propagate through the pipeline, they will still be stored in the data lake for reference and investigation purposes.

These changes aim to improve pipeline efficiency and reduce unnecessary alert noise.

This scoring layer increases ( DOUBLE_INC ) the confidence and severity of leads where a successful login has been found and there was a spray attempt with a number of users above a configurable threshold. This layer verifies that only high-probability password spray attacks will enter the SOC Queue.

Relevant detectors:

🔎edr_logon_events_password_spraying

🔎login_logs_password_spraying

This custom rule increases the confidence of brute force leads where the number of failed attempts crosses the threshold of 150. The custom rule, along with the relevant successful brute force scoring layers that already exist, will work together to insert only high-probability brute force attacks into the queue, and update the severity of the attacks' success.

Relevant detectors:

🔎login_logs_brute_force_attempt

🔎windows_event_password_brute_force_attempt_ts

🔎edr_excessive_remote_logon_attempts_from_new_ip