Why Security Teams Need a Second Set of Eyes

During a recent penetration test, I hijacked the client’s email server, posed as the client CEO, and sent a fraudulent email to the client CFO asking the CFO to wire $10,000 USD to an offshore bank account.

Interestingly, after receiving a string of actual malicious phishing attacks requesting money transfers, the client security team had specifically checked their email servers to ensure that this attack vector could not be exploited. As is best practice, after checking the security of their email servers and external network, the client requested that CRITICALSTART come in, give a second set of eyes, and validate their findings.

We found that the email server had been locked down from the inside but was open from the outside. That is, if an attack was attempted from within the client domain, it would be unsuccessful. But, if the attack originated from the Internet, as most attacks do, the email server was wide open and vulnerable to attack.

 

The Attack

Coming from the Internet, I performed recon and discovered the client’s email server information by studying the Domain Name Resolution (DNS) records. The MX, or Mail Exchanger, record pointed to the main email server and a backup email server. I scanned the server for open ports, using nmap, and found the Simple Mail Transfer Protocol (SMTP) port open. This is a normal function of email servers and is part of how email servers speak to each other.

Using the networking program, ‘netcat,’ I manually connected to the email server and looked around. While most email servers will limit the options available to outsiders with no authentication, this one allowed me to issue critical commands, such as RCPT, MAIL, and DATA, all core elements to sending an email within the client’s domain. I was able to designate any internal email address as the sender and receiver. I could send an email from anyone within the client company to anyone else inside the client company.

As soon as I found this out, I ran some simple Google searches to find email addresses from the client. With a few sample email addresses, I found that the client used a common email schema of “first.last@company.com” (e.g. jane.doe@company.com). A quick LinkedIn search gave me the names of the client CEO and CFO. With the email schema known, creating the valid email addresses of the CEO and CFO was a straight forward task.

I then loaded up a simple emailer program found within the Metasploit project (auxiliary/client/smtp/emailer), pointed it at the open email server, and sent an email from the CEO to the CFO asking the CFO to wire money. What’s more, as I was using the functionality of the email server, itself, the client’s Outlook email application matched the CEO’s email with the CEO’s face and internal company profile.

 

Remediation

This was a controlled Proof of Concept. During the “attack,” the client’s lead security analyst was on the phone with me and all interested parties were aware of the actions. After completing the Proof of Concept attack, the lead security analyst and I set to find out why the email server was open, especially as they checked for this specific vulnerability.

I walked the client security analyst through my attack and had the analyst validate my findings. The output on the security analyst’s side was different than mine. His side was still locked down. We both puzzled over this for a bit before realizing that the security analyst was attempting the attack from within the company’s domain. The security analyst attempted the same attack from outside the network by bouncing through an external secure shell (SSH) connection. Sure enough, the findings matched my own. It seemed that the messaging administrator had made a simple mistake while securing the email server. With that misconfiguration, the intended security measures only applied to the internal domain and left the server open to the outside.

 

Conclusion

I didn’t find many other vulnerabilities. This email server vulnerability was a bit of a fluke, an unintended misconfiguration. This client’s security team did a great job of securing their own network. After doing their job, they followed the best security practices and brought us in to verify and validate.

The key takeaway from this test was that every company, including (and most especially) security conscience companies, need that second set of eyes.