* adding new rule 'Threat Intelligence Signal - Microsoft Defender for Office 365'
* added mitre mapping
* Update rules/integrations/o365/initial_access_defender_for_m365_threat_intelligence_signal.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* added note for max signals
* linted
* fixed unit test failure
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* tuning rule 'Multi-Factor Authentication Disabled for User'
* adjusted query logic
* fixed query logic for optimization that passes unit tests; changed severity and risk back to medium
Rule is executing as expected, however it is alerting on failed requests. Low alert telemetry.
This tuning:
- removed markdown and edited description to be more specific
- reduced execution window for 1 min lookback
- name change to add `AWS` consistent with all other rules
- added references that reflect in the wild threats and persistence usage
- increased risk_score and severity to medium accounting for usage as persistence mechanism in the wild
- added Persistence tag and Mitre tactic, technique, subtechnique
- added `event.outcome: success` criteria to query
- edited investigation guide to be more accurate reflection of steps required for investigating alert, including appropriate response action
- added highlighted fields
** Note: only IAMUser and Root user identities can call this actions so we can use `aws.cloudtrail.user_identity.arn` as the new terms field without worrying about Role vs Role + Session issue seen with other new_terms rules
* [Tuning] First Time AWS Cloudformation Stack Creation by User
- corrected a creation_date error
- Removed `CreateStackSet` API call as this only creates a blueprint for creating stack instances across multiple AWS accounts and regions but does not actually create the resources
- Added `CreateStackInstances` API call which is used to create resources defined in the StackSet
- removed user from rule name as this also triggers for roles
- edited description and investigation guide
- added Mitre technique
* adding highlighted fields
This rule is evaluating the "new terms" against every individual role session, rather than against the Role itself. This is causing a massive volume of alerts
- updated rule description and investigation guide
- reduced execution window and interval
- replaced new terms from `user.id` to combination of `cloud.account.id` and `user.name` to account for evaluation against Roles and in the event that separate AWS accounts under the same Org reuse IAM user names. This will only evaluate the Role instead of each individual role session, which should greatly improve performance.
* [Rule Tuning] AWS STS GetCallerIdentity API Called for the First Time
Rule is executing as expected with no troubling alerts in telemetry. For tuning I've:
- reduced the execution window
- removed MD from description and FP as it's not supported in Kibana UI
- edited some of the language of IG to speak about the exclusion of AssumedRoles
- edited the highlighted fields for consistency across AWS rules
* updated broken link
updated broken reference link
* [Rule Tuning] AWS STS AssumeRole with New MFA Device
This rule is triggering as expected and low volume of alerts in telemetry. This tuning:
- slight edits to IG
- removed user.id wildcard usage in query as this field always exists for these events
- added the from and interval fields for consistency across rules (they are currently using the same values by default so no real change here)
* adding investigation fields
adding investigation fields
* [Tuning] SDH - Investigating MFA Deactivation with no Re-Activation for Okta User Account
This tuning addresses SDH ticket by:
- replacing sequence by `okta.actor.id` with `okta.target.id` in query. This will ensure the deactivation and activation attempts are measured against the target entity. To account for instances where separate users (okta.actor.id) perform deactivation and activation actions against the same target account (okta.target.id)
- Adjusts the investigation guide to use correct target vs. actor fields
* add actor and target id fields to investigation guide
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* adjusted Potential Widespread Malware Infection Across Multiple Hosts
* adjusted Microsoft Azure or Mail Sign-in from a Suspicious Source
* adjusted AWS EC2 Multi-Region DescribeInstances API Calls
* adjusted AWS Discovery API Calls via CLI from a Single Resource
* adjusted AWS Service Quotas Multi-Region Requests
* adjusted AWS EC2 EBS Snapshot Shared or Made Public
* adjusted AWS S3 Bucket Enumeration or Brute Force
* adjusted AWS EC2 EBS Snapshot Access Removed
* adjusted Potential AWS S3 Bucket Ransomware Note Uploaded
* adjusted AWS S3 Object Encryption Using External KMS Key
* adjusted AWS S3 Static Site JavaScript File Uploaded
* adjusted AWS Access Token Used from Multiple Addresses
* adjusted AWS Signin Single Factor Console Login with Federated User
* adjusted AWS IAM AdministratorAccess Policy Attached to Group
* adjusted AWS IAM AdministratorAccess Policy Attached to Role
* adjusted AWS IAM AdministratorAccess Policy Attached to User
* adjusted AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session
* adjusted AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session
* adjusted AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
* adjusted Unusual High Confidence Content Filter Blocks Detected
* adjusted Potential Abuse of Resources by High Token Count and Large Response Sizes
* AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User
* Unusual High Denied Sensitive Information Policy Blocks Detected
* adjusted Unusual High Denied Topic Blocks Detected
* adjusted AWS Bedrock Detected Multiple Validation Exception Errors by a Single User
* adjusted Unusual High Word Policy Blocks Detected
* adjusted Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties
* adjusted Azure Entra MFA TOTP Brute Force Attempts
* adjusted Microsoft Entra ID Sign-In Brute Force Activity
* adjusted Microsoft Entra ID Exccessive Account Lockouts Detected
* adjusted Microsoft 365 Brute Force via Entra ID Sign-Ins
* deprecated Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
* adjusted Microsoft Entra ID Session Reuse with Suspicious Graph Access
* adjusted Suspicious Microsoft OAuth Flow via Auth Broker to DRS
* adjusted Potential Denial of Azure OpenAI ML Service
* adjusted Azure OpenAI Insecure Output Handling
* adjusted Potential Azure OpenAI Model Theft
* adjusted M365 OneDrive Excessive File Downloads with OAuth Token
* adjusted Multiple Microsoft 365 User Account Lockouts in Short Time Window
* adjusted Potential Microsoft 365 User Account Brute Force
* adjusted Suspicious Microsoft 365 UserLoggedIn via OAuth Code
* adjusted Multiple Device Token Hashes for Single Okta Session
* adjusted Multiple Okta User Authentication Events with Client Address
* adjusted Multiple Okta User Authentication Events with Same Device Token Hash
* adjusted High Number of Okta Device Token Cookies Generated for Authentication
* adjusted Okta User Sessions Started from Different Geolocations
* adjusted High Number of Egress Network Connections from Unusual Executable
* adjusted Unusual Base64 Encoding/Decoding Activity
* adjusted Potential Port Scanning Activity from Compromised Host
* adjusted Potential Subnet Scanning Activity from Compromised Host
* adjusted Unusual File Transfer Utility Launched
* adjusted Potential Malware-Driven SSH Brute Force Attempt
* adjusted Unusual Process Spawned from Web Server Parent
* adjusted Unusual Command Execution from Web Server Parent
* adjusted Rare Connection to WebDAV Target
* adjusted Potential PowerShell Obfuscation via Invalid Escape Sequences
* adjusted Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
* adjusted Unusual File Creation by Web Server
* adjusted Potential PowerShell Obfuscation via High Special Character Proportion
* adjusted Potential Malicious PowerShell Based on Alert Correlation
* adjusted Potential PowerShell Obfuscation via Character Array Reconstruction
* adjusted Potential PowerShell Obfuscation via String Reordering
* adjusted Potential PowerShell Obfuscation via String Concatenation
* adjusted Potential PowerShell Obfuscation via Reverse Keywords
* adjusted PowerShell Obfuscation via Negative Index String Reversal
* adjusted Dynamic IEX Reconstruction via Method String Access
* adjusted Potential Dynamic IEX Reconstruction via Environment Variables
* adjusted Potential PowerShell Obfuscation via High Numeric Character Proportion
* adjusted Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation
* adjusted Rare Connection to WebDAV Target
* adjusted Potential PowerShell Obfuscation via Invalid Escape Sequences
* adjusted Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
* adjusted Potential PowerShell Obfuscation via Character Array Reconstruction
* adjusted Potential PowerShell Obfuscation via High Special Character Proportion
* adjusted Potential PowerShell Obfuscation via Special Character Overuse
* adjusted Potential PowerShell Obfuscation via String Reordering
* adjusted Suspicious Microsoft 365 UserLoggedIn via OAuth Code
* adjusted fields that were inconsistent
* adjusted additional fields
* adjusted esql to Esql
* adjusted several rules for common field names
* updating rules
* updated dates
* updated dates
* updated ESQL fields
* lowercase all functions and logical operators
* adjusted dates for unit tests
* Update Esql_priv to Esql_temp as these don't hold PII
* PowerShell adjustments
* Make query comments consistent
* update comment
* reverted 2856446a-34e6-435b-9fb5-f8f040bfa7ed
* Update rules/windows/discovery_command_system_account.toml
* removed dot notation
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
Samirbous