Background

If you haven’t done so yet, read my first Zix exploitation article: Spear Phishing with Zix: An Undisclosed Red Team Method for the Hungry APT, which established baselines to abuse the native organizational trust that Zix provides to perform spear phishing on the affected company. Shortly after the spear phishing writeup, I discovered that Zix is also an excellent data exfiltration tool. The innate trust that Zix Secure Messaging provides allows an insider threat or threat actor with internal access to the network to bypass organizational data loss prevention controls (DLP) with ease.

Identification

I found myself part of a red team engagement where the objective of financial data exfiltration was one of the key goals during the scoping discussion. With access to the client’s network, I attempted to exfiltrate data but it was exceedingly difficult. The client had several DLP tools in place, preventing unsanctioned transfer of enterprise data. As an example, Gmail, DropBox, Github, or any other website that fell into a “file sharing” category in Symantec Bluecoats was blocked. In addition, outbound traffic inspection tools covered all of the edge cases for websites that might be in other categories of Bluecoats that might not be blocked. Rather than to trying to setup infrastructure or inventing complex methodology/spam-attempting existing methodology, I looked no further than Zix.

At this point, I already knew that in many cases, Zix Secure Messaging was utilized as a means of transmitting data securely between internal employees and third-party partners. It was established in my spear phishing writeup that many organizations using Zix do not properly configure their instance, resulting in the ability for anyone with any email address to signup for an account. The lack of access control on registration actually ends up being the death of any DLP tools that are utilized in the environment.

Exploitation

The exploitation chain was simple. First, I registered an account through the organization’s secure messaging portal, as shown above. Next, I focused on thinking about the best way to make the blue team’s life even harder if they were to figure out that I was attempting to exfiltrate data via Zix. Based on the spear phishing vulnerabilities discovered on Zix in my last writeup, I knew that Zix does basic checks to ensure that you’re not trying to upload malicious content. With that in mind, I had no idea what the application was doing to prevent DLP, but I know for certain that most tools can’t inspect password protected or encrypted files.

I segmented all of the files that I wanted to exfiltrate in separate .zip archives and used ZipCrypto to place a password on each archive.

The main issue with using ZipCrypto, is that it’s a weak method of protecting an archive. If someone wants to break into the archive, a person would only need to know 12 bytes of plain text and where it’s located in the zip file which allows them to decrypt the archive. Tools such as bkcrack have the ability to quickly run through this process. Ideally, for the most secure data exfiltration method, hackers should strive to use AES-256.

In my case I could not use AES-256 because the native machine didn’t have 7zip installed and Carbon Black was limiting my ability to install programs that deviate from “an allowlist”. I wasn’t concerned with trying to protect the archive from attackers, so much as I was trying to exfiltrate the data. I logged into my newly-created Zix Secure Messaging account, and clicked on the “Compose” button to start writing a new message.

As you can see, I was able to upload the test .zip file. I attempted to save the message as a draft to see if I could recover the archive, but clicking on the archive just loaded up the message draft. I entered in my personal data exfiltration email address, and clicked on send, but the organization was restricting my ability to send messages to non-employee email addresses - and that’s when I discovered an additional Zix vulnerability. There’s no logic that checks to see if a company email address is valid. Zix Secure Messaging just expects the user to send a message to an email that has the company domain in the address field.

I addressed the email to foo@redacted.com [where foo was a slight variation of my actual employee UID that I was attempting to exfiltrate from, and where redacted.com was the real company email ending]. I clicked on send, and it worked like a charm. Even though the email address didn’t exist in the company directory, the message was sent.

As seen above, the message went through. I loaded up the other archives, and sent them to the same email address.

I navigated to the secure messaging portal on my data exfiltration machine off network, and logged into the account that I sent the messages from. Clicking on the “Sent Mail” tab, and then subsequently clicking on the attachments in each message, I was able to successfully download the archives and exfiltrate data from the victim machine.

Limitations & Impact

It’s important to note that there are limitations. For example, if the organization has their Zix Secure Messaging instance secured correctly, you won’t be able to register your own account to perform the data exfiltration technique with. As far as impact goes, it’s a severe issue that could result in a threat actor quickly exfiltrating data they need such as credit card information, network graphs, passwords, certificates, keys, etc. In a matter of minutes, I was able to exfiltrate ~2000 files, of varying size through the usage of multiple archives.

I wouldn’t exactly call this an “APT” level of data exfiltration, unless the threat actor primarily operates with Living off of the Land methodology or plays the long game. APTs would have trouble exfiltrating gigabytes or terabytes of organizational data with these vulnerabilities. Nonetheless, exfiltrating data that will help a threat actor exploit the network further could circumvent data exfiltration limits.