NGINX and PHP Malware Used in Petya/Nyetya Ransomware Attack

Author’s note: This is a technical blog post which I’m hoping server administrators and web hosting providers will find helpful. It also includes malware history and video footage which I hope you enjoy. ~Mark Maunder

Cisco’s Talos security group published an excellent blog post yesterday describing the recent ransomware campaign that goes by various names, including Petya, NotPetya and Nyetya. For clarity, I’m going to call it Nyetya from here on in.

The Talos team’s post provides a very clear account of how the initial ransomware infections started. In the account, they describe how the attackers reconfigured an NGINX web server to reverse proxy requests to a compromised server at a hosting provider. The Talos team also discovered a well-known malware variant on the compromised web server. This immediately got our attention because, of course, PHP malware and attack vectors are what we think about all day long at Wordfence.

In this post, I’m going to try to provide a clear picture of how the web components in the attack were used and abused by attackers. At the end of the post I’ll discuss what hosting providers and site admins can learn from this attack.

How and Why the Attacker Used NGINX Reverse Proxying to Control Infected Machines

M.E.Doc is a company in Ukraine that makes accounting software. They have many clients, and they distribute their software directly to their customers. Around April this year, their network was compromised because an attacker managed to acquire stolen credentials belonging to an administrator. Using these credentials, the attacker was able to log in and start modifying server configurations and software.

The attacker modified the nginx.conf config file on an M.E.Doc update server to reverse proxy requests to a server hosted at OVH. The server was being used by a hosting reseller called THCServers.com. This server had been compromised by the attacker prior to launching the attack on M.E.Doc.

The attacker then modified the M.E.Doc accounting software to include their own malicious code. Unaware of the infection, M.E.Doc then distributed the compromised software to its clients as usual. Once installed on a workstation, the modified software contacted the compromised M.E.Doc NGINX server every two minutes to fetch commands the attacker wanted to run.

That request to the M.E.Doc NGINX server for commands was reverse proxied through to the compromised OVH command and control server the attacker controlled. When the attacker wanted to send commands to infected workstations, they simply set up a new command on the compromised OVH server which the workstations then dutifully fetched via the compromised NGINX server.

To summarize:

• The attacker modified the M.E.Doc accounting software to fetch commands from a hacked M.E.Doc update server.
• That software was distributed to clients.
• The hacked M.E.Doc NGINX server proxied those requests for commands to a hacked OVH server.
• Attacker sent commands back to the hacked NGINX server, which were forwarded to the compromised workstations running the M.E.Doc accounting package.

The following diagram illustrates the configuration the attacker created.

This Is Smart Because It Is Evasive

Many network administrators have intrusion detection systems on their networks. One of the intrusion methods those IDS systems look for is communication from malware to a command and control (C&C) server. The IDS systems have a database of indicators of compromise, or IOCs. Those IOCs include IP addresses of known C&C servers.

If the attacker in this case had communicated directly from the hacked M.E.Doc software to their C&C server, a network IDS would have detected it, then would have blocked the request and alerted the network administrator. Instead, the network administrators saw M.E.Doc software communicating with an M.E.Doc update server as expected, and assumed everything was okay.

How the Attacker Distributed Ransomware

Once the attacker controlled a large enough number of machines using the above technique, they simply ran a command that caused the controlled machines to fetch ransomware and install it. It was that simple. The rest is the story of the Petya/Nyetya/NotPetya ransomeware infection you’ve read about in the news recently.

The PHP Malware Used In This Attack Has a Colorful History

The Cisco Talos team also found PHP malware on the compromised NGINX machine with the following path: http://www.me-doc[.]com[.]ua/TESTUpdate/medoc_online.php [Square parentheses included for safety.]

We managed to get a sample of the malware from intelligence-sharing partners, along with the password to decrypt it. Surprise, surprise: the malware is our old friend “PAS.” Last year in December, we wrote a detailed analysis of the PHP malware used in the US election hack. The malware was released by the U.S. Department of Homeland Security as part of a set of indicators of compromise related to the election hack. We analyzed the malware back then, and found that it is well-known, widely used, freely available and is known as PAS.

We tracked down the site that provides the malware. At the time it was available from: http://profexer.[name]/pas/download.php

That site is now offline, and for good reason. Someone posted a link to the DHS report and our blog post to the forums at rdot.org where the author who goes by profexer hangs out. When he discovered his web shell and website had been linked to the election hack, he presumably got nervous and took his site offline. It has been offline since then.

The malware that the Cisco Talos team found in the Nyetya ransomware attack is a version of PAS. Once you access the malware via a web interface and enter the password to decrypt it, this is what it looks like:

The Talos team don’t seem to have data showing how the PAS web shell was used in the attack. My guess is that it was just used as a convenience by the attacker to provide them with a graphical interface in a browser rather than having to use SSH and the command line.

What is interesting is that accessing this malware would have been “noisy.” It would have left a trail in the web server access logs, and if it had been accessed via HTTP and not HTTPS, it may have triggered alarms. SSH would have looked less suspicious because the only data would have been the source and target IP and the connect and disconnect. Using a web shell creates a log entry for every command run. This suggests a lack of sophistication or perhaps simply a lack of care on the attackers’ part.

Once we received this sample, we checked our own attack data to determine if this exact variant of PAS had been used to target our own customer sites. It has not; however, we did find several instances where other PAS variants had targeted customer sites. In all these cases, Wordfence successfully blocked the attacks. We’ve since confirmed that Wordfence is also blocking this specific sample.

Takeaways for Web Hosting Providers and Server Admins

As I mentioned at the start of this post, the hackers in this attack were able to compromise the M.E.Doc network using stolen credentials. If you are a hosting provider or server admin, consider using two-factor authentication for any server access, including SSH. Assuming the attacker did not have access to the credential owner’s other devices, two-factor authentication would have stopped this attack, or at least made it significantly harder for the attacker to gain access.

Better configuration management might have helped alert a system administrator to a change in an nginx.conf file. This might have also caught the malicious change in the M.E.Doc software when the file hashes changed.

If M.E.Doc had had an internal IDS configured to monitor the default gateway, they might have caught the traffic from the compromised NGINX server being reverse proxied to a compromised OVH server.

The M.E.Doc servers had reportedly not been updated since 2013. So it goes without saying: bring all your servers up to the latest patch levels, and actively maintain all other software.

The Ukraine National Police posted the video below, showing them raiding the M.E.Doc servers. Notice the “creative” server cooling tech being used at around 1:00 in the video.

As always I’ll be around to reply to any questions or comments. Stay safe out there, keep your credentials secure, and keep those servers up to date.

~Mark Maunder