Skip to content

Instantly share code, notes, and snippets.

@msuiche
Created March 6, 2025 19:06
Show Gist options
  • Save msuiche/d1d1f955c980998fb797a8ce409afc1b to your computer and use it in GitHub Desktop.
Save msuiche/d1d1f955c980998fb797a8ce409afc1b to your computer and use it in GitHub Desktop.
TraderTraitor (UNC4899) threat group Yara files

YARA Security Signatures

This repository contains YARA rules for detecting potentially dangerous patterns in code and configuration files.

Those files have been generated from the information shared in the following blogposts: Suspicious files that may be related to the latest UNC4899 hack of Safe/ByBit

TraderTraitor YAML Deserialization Attack

This signature detects unsafe YAML loading patterns in Python scripts that have been associated with the TraderTraitor (UNC4899) threat group attributed to North Korea (DPRK).

The FBI has attributed a major cryptocurrency heist on February 21 to this threat group. The pattern specifically looks for insecure YAML deserialization using yaml.load(resp.text, Loader=yaml.Loader), which could allow for arbitrary code execution.

Why this is dangerous: Using yaml.Loader with untrusted data can lead to remote code execution vulnerabilities, as it allows for the deserialization of arbitrary Python objects. Attackers can craft malicious YAML content that, when deserialized, executes arbitrary code on the target system. This is a common vector used in supply chain attacks against cryptocurrency projects.

Recommended fix: Replace yaml.Loader with yaml.SafeLoader to restrict deserialization to basic YAML types only.

rule TraderTraitor_YAML_Deserialize {
    meta:
        description = "Detects unsafe YAML loading pattern associated with TraderTraitor (UNC4899/DPRK) attacks"
        author = "Matt Suiche (@msuiche)"
        reference = "February 21 cryptocurrency heist attributed to TraderTraitor by FBI"
        severity = "high"
        date = "2025-03-06"
        threat_actor = "TraderTraitor/UNC4899"
        attribution = "DPRK"
    
    strings:
        // Main pattern to detect the unsafe YAML loading
        $yaml_unsafe_load = "yaml.load(resp.text, Loader=yaml.Loader)" ascii wide
        
        // Additional common variations
        $yaml_unsafe_var1 = "yaml.load(" ascii wide
        $yaml_unsafe_var2 = "Loader=yaml.Loader" ascii wide
        $yaml_unsafe_var3 = "Loader=yaml.UnsafeLoader" ascii wide
        
        // Common imports that would be present
        $import1 = "import yaml" ascii wide
        $import2 = "from yaml import" ascii wide
        
        // Response handling context
        $resp_text = "resp.text" ascii wide
        $response_text = "response.text" ascii wide
        $request_context = "requests." ascii wide
    
    condition:
        // File is a Python script
        extension == ".py" and
        
        // Primary detection: exact pattern
        $yaml_unsafe_load or
        
        // Secondary detection: components appearing together
        (
            ($yaml_unsafe_var1 and ($yaml_unsafe_var2 or $yaml_unsafe_var3)) and
            (any of ($import*)) and
            (any of ($resp_text, $response_text, $request_context))
        )
}

Docker Compose Privileged Container Detection

This signature identifies Docker Compose configuration files that contain privileged: true settings, which grant containers elevated privileges on the host system.

Why this is dangerous: Privileged containers have nearly equivalent capabilities to processes running directly on the host. This breaks container isolation and can lead to container escapes, allowing attackers who compromise a container to gain access to the host system. In production environments, privileged containers should be avoided whenever possible.

Recommended fix: Remove the privileged: true setting and instead use more granular security configurations:

  • Use specific capabilities with cap_add instead of granting all capabilities
  • Mount only the specific devices needed instead of all devices
  • Use security profiles to further restrict container permissions

For necessary elevated operations, consider implementing rootless containers or using Podman with enhanced security contexts.

rule Docker_Compose_Privileged_Container {
    meta:
        description = "Detects docker-compose files with privileged: true setting which may indicate privilege escalation"
        author = "Security Analyst"
        date = "2025-03-06"
        severity = "medium"
        reference = "Docker privilege escalation risks"
        category = "container_security"
    
    strings:
        // Target docker-compose file patterns
        $privileged_true1 = "privileged: true" ascii wide
        $privileged_true2 = "privileged:true" ascii wide
        $privileged_true3 = "privileged: yes" ascii wide
        $privileged_true4 = "privileged:'true'" ascii wide
        $privileged_true5 = "privileged: \"true\"" ascii wide
    
    condition:
        // Match docker-compose files (.yaml, .yml)
        (extension == ".yaml" or extension == ".yml") and
        
        // Filename contains "docker-compose"
        (filename contains "docker-compose" or filename contains "docker_compose") and
        
        // Contains privileged: true setting
        any of ($privileged_true*)
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment