Advanced persistent threat (APT) groups are typically the most sophisticated of cybercrime operations. Many have been active for years, stealing tens of thousands of dollars and wreaking havoc upon their enemies and victims. Often backed by nation states, many APT groups carry out cyber espionage, spying on their country’s political enemies.
Despite the apparent sophistication of APT groups, they make some surprising mistakes. In coordination with my SafeBreach Labs team, I’ve spent the last seven years on a research project dedicated to identifying these mistakes and using them to uncover unparalleled insights into the inner workings of cybercriminal groups.
This undertaking culminated in a talk at this year’s DEF CON 30 that I dubbed “OopSec – The bad, the worse, and the ugly of APT’s operations security.” During my presentation, I shared many of the strange, stupid, and downright embarrasing mistakes made by some of the world’s most prominent APT groups.
Before setting out on my research mission, I posed three research assumptions at the heart of my project:
- Attackers are human and prone to mistakes.
- Threat actors wouldn’t necessarily fix OpSec holes, even if they have suffered from a past takedown or data leak.
- We could learn new techniques, current targets, plans, and additional valuable data by leveraging their mistakes.
With these assumptions established, I took a deep dive into the mistakes made by some of the world’s most prominent APTs. In this blog, we will look into the first APT I investigated—a state-sponsored threat actor responsible for a decade-long malware campaign aimed at monitoring and collecting data on Windows and Android users.
This threat actor, dubbed “Bad Patch”, was first discovered by Palo Alto Networks in 2017, although the oldest observed activity had a compile date of June 2012. The C2 server linked to that sample, pal2me.net, was also registered on that date.
The malware itself has several collection capabilities, including the monitoring of SMS and phone calls. Once collected, the data is exfiltrated to a C2 server using a HTTP POST request. The 2022 Android version of the malware is currently masquerading as a Google Play SSL app. A look at the app’s certificate locality and upload origin to VirusTotal allowed SafeBreach to ascertain that the threat actor is operating out of Gaza, Palestine.
Bad authentication processes allowed Palo Alto Networks researchers to access the threat actor’s systems without authentication. Navigating directly to “/lms/index.php”—the index page—did not take researchers login.php, instead granting authenticated access to the systems and the keylogger exfiltration scheme.
Shocked by how easy it was to gain access to this information, I asked myself if this was a one-time mistake. It wasn’t. I discovered that every single C2 server was vulnerable.
In 2017, the first stage malware code downloaded the second stage malware code, named “dbd.zip”, from the C2 server named “pal4u.net/zzzzz”. Curious as to whether the pattern remained in 2022, I looked a little deeper. A short investigation revealed that the same domain that was used and publicly disclosed was nothing more than a subdomain of the C2 server. I then found a folder named “CCC Directory”. This folder contained all the exfiltrated data of some 7800 victims, ready and waiting to be downloaded.
The data, which included phone call recordings, microphone hijacks, CV files, and images, belonged primarily to Gaza residents, as well as some victims from other Middle Eastern countries. All in all, it accounts for a staggering 50 GB of compressed data. That’s, on average, 470 megabytes of compressed data per day.
Another OpSec mistake this threat actor made was in their Open Dir C2 server, “tawjihi.pal4u.net”. Open as all their C2 servers were, this particular server included a 12 MB file called “tawjihi.zip”. To my disbelief, I opened the file and found the full server side backend logic.
It’s often not enough to just find the Open Dir C2 server, as most of the time the data is in the form of a .php or .aspx file, which cannot be downloaded by simply clicking the link. As these are backend files, the web server will not send the file to a web browser. In this case, however, the threat actor chose to compress all of this data into a zip file, which could be downloaded, and allowed me to download the backend logic.
Despite these mistakes, I found that the upload file logic for exploratory data was well done. The threat actor only allowed .csv extensions, which is not particularly malicious, and used unique identifiers (i.e., anyone attempting to upload a webshell file instead of exfiltrating data would not be able to guess its name). However, the node.js logic reveals the files upload path, which is not good practice.
While this is just the tip of the iceberg of my APT research project, it should provide some idea as to its scope. The insight that research like this provides is invaluable for business security posture—understanding the mistakes that APT groups make helps security professionals mitigate the harm they cause. This type of original research is also used to inform the SafeBreach Hacker’s Playbook, making SafeBreach’s breach and attack simulation (BAS) platform even more effective, accurate, and realistic.
For more of my research and discoveries, check out my full DEF CON presentation below: