Certificate used for digitally signing malware.

Hunt Hypothesis

This detection identifies adversaries leveraging valid digital certificates to sign malicious executables, a tactic designed to bypass signature-based security controls and establish trust with endpoints. Proactively hunting for this behavior in Azure Sentinel is critical because attackers increasingly abuse legitimate certificate authorities to mask malware distribution, allowing threats to evade standard antivirus solutions that prioritize trusted signatures.

YARA Rule

rule cert_blocklist_13c8351aece71c731158980f575f4133 {
    meta:
        author      = "ReversingLabs"
        source      = "ReversingLabs"
        status      = "RELEASED"
        sharing     = "TLP:WHITE"
        category    = "INFO"
        description = "Certificate used for digitally signing malware."

    condition:
        uint16(0) == 0x5A4D and
        for any i in (0..pe.number_of_signatures): (
            pe.signatures[i].subject contains "Opera Software ASA" and
            pe.signatures[i].serial == "13:c8:35:1a:ec:e7:1c:73:11:58:98:0f:57:5f:41:33" and
            1371513600 <= pe.signatures[i].not_after
        )
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the rule “Certificate used for digitally signing malware,” including suggested filters and exclusions tailored for an enterprise environment:

• Scenario: Antivirus Engine Updates via Scheduled Tasks

  • Context: Enterprise security suites like Microsoft Defender, CrowdStrike Falcon, or Symantec Endpoint Protection frequently download and install definition updates. These updates are often signed by the same certificate used to sign the core engine, which may have previously been flagged as “malware-signing” in a specific threat intelligence feed due to its broad usage across multiple vendor products.
  • Filter/Exclusion: Create an exclusion based on the process name (e.g., MsMpEng.exe, FalconSensor.exe) and the scheduled task trigger. Exclude events where the process is running under the context of a known update service account (e.g., NT SERVICE\DefenderSvc).

• Scenario: Deployment of Internal Scripts via Configuration Management Tools

  • Context: IT Operations teams use tools like Microsoft SCCM, Ansible, or PowerShell DSC to deploy internal scripts and automation agents. These internal artifacts are often signed by a corporate Root CA certificate that is also used by external vendors, causing the detection engine to flag legitimate internal deployment binaries as potential malware signers.
  • Filter/Exclusion: Implement a filter based on the source IP address of the deployment server (e.g., exclude traffic from the 10.x.x.x management subnet) and the publisher name. Specifically, whitelist certificates issued by the internal “Enterprise Root CA” that are not listed in the external threat intelligence feed’s “malware signer” list.

• Scenario: Execution of Third-Party Backup Agents

  • Context: Enterprise backup solutions such as Veeam, **Commvault