Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
236 detections
Filters
Last updated
All Time
Detection languages
100
47
32
24
10
Contributors
52
45
40
28
16
Categories
20,440
11,814
5,871
5,145
4,864
Platforms
158
60
20
14
4
Products / Services
65
55
49
49
40
MITRE Techniques
74
66
39
27
22
CVEs
3
2
2
2
2
IDS Classtypes
30
13
3
1
IDS Protocols
43
2
2
This rule detects the use of a suspicious wildcard certificate in the TLS handshake where the certificate subject contains a wildcard character followed by a domain name with a specific pattern (6 to 12 alphanumeric characters) and a top-level domain (TLD) from a list associated with malicious activities (xyz, top, club, icu). This pattern is often observed in attack infrastructure, particularly for phishing or command and control (C2) servers, to make them appear more legitimate or to facilitate rapid domain generation. The rule specifically looks for '*.domain.tld' where 'domain' is 6-12 chars and 'tld' is one of the specified suspicious TLDs.
Detects issuance of free SSL certificates for newly registered attack domains
This rule detects the installation of a root certificate via an HTTP response. It specifically looks for HTTP traffic flowing from the server to the client (to_client, established) where the URI contains ".cer" (case-insensitive) and the file data contains the string "-----BEGIN CERTIFICATE-----". This combination suggests a certificate file being delivered over HTTP, which could be indicative of a malicious root certificate installation attempt, often used in man-in-the-middle attacks or to establish persistence for malware.
This rule detects the installation of a new self-signed TLS certificate that might be used by a Command and Control (C2) server. It specifically looks for TLS certificates where both the issuer and subject Common Name (CN) are at least 5 alphanumeric characters long and the 'not before' date is in the current or future years (2024-2029). This combination of characteristics can indicate a newly generated, potentially malicious self-signed certificate.
This rule detects suspicious activity related to OpenSSL or certificate manipulation by identifying processes that execute commands containing 'openssl' or 'certificate' keywords. It aggregates these activities by computer and account within one-hour bins and flags if three or more such activities occur, which could indicate credential access attempts or system misconfiguration.
Detects the creation of files ending with '.sig', '.asc', or '.cer'. These extensions are commonly associated with digital signatures, PGP/GPG keys, and certificates, which could indicate activities like code signing, certificate generation/import, or PGP/GPG key manipulation by an adversary.
This rule detects the use of self-signed TLS certificates on newly registered domains, specifically those ending in .xyz, .top, .club, .online, or .site. It looks for certificates where both the issuer and subject Common Name (CN) fields are present, and the subject CN matches a pattern indicative of a newly registered domain (5 to 20 alphanumeric characters followed by one of the specified TLDs). This pattern is often associated with malicious infrastructure setup.
Detects the creation of files ending with '.sig', '.asc', or '.cer'. These extensions are commonly associated with digital signatures, PGP/GPG keys, and certificates, which could indicate activities like code signing, certificate generation/import, or PGP/GPG key manipulation by an adversary.
This rule detects suspicious activity related to OpenSSL or certificate manipulation by identifying processes that execute commands containing 'openssl' or 'certificate' keywords. It aggregates these activities by computer and account within one-hour bins and flags if three or more such activities occur, which could indicate credential access attempts or system misconfiguration.
Detects copying or writing certificate material and modifications to system keychains. Execution of `security add-trusted-cert`.
This query detects Identity Spoofing via Certificate Request, where a non-machine account (a human user) successfully requests a certificate containing a DNS Name in the Subject Alternative Name (SAN) field—an action typically reserved for servers—indicating the first step of a WSUS hijacking or server impersonation attack.
Detects newly added root certificate authority to an AzureAD tenant to support certificate based authentication.
Detects the execution of files signed by "TrustConnect Software PTY LTD", a certificate issuer observed signing malware that impersonates legitimate workplace applications to deploy RMM backdoors. This rule identifies processes launched from binaries associated with this suspicious certificate.
This rule identifies the use of specific malicious code signing certificates by matching their SHA1 thumbprints against a predefined list. These certificates are known to be associated with various threat actors or malicious software, indicating potential supply chain compromise or the use of signed malware.
This rule detects when a certificate is issued to a privileged user. It identifies privileged users by checking their group membership against a predefined list of administrative groups such as 'Domain Admins', 'Enterprise Admins', and 'Administrators'. The rule then looks for Windows Security Event ID 4886, which indicates a certificate services operation, and extracts the principal name from the Subject Alternative Name field. Finally, it joins this information with the identified privileged users to flag any certificate issuance to them.
Detects the addition of a new root certificate authority to an Azure AD tenant. This action can be performed by an attacker to establish persistence and enable certificate-based authentication for unauthorized access, potentially bypassing traditional password-based authentication mechanisms. This is a critical security event as it can lead to privilege escalation and persistent access within the Azure AD environment.
This analytic detects the extraction of authentication certificates using Windows Event Log - CAPI2 (CryptoAPI 2). It specifically leverages EventID 70, which is generated when a certificate's private key is acquired. This detection is significant because it can identify potential misuse of certificates, such as those extracted by tools like Mimikatz or Cobalt Strike. If confirmed malicious, this activity could allow attackers to impersonate users, escalate privileges, or access sensitive information, posing a severe risk to the organization's security.
This analytic detects attempts to add a certificate to the untrusted certificate store using the 'certutil -addstore' command. This activity is significant as it may indicate an attacker trying to disable security tools to gain unauthorized access. If confirmed malicious, this could lead to the compromise of system security, allowing attackers to bypass defenses and potentially escalate privileges or persist in the environment.
The following analytic detects the use of certutil.exe to add a certificate to the Root certificate store using the "-addstore" flag. In this case, the certificate is loaded from a temporary file path (e.g., %TEMP%) or other uncommon locations (e.g. C:\Users\Public\), which is highly suspicious and uncommon in legitimate administrative activity. This behavior may indicate an adversary is installing a malicious root certificate to intercept HTTPS traffic, impersonate trusted entities, or bypass security controls. The use of flags such as -f (force) and -Enterprise, combined with loading .tmp files from user-writable locations, is consistent with post-exploitation activity seen in credential theft and adversary-in-the-middle (AiTM) attacks. This should be investigated immediately, especially if correlated with unauthorized privilege use or prior certificate modifications. You should monitor when new certificates are added to the root store because this store is what your system uses to decide which websites, apps, and software can be trusted. If an attacker manages to add their own certificate there, they can silently intercept encrypted traffic, impersonate trusted websites, or make malicious programs look safe. This means they could steal sensitive data, bypass security tools, and keep access to your system even after other malware is removed.
Detects a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID). This could be a sign of exploitation of elevation of privilege vulnerabilities (CVE-2022-34691, CVE-2022-26931, CVE-2022-26923) that can occur when the KDC allows certificate spoofing by not requiring a strong mapping. Events where the AccountName and CN of the Subject do not match, or where the CN ends in a dollar sign indicating a machine, may indicate certificate spoofing.
Detects a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID)
This could be a sign of exploitation of the elevation of privilege vulnerabilities (CVE-2022-34691, CVE-2022-26931, CVE-2022-26923) that can occur when the KDC allows certificate spoofing by not requiring a strong mapping.
Events where the AccountName and CN of the Subject do not match, or where the CN ends in a dollar sign indicating a machine, may indicate certificate spoofing.
This could be a sign of exploitation of the elevation of privilege vulnerabilities (CVE-2022-34691, CVE-2022-26931, CVE-2022-26923) that can occur when the KDC allows certificate spoofing by not requiring a strong mapping.
Events where the AccountName and CN of the Subject do not match, or where the CN ends in a dollar sign indicating a machine, may indicate certificate spoofing.
Page 9 of 12