Product updates
Increased API security
As part of our ongoing commitment to fortify the security of our platform, we are introducing stronger security protocols, which include decreasing the maximum allowable limit for the get-stories and get-leads API calls. Starting from April 7th, 2024, this limit will be reduced to 10,000, from the current 100,000.
This change will be reflected in the limit query parameter which is part of the get-stories and get-leads API calls. After implementing this change, any attempts to set a limit higher than 10,000 will result in a 400 error code from the API, accompanied by the message: "Limit must be less than or equal to 10000."
Please make sure your API calls are updated accordingly to avoid inconveniences.
MITRE ATT&CK framework update
We’ve recently completed the update of the MITRE ATT&CK framework on the Hunters platform to version 14.
This update reflects significant advancements in the framework, introducing new structures, features, and techniques to stay abreast of the rapidly evolving landscape of cyber threats. Our commitment to maintaining relevance and maximizing our impact for our customers necessitates staying updated with the latest developments in the MITRE framework.
Learn more about Threat Coverage here.
Asset tag filtering in the SOC Queue
We’re excited to announce that you can now filter the SOC Queue by asset tag. This enhancement allows security analysts to maintain better monitoring of crown jewels and effectively track suspicious assets involved in attacks.
You can use this feature to achieve the following:
- Spot Risks Quickly: Identify risks associated with tagged assets swiftly.
- Prioritize Alerts: Act promptly on alerts related to tagged assets.
Learn more about Asset Tags here.
Integrations
NetIQ
NetIQ eDirectory is a directory service software that facilitates the centralized management of resources and user identities across different network environments. Audit logs in NetIQ eDirectory capture detailed information about events and operations performed within the directory service.
The new integration includes:
- Ingestion of the data to the data lake
- Mapping the data to Hunters’ Login Schema
- Mapping the data to IOC Search
Learn more here
Alibaba Cloud
Alibaba Cloud logs furnish essential transparency into the operations and resources within an organization's Alibaba Cloud ecosystem. As cloud environments diverge significantly from traditional on-premises environments, many conventional security defenses and auditing and logging mechanisms are not directly transferable to the cloud context, emphasizing the importance of Alibaba Cloud's comprehensive logging solutions in safeguarding an organization's cloud infrastructure.
The integration includes the following:
- Alibaba RDS logs
- Alibaba Actiontrail
- Alibaba WAF
- Alibaba SLB
- Alibaba security center alerts
- Alibaba Kubernetes audit logs
- Alibaba Kubernetes cloud controller manager
- Alibaba Kubernetes API server logs
- Alibaba Kubernetes controller manager
Learn more here
Vectra Stream
An addition to the Vectra offering, Vectra Stream logs are data outputs from the Vectra cybersecurity platform, specializing in network detection and response (NDR). These logs provide detailed information on detected network behaviors and threats, helping organizations to identify and respond to cyber threats in real-time.
As Vectra Stream includes all data types provided by Zeek, this data type will essentially replace the Zeek integration.
The new integration includes:
- Ingestion of the data to the data lake
- Mapping the data to Hunters’ Login Schema
- Mapping the data to IOC Search
Learn more here
Nozomi Networks
Nozomi Networks Alerts are notifications generated by their cybersecurity solutions, specifically designed to inform users about potential security incidents, vulnerabilities, or other relevant events within their operational technology (OT), Internet of Things (IoT), and industrial control system (ICS) environments. These alerts are a critical component of Nozomi Networks' approach to ensuring the cybersecurity and operational integrity of critical infrastructure and industrial operations.
The new integration includes:
- Ingestion of the data to the data lake
- Mapping the data to IOC Search
Learn more here
Detection
New Detectors
🔎 User Created and Deleted in a Short Period
Detector ID: windows_event_user_created_and_deleted
When users are created in a Windows environment, they usually exist for the long run. When a user is created and then deleted in a short period, it may hint at an abnormal or even malicious activity (such as a threat actor trying to test his newly acquired privileges, or making his actions harder to investigate).
To detect this, this new detector looks at a User Created event followed by a User Deleted event that occurred within 8 hours of each other (or any other desired timespan). The lead score will be increased if the timespan is less than an hour, and if the user has been added to any interesting administrative groups.
Recommended investigation steps:
- Who is the user who initiated the deletion? What are his privileges? Is managing users normal for him?
- Who is the deleted user? What was his creation’s purpose? What are his privileges?
- What did the user do in his existence timeframe? What stations did he log into? What resources did he access?
With the growing adoption of container orchestration solutions such as Kubernetes for application management and deployment, the importance of solid security measures is more critical than ever. We took it upon ourselves to explore the complex realm of Kubernetes security, beginning with the essential Kubernetes API Audit Log and its pivotal function in spotting and neutralizing potential security threats. We will also cover tactics for developing strategies to detect and counteract key threat tactics like Initial Access, Privilege Escalation, Defense Evasion, and Discovery.
🔎 Kubernetes Secret Enumeration
Detector ID: k8s_secret_enumeration
As part of our growing Kubernetes detection pack, this new time-series detector is looking for an abnormal amount of unique secret requests by a user or service account.
Upon initial foothold on a Kubernetes container or compromised operator machine, attackers frequently attempt to identify and list all secrets stored within a cluster’s secret store. These secrets can encompass a wide range of sensitive information, such as API tokens, passwords, or other confidential data. Access to such secrets can potentially enable lateral movement or privilege escalation and unauthorized access to critical resources.
Recommended investigation steps:
- Check the recent activity, source pod, and user agent of the initiating users to determine if this behavior is automatic or a “hands on keyboard” event.
🔎 Creation of a reverse Shell to a Kubernetes Pod
Detector ID: k8s_creation_reverse_shell
Another detector from the Kubernetes detection pack, this new detector is looking for the creation of a reverse shell to a Kubernetes Pod. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount to gain access to the node. There are many ways a container with unrestricted access to the host file system can escalate privileges, including reading data from other containers and accessing tokens of more privileged pods.
Recommended investigation steps:
- Check the activity of this Kubernetes user in the cluster: check for multiple IPs related to it from unrelated geographic places, and check if this user has multiple user agents associated with it.
- Check the reputation and activity of the initiating IP address using: PulseDive, IPInfo, AbuseIPdb, etc.
🔎 Execution in kube-system namespace
Detector ID: k8s_execution_in_kube_system
The detector is looking for the execution of commands on pods in the kube-system namespace. This is a namespace that contains critical resources of Kubernetes and can be leveraged by threat actors to disrupt or extract information. The kube-system namespace is a default namespace, which is primarily used for system-level components such as kube-dns and kube-proxy. It is very uncommon to execute commands inside pods or containers under the kube-system namespace and may indicate suspicious activity.
Recommended investigation steps:
- Investigate the attacked container and its function
- Investigate the command and find out what was the purpose of it, or the impact it had
- Investigate the initiating user and view his past actions to identify compromise
🔎Creation of a Pod with a Sensitive hostPath Volume
Detector ID: k8s_creation_sensitive_hostpath_pod
Detects creation of a pod with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount to gain access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.
Recommended investigation steps:
- Check the activity of this Kubernetes user in the cluster: check for multiple IPs related to it from unrelated geographic places, and check if this user has multiple user agents associated with it.
- Check the reputation and activity of the initiating IP address using: PulseDive, IPInfo, AbuseIPdb, etc.
New enrichments
We have recently added new enrichments to the system that will provide you with more context on leads and alerts from the VMware Carbon Black Alerts data type:
-
cb_platform_lead_events - This enrichment fetches events directly related to the lead by the alert_id provided by Carbon Black. This provides additional context to the alert like process command line, PID, event description, and more.
-
cb_platform_threat_activity - This enrichment queries the Carbon Black events database for events related to the threat cause hash and adds an Is Threat Blocked attribute if it appears in the logs that the process has been blocked by Carbon Black, which can be useful for custom scoring
-
cb_alert_info entity - This entity contains both enrichments mentioned above, the threat hash and alert ID, and the Is Threat Blocked attribute.
