Turla (Secret Blizzard): STOCKSTAY and Kazuar Backdoors Explained

Summary

Turla is a long-established, Russia-aligned APT group associated with the FSB and known for cyber-espionage operations against government and military targets. The group relies on custom malware, including the STOCKSTAY and Kazuar backdoors, to preserve long-term access in compromised environments. It also frequently abuses legitimate cloud services such as GitHub and Cloudflare to disguise command-and-control traffic.

Investigation

The report examines the evolution of Turla’s malware toolsets, with a focus on the STOCKSTAY and Kazuar families. It analyzes the group’s infrastructure hijacking techniques, its use of serverless platforms for command and control, and its ability to exploit vulnerabilities such as WinRAR path traversal. The investigation also highlights Turla’s use of environmental keying to reduce exposure to sandbox analysis.

Mitigation

Organizations should deploy strong monitoring for unauthorized use of trusted web platforms such as GitHub and Cloudflare when traffic patterns appear abnormal. Prompt patching of vulnerabilities like CVE-2025-8088 is essential to prevent unauthorized file writes. Defenders should also watch for unauthorized root certificate installation and suspicious PowerShell or VBScript execution that may indicate Turla activity.

Response

If Turla activity is detected, responders should isolate affected hosts and investigate for unauthorized local administrator accounts. A detailed review of process trees should be performed to uncover DLL sideloading involving legitimate binaries such as NVIDIA or Brother Printer utilities. Network telemetry should also be checked for unusual WebSocket traffic, and the machine trust store should be reviewed for suspicious certificate changes.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre-flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands: An adversary has successfully established a foothold and is now attempting to establish C2 communication. To evade detection, they use a “living-off-the-land” approach by reaching out to a serverless platform hosted on onrender.com via a WebSocket connection. Simultaneously, they attempt to pull a secondary stage payload from a public GitHub repository to blend in with developer traffic. The simulation will use curl and wscat (if available) or standard web requests to generate the specific URL patterns defined in the detection logic.

• Regression Test Script: [Provide the exact, self-contained, and executable code snippet for the simulation.]

  #!/bin/bash
  # Simulation script for STOCKSTAY C2 Detection Validation
  
  echo "[+] Starting Simulation: STOCKSTAY C2 TTPs"
  
  # 1. Trigger: WebSocket C2 via Render (Specific URL)
  echo "[*] Simulating WebSocket connection to malicious Render URL..."
  curl -k "wss://google-ai-labs-it.onrender.com/ws"
  
  # 2. Trigger: WebSocket C2 via Glitch (Specific URL)
  echo "[*] Simulating WebSocket connection to malicious Glitch URL..."
  curl -k "wss://wool-basalt-clock.glitch.me/ws"
  
  # 3. Trigger: GitHub Staging (Broad Domain Match)
  echo "[*] Simulating payload staging via GitHub..."
  curl -I "https://github.com/malicious-actor/payload-repo/raw/main/shell.sh"
  
  echo "[+] Simulation Complete. Check SIEM for alerts."

• Cleanup Commands:

  # No persistent artifacts are created on the host by this simulation.
  # Ensure any temporary bash files are removed if created.
  rm -f simulation_stockstay.sh