A sophisticated hacker group pwned Amazon Web Services (AWS) servers, set up a rootkit that let them remotely control servers, then merrily funnelled sensitive corporate data home to its command and control (C2) servers from a range of compromised Windows and Linux machines inside an AWS data centre.

That’s according to a report from the UK’s Sophos published late last week, which has raised eyebrows and questions in the security industry. The attackers neatly sidestepped AWS security groups (SGs); which, when correctly configured, act as a security perimeter for associated Amazon EC2 instances.

The unnamed target of this attack had correctly tuned their SGs. But with a rootkit installed on their AWS servers that gave attackers remote access, the compromised Linux system was still listening for inbound connections on ports 2080/TCP and 2053/TCP: something that eventually triggered Sophos’ intervention.

AWS Servers Hacked But “It Could Have Been Anyone”

Sophos was at pains to emphasise that while this particular attack targeted AWS servers, it was “not an AWS problem per se. It represents a method of piggybacking C2 traffic on a legitimate traffic… in a way that can bypass many, if not most, firewalls.”

Security experts agreed that the attacker, likely a nation state actor, could have used the bespoke rootkit to funnel data off most servers, whether in the cloud or on-premises. (Those interested in the precise details of how the attackers managed their data exfiltration can refer to detailed technical write-up here).

Sophos dubbed the incident, which used a customised Gh0st RAT trojan –”Cloud Snooper”. One cybersecurity researcher (initial reaction: “dude this happens all the time. It only gets noticed if it has a fancy name”) described it to us after looking closely at the incident as “from a technical perspective, a thing of beauty…

Many questions about the security breach remain unanswered, however, not least how the attackers got the rootkit onto the AWS servers to start with.

Here’s What Happened

Sophos said: “An analysis of this system revealed the presence of a rootkit that granted the malware’s operators the ability to remotely control the server through the AWS SGs. But this rootkit’s capabilities are not limited to doing this in the Amazon cloud: It also could be used to communicate with, and remotely control, malware on any server behind any boundary firewall, even an on-premises server.

“By unwinding other elements of this attack, we further identified other Linux hosts, infected with the same or a similar rootkit.

The company added: “Finally, we identified a compromised Windows system with a backdoor that communicated with a similar C2 as other compromised Linux hosts, using a very similar configuration format. The backdoor is apparently based on source code of the infamous Gh0st RAT malware.”

At the heart of the attack was another backdoor trojan dubbed “snoopy” that can be executed both as a command line tool and as a daemon. This opens HTTP and/or DNS services on a compromised system, and allows traffic tunneling, operating both as a reverse SOCKS5 proxy server, and client.

(Snoopy stores many debug messages in clear text, several in Chinese, i.e. “远程内存空间分配失败! – Remote memory space allocation failed!”)

Sophos’s full write-up of the techniques used can be found here [pdf].

“The default installation for the SSH server also needs extra steps to harden it”

The security firm noted: “AWS SGs provide a robust boundary firewall for EC2 instances. However, this firewall does not eliminate the need for network administrators to keep all external-facing services fully patched.

“The default installation for the SSH server also needs extra steps to harden it against attacks, turning it into a rock-solid communication daemon.”

Security researcher Willem Mouton told Computer Business Review: “From a technical perspective it is a thing of beauty, also the fact that they made it cross platform.

“The one thing that the article did not clear up was what the initial entry vector as well as the privacy escalation was. In order to install such a rootkit you would probably [need] root on Linux and LocalAdmin/System level privileges on Windows.

“This rootkit was most probably deployed to maintain an advanced covert level of network persistence. Which makes me wonder on whose network they found this because that seems like a hell of a lot of tech and effort so it must have been a target of real interest. Also, the article mentions everything was hosted on AWS, and usually you would see attackers go for the AWS/Cloud tenancy or subscription to maintain access, but again nothing of that was mentioned.

“I would love to see the full outcome of their investigation”.

Sophos said Indicators of Compromise (IoCs) included having the following ports open on local host: tcp 2080; udp 2053; tcp 10443. Suspect file names include /tmp/rrtserver-lock; /proc/sys/rrootkit; /tmp/rrtkernel.ko; /usr/bin/snd_floppy; snd_floppy.

The following warning syslog messages also showed up:

  • “…insmod: ERROR: could not insert module /usr/bin/snd_floppy: File exists”
  • “…kernel: snd_floppy: loading out-of-tree module taints kernel.”
  • “…kernel: snd_floppy: module verification failed: signature and/or required key missing – tainting kernel

One high profile previous attack on cloud servers was demonstrated by Eclypsium, which leased a bare metal IBM server and exploited a vulnerability in its Baseboard Management Controller (BMC); a third-party server component used to enable remote management for initial provisioning, OS reinstall and troubleshooting.

It then relinquished the use of the server, which was re-released for use by other cloud customers. But the BMC was not re-flashed with factory firmware meaning Eclypsium sustained its access, in an incident that IBM Cloud played down.

Read this: IBM Cloud Server Compromised: Vulnerability Let Loose in Hardware Pool