All postsAnd we’re really quite proud about it!
Our tests are so close to real-life hacking that sometimes there is no practical difference between the two. We don’t usually expect to interact directly with cyber criminals, but it sometimes happens. In this case, our attacker was rude enough to spoil our initial analysis and to leave a sexually aggressive message for our team, too. SE Labs has been hacked!
The offensive ‘offer’ left on our test system leads us to assume that the attacker was a male, but who really knows? We’re yet to encounter a security product or team that can attribute attacks to specific countries with 100% accuracy, let alone to genders.
For more on nation state cyber attack attribution, see Simon Edwards’ article about APT attribution: Whodunnit? APT attribution is hard.
Reassuringly vulnerable
We’ll get to technical specifics below, but the very short version of this story is that, while we were testing security products, a hacker broke into one of our test systems and did his business. So to speak.
He stored his evasive malware tools (which were largely unknown by the industry at the time) and secured them using his passwords (that we now know). As he explored our system he realised that we were monitoring him and promptly deleted all of his files (too late) and created a directory called “suck my d*ck”.
When we test using threats that we generate in the lab we are the ‘attackers’ so we don’t see third-party involvement like this. (Well, there was one time, but that’s another story.) But we also test using threats that affect the general public at the time of testing, so there is always a chance that a real bad guy will end up on our network.
We often see automated attacks and not hands-on, real people interacting with us during a test, so this was, in a sick way, reassuring! SE Labs has been hacked, but we want to be.
It proves that our tests are so realistic that there is no difference between our test and a real breach.
For example, in our Breach Response tests we behave exactly like different groups of cyber criminals and spies.
Under the hood
As we were running the test on a system being monitored by a well-known EDR product, we could reconstruct the attacker’s actions, in the same way that a customer would do following a breach. This is despite the attacker trying to cover his tracks.
We also discovered new malware tools and passwords for those tools.
The attack involved a remote access Trojan (aka a ‘RAT’) and DLL side-loading. The anti-malware industry likes to classify malware into ‘families’ and the consensus is that this attack started with malware in the TVRAT family, which probably stands for TeamViewer Remote Access Trojan.
This variant of TVRAT abused a vulnerable version of TeamViewer to achieve a DLL Load Order Hijacking attack, which gives TeamViewer more ‘features’. In this case the new DLL established a secret remote session for our attacker.
Six hours later the attacker connected and uploaded two applications designed to steal passwords. The security industry calls such an application a Password Stealer (PWS). The EDR solution detected and quarantined both.
During his remote session with our systems the attacker appeared to realise that we were watching his behaviour. His reaction was to delete his tools; identify the directory in which we were storing our analysis logs; delete those logs (thanks a lot!); and create a directory called “suck my d*ck”.
To all intents and purposes, SE Labs has been hacked!
Gentle evolution of threats
What this episode shows us is that, while headlines might scream about millions of new malware samples appearing every hour, the likely truth is that attackers are generating millions of subtle variations of malware. The initial attack was using code and techniques that have been know about since at least 2016.
We can also surmise that people are not updating their software. It’s the most boring, hackneyed piece of advice you’ve been seeing for two decades, but updating vulnerable applications is really important. The attack we’ve described here happened in late 2020.
The vulnerabilities in TeamViewer are not new. There are security patches available. This is not a zero day attack. If TeamViewer users were generally up to date then attackers would not still be using these old exploits, because they wouldn’t work most of the time.
We can also see that our tests are so close to real-life hacking that sometimes there is often no practical difference between one and the other.
Our final conclusion is that hackers can be rude.
Indicators of Compromise
The EDR that we were testing at the time produced the following details.
Application path:
%AppData%\Roaming\PlayReady\wmipse.exe
Side-loaded DLL path and hash:
\Users\Username\AppData\Roaming\PlayReady\msi.dll 923766eb10a163d0bfb3f85bcf19f8ac774d1e69627bc4a63c1321a366ab671c
On-system actions:
xcopy /Y /I /S "C:\Users\Username\AppData\Local\Temp\dbnlwte0*" "C:\Users\Username\AppData\Roaming\PlayReady\"
PWS paths and hashes:
C:\Users\Username\AppData\Local\Temp\cli.exe a739910a18c1ded77bca7f33c0ff47bf2ef0c049bf0d53d2f7c045d25659581b
C:\Users\Username\AppData\Local\Temp\log.exe 8747e88c0119b175da457d9bedf7cf1eae8c9a2c021434263c9de22f2b112545
Other:
Blue language
