How to become cyber resilient quickly and remain in full control

Running Cyber Security Operations is crucial but difficult

Successful and effective cyber security is not only about tools, but (increasingly) about the processes and people to operate those tools effectively. While organizations used to buy security tools and believed this would be sufficient, they increasingly realize that running the actual Cyber Security Operations (CSO) with the right people is necessary to benefit from those tools.

Designing, implementing and operating CSO is by no means easy. Especially the expertise (e.g. specialized security knowledge to make sense of many alerts) and processes (e.g. quick follow-up on high risk events) are often difficult to implement.

Many organizations want to build, improve or (partly) outsource their CSO because they realize it is a crucial part in becoming more secure. However, they struggle to find the right balance between in-house and outsourced operations, especially when it comes to controlling the full operational process. Also, many organizations do not know how to become sufficiently cyber resilient quickly during this transition process.

In addition, operating cost effective CSO is difficult for tasks requiring scale, such as:

  • 24/7 human monitoring
  • high expertise intelligence gathering
  • emergency response

Many organizations choose not to build those capabilities in-house, but to outsource them to a security partner.

Fox-IT has developed its hybrid approach to address the above mentioned challenges.

 

A hybrid approach makes Cyber Security Operations easy and secure from the start

With a hybrid approach to CSO, organizations can choose a mix of outsourcing tasks and performing tasks in-house. For example, an organization can choose to outsource all detection tasks, while keeping other functions (e.g. vulnerability management, incident response) in-house. This ensures that difficult tasks, that require significant build-up periods, are operational from the start, while tasks requiring local knowledge or physical proximity can still be performed in-house.

Another advantage of this approach is that an organization can gradually grow into the in-house operation of specific parts of security. For example, after having outsourced all detection tasks, all 1st line tasks can initially be performed in-house, followed by the 2nd and 3rd line if the initial step is successful. The security partner can support this transition by performing these tasks and provide specific training modules. This way, the organization optimally benefits from the security partner’s expertise.

Organizations that want a hybrid approach to CSO should realize that, even though parts of the operation are outsourced, this approach will require significant investment and resources. However, we believe those investments and resources are significantly smaller than when either outsourcing all security tasks (because several tasks could be performed more efficiently by employees with specific knowledge of the organizations’ situation and physical proximity) or performing them in-house (because of a lack of scale in certain tasks).

 

A hybrid approach to Cyber Security Operations typically takes four steps

The implementation of a hybrid approach to CSO is not easy. Care should be taken in planning and implementing this approach. In our experience, four distinct steps can be identified in a hybrid CSO implementation:

  1. An assessment of the current state of cyber security operations is performed. This includes identifying the existing technology, processes and people in place that perform security tasks. Also a target situation of security operations is defined, to guide the whole transition.
  1. The functional design of the hybrid CSO is developed. All cyber security operations tasks (e.g. vulnerability management, intelligence management, incident detection, etc.) are detailed on a technology, process and people level. That design is mapped on a project plan or roadmap for implementation with different phases.
  1. The technical design and implementation phase starts with the easy activities or quick wins to become more cyber resilient early in the project. Then, more complex phases can be implemented. Also, the capability building program (e.g. training) should start early to hand over tasks to the in-house team as soon as possible. During this phase strong project management with regular measurement of progress is crucial.
  1. The operations phase starts gradually for each implemented task. In this phase, continuous improvement is crucial to remain cyber resilient. Feedback from incidents, false positives and false negatives should be fed back to improve each part of the operation. Also, intelligence on new threats, vulnerabilities and protected interests should be used to improve operations.

 

Fox-IT can support your organization in developing a plan towards a Hybrid CSO or to guide you through the whole transition. If you have any questions regarding the hybrid approach to CSO, please contact us at fox@fox-it.com

Large malvertising campaign targeting the Netherlands

At the Fox-IT SOC we see malvertising incidents on a daily basis, as blogged on before. Sadly malvertising has become a usual occurence, but the events we’ve been observing since Thursday the 11th of June stood out. An active malvertising campaign propagating via 2 major advertisement networks is targeting visitors only coming from the Netherlands, using the Angler Exploit Kit.

Currently the popular Dutch news website Telegraaf[.]nl is, indirectly, causing the most victims.

Details

Since Friday we’ve seen the following two advertisement providers serving traffic from a specific third party:

  • AppNexus
  • Rubicon

The specific advertisements from these two networks were loaded for (at least) the following websites:

  • telegraaf.nl
  • theguardian.co.uk
  • huffingtonpost.com
  • lemonde.fr

The third party responsible for the malicious redirects to the Angler Exploit Kit is known as otsmarketing[.]com and is located at 107[.]181[.]187[.]81. When this page is loaded a short-link of Google’s service goo.gl is used for redirection. Due to the fact that this short-link service operates under HTTPS it will lose the referrer chain from the advertiser towards the exploit kit.

Because the otsmarketing[.]com domain is currently the chain connecting the advertisers with the exploit kit, we advice blocking the IP address at this time. Keep in mind however that these criminals will surely change this tactic as soon as its noticed. We have tried to contact the people behind otsmarketing[.]com but were not successful in doing so. We’re also doubting the legitimacy of this company as we didn’t see it being loaded via advertisements until Thursday last week, the first day we’ve seen this malvertising campaign in action.

Update 16-06-2015: After coordinating with the advertisers the malicious host was blocked and removed from their advertisement platforms.

Indicators of Compromise

The following IP and domain should be blocked in order to avoid the current campaign:

  • otsmarketing[.]com / 107[.]181[.]187[.]81

The Angler Exploit kit typically installs the Bedep Trojan, which installs additional malware. Bedep can typically be found by looking at consecutive POST requests to the following two websites:

  • earthtools.org/timezone/0/0
  • ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml

We have yet to identify the final payload.

Yonathan Klijnsma & Maarten van Dantzig, Threat Intelligence Analysts at Fox-IT

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: https://vimeo.com/88822483.

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

QUANTUMINSERT

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

QUANTUMBOT

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

QUANTUMBISQUIT

Enhances QIs effectiveness against proxies and other hard to reach targets

QUANTUMDNS

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

QUANTUMHAND

Exploits the computers of Facebook users

QUANTUMSKY

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

QUANTUMCOPPER

File download/upload disruption and corruption.

Source: https://firstlook.org/theintercept/document/2014/03/12/one-way-quantum/

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, but 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.

quantum_follow_stream3

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: https://github.com/fox-it/quantuminsert/tree/master/poc/

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.

quantum_insert_wireshark

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: https://github.com/fox-it/quantuminsert/tree/master/pcaps

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: https://github.com/fox-it/quantuminsert/tree/master/detection

Snort

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 README.md for more technical details: https://github.com/fox-it/quantuminsert/tree/master/detection/snort

We hope these patches will eventually find its way upstream.

Bro

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 README.md for additional technical details:https://github.com/fox-it/quantuminsert/tree/master/detection/bro

Suricata

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.

https://github.com/fox-it/quantuminsert/tree/master/detection/suricata

Evasion

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: https://github.com/stealth/QI

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.

 

References

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

Liveblog: Malvertising from Google advertisements via possibly compromised reseller

We are currently observing a large scale malvertising campaign originating from all the Google advertisement services resold from engagelab.com. It appears as if if all of engagelab.com its advertisement & zone ID’s are currently redirecting to a domain, which in its turn is redirecting to the Nuclear Exploit Kit, indicating a possible compromise at this reseller of Google advertisement services. This Nuclear Exploit kit targets vulnerabilities in Adobe Flash, Oracle Java and Microsoft Silverlight software.

Fox-IT observed the first redirect to the malicious domain on April 7th 2015 on 15:41:42 (CEST/GMT +02:00). The Fox-IT SOC has detected a relatively large amount of infections and infection attempts from this exploit kit among our customers. We suspect that this malvertising campaign will be of a very large scale.

The domains for the exploit kit itself aren’t directly used for redirection; a secondary site is used as an intermediate. The domains and IP’s used for the exploit kit are constantly changing, to mitigate the threat for now we suggest blocking the website between the legitimate websites and the exploit kit. We have observed the following being in constant use (we will update if anything changes):

  • foley.go2lightuniversity.com / 85.143.217.196

Domains observed for the Nuclear Exploit Kit:

  • banking.techpool.org / 62.76.44.174
  • soaring.betsystemreviews.com / 62.76.44.174
  • supervision.sactown.us (currently offline)

Though we have yet to identify the exact malware variant victims are currently being infected with via the exploit kit we have identified the command and control server used:

  • alfiantoys.com/wp-news.php / 174.36.217.82

To limit damage we recommend the following steps

  • Block access to 85.143.217.196
  • Use an adblocker
  • Update Java, Silverlight and Flash to the latest versions

Google has been notified of the issue.

Update #1: Added image (see below) to illustrate the malvertising redirection chain (21:49 CEST/GMT +02:00)

Update #2: Though we have not received any official confirmation, we are currently no longer observing malicious redirects from the advertisement reseller (22:54 CEST/GMT +02:00)

Update #3: After analysis the payload has been identified as Pony Loader, malware able to steal credentials and install other types of malware. VirusTotal link with basic information: https://www.virustotal.com/en-gb/file/33ea978af4508cf411fa04a7e25e060e8e6932a07cdc2608a83886d3f551f2ec/analysis/ (18:27 CEST/GMT +02:00)

Keep an eye on this blog for updates on the situation.

The following image illustrates the malvertising chain from a website using Doubleclick to the Nuclear exploit kit (for a more thorough explanation of what malvertising is, please see: Malvertising: not all Java from Java.com is legitimate):
Malvertising via Doubleclick

CryptoPHP a week later: more than 23.000 sites affected

On November 20th we published our report on CryptoPHP. Since publishing we have, together with other parties, been busy dealing with the affected servers and taking down the CryptoPHP infrastructure.

Sinkhole statistics

With the help of the NCSC, Abuse.ch, Shadowserver and Spamhaus we have been able to gather data about the scale of the operation ran by the CryptoPHP authors. Most C2 domains that were active at the time of publishing have been either sinkholed or taken down. From the sinkholed domains we’ve been able to gather statistics.

In total 23.693 unique IP addresses connected to the sinkholes. We are already seeing a decline in sinkhole connections, on the 22nd 20.305 connections were made, on the 23rd 18.994 and on the 24th it was already down to 16.786. These numbers are however not a clear indication, mostly because the servers connecting to our sinkholes were shared hosting with at least 1 or multiple backdoored websites. This means the actual affected websites will be higher. Unfortunately we are also unable to make statistics on whether the affected server is running WordPress, Joomla or Drupal. This information is encrypted using public key encryption as explained in the paper.

A geological map was generated from the sinkhole data, the image below gives an overview of the affected countries.

CryptoPHP Sinkhole Infection_Statistics

Updated information

Since publishing we’ve been keeping an eye on any new developments within CryptoPHP. On the 23rd most of the websites used to spread the backdoored plug-ins and themes went offline, unfortunately they were back up with a new setup a day later and are still active at the time of this publication.
A new version of the backdoor was pushed, although the version number wasn’t changed we did get a new filehash for the backdoor. The SHA1 hash for the file is ‘c4fe641e3410fb047004c9653c79124c32a66446’; the version number is still 1.0.
The updated hash was committed to the github repo with IOCs at:
https://www.github.com/fox-it/cryptophp/

Advice

We noticed that our advice in our paper wasn’t clear to everyone. Spamhaus received a lot of inquiries about what to do with affected servers or how to find them. For this reason we’ve added this section to explain this a bit better.

Detection

We have created two Python scripts to help administrators detect CryptoPHP:

  1. check_url.py
  2. check_filesystem.py

Both scripts can be found on our GitHub repo: https://www.github.com/fox-it/cryptophp/scripts/
check_filesystem.py is for scanning the filesystem for the CryptoPHP backdoor files. It will find all “social*.png” files and determine if it’s malicious.
And check_url.py script can scan a website to determine if the website is affected by CryptoPHP. This can be useful if you have multiple virtual hosts and don’t know which one is affected.

Removal

If CryptoPHP has been found we recommend the following steps:

  1. Remove the “include” of the backdoor. For example, find the script that contains: “<?php include(‘images/social.png’); ?>”. Note that this path can vary.
  2. Remove the backdoor (social*.png) itself by deleting it.
  3. Check your database to see if any extra administrator accounts were added and remove them
  4. Reset the credentials of your own CMS account and other administrators (they were most likely compromised)

The steps above should be sufficient to remove the impact CryptoPHP has had on your website. We do however recommend performing a complete reinstall of your CMS since the system integrity may have been compromised. An attacker may have gained system wide access for example.
For both security and legal reasons we would advise not to install this kind of pirated (nulled) content.

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

CryptoPHP

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

Cryptolocker variant Torrentlocker making new victims in NL

This posting is an update to Torrentlocker blog postings of October 15 and October 21.

Introduction

Since past weekend, the Netherlands were hit with another spam run spreading the Cryptolocker variant known as Torrentlocker. Torrentlocker presents itself to victims as Cryptolocker in all cases, however this is a completely different malware. Fox-IT received multiple reports of new victims in the Netherlands and we are currently analyzing the new spam run and malware that was subsequently used.

For the indicators of compromise of this new spam run, see below.

You have fallen victim to Torrentlocker if you find that a number of your (data) files have been encrypted and are unreadable. In case of infection with Torrentlocker, the following notice will appear on the screen of the infected system:

warning-tl

Also, each directory that contains encrypted files will also contain an HTML file with instructions on how to contact and pay the criminals behind this latest wave of Torrentlocker attacks.
What to do if you are a victim?

There are a number of things that you can do yourself to find the original infection and contain the spread of torrentlocker, and possibly restore files to their original state.

  1. Block access to certain resources on the internet in order to minimize the risk of further infections. For information on which resources to block, see section “Indicators of compromise in network traffic”.
  2. Activate system policies that prevent further activity by torrentlocker:
    1. Restrict “delete” permissions. Activate a policy that prevents users from deleting files from shares. We have indications that such a policy may prevent torrentlocker from working effectively. We are currently investigating this claim.
    2. Restrict “write” permissions. To be extra careful, you may change user’s rights on all files to “read-only”. This will prevent any changes to files.
  3. Identify the systems that are infected with torrentlocker. The following steps will help with identification:
    1. Identify who received emails as part of the spam run. In your email messaging logs, search for email messages with characteristics as described in the section “Indicators of compromise in email”. Any hits should provide you with information about who within your organization received emails as part of the spam run and will allow you to remove these emails.
    2. Identify who visited suspicious torrentlocker websites. In your gateway logs (proxy logs, firewall logs, IDS logs etc), search for visits to websites known to be associated with this spam run. Any hits should provide you with evidence which systems within your infrastructure visited those websites and are potentially infected with torrentlocker. More information about what to look for can be found in section “Indicators of compromise in network traffic”.
    3. Identify which systems are infected. After the previous two steps, you may have narrowed down the number of systems that are potentially infected and have caused the files to be encrypted. On suspected systems, you may use the information in the section “Indicators of compromise on hosts”.
  4. Isolate the infected systems from your infrastructure. Once identified, these systems should be carefully isolated from the infrastructure, to prevent further encryption of additional files but at the same time preserve digital traces.
    1. Immediately cease all user activity on infected systems as they may contain important clues for decryption of the encrypted files or additional information about the infection.
    2. Physically disconnect the infected systems from the network.
    3. Do not power off, wipe or reimage infected systems.
  5. Restore backups of the infected files. Backups that are stored offline are not affected. Torrentlocker is known to disable the built-in “Previous Versions” feature in Windows. This fails in some cases allowing you to recover your files via the “Previous Versions” tab in the file properties window. Also, the “Previous versions” feature of cloud storage services like Dropbox might still contain the unencrypted version of your data.
  6. Seek professional assistance. In case backups are not available or only partly available, and you have preserved sufficient digital evidence, you may seek professional assistance in an effort to recover infected files.

About paying the ransom

Several reports have reached us of people who have paid the ransom in order to get their files back. In some cases they were successful or partly successful, in other cases they were not. The currently known problems with paying the ransom to get your files decrypted are:

  • There is no guarantee whatsoever that you will receive a decryption tool after paying;
  • In case your files are encrypted by multiple different infections of Torrentlocker, you will have to pay multiple times;
  • The decryption tool as distributed by the criminals contains flaws. After decryption, the resulting files will be partly corrupted, which may render them unusable;
  • Last but not least: you are aiding criminals.

Indicators of compromise in email

To detect the latest Torrentlocker spam run, you may search your messaging logs for e-mails with the subjects:

Den Haag - Incassoburea Nederland.
Den Haag - Intrum Justitia
Den Haag - Intrum Incasso
Den Haag Incasso Nederland.
INCASSO NEDERLAND.
*INCASSO* NEDERLAND.

And you may search for e-mails from the following sender:

bdiu@inkasso.nl

The e-mails are impersonating a Dutch debt collection agency called Intrum Justitia.

incasso mail

Attached to the e-mail is a Word document, containing several malicious macro’s. The recipient of the email is enticed to open the Word document, and to enable macros (if not already enabled).

word macros

If the document is opened and macros are enabled, the macros will download a malicious binary, which acts as a dropper to install Torrentlocker on the system.

Indicators of compromise on disk

The dropper is downloaded to the user’s temporary folder:

c:\Users\<username>\AppData\Local\Temp\[A-Z]{10}.exe

Depending on whether it has admin privileges, the dropper drops malware at the following locations:

c:\Windows\[a-z]{8}.exe
c:\ProgramData\[a-z]{8}.exe

Indicators of compromise in network traffic

Within your gateway logs (proxy, firewall and IDS logs, etc) you may search for traffic to the following IOC’s in order to identify systems within your infrastructure that visited malicious hosts associated with this attack. This list contains currently known IOC’s and is not necessarily complete.

Dropper download location:

hxxp://109.105.193.99/a.png

Command and control server hostname:

allwayshappy.ru

Command and control server IP’s (of all Torrentlocker campaigns):

46.161.30.16
46.161.30.17
46.161.30.18
46.161.30.19
46.161.30.20
46.161.30.21

Update on the Torrentlocker ransomware

This posting is an update to the Torrentlocker blog posting of October 15. For guidance on containment and recovery, see the previous blog post.

Financial aspects

Payments for the ransom have to be done in Bitcoins. We have identified 7 Bitcoin addresses that received ransom payments. The total income as of the 21th of October is 862,79539531 BTC which comes down to 257.393,45 EURO made in payments to the criminals. Based on the current BTC price for the ransom, currently 1.32 BTC about 400 EURO, we can say that at least 653 victims have paid the ransom. We have confirmed 4180 infected clients up until October 21st. If they would all pay the ransom that would amount to 1.6 million euros.

Harvesting new e-mail addresses

Torrentlocker is currently being spread via phishing emails luring victims to fake postal service websites. One of the ways the criminals are getting new emails to send the emails towards is by harvesting email addresses from infected machines. It is able to grab email addresses from:

  • Thunderbird
  • Outlook
  • Windows Live Mail

We’ve found that they were able to harvest 2.614.109 email addresses in total. In addition to email addresses to use as a recipient, Torrentlocker also looks for IMAP/POP3/SMTP credentials to send the emails from. Started from the 20th we have seen them harvest a total of 1746 SMTP account credentials.

harvested-torrentlocker-addresses

Location and number of the affected clients

This Torrentlocker campaign started on the 16th of September 2014 and has been targeting various countries. The criminals have made payment templates for the following countries:

  • Australia
  • Canada
  • Spain
  • Great Britain
  • Ireland
  • Italy
  • Namibia
  • Netherlands
  • New Zealand

They have been sending the phishing mails to recipients in the following countries:

  • Albania
  • Australia
  • Austria
  • Belgium
  • Canada
  • Chile
  • Colombia
  • Egypt
  • France
  • Germany
  • Great Britain
  • Greece
  • Hongkong
  • Hungary
  • India
  • Indonesia
  • Iran
  • Ireland
  • Isle of Man
  • Italy
  • Japan
  • Korea
  • Malta
  • Namibia
  • Netherlands
  • New Caledonia
  • New Zealand
  • Norway
  • Papue new Guinea
  • Philippines
  • Poland
  • Portugal
  • Puerto Rico
  • Qatar
  • Romania
  • Russia
  • Serbia
  • Singapore
  • South Africa
  • Spain
  • Sweden
  • Switserland
  • Turkey
  • United Arab Emirates
  • United States

In total we were able to confirm 4180 infections in 44 countries. This campaign first started on the 16th of September. They have done runs sometimes a week apart and sometimes only a day apart. The last run we saw started on the 21st of October. In every country they impersonate emails from the local postal service.

New IoCs

The following new domain names were used for hosting the fake website for the Dutch phishing campaign

  • Postnl-track.org
  • Postnl-track.net
  • Postnl-tracktrace.net

The following IP-addresses were additionally used for global C&C traffic

  • 46.161.30.16
  • 46.161.30.17
  • 46.161.30.18
  • 46.161.30.19
  • 46.161.30.20
  • 46.161.30.21

On the infected client system, the ransomware copies itself to a location based on whether it has admin privileges:

  • With admin privileges it will copy itself to C:\WINDOWS\[a-z]{8}.exe
  • Without admin privileges it will copy itself to C:\ProgramData\[a-z]{8}.exe

Additionally a startup key is added to the registry to start the ransomware upon a reboot.

New Torrentlocker variant active in the Netherlands

Introduction

The Netherlands was hit with a new spam run designed to spread a cryptolocker variant known as torrentlocker from Monday October 13th 2014 onwards. Please note that torrentlocker appears to present itself to victims as cryptolocker in all cases. Fox-IT now receives multiple reports of new victims in the Netherlands and we are currently analyzing the new spam run and malware that was subsequently used.

This blogpost is aimed at providing victims with advice on how to deal with the infections. It contains technical details that will help system administrators trace back the original infection, and contain the spread of the infection as much as possible. We will update this blog post as more information is available.

What to do if you are a victim of torrentlocker?

You have fallen victim to torrentlocker if you find that a number of your (data) files have been encrypted and are unreadable. In this instance of torrentlocker, each directory that contains encrypted files will also contain an HTML-file with instruction on how to contact and pay the criminals behind this latest wave of torrentlocker attacks.

There are a number of things that you can do yourself to find the original infection and contain the spread of torrentlocker, and possibly restore files to their original state.

  1. Block access to certain resources on the internet in order to minimize the risk of further infections. For information on which resources to block, see section “Indicators of compromise in network traffic”.
  2. Activate system policies that prevent further activity by torrentlocker:
    1. Restrict “delete” permissions. Activate a policy that prevents users from deleting files from shares. We have indications that such a policy may prevent torrentlocker from working effectively. We are currently investigating this claim.
    2. Restrict “write” permissions. To be extra careful, you may change user’s rights on all files to “read-only”. This will prevent any changes to files.
  3. Identify the systems that are infected with torrentlocker. The following steps will help with identification:
    1. Identify who received emails as part of the spam run. In your email messaging logs, search for email messages with characteristics as described in the section “Indicators of compromise in email”. Any hits should provide you with information about who within your organization received emails as part of the spam run and will allow you to remove these emails.
    2. Identify who visited suspicious torrentlocker websites. In your gateway logs (proxy logs, firewall logs, IDS logs etc), search for visits to websites known to be associated with this spam run. Any hits should provide you with evidence which systems within your infrastructure visited those websites and are potentially infected with torrentlocker. More information about what to look for can be found in section “Indicators of compromise in network traffic”.
    3. Identify which systems are infected. After the previous two steps, you may have narrowed down the number of systems that are potentially infected and have caused the files to be encrypted. On suspected systems, you may use the information in the section “Indicators of compromise on hosts”.
  4. Isolate the infected systems from your infrastructure. Once identified, these systems should be carefully isolated from the infrastructure, to prevent further encryption of additional files but at the same time preserve digital traces.
    1. Immediately cease all user activity on infected systems as they may contain important clues for decryption of the encrypted files or additional information about the infection.
    2. Physically disconnect the infected systems from the network.
    3. Do not power off, wipe or reimage infected systems.
  5. Restore backups of the infected files. In case backups are not available or only partly available, and you have preserved sufficient digital evidence, you may seek professional assistance in an effort to recover infected files.

Infection process

TorrentLocker

Indicators of compromise in email

Within your messaging logs, you may search for emails with the subject:

Heb je niet geleverde packet

Starting on Sunday emails were sent around impersonating a Dutch postal company called PostNL. The emails were styled so as to look exactly like the company’s normal email communication:

postnl phishing

The recipient of the email is enticed to click on the ‘Zie de informatie’ link. This took the recipient to a compromised wordpress website used as redirection page towards the actual malicous page.

Indicators of compromise in network traffic

Within your gateway logs (proxy, firewall and IDS logs, etc) you may search for traffic to the following site in order to identify systems within your infrastructure that visited malicious websites associated with this attack. Please note that this list contains currently known resources on the internet but is not necessarily complete.

Initial websites linked to in the email:

annswebfolio.com/wp-content/themes/twentfourteen/showthread.php
nodramadating.com/wp-content/uploads/showthread.php
strengthyourrunning.com/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/img/showthread.php
kjob.jp/re/wp-content/themes/twentyten/showthread.php
garypilafas.com/wp-content/themes/whitehousepro3_dev/showthread.php

The above websites redirected to:

www.postnl-tracktrace.com
postnl-track.com

Domains for command and control traffic over SSL:

server4love.ru
octoberpics.ru

Command and control IP’s involved with this threat:

46.161.30.20
46.161.30.16

Fake PostNL IP’s involved with this threat:

109.68.190.174
193.124.95.83

The domain ‘postnl-track.com’ had its CSS and images loaded from ‘postnl-track.com’. The page was a convincing page talking about a track and trace document being available:

tracktrace

The user is forced to enter the captcha in order to proceed. After the captcha the user is presented with a download of their track and trace information:

tracktrace2

The user is presented with a zip which has the payload inside. After opening their ‘document’ the malware will start connecting with its command and control server, generate encryption keys and start encrypting files. After its completed the user is presented with the following notice:

warning

When visiting one of the links of their payment website the user is told to pay 400 EURO’s within a certain time otherwise the price will be doubled:

payment

Indicators of compromise on hosts

On suspected systems, you may look for the following clues of infection by torrentlocker. Please note that once you determine that a system is infected, you should remove it from your infrastructure. Do not wipe or reinstall the system as it may contain additional clues about the infection.

  • The initial infection is dropped as the following file C:\WINDOWS\[a-z]{8}.exe
  • There will be a reference in the registry to the previous file, to make sure that torrentlocker starts up automatically upon boot. You may use the Windows tool msconfig to inspect startup entries.
  • A second process “explorer.exe” will be active.

Live blog on SSLv3 protocol vulnerability ‘POODLE’

Google has announced the discovery of a protocol vulnerability in SSLv3. This vulnerability allows an attacker to read contents of connections secured by SSLv3.

SSLv3 is a Secure Sockets Layer (SSL) protocol that has been ratified in 1996. SSL is used to encrypt communications between clients and servers. It is usually integrated with webservers, mailservers or other software that use secure communications.

SSLv3 has been succeeded by TLS v1.0 in 1999 and later by TLS v1.1 and v1.2 in 2006 and 2008 respectively. SSLv3 is still supported on most servers for backward compatibility with old clients that have no TLS support such as Internet Explorer 6.

What is the vulnerability?

An attacker can perform a man-in-the-middle attack on SSLv3. This attack consists of two steps

  1. Make sure the client and server agree on using SSLv3
  2. Exploit protocol vulnerabilities in SSLv3 to obtain plaintext traffic

The original paper describing the attack can be found here: https://www.openssl.org/~bodo/ssl-poodle.pdf

The vulnerability is assigned CVE reference 2014-3566

Are you affected?

All software supporting SSLv3 is affected by this vulnerability. To see if your servers support the SSLv3 protocol we recommend to following tools to scan your websites:

You can test your server by using the following OpenSSL command:

openssl s_client -ssl3 -connect [host]:[port]

For services using STARTTLS such as SMTP, POP3 and IMAP you need to add the -starttls option:

openssl s_client -starttls [smtp|pop3|imap|ftp|xmpp] -ssl3 -connect [host]:[port]

If the server does not support SSLv3 you should see a SSL alert similar to this:

SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/xx/src/ssl/s3_pkt.c:1125:SSL alert number 40
SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/xx/src/ssl/s3_pkt.c:546:

Or you can use the following Nmap command (does not support STARTTLS):

nmap --script ssl-enum-ciphers -p [port] [host or subnet]

If the server does not support SSLv3 you should see output similar to this:

| ssl-enum-ciphers: 
| SSLv3: No supported ciphers found

As a system admin – what can I do?

As a consumer – what can I do?

See the following blogpost by Zmap.io for information how to disable clientside SSLv3 for the most popular browsers: https://zmap.io/sslv3/

Detecting SSLv3 usage in your network

You can identify servers that still use SSLv3 in your network only when an SSLv3 connection is successfully negotiated using the following IDS signature:

Note: The following rule only detects the usage of SSLv3 on servers, not clients. It makes use of the Snort SSL preprocessor (http://manual.snort.org/node147.html), please make sure the ports you want to monitor are listed in both the preprocessor config and the signature. Servers can still be vulnerable if SSLv3 is enabled but no clients make use of SSLv3 towards the server, the rule only triggers if SSLv3 is successfully negotiated.

alert tcp $HOME_NET [443,465,993,995,25] -> any any (msg:"FOX-SRT - SSLv3 Server Hello Detected (Poodle)"; flow:established,to_client; ssl_version:sslv3; ssl_state:server_hello; content:"|16 03 00|"; depth:3; threshold: type limit, track by_src, seconds 300, count 1; reference:cve,2014-3566; classtype:policy-violation; reference:url,http://blog.fox-it.com/2014/10/15/poodle/; sid:1; rev:2;)

Further reading