SOC Prime Bias: High

26 Aug 2026 06:42 UTC

SynkLoader Combines Multiple Evasion and Delivery Techniques

Author Photo
SOC Prime Team linkedin icon Follow
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Inside SynkLoader: A Loader Packed with Evasion Techniques

Summary

SynkLoader is a newly identified modular malware family that uses a multi-language architecture to complicate detection. The malware relies on a Python-based loader to deploy memory-resident modules for system profiling, persistence, and credential theft through a fake Windows lock screen. It also uses advanced evasion techniques including in-memory DLL loading and custom ChaCha20 encryption for C2 communications.

Investigation

Researchers discovered SynkLoader during an incident investigation and later built a C2 emulator to draw the threat actors into a controlled environment. By supplying fake system information, they observed the deployment of multiple modules, including persistence and phishing components. This active deception approach allowed analysts to capture a large portion of the attacker’s toolkit and better understand its communication protocols.

Mitigation

Organizations should block unauthorized MSI installers delivered from public cloud storage and monitor for suspicious PowerShell activity involving encoded commands. Strict controls around Microsoft Teams file downloads and monitoring for unauthorized scheduled tasks created through COM interfaces are recommended. EDR solutions should also detect in-memory DLL loading and unusual Python process behavior.

Response

If SynkLoader activity is detected, the affected host should be isolated immediately to limit lateral movement enabled by the TrafficRedirector module. Responders should perform memory forensics to identify resident components and inspect scheduled tasks or COM object manipulation for persistence. Authentication logs should also be reviewed for suspicious sign-ins following possible deployment of the PhishLocker module.

Attack Flow

We are still updating this part.

Detections

Suspicious Powershell Strings (via powershell)

SOC Prime Team
25 Aug 2026

Call Suspicious .NET Methods from Powershell (via powershell)

SOC Prime Team
25 Aug 2026

Python Execution from Suspicious Folders (via cmdline)

SOC Prime Team
25 Aug 2026

Possible System Enumeration (via cmdline)

SOC Prime Team
25 Aug 2026

Possible Account or Group Enumeration / Manipulation (via cmdline)

SOC Prime Team
25 Aug 2026

Possible Powershell Obfuscation Indicators (via powershell)

SOC Prime Team
25 Aug 2026

Suspicious Scheduled Task (via audit)

SOC Prime Team
25 Aug 2026

IOCs (HashSha256) to detect: SynkLoader: when you throw in everything but the kitchen sink

SOC Prime AI Rules
25 Aug 2026

Detection of SynkLoader Execution Using Python Loader [Windows Process Creation]

SOC Prime AI Rules
25 Aug 2026

Detection of In-memory PowerShell Execution Using Hex Encoded Values [Windows Powershell]

SOC Prime AI Rules
25 Aug 2026

Detection of PhishLocker Fake Lock Screen and Scheduled Task Persistence [Microsoft Windows Security Event Log]

SOC Prime AI Rules
25 Aug 2026

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 gained initial access and intends to execute a secondary-stage payload entirely in memory to avoid leaving a footprint on the disk. To evade simple file-based AV, they use PowerShell’s Invoke-Expression (aliased as iex) to run a hex-encoded string. They also attempt to use the [System.Management.Automation.ScriptBlock]::Create method, a more advanced technique often used by sophisticated loaders to execute code blocks directly from memory. These actions are designed to trigger the specific command-line patterns monitored by the security rule.

  • Regression Test Script:

    # Simulation Script: Triggering In-Memory Execution Detection
    Write-Host "[*] Starting Detection Validation Simulation..." -ForegroundColor Cyan
    
    # 1. Trigger via 'iex' (Invoke-Expression)
    Write-Host "[*] Executing Payload via 'iex' pattern..." -ForegroundColor Yellow
    $hexPayload = "Write-Host 'ALARM: In-memory execution via IEX detected!'"
    $hexEncoded = [System.BitConverter]::ToString([System.Text.Encoding]::UTF8.GetBytes($hexPayload)).Replace("-", " ")
    # Simulating the command line execution that would appear in logs
    powershell.exe -Command "iex ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromHexString('$($hexEncoded.Replace(' ', ''))')))"
    
    Start-Sleep -Seconds 2
    
    # 2. Trigger via 'ScriptBlock::Create' pattern
    Write-Host "[*] Executing Payload via 'ScriptBlock::Create' pattern..." -ForegroundColor Yellow
    $cmd = "Write-Host 'ALARM: In-memory execution via ScriptBlock detected!'"
    powershell.exe -Command "& ([System.Management.Automation.ScriptBlock]::Create('$cmd'))"
    
    Write-Host "[*] Simulation Complete." -ForegroundColor Green
  • Cleanup Commands:

    # No persistent artifacts are created by this simulation as it is purely in-memory.
    # However, we clear the console to signify completion.
    Clear-Host
    Write-Host "[*] Cleanup Complete. No files were written to disk." -ForegroundColor Cyan