This One Time on a Pen Test, Part 1: Curiosity Didn’t Kill the Cat—Honesty Did

Last updated at Thu, 28 Dec 2023 19:32:59 GMT

*Each year, Rapid7 penetration testers complete hundreds of internally and externally based penetration testing service engagements.

Electronic social engineering engagements often vary from client to client, and Rapid7 works diligently to ensure testing simulates threat actors that clients are most worried about. For this particular story, I worked with the client to craft an engagement that would evaluate their employee and technology preparedness against a sophisticated, targeted phishing and vishing attack. Incidentally, this sort of thing is my favorite type of assessment.

First three steps? Reconnaissance.

There is no such thing as too much attacker reconnaissance. Employees were selected based upon their role, look-alike domains were registered, and external portals were cloned to simulate the company. Finally, phone-based reconnaissance was conducted against the help desk to determine the available payload phishing attack surface (aka what endpoint protections were in place).

What came of 70% reconnaissance and 30% crafting was a cloned Proofpoint Secure Email Portal] using the company’s branding. Behind a fake authentication page was a “secure” email from human resources and a Microsoft Excel document that tempted staff with “employee salaries.” After all, who wouldn’t want to take a peek at what their peers are making? The Excel document was thoughtfully crafted with a payload abusing Dynamic Data Exchange (DDE) functionality that executed CertUtil.exe to download additional commands to run.

Previous reconnaissance against the help desk revealed that application whitelisting was in place, as well as a policy to prevent employees from executing PowerShell.exe. To bypass these protections, Rapid7’s payload echoed C# code into a .cs file and compiled it locally into an executable using CSC.exe, a tool within the .NET framework.

The executable relied on the System.Management.Automation library to execute PowerShell commands without calling PowerShell.exe. Additionally, the executable was designed with an installer class that allowed it to be executed by InstallUtil.exe, a Microsoft-signed binary. In the end, I had a payload that bypassed the company’s application whitelisting and PowerShell.exe restrictions. Now, all that was required was sending the email to a target who would be willing to enter their credentials into a cloned portal, be curious enough to download a list of employee salaries “mistakenly” sent to them, and then click “Enable Content” and two more warning prompts in Excel to reveal the fake employee salaries.

Gone phishing

I sent a phishing email with a link to the cloned site to four senior-level employees in different departments, indicating that a secure email from human resources was available in the Proofpoint portal. Within 15 minutes, one employee opened the portal and entered their credentials.

However, a request was never made to download the Excel document. Instead, a reply was sent to my misspelled HR email address indicating that the email must have been a mistake, as they should not have access to employee salary information. Good for the employee—they were honest and considerate. Now, how could this be abused?

Switching gears

Thinking on my feet, I quickly created a fake email chain between the HR email account and a newly created, fake third-party law firm that asked for guidance on how to handle an accidental breach of sensitive employee data. Once the email chain looked legitimate, I replied to the targeted employee from the third-party legal team email. Indicating that this (fake) employee was working on behalf of the HR department, I sent over a confidentiality document to ensure the information received by the employee was kept confidential. The employee replied that while they did not open the spreadsheet, they were willing to sign the document. Perfect. Now to craft a new payload to fit this new pretext.

An Excel document did not seem right for the occasion, so I reverted to using a Microsoft HTML Application (.hta). These are essentially web pages that can execute content without browser sandboxing restrictions, executed by default by MSHTA.exe, another Microsoft-signed binary. The HTA contained JavaScript with an ActiveXObject that executed a serialized binary stream (thanks to DotNet2JScript) of Rapid7’s previously compiled executable payload.

When opened, the HTA presented a full screen on the employee’s workstation including company logos, verbiage requesting the employee delete any confidential data received, and confirmation that the employee did not share data with anyone else. A text field was included for the target employee to enter their name as an electronic signature, along with a “Submit” button that caused the HTA to minimize and remove itself from being displayed on the taskbar.

Within minutes of sending the “legal document” to the employee, I received a Meterpreter shell on the employee’s workstation that provided command-line access to the host and a route into the company’s internal network.

In the end, honesty killed the cat, not curiosity. While it was exceptionally hard for the employee to spot this attack chain, additional application whitelisting and better behavior-based detection and prevention controls could have prevented the payloads from executing. A list of known Microsoft-signed binaries used by malicious actors to bypass controls can be found in the deployment guide for Application Locker and Windows Defender Application Control on Microsoft’s website.