Product updates
Lead attributes in API
The /GET leads API endpoint will now return lead attributes, depending on the value of the include_attributes parameter. If set to true, the response will include the lead attributes as in the example below:
{
"ip": { "value": "..." },
"os": { "value": "Mac OS X (iPad)" },
"browser": { "value": "SAFARI" },
"user_agent": {
"value": "..."
},
"device_type": { "value": "Tablet" },
"outcome_reason": { "value": "LOCKED_OUT" },
"outcome_result": {"value": "FAILURE" },
"display_message": {
"value": "Max sign in attempts exceeded"
},
"okta_display_name": { "value": "..." },
"action_request_uri": {
"value": "/api/v1/authn"
},
"actor_alternate_id": {
"value": "..."
},
"device_fingerprint": {
"value": "..."
},
"action_request_uri_full": {
"value": "/api/v1/authn?"
}
}
Learn more here
Data source health status in API
This feature is currently in Beta stage.
The /GET data source status and health API endpoint response was updated with the following items:
- The
error_detailsparameter will be deprecated and replaced by the newmessageparameter. This is to allow all statuses to be returned with a message, not just error statuses. - A new parameter,
inner_status, was added. If the data source status is Error, this field will show the type of error that occurred. Possible values: 'Internal error', 'Configuration issue'.
Contact your account manager to learn more about this new capability.
Improvement in data retrieval time
As part of our ongoing infrastructural efforts, we’ve improved our Office365 Puller, focusing on its error-handling mechanism.
We recently noticed some delays in data retrieval. To remedy the situation, we’ve transformed this puller into an asynchronous one, enabling us to retrieve data faster and more efficiently.
Integrations
Auth0
A new data type from Auth0 is now supported by Hunters - Auth0 Log Events. You can connect this data type independently to Hunters from the platform.
The integration includes:
- API Collection
- Ingestion into the datalake (SOLUTIONS_STAGING_DB.RAW.AUTH_ZERO_LOG_EVENTS)
- Mapping to Login Unified Schema
Learn more here
Atlassian
Hunters’ Atlassian integration now includes BitBucket Audit Logs. Bitbucket is a Git-based source code repository hosting service owned by Atlassian. The auditing component of Bitbucket Data Center and Server will log many different events that occur when being used.
The new integration includes:
- A transformer for BitBucket Audit Logs
- Mapping of the events to IOC Search
Learn more here
Lacework
An enhancement to the Lacework integrations offering - Lacework Agent Alerts. These are third-party alerts by Lacework over the Lacework Agent data source. So far this data source was used for ingestion only, but now these events will generate a third-party alert in the system.
Learn more here
Linux
Hunters now supports the ingestion of Linux SSHD logs. sshd, the Secure Shell Daemon, allows remote access to the system. It’s a silent process that listens to all the authentication and login attempts of Linux. Using sshd logs, you can monitor authorized and unauthorized login attempts on your system, which helps in keeping your system secure. The logs should be located under the /var/log/auth.log location.
The new integration includes:
- A transformer for the Linux SSHD logs
- Mapping of the source to Login Unified Schema
- Mapping of the source to IOC Search
Learn more here
Crowdstrike
We are growing our Crowdstrike integrations offering with an addition of Crowdstrike Indicators.
Falcon Intelligence provides threat intelligence information gathered by CrowdStrike to help understand the threat landscape. The Indicators data type shows active indicators in the environments that are related to malware activity (IOCs such as URL, Hashs, domain).
The integration includes:
- API Collection
- Self service ingestion
- Ingestion into the data lake
- Mapping to Threat Intel IOCs Unified Schema
- Mapping to IOC Search
- Connection to threat_intel_ioc_lookup DrillDown
Learn more here
Detection
New detectors
🔎 Login to a user tagged as terminated
Detector ID: login_logs_terminated_user_login
The detector looks for login events made by users tagged (via Asset Tagging) as employees who have been terminated. If a user is tagged as terminated prior to the login event, a lead will be created for the login event.
For this detector to function as planned, use the Hunters Asset Tagging capability and tag past employees with the terminated_user tag.
🔎 Usage of EC2 instance credentials outside of AWS
Detector ID: cloudtrail_ec2_instance_credentials_used_from_outside_aws
This detector is part of our noise reduction efforts, replacing the existing Instance Profile Security Credentials Used by the Multiple IP Addresses detector (see deprecation message below).
The detector covers a very interesting attack surface - Instance credentials which are given to EC2 instances to perform API calls. This detector detects the usage of EC2 instance credentials outside of AWS. EC2 credentials should be used directly within AWS by EC2 instances. Malicious actors can gain access to these credentials using various methods. Once they are used from an ASN that does not belong to AWS it might indicate the credentials were compromised.
It is recommended to check whether the ASN belongs to the organization and if not, investigate the activity performed using the instance credentials.
🔎 Suspicious App Impersonation in O365 Exchange
Detector ID: o365_suspicious_app_impersonation
As part of our growing Office365 content pack, this new detector looks for application impersonation in O365 exchange.
Malicious actors who gain access to the Exchange Administrator (or any user with the Organization Management or Company Administrator role) might assign an “Application Impersonation” role in order to remain persistent in Office 365 exchange online. This role enables the user given the role assignment the ability to impersonate other mailboxes users. Moreover, by default, the user granted the role assignment is able to impersonate and gain access to all mailboxes.
🔎 Over Permissive Access Was Granted On Microsoft 365's Mailbox Folder
Detector ID: office365_over_permissive_access_granted_to_mailbox_folder
Another addition to our Office365 content pack is this new detector, designed to detect possible threat actors gaining access to a mailbox or to admin permissions which they can then leverage to set folder permission on the compromised mailbox, and hence maintain access even with a non-privileged user.
This technique is mainly common in financial frauds or exfiltration attempts, as a result of a business email compromise scenario.
The detector looks at Set-MailboxFolderPermission or Add-MailboxFolderPermission operations, where the Anonymous or Default users have been assigned permissions other than None. Default users can be internal, authenticated users, i.e., every Office365 user within the organization, while Anonymous user refers to external, unauthenticated users, i.e., every Office365 user, including users out of the organization.
There are cases where the requested access rights are limited only to certain details related to the calendar. The detector filters out such cases since they are common in an enterprise environment
Modified detectors
🔎 New Device Using RDP Connection
Detector ID: edr_new_device_with_rdp_connection
The detector is based on the fact that normally, in a network, there are machines that should initiate RDP connections on a regular basis (jump boxes, system admins, support, etc.) and there are machines that shouldn’t (Finance, Marketing, Executives, etc.). Hence, the detector should trigger on machines that have never initiated RDP and then suddenly start using it.
As part of the effort to decrease the noise level we made some modifications to this detector. As a result, we now see a decrease of ~75% of the previously detected noise.
Due to these improvements, we’ve decided to increase the confidence of this detector from 2 to 3, and by that, the base risk is 2 (instead of 1).
🔎 Possible exfiltration of secrets from AWS Secrets Manager
Detector ID: cloudtrail_secrets_exfil
The detector counts GetSecret API calls performed by users in order to detect multiple events performed by the same user, in a given time frame, that could be used in order to exfiltrate AWS secrets from the Secret Manager.
Previously, this detector did not yield many leads since it was looking for specific occasions that contained ListSecret events. We’ve converted this detector into a time-series template to increase the coverage and now the detector is only looking for GetSecret events and creates the baseline for Distinct secrets.
Deprecated detectors
🔎 Instance Profile Security Credentials Used by Multiple IP Addresses
Detector ID: instance_profile_used_by_multiple_ips
The detector aims to find malicious usage of EC2 instance credentials, however, due to its implementation it created a lot of false positives. As a result of our noise reduction efforts, we have decided to deprecate it and replace it with a new detector: Usage of EC2 instance credentials outside of AWS (see above).