Microsoft, Stop Reading My Emails!

by D33r

On an engagement that simulated access as a typical remote worker, I wrote a very simple custom executable intended to serve solely as a proof-of-concept.

The purpose was to test the in-place email security controls and illustrate to the client if a malicious file could be delivered over email and executed on a remote worker's laptop.  The payload was written quickly in Python and turned into an executable using PyInstaller without too much interest in the evasion of anti-virus products (though I have seen PyInstaller executables hold their own against some anti-virus products).  I also wrote a corresponding multi-threaded Command and Control (C2) server in Python and deployed it on a VPS with a public IP address and tied it to a domain for testing.  As things tend to go when hacking computers, events took a strange turn.  The email filter wound up doing a little more than expected!

The setup was as follows: we were to send a malicious email from an external user to the simulated employee's Microsoft 365 account (we had a physical employee-issued laptop for a more realistic simulation) and would then attempt to click on the attachment.  We went through the typical list of executables/malicious attachment files such as HTA, HTML, JS EXE, DLL, etc. to give a well-rounded assessment of their email security filters.  Most of these went as expected... besides the EXE file that was attached!

The email with the EXE was never delivered (unsurprisingly) as described in Microsoft's Outlook documentation that shows blocked attachments: Blocked Attachments in Outlook

Suddenly, I noticed that my C2 server had captured a shell from a host!

Heart pounding and sweat forming, I thought I had inadvertently done something wrong!  Did I send the attachment to the wrong person?  Was there a typo in the email address?  A slight panic rushed over me as I feared the sounds of federal agents at my door were soon to be heard.

Conveniently, the first stage of the payload was instructed to send host information such as IP addresses, usernames, and the hostname.  The payload determined the host was a Windows 10 machine with AMD64 architecture and was executed as the user account "CherryBerry".

An effortless ICANN lookup of the origin IP address that was displayed in my C2 server revealed the machine was located at a Microsoft data center.  I soon realized that I had not made a mistake, but Microsoft had taken the liberty of executing my code (what an honor!)!

"CherryBerry" sounds like something I would name a sandbox account, so I felt assured that this was merely a simulation.  Fortunately, I had not just unleashed a plague on the digital world!

Interestingly, the executable was placed in the Outlook directory just as a normal email attachment would be.  I suspect this is to prevent sandbox evasion techniques and to simulate an actual user clicking on the email.  After executing a few basic commands to verify my theory such as dir and ipconfig, I captured my screenshots to show the client and my colleagues this puzzling event, then promptly closed the shell and terminated the session.

After starting to wrap up this section of the engagement, Microsoft continued to execute the malware on many additional sandbox instances.  This resulted in a barrage of shells with similarly humorous usernames until I finally stopped my C2 server and destroyed the VPS I had created.

This hilarious and surprising situation highlighted a case study surrounding the everlasting debate between privacy and security.  Is this invasion of privacy in user email accounts justified to keep users "safe" in their own inbox?  I am relatively certain that deep within the privacy policies of Microsoft, I agreed to this digital surveillance somewhere.

Though I certainly did not anticipate them stealing my email in transit and to then execute arbitrary code.