diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc new file mode 100644 index 0000000000..ac7ff5d646 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-30-azure-aks-service-account-token-created-via-tokenrequest-api]] +=== Azure AKS Service Account Token Created via TokenRequest API + +Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Service Account Token Created via TokenRequest API* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. The TokenRequest API +(`serviceaccounts/token`) mints a bound service account token. The kubelet (`system:node:*`) and the +kube-controller-manager (`aksService`) mint these tokens continuously for normal pod operation and are excluded; the +signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act +as that workload identity, reaching resources the compromised principal cannot. + + +*Possible investigation steps* + + +- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should mint tokens. A workload service account + (`system:serviceaccount::`) minting a token, or `masterclient` (the local cluster-admin cert), is the + higher-concern case. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive/expected tooling (`kubectl create + token`) from custom clients (for example `curl`), which is a stronger indicator of scripted abuse. +- Identify the target service account in `azure.platformlogs.properties.log.objectRef.name` / + `azure.platformlogs.properties.log.objectRef.namespace` and what RBAC that account holds; minting a token for a + higher-privileged service account is privilege escalation. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on API calls made with + the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity. + + +*False positive analysis* + + +- Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the + kube-controller-manager as `aksService`, which is excluded). Additional automation such as GitOps operators or CI + running `kubectl create token` may surface; baseline those identities and exclude the specific validated account + rather than re-broadening to all `system:*`, which would blind the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, revoke the minted token and the requesting identity's credentials, and review the RBAC that permitted + token creation. +- Audit actions performed with the target service account's identity after the request. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). TokenRequest is a +mutating create recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per request. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"serviceaccounts" and + azure.platformlogs.properties.log.objectRef.subresource:"token" and + azure.platformlogs.properties.log.verb:"create" and + azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-first-time-seen-rmm-signer-across-the-environment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-first-time-seen-rmm-signer-across-the-environment.asciidoc new file mode 100644 index 0000000000..96d392ed86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-first-time-seen-rmm-signer-across-the-environment.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-30-first-time-seen-rmm-signer-across-the-environment]] +=== First Time Seen RMM Signer Across the Environment + +Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen RMM Signer Across the Environment* + + +Attackers abuse legitimate RMM and remote-access software to open interactive sessions, persist, and stage follow-on tooling while blending into IT support activity. This rule alerts on a Windows Elastic Defend process start whose `process.code_signature.subject_name` matches a curated vendor list, when that subject is first seen across the visible fleet in the 10-day new_terms history window. Novelty is keyed only on the signer subject, so each certificate string alerts once environment-wide and renamed binaries that still carry a listed signer still match. Signature trust is not a query condition; review `process.code_signature.trusted` as context only. + + +*Possible investigation steps* + + +- Is the matched binary a remote-access component, or an unrelated product that shares this signer? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.command_line`. + - Review the other binaries this signer started on the alerted host with !{investigate{"description":"Show which binaries sharing the matched code-signature subject started on the alerted host during the investigation window.","label":"Signer footprint on the alerted host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Several vendors on this list also ship backup, virtualization, terminal-emulation, and management software under the same certificate, so a signer's first appearance is often not its remote-access product. A path, original file name, and command line matching the vendor's remote-access agent keeps that hypothesis active. An unrelated product from the same vendor makes this a low-value observation that still consumes the signer's novelty term, so confirm the vendor's remote-access footprint now rather than waiting for a later alert this rule will not produce. +- Does the parent and session context explain why this process launched on this host? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, `user.name`. + - Retrieve the parent process event while the parent entity is still retained with !{investigate{"description":"Find the parent process event for the matched launch when the parent entity is retained.","label":"Parent process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: A parent consistent with a software-deployment service or a scheduled management task keeps this inside a rollout hypothesis. A launch from a browser, archive, mail client, script interpreter, or an unexpected interactive session points instead to social engineering or staged access. +- What did the matched process start after launch? + - Focus: child `process.name`, `process.command_line`, `process.parent.entity_id`. + - Review child process starts on the same host with !{investigate{"description":"Find child process starts spawned by the matched process on the same host.","label":"Child process starts","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: No child process evidence is unresolved, not benign. Children limited to the vendor's own service and updater binaries stay consistent with normal tool operation without proving the deployment was authorized, while child shells, script interpreters, discovery commands, or credential tooling are suspicious. +- Did the same process perform remote-access network activity that changes the host scope? + - Focus: `destination.ip`, `destination.port`, `network.direction`. + - Review endpoint network events for the same process entity with !{investigate{"description":"Search for endpoint network events tied to the matched process entity on the same host.","label":"Same-process network events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Missing network telemetry is unresolved, not benign. Sessions to the vendor's own service endpoints show the tool operating normally but do not establish who initiated the session, while connections to unrelated external infrastructure keep the case open for escalation and wider scoping. +- If local evidence is suspicious or unresolved, is the same signer or executable hash appearing beyond the alerted host? + - Focus: `process.code_signature.subject_name`, `process.hash.sha256`, `process.executable`, `host.name`, `user.name`. + - Review recent process starts sharing the matched signer or executable hash with !{investigate{"description":"Search the 24-hour investigation window for process starts that share the matched signer or executable hash. Widen the Timeline range to look further back.","label":"Recent signer and hash spread","providers":[[{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}; the pivot is bounded to the last 24 hours for performance, so widen the Timeline range when the deployment window or suspected activity is older. + - Implication: Additional hosts or users shift the hypothesis from a single host deployment to an environment-wide remote-access introduction and should expand response scope. This rule reports a signer once for the whole fleet, so it will not alert again for this vendor and will not alert at all on a renamed binary reusing an already-observed signer; a clean 24-hour pivot therefore bounds recent spread only and is not evidence that spread has stopped. + +After these checks, escalate when source process, parent, network, or cross-host evidence is suspicious; close only when alert-local and recovered evidence prove the exact expected host/user/signer/hash scope with verified owner confirmation; preserve and escalate mixed or incomplete cases for more context. + + +*False positive analysis* + + +- This rule can alert on a real but expected first appearance of a listed signer when a software rollout, support session, or vendor agent introduction reaches the Elastic Defend fleet for the first time in the 10-day history window. +- Treat benign disposition as evidence-bounded: the alert's `process.code_signature.subject_name`, `process.executable`, `process.hash.sha256`, `host.id`, `host.name`, `user.id`, and `user.domain` should match a validated change record or verified owner confirmation for the exact system and activity. +- Treat `process.code_signature.trusted` as contextual evidence, not clearance: a trusted signature does not establish authorization or benign intent, and an untrusted, invalid, or missing trust value does not by itself prove malicious use. +- Certificate subjects that differ only in case or punctuation are separate novelty terms, so a single vendor can produce more than one alert as its certificate strings drift across products and releases. Correlate those and treat them as one introduction rather than as repeat findings. +- When justified, scope an exception conjunctively to the exact `process.code_signature.subject_name` plus `process.executable`, further bounded by supported host/user anchors such as `host.id`, `host.name`, `user.id`, or `user.domain`; never exclude on signer alone. `process.hash.sha256` is precise for scoping one investigation but is not a durable exception anchor, because the vendor's next release changes it and the exception silently stops matching. +- Expect an exception to have limited effect here, because the first alert already consumes that signer's novelty term for the history window; an exception only applies if the signer disappears from the visible fleet for more than 10 days and returns. `user.name` appears in the Focus lines for readability during analysis, while exception criteria prefer `user.id` and `user.domain` as stable identifiers rather than display names. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- Scope the activity by signer, executable hash, process entity, host, and user before containment; include child processes, same-process network events when available, and any later hosts that show the same signer or hash. +- If malicious use is confirmed, contain affected hosts through the endpoint response integration when available and contain affected accounts using reversible controls first; if direct endpoint response is unavailable, document the collected evidence and artifacts and hand them off to the responsible endpoint or incident-response team able to act. After evidence collection and scoping, terminate malicious processes, remove persistence, and clean up remote-access tooling. +- Review collected evidence for credential exposure, lateral movement, and follow-on tooling before final remediation decisions. +- Document confirmed indicators and any logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and +event.category: "process" and event.type: "start" and +process.code_signature.subject_name: ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-newly-observed-rc4-kerberos-service-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-newly-observed-rc4-kerberos-service-ticket-request.asciidoc new file mode 100644 index 0000000000..c9d51995d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-newly-observed-rc4-kerberos-service-ticket-request.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-30-newly-observed-rc4-kerberos-service-ticket-request]] +=== Newly Observed RC4 Kerberos Service Ticket Request + +Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos + +*Tags*: + +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Newly Observed RC4 Kerberos Service Ticket Request* + + +This alert flags a successful Windows Kerberos service ticket request that used legacy RC4 encryption for a requester-to-service pairing not seen in the last week. It matters because RC4 tickets are easier for attackers to crack offline, and a new pairing can reveal account targeting rather than normal application behavior. A common pattern is an intruder using a low-privileged domain account to request RC4 tickets for SPN-backed service accounts, then extracting password hashes for Kerberoasting. + + +*Possible investigation steps* + + +- Validate whether the requester, source host, and service account relationship aligns with a known application change, scheduled task, or newly deployed system, because legitimate first-seen pairings often coincide with onboarding or configuration work. +- Review recent authentication activity for the requester across domain controllers for bursts of service ticket requests to multiple SPNs, especially privileged or human-managed service accounts, which is a strong Kerberoasting pattern. +- Pivot on the requesting host and user for adjacent suspicious behavior such as interactive logons from unusual systems, PowerShell or script execution, remote administration activity, credential dumping alerts, or other Active Directory enumeration in the same timeframe. +- Examine the targeted service account’s privilege level, password age, SPN exposure, delegation settings, and whether it still permits RC4, then prioritize escalation if the account is highly privileged, old, or tied to critical services. +- If the activity is not readily explained, contain the requester and source system as appropriate and rotate the service account credentials while planning to disable RC4 support and enforce stronger Kerberos encryption for affected accounts. + + +*False positive analysis* + + +- A newly deployed or reconfigured Windows service, scheduled task, or application host can create a first-seen requester-to-service pairing against a legacy SPN that still uses RC4, so verify recent change activity and confirm the requester, source host, and service account match the expected business function. +- An infrequently run maintenance or batch process may legitimately request an RC4 service ticket after more than seven days of inactivity, so confirm the event time aligns with its normal schedule and review adjacent 4769 activity to ensure the account is only accessing its usual limited set of services. + + +*Response and remediation* + + +- Isolate the requesting host and any other systems used by the compromised account from the network, block remote administration access, and preserve volatile and disk evidence before rebooting or rebuilding them. +- Disable the compromised requester account and the targeted service account, rotate passwords or keys for every exposed SPN-backed service they can access, and force logoff or ticket purge so previously issued Kerberos tickets cannot be reused. +- Remove attacker persistence by reviewing and deleting unauthorized scheduled tasks, services, startup items, WMI event subscriptions, remote access tools, Run key entries, and any newly granted local or domain group memberships tied to the affected identities or hosts. +- Restore affected endpoints and servers to a known-good state by reimaging compromised systems or rolling back unauthorized changes, then verify business applications start cleanly with the newly rotated service credentials. +- Escalate to incident response immediately if the targeted service account is privileged, tied to domain controllers or other Tier 0 systems, or if you also find credential dumping, lateral movement, multiple unusual SPN requests, or forged-ticket activity. +- Harden the environment by disabling RC4 where legacy dependencies permit it, enforcing AES-only Kerberos encryption on service accounts, migrating eligible services to gMSAs, reducing excessive service account privileges and SPNs, and adding detections for unusual service ticket bursts and new requester-to-service relationships. + + +==== Setup + + + +*Setup* + + +Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:authentication and event.code:4769 and + winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and + winlog.event_data.TargetUserName:* and + winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and + not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-potential-computer-account-ntlm-relay-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-potential-computer-account-ntlm-relay-activity.asciidoc new file mode 100644 index 0000000000..ae96a81379 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-potential-computer-account-ntlm-relay-activity.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-30-potential-computer-account-ntlm-relay-activity]] +=== Potential Computer Account NTLM Relay Activity + +Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Computer Account NTLM Relay Activity* + + + +*Possible investigation steps* + + +- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account. +- Examine the source.ip activities as this is the attacker IP address used to relay. +- Review all relevant activities such as services creation, file and process events on the target server within the same period. +- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies. +- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts. +- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + + +*False positive analysis* + + +- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes. +- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames. +- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule. +- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts. +- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. + - If the involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed. +- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable. +- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems. +- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems. +- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response. +- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity. +- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future. + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +authentication where host.os.type == "windows" and event.code in ("4624", "4625") and + winlog.logon.type == "Network" and winlog.event_data.AuthenticationPackageName == "NTLM" and + endswith~(user.name, "$") and user.name != "$" and + source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" and + + /* Filter for a machine account that matches the hostname */ + startswith~(host.name, substring(user.name, 0, -1)) and + + /* Verify the machine account matches the full hostname, not just a prefix substring */ + (startswith~(substring(user.name, 0, -1), host.name) or startswith~(host.name, concat(substring(user.name, 0, -1), "."))) and + + /* Verify if the Source IP belongs to the host */ + not endswith(string(source.ip), string(host.ip)) and + indexOf(string(host.ip), string(source.ip)) == null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc new file mode 100644 index 0000000000..6b4d6a4baf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rule-8-19-30-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-30-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension]] +=== Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension + +This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-22045 +* https://nvd.nist.gov/vuln/detail/CVE-2024-5535 +* https://www.rfc-editor.org/rfc/rfc8737 +* https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Use Case: Vulnerability +* Data Source: Network Traffic +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension* + + +This rule fires when five or more TLS connections from the same source IP to the same destination IP +are recorded where the ClientHello advertises `acme-tls/1` as an ALPN protocol, the handshake never +completes (`tls.established: false`), or where malformed ALPN data produces a relevant TLS alert. +Individually, an incomplete ACME challenge can be a transient network issue. In volume, this pattern is +consistent with attempts to exhaust reverse proxy resources, including CVE-2026-22045, and cause a +denial of service. + +Packetbeat TLS events describe the TLS handshake and do not include connection byte totals or reliable +elapsed duration for an incomplete handshake. Use `network_traffic.flow` events correlated by +`network.community_id` when byte counts or connection duration are required during investigation. + +`acme-tls/1` is legitimately used only by ACME certificate clients performing TLS-ALPN-01 domain +validation. Repeated stalled sessions outside of scheduled certificate renewal windows are anomalous. + + +*Possible investigation steps* + + +- Identify the source IP (`source.ip`) and verify whether it belongs to a known ACME certificate + authority (Let's Encrypt: 66.133.109.0/24, 172.65.32.248/28; ZeroSSL; Buypass) or an authorized + internal ACME renewal agent. Traffic from unexpected sources is the primary indicator of exploitation. +- Pivot to `destination.ip` and `destination.port` to determine which TLS listener is targeted and + whether it is internet-exposed. Traefik, nginx, HAProxy, and similar reverse proxies are the + most likely targets. +- Count total stalled events from the same `source.ip` over the past hour to understand the full + attack volume: + ```esql + FROM logs-network_traffic.tls* + | WHERE tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" + AND tls.established == false + | STATS count = COUNT(*) BY source.ip, destination.ip, destination.port + | SORT count DESC + ``` +- If flow reporting is enabled, correlate `logs-network_traffic.flow-*` events on `network.community_id` + to review `network.bytes`, `source.bytes`, `destination.bytes`, and `event.duration`. +- Check server-side metrics on the destination host around the alert time: goroutine count for Go + services (Traefik, Caddy), worker or thread count for nginx or HAProxy, and TCP accept queue depth. + Saturation aligned with the alert window confirms impact. +- Review whether the targeted service is patched for CVE-2026-22045. Traefik versions before the + fix did not enforce handshake timeouts on acme-tls/1 listeners, allowing indefinite goroutine hold. + + +*False positive analysis* + + +- cert-manager, Certbot, or Caddy ACME clients produce `acme-tls/1` connections during certificate + renewal. These complete quickly under normal conditions; isolated stalled events from recognized + ACME client IPs are likely transient network issues, not attacks. The threshold of five events within + the detection window suppresses most one-off failures. +- Load balancer health checks misconfigured to probe with TLS-ALPN-01 can generate this pattern; + identify the health check source IP and add it to the exception list. + + +*Response and remediation* + + +- If the source IP is not a known ACME CA or authorized renewal agent, block it at the perimeter. +- Upgrade Traefik to a version patched for CVE-2026-22045. Apply equivalent handshake-timeout + configurations on other reverse proxies (`ssl_handshake_timeout` in nginx). +- Enforce a TLS handshake timeout at the listener level to bound how long any stalled connection + can hold a goroutine or worker slot. +- Rate-limit inbound TLS connections per source IP at the network boundary to limit the blast radius + of connection-exhaustion attacks. +- If service degradation is confirmed, restart the affected reverse proxy after applying timeout + mitigations to recover exhausted resources. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Agent `network_traffic` integration with TLS protocol parsing enabled +and `include_detailed_fields: true` (the default). Without this setting, the field +`tls.detailed.client_hello.extensions.application_layer_protocol_negotiation` is not populated and +the rule will not match. + +Verify your `network_traffic` integration configuration includes: + +```yaml +packetbeat.protocols: + - type: tls + ports: [443, 8443, 9443] + include_detailed_fields: true + transaction_timeout: 30s +``` + +Adjust the port list to cover all TLS listeners in your environment that could be targeted, including +reverse proxy listeners and custom TLS service ports. The `include_detailed_fields` key defaults to +`true`; if it was explicitly disabled, re-enable it and restart the agent. + +Packetbeat's default TLS `transaction_timeout` is 10 seconds. Incomplete handshakes that remain idle +beyond this timeout can expire without producing a `network_traffic.tls` event. Configure +`transaction_timeout` to exceed the longest incomplete-handshake interval you intend to observe. The +example above uses 30 seconds; increasing this value retains connection state longer and can increase +memory usage on high-volume sensors. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.tls* +| where source.ip is not null and destination.ip is not null and ( + ( + tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" and + tls.established == false + ) or ( + CONTAINS(TO_LOWER(tls.detailed.client_hello.extensions._unparsed_), "alpn") and + tls.detailed.alert_types in ("decode_error", "illegal_parameter") + ) + ) +| stats + Esql.event_count = COUNT(*), + Esql.destination_port_values = MV_SLICE(MV_DEDUPE(TOP(destination.port, 10, "asc")), 0, 10), + Esql.network_community_id_values = MV_SLICE(MV_DEDUPE(TOP(network.community_id, 10, "asc")), 0, 10), + Esql.alpn_values = MV_SLICE( + MV_DEDUPE(TOP(tls.detailed.client_hello.extensions.application_layer_protocol_negotiation, 10, "asc")), + 0, + 10 + ), + Esql.alert_type_values = MV_SLICE(MV_DEDUPE(TOP(tls.detailed.alert_types, 10, "asc")), 0, 10) + by source.ip, destination.ip +| where Esql.event_count >= 5 +| keep + source.ip, + destination.ip, + Esql.event_count, + Esql.destination_port_values, + Esql.network_community_id_values, + Esql.alpn_values, + Esql.alert_type_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Service Exhaustion Flood +** ID: T1499.002 +** Reference URL: https://attack.mitre.org/techniques/T1499/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-appendix.asciidoc new file mode 100644 index 0000000000..dedce1b592 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-appendix.asciidoc @@ -0,0 +1,11 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-30-prebuilt-rules-8-19-30-appendix"] += Downloadable rule update v8.19.30 + +This section lists all updates associated with version 8.19.30 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-30-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc[] +include::prebuilt-rule-8-19-30-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc[] +include::prebuilt-rule-8-19-30-first-time-seen-rmm-signer-across-the-environment.asciidoc[] +include::prebuilt-rule-8-19-30-newly-observed-rc4-kerberos-service-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-30-potential-computer-account-ntlm-relay-activity.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-summary.asciidoc new file mode 100644 index 0000000000..1f5336eff0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-summary.asciidoc @@ -0,0 +1,22 @@ +[[prebuilt-rule-8-19-30-prebuilt-rules-8-19-30-summary]] +[role="xpack"] +== Update v8.19.30 + +This section lists all updates associated with version 8.19.30 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded. | new | 1 + +|<> | This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity. | new | 2 + +|<> | Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware. | new | 1 + +|<> | Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting. | new | 1 + +|<> | Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. | update | 112 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 0d35052387..e55e39bb4e 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 11 Aug 2026 | 4 | 1 | +This release includes new rules for Windows, Azure, and Network Traffic. New rules for Windows include detection for credential access and command and control. New rules for Azure include detection for credential access. New rules for Network Traffic include detection for impact. Additionally, this release fixes rule Potential Computer Account NTLM Relay Activity, which failed to load due to an unsupported EQL field length comparison. + + |<> | 04 Aug 2026 | 35 | 34 | This release includes new rules for Linux, AWS, GCP, Windows, Azure, Network Traffic, SonicWall, and macOS. New rules for Linux include detection for privilege escalation, persistence, execution, and command and control. New rules for AWS include detection for execution, collection, defense evasion, privilege escalation, and persistence. New rules for GCP include detection for discovery, privilege escalation, and credential access. New rules for Windows include detection for defense evasion and command and control. New rules for Azure include detection for discovery, credential access, defense evasion, and execution. New rules for Network Traffic include detection for impact, collection, initial access, execution, and persistence. New rules for SonicWall include detection for credential access. New rules for macOS include detection for command and control. Additionally, significant tuning for Linux, Windows, macOS, Azure, and Microsoft 365 rules improves efficacy and performance. @@ -158,3 +162,4 @@ include::downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc[l include::downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-28/prebuilt-rules-8-19-28-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-30/prebuilt-rules-8-19-30-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index 45f99b6414..64f47cecdb 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -1264,6 +1264,8 @@ and their rule type is `machine_learning`. |<> |Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111 +|<> |Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |1 + |<> |Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs], [Data Source: Sysmon] |None |118 |<> |Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 @@ -2186,6 +2188,8 @@ and their rule type is `machine_learning`. |<> |This rule alerts on processes exhibiting high CPU usage and that are observed for the first time in the previous 5 days. A previously unseen process consuming sustained CPU resources may indicate suspicious activity such as cryptomining, exploit payload execution, or other forms of resource abuse following host compromise. In some cases, this may also surface legitimate but unexpected software causing performance degradation. |[Use Case: Threat Detection], [Use Case: Observavility], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |2 +|<> |Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting. |[Domain: Identity], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |1 + |<> |Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |4 |<> |This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |4 @@ -2352,7 +2356,7 @@ and their rule type is `machine_learning`. |<> |Identifies instances of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) making unusual network connections. Adversaries could abuse Internet Explorer via COM to avoid suspicious processes making network connections and bypass host-based firewall restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 -|<> |Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111 +|<> |Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |112 |<> |Identifies the execution of a Chromium based browser with the debugging process argument, which may indicate an attempt to steal authentication cookies. An adversary may steal web application or service session cookies and use them to gain access web applications or Internet services as an authenticated user without needing credentials. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs], [Data Source: Sysmon] |None |211 @@ -3026,6 +3030,8 @@ and their rule type is `machine_learning`. |<> |Adversaries may modify SSH related binaries for persistence or credential access by patching sensitive functions to enable unauthorized access or by logging SSH credentials for exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |115 +|<> |This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity. |[Domain: Network], [Use Case: Threat Detection], [Use Case: Network Security Monitoring], [Use Case: Vulnerability], [Data Source: Network Traffic], [Tactic: Impact], [Resources: Investigation Guide] |None |2 + |<> |This rule detects the installation of root certificates on a Linux system. Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to their command and control servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106 |<> |Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which an outbound network connection is initiated by UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use the ptrace system call, which is typically used for debugging and allows the process to trace and control other processes. Attackers may leverage this capability to hook and inject into a process that is running with root permissions in order to execute shell code and gain a reverse shell with root privileges. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index 14bcd3daf6..d0c912387c 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -623,6 +623,7 @@ include::rule-details/first-time-seen-google-workspace-oauth-login-from-third-pa include::rule-details/first-time-seen-memcached-writer.asciidoc[] include::rule-details/first-time-seen-nfs-auth-sys-root-uid-access.asciidoc[] include::rule-details/first-time-seen-newcredentials-logon-process.asciidoc[] +include::rule-details/first-time-seen-rmm-signer-across-the-environment.asciidoc[] include::rule-details/first-time-seen-remote-monitoring-and-management-tool.asciidoc[] include::rule-details/first-time-seen-removable-device.asciidoc[] include::rule-details/first-time-destructive-mongodb-command-from-a-client-ip.asciidoc[] @@ -1084,6 +1085,7 @@ include::rule-details/newly-observed-high-severity-detection-alert.asciidoc[] include::rule-details/newly-observed-high-severity-suricata-alert.asciidoc[] include::rule-details/newly-observed-palo-alto-network-alert.asciidoc[] include::rule-details/newly-observed-process-exhibiting-high-cpu-usage.asciidoc[] +include::rule-details/newly-observed-rc4-kerberos-service-ticket-request.asciidoc[] include::rule-details/newly-observed-screenconnect-host-server.asciidoc[] include::rule-details/node-js-pre-or-post-install-script-execution.asciidoc[] include::rule-details/nping-process-activity.asciidoc[] @@ -1504,6 +1506,7 @@ include::rule-details/remotely-started-services-via-rpc.asciidoc[] include::rule-details/renamed-automation-script-interpreter.asciidoc[] include::rule-details/renamed-utility-executed-with-short-program-name.asciidoc[] include::rule-details/renaming-of-openssh-binaries.asciidoc[] +include::rule-details/repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc[] include::rule-details/root-certificate-installation.asciidoc[] include::rule-details/root-network-connection-via-gdb-cap-sys-ptrace.asciidoc[] include::rule-details/roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc[] diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-seen-rmm-signer-across-the-environment.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-seen-rmm-signer-across-the-environment.asciidoc new file mode 100644 index 0000000000..ef40b66006 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/first-time-seen-rmm-signer-across-the-environment.asciidoc @@ -0,0 +1,222 @@ +[[first-time-seen-rmm-signer-across-the-environment]] +=== First Time Seen RMM Signer Across the Environment + +Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen RMM Signer Across the Environment* + + +Attackers abuse legitimate RMM and remote-access software to open interactive sessions, persist, and stage follow-on tooling while blending into IT support activity. This rule alerts on a Windows Elastic Defend process start whose `process.code_signature.subject_name` matches a curated vendor list, when that subject is first seen across the visible fleet in the 10-day new_terms history window. Novelty is keyed only on the signer subject, so each certificate string alerts once environment-wide and renamed binaries that still carry a listed signer still match. Signature trust is not a query condition; review `process.code_signature.trusted` as context only. + + +*Possible investigation steps* + + +- Is the matched binary a remote-access component, or an unrelated product that shares this signer? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.command_line`. + - Review the other binaries this signer started on the alerted host with !{investigate{"description":"Show which binaries sharing the matched code-signature subject started on the alerted host during the investigation window.","label":"Signer footprint on the alerted host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Several vendors on this list also ship backup, virtualization, terminal-emulation, and management software under the same certificate, so a signer's first appearance is often not its remote-access product. A path, original file name, and command line matching the vendor's remote-access agent keeps that hypothesis active. An unrelated product from the same vendor makes this a low-value observation that still consumes the signer's novelty term, so confirm the vendor's remote-access footprint now rather than waiting for a later alert this rule will not produce. +- Does the parent and session context explain why this process launched on this host? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, `user.name`. + - Retrieve the parent process event while the parent entity is still retained with !{investigate{"description":"Find the parent process event for the matched launch when the parent entity is retained.","label":"Parent process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: A parent consistent with a software-deployment service or a scheduled management task keeps this inside a rollout hypothesis. A launch from a browser, archive, mail client, script interpreter, or an unexpected interactive session points instead to social engineering or staged access. +- What did the matched process start after launch? + - Focus: child `process.name`, `process.command_line`, `process.parent.entity_id`. + - Review child process starts on the same host with !{investigate{"description":"Find child process starts spawned by the matched process on the same host.","label":"Child process starts","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: No child process evidence is unresolved, not benign. Children limited to the vendor's own service and updater binaries stay consistent with normal tool operation without proving the deployment was authorized, while child shells, script interpreters, discovery commands, or credential tooling are suspicious. +- Did the same process perform remote-access network activity that changes the host scope? + - Focus: `destination.ip`, `destination.port`, `network.direction`. + - Review endpoint network events for the same process entity with !{investigate{"description":"Search for endpoint network events tied to the matched process entity on the same host.","label":"Same-process network events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Missing network telemetry is unresolved, not benign. Sessions to the vendor's own service endpoints show the tool operating normally but do not establish who initiated the session, while connections to unrelated external infrastructure keep the case open for escalation and wider scoping. +- If local evidence is suspicious or unresolved, is the same signer or executable hash appearing beyond the alerted host? + - Focus: `process.code_signature.subject_name`, `process.hash.sha256`, `process.executable`, `host.name`, `user.name`. + - Review recent process starts sharing the matched signer or executable hash with !{investigate{"description":"Search the 24-hour investigation window for process starts that share the matched signer or executable hash. Widen the Timeline range to look further back.","label":"Recent signer and hash spread","providers":[[{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}; the pivot is bounded to the last 24 hours for performance, so widen the Timeline range when the deployment window or suspected activity is older. + - Implication: Additional hosts or users shift the hypothesis from a single host deployment to an environment-wide remote-access introduction and should expand response scope. This rule reports a signer once for the whole fleet, so it will not alert again for this vendor and will not alert at all on a renamed binary reusing an already-observed signer; a clean 24-hour pivot therefore bounds recent spread only and is not evidence that spread has stopped. + +After these checks, escalate when source process, parent, network, or cross-host evidence is suspicious; close only when alert-local and recovered evidence prove the exact expected host/user/signer/hash scope with verified owner confirmation; preserve and escalate mixed or incomplete cases for more context. + + +*False positive analysis* + + +- This rule can alert on a real but expected first appearance of a listed signer when a software rollout, support session, or vendor agent introduction reaches the Elastic Defend fleet for the first time in the 10-day history window. +- Treat benign disposition as evidence-bounded: the alert's `process.code_signature.subject_name`, `process.executable`, `process.hash.sha256`, `host.id`, `host.name`, `user.id`, and `user.domain` should match a validated change record or verified owner confirmation for the exact system and activity. +- Treat `process.code_signature.trusted` as contextual evidence, not clearance: a trusted signature does not establish authorization or benign intent, and an untrusted, invalid, or missing trust value does not by itself prove malicious use. +- Certificate subjects that differ only in case or punctuation are separate novelty terms, so a single vendor can produce more than one alert as its certificate strings drift across products and releases. Correlate those and treat them as one introduction rather than as repeat findings. +- When justified, scope an exception conjunctively to the exact `process.code_signature.subject_name` plus `process.executable`, further bounded by supported host/user anchors such as `host.id`, `host.name`, `user.id`, or `user.domain`; never exclude on signer alone. `process.hash.sha256` is precise for scoping one investigation but is not a durable exception anchor, because the vendor's next release changes it and the exception silently stops matching. +- Expect an exception to have limited effect here, because the first alert already consumes that signer's novelty term for the history window; an exception only applies if the signer disappears from the visible fleet for more than 10 days and returns. `user.name` appears in the Focus lines for readability during analysis, while exception criteria prefer `user.id` and `user.domain` as stable identifiers rather than display names. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- Scope the activity by signer, executable hash, process entity, host, and user before containment; include child processes, same-process network events when available, and any later hosts that show the same signer or hash. +- If malicious use is confirmed, contain affected hosts through the endpoint response integration when available and contain affected accounts using reversible controls first; if direct endpoint response is unavailable, document the collected evidence and artifacts and hand them off to the responsible endpoint or incident-response team able to act. After evidence collection and scoping, terminate malicious processes, remove persistence, and clean up remote-access tooling. +- Review collected evidence for credential exposure, lateral movement, and follow-on tooling before final remediation decisions. +- Document confirmed indicators and any logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and +event.category: "process" and event.type: "start" and +process.code_signature.subject_name: ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-rc4-kerberos-service-ticket-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-rc4-kerberos-service-ticket-request.asciidoc new file mode 100644 index 0000000000..429a0fb1e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-rc4-kerberos-service-ticket-request.asciidoc @@ -0,0 +1,128 @@ +[[newly-observed-rc4-kerberos-service-ticket-request]] +=== Newly Observed RC4 Kerberos Service Ticket Request + +Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos + +*Tags*: + +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Newly Observed RC4 Kerberos Service Ticket Request* + + +This alert flags a successful Windows Kerberos service ticket request that used legacy RC4 encryption for a requester-to-service pairing not seen in the last week. It matters because RC4 tickets are easier for attackers to crack offline, and a new pairing can reveal account targeting rather than normal application behavior. A common pattern is an intruder using a low-privileged domain account to request RC4 tickets for SPN-backed service accounts, then extracting password hashes for Kerberoasting. + + +*Possible investigation steps* + + +- Validate whether the requester, source host, and service account relationship aligns with a known application change, scheduled task, or newly deployed system, because legitimate first-seen pairings often coincide with onboarding or configuration work. +- Review recent authentication activity for the requester across domain controllers for bursts of service ticket requests to multiple SPNs, especially privileged or human-managed service accounts, which is a strong Kerberoasting pattern. +- Pivot on the requesting host and user for adjacent suspicious behavior such as interactive logons from unusual systems, PowerShell or script execution, remote administration activity, credential dumping alerts, or other Active Directory enumeration in the same timeframe. +- Examine the targeted service account’s privilege level, password age, SPN exposure, delegation settings, and whether it still permits RC4, then prioritize escalation if the account is highly privileged, old, or tied to critical services. +- If the activity is not readily explained, contain the requester and source system as appropriate and rotate the service account credentials while planning to disable RC4 support and enforce stronger Kerberos encryption for affected accounts. + + +*False positive analysis* + + +- A newly deployed or reconfigured Windows service, scheduled task, or application host can create a first-seen requester-to-service pairing against a legacy SPN that still uses RC4, so verify recent change activity and confirm the requester, source host, and service account match the expected business function. +- An infrequently run maintenance or batch process may legitimately request an RC4 service ticket after more than seven days of inactivity, so confirm the event time aligns with its normal schedule and review adjacent 4769 activity to ensure the account is only accessing its usual limited set of services. + + +*Response and remediation* + + +- Isolate the requesting host and any other systems used by the compromised account from the network, block remote administration access, and preserve volatile and disk evidence before rebooting or rebuilding them. +- Disable the compromised requester account and the targeted service account, rotate passwords or keys for every exposed SPN-backed service they can access, and force logoff or ticket purge so previously issued Kerberos tickets cannot be reused. +- Remove attacker persistence by reviewing and deleting unauthorized scheduled tasks, services, startup items, WMI event subscriptions, remote access tools, Run key entries, and any newly granted local or domain group memberships tied to the affected identities or hosts. +- Restore affected endpoints and servers to a known-good state by reimaging compromised systems or rolling back unauthorized changes, then verify business applications start cleanly with the newly rotated service credentials. +- Escalate to incident response immediately if the targeted service account is privileged, tied to domain controllers or other Tier 0 systems, or if you also find credential dumping, lateral movement, multiple unusual SPN requests, or forged-ticket activity. +- Harden the environment by disabling RC4 where legacy dependencies permit it, enforcing AES-only Kerberos encryption on service accounts, migrating eligible services to gMSAs, reducing excessive service account privileges and SPNs, and adding detections for unusual service ticket bursts and new requester-to-service relationships. + + +==== Setup + + + +*Setup* + + +Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:authentication and event.code:4769 and + winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and + winlog.event_data.TargetUserName:* and + winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and + not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-computer-account-ntlm-relay-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-computer-account-ntlm-relay-activity.asciidoc index 6fd698d2e0..5185af96c4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-computer-account-ntlm-relay-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-computer-account-ntlm-relay-activity.asciidoc @@ -38,7 +38,7 @@ Identifies potential relay activities against a Computer account by identifying * Data Source: Windows Security Event Logs * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -123,7 +123,7 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625" startswith~(host.name, substring(user.name, 0, -1)) and /* Verify the machine account matches the full hostname, not just a prefix substring */ - (length(host.name) == length(user.name) - 1 or substring(host.name, length(user.name) - 1, length(user.name)) == ".") and + (startswith~(substring(user.name, 0, -1), host.name) or startswith~(host.name, concat(substring(user.name, 0, -1), "."))) and /* Verify if the Source IP belongs to the host */ not endswith(string(source.ip), string(host.ip)) and diff --git a/docs/detections/prebuilt-rules/rule-details/repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc b/docs/detections/prebuilt-rules/rule-details/repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc new file mode 100644 index 0000000000..51ee9bb1cd --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc @@ -0,0 +1,211 @@ +[[repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension]] +=== Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension + +This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-22045 +* https://nvd.nist.gov/vuln/detail/CVE-2024-5535 +* https://www.rfc-editor.org/rfc/rfc8737 +* https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Use Case: Vulnerability +* Data Source: Network Traffic +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension* + + +This rule fires when five or more TLS connections from the same source IP to the same destination IP +are recorded where the ClientHello advertises `acme-tls/1` as an ALPN protocol, the handshake never +completes (`tls.established: false`), or where malformed ALPN data produces a relevant TLS alert. +Individually, an incomplete ACME challenge can be a transient network issue. In volume, this pattern is +consistent with attempts to exhaust reverse proxy resources, including CVE-2026-22045, and cause a +denial of service. + +Packetbeat TLS events describe the TLS handshake and do not include connection byte totals or reliable +elapsed duration for an incomplete handshake. Use `network_traffic.flow` events correlated by +`network.community_id` when byte counts or connection duration are required during investigation. + +`acme-tls/1` is legitimately used only by ACME certificate clients performing TLS-ALPN-01 domain +validation. Repeated stalled sessions outside of scheduled certificate renewal windows are anomalous. + + +*Possible investigation steps* + + +- Identify the source IP (`source.ip`) and verify whether it belongs to a known ACME certificate + authority (Let's Encrypt: 66.133.109.0/24, 172.65.32.248/28; ZeroSSL; Buypass) or an authorized + internal ACME renewal agent. Traffic from unexpected sources is the primary indicator of exploitation. +- Pivot to `destination.ip` and `destination.port` to determine which TLS listener is targeted and + whether it is internet-exposed. Traefik, nginx, HAProxy, and similar reverse proxies are the + most likely targets. +- Count total stalled events from the same `source.ip` over the past hour to understand the full + attack volume: + ```esql + FROM logs-network_traffic.tls* + | WHERE tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" + AND tls.established == false + | STATS count = COUNT(*) BY source.ip, destination.ip, destination.port + | SORT count DESC + ``` +- If flow reporting is enabled, correlate `logs-network_traffic.flow-*` events on `network.community_id` + to review `network.bytes`, `source.bytes`, `destination.bytes`, and `event.duration`. +- Check server-side metrics on the destination host around the alert time: goroutine count for Go + services (Traefik, Caddy), worker or thread count for nginx or HAProxy, and TCP accept queue depth. + Saturation aligned with the alert window confirms impact. +- Review whether the targeted service is patched for CVE-2026-22045. Traefik versions before the + fix did not enforce handshake timeouts on acme-tls/1 listeners, allowing indefinite goroutine hold. + + +*False positive analysis* + + +- cert-manager, Certbot, or Caddy ACME clients produce `acme-tls/1` connections during certificate + renewal. These complete quickly under normal conditions; isolated stalled events from recognized + ACME client IPs are likely transient network issues, not attacks. The threshold of five events within + the detection window suppresses most one-off failures. +- Load balancer health checks misconfigured to probe with TLS-ALPN-01 can generate this pattern; + identify the health check source IP and add it to the exception list. + + +*Response and remediation* + + +- If the source IP is not a known ACME CA or authorized renewal agent, block it at the perimeter. +- Upgrade Traefik to a version patched for CVE-2026-22045. Apply equivalent handshake-timeout + configurations on other reverse proxies (`ssl_handshake_timeout` in nginx). +- Enforce a TLS handshake timeout at the listener level to bound how long any stalled connection + can hold a goroutine or worker slot. +- Rate-limit inbound TLS connections per source IP at the network boundary to limit the blast radius + of connection-exhaustion attacks. +- If service degradation is confirmed, restart the affected reverse proxy after applying timeout + mitigations to recover exhausted resources. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Agent `network_traffic` integration with TLS protocol parsing enabled +and `include_detailed_fields: true` (the default). Without this setting, the field +`tls.detailed.client_hello.extensions.application_layer_protocol_negotiation` is not populated and +the rule will not match. + +Verify your `network_traffic` integration configuration includes: + +```yaml +packetbeat.protocols: + - type: tls + ports: [443, 8443, 9443] + include_detailed_fields: true + transaction_timeout: 30s +``` + +Adjust the port list to cover all TLS listeners in your environment that could be targeted, including +reverse proxy listeners and custom TLS service ports. The `include_detailed_fields` key defaults to +`true`; if it was explicitly disabled, re-enable it and restart the agent. + +Packetbeat's default TLS `transaction_timeout` is 10 seconds. Incomplete handshakes that remain idle +beyond this timeout can expire without producing a `network_traffic.tls` event. Configure +`transaction_timeout` to exceed the longest incomplete-handshake interval you intend to observe. The +example above uses 30 seconds; increasing this value retains connection state longer and can increase +memory usage on high-volume sensors. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.tls* +| where source.ip is not null and destination.ip is not null and ( + ( + tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" and + tls.established == false + ) or ( + CONTAINS(TO_LOWER(tls.detailed.client_hello.extensions._unparsed_), "alpn") and + tls.detailed.alert_types in ("decode_error", "illegal_parameter") + ) + ) +| stats + Esql.event_count = COUNT(*), + Esql.destination_port_values = MV_SLICE(MV_DEDUPE(TOP(destination.port, 10, "asc")), 0, 10), + Esql.network_community_id_values = MV_SLICE(MV_DEDUPE(TOP(network.community_id, 10, "asc")), 0, 10), + Esql.alpn_values = MV_SLICE( + MV_DEDUPE(TOP(tls.detailed.client_hello.extensions.application_layer_protocol_negotiation, 10, "asc")), + 0, + 10 + ), + Esql.alert_type_values = MV_SLICE(MV_DEDUPE(TOP(tls.detailed.alert_types, 10, "asc")), 0, 10) + by source.ip, destination.ip +| where Esql.event_count >= 5 +| keep + source.ip, + destination.ip, + Esql.event_count, + Esql.destination_port_values, + Esql.network_community_id_values, + Esql.alpn_values, + Esql.alert_type_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Service Exhaustion Flood +** ID: T1499.002 +** Reference URL: https://attack.mitre.org/techniques/T1499/002/ diff --git a/docs/index.asciidoc b/docs/index.asciidoc index 9cfa8721f8..5cef9bee4e 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -141,3 +141,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules- include::detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rules-8-19-28-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules-8-19-30-appendix.asciidoc[]