Stealing Emails, Let Me Count the Ways

The recently publicized hack of the Democratic National Committee has brought an incredibly common form of data theft back into the spotlight: intrusions that target e-mails. The knee-jerk response to such breaches often advocates controls like message encryption and two-factor authentication. In reality, preventing, detecting, and responding to these attacks is much more complicated. An average corporate network provides a myriad of opportunities for attackers to steal e-mail, be it a highly-focused endeavor impacting a small number of users, or an attempt to harvest data in bulk over time.

Over the past seven years, I’ve worked with many organizations that lost sensitive e-mails during targeted attacks. In this blog post, I’ll cover several common techniques that I’ve seen attackers use, discuss the impact of authentication and encryption, and highlight ways that Tanium can help detect and respond to these methods.

Underlying Assumptions

For the purposes of this post, we’ll make a few assumptions that I consider “table stakes” for any targeted intrusion of a Windows environment. First, let’s establish that the victim organization is using Microsoft Exchange, which remains the most prevalent enterprise e-mail platform. Let’s also presume that the attacker has already gained access to the victim’s internal network, and can subsequently operate from at least one of the following vantage points:

• Browser-based access to an externally-accessible webmail server, such as Outlook Web Access
• A route to internal Exchange servers through either (1) previously backdoored systems within the same internal network, or (2) a compromised VPN or other remote access solution
• Backdoor access to an end-user workstation belonging to a targeted individual whose e-mails are of interest

Finally, we’ll presume that the attacker has successfully compromised at least one of the following types of credentials:

• A privileged Active Directory account belonging to an Exchange or Domain Administrator
• A common local administrator account that can be re-used for lateral movement among victim PCs
• A non-privileged domain account belonging to a targeted individual whose e-mails are of interest

With that in mind, let’s go through a few common scenarios.

Attackers often target Outlook Web Access (OWA)

Attackers often target Outlook Web Access (OWA) during the post-compromise phase of an intrusion, i.e. after successful credential theft. It’s especially easy to access OWA if it does not require two-factor authentication or if is not positioned behind a VPN that does so. Once a domain account, or all domain accounts, are stolen, it’s just a matter of logging in like any normal user. Detecting this activity at-scale in a large, multi-national organization can be challenging, especially considering that the attacker can use browser-based access from any source address or through any hop point at their disposal.

Even if webmail is positioned behind a VPN, it still may be exposed to an attacker that’s gained a foothold on the internal network. Attackers will often explore whether the internally-accessible instance of webmail can be accessed with single-factor domain credentials. If so, they can use tunneling malware to pivot from an existing backdoored host, and authenticate as the user of interest.

Would Encryption Help?

If the organization is using S/MIME with Outlook Web Access, only Internet Explorer can be used to read encrypted e-mails. In addition, the private key necessary to decrypt messages must be installed on the local endpoint’s certificate store. The attacker must thereby gain access to the victim user’s private key, or utilize remote access to the victim’s own PC to access e-mail on their behalf. Neither would be a significant impediment in a domain-wide compromise.

If the organization is using other encryption methods, such as PGP, the attacker once again would need to recover private keys and keyphrases from the targeted user’s own system. Given a domain-wide compromise, it may be hard to prevent an attacker from gaining access to a specific user’s system. However, it does force the attacker to shift from opportunistic behavior (“I can get Adam’s e-mail from any vantage point”) to targeted behavior (“First, I need to compromise Adam’s system…”).

It’s worth bearing in mind that users will often take the path of least resistance when using a service like webmail. That often results in the exchange of unencrypted messages when using their own computers or other browsers – providing an opportunity for easier data theft, albeit against a narrower scope of e-mail.

How Could Tanium Detect This?

An organization obviously wouldn’t have any visibility into an attacker-owned endpoint used to directly access OWA over the Internet using previously stolen credentials. This narrows the sources of available evidence to network traffic and log data on the mail servers themselves. Centralizing Outlook Web Access authentication events in a SIEM, as well as the web server logs, can greatly facilitate after-the-fact investigations. Depending on the network architecture, you also might have to correlate a few sources of data to get the true source IP for inbound webmail requests.

Tanium provides a Copy Tools package that can automatically gather and distribute endpoint logs to a centralized location for ingestion and post-processing. In prior cases, I’ve worked with investigators that were able to successfully distinguish malicious from legitimate OWA access for a compromised account using browser user agents recorded in access logs, in conjunction with access time and source addresses.

If the attacker is accessing webmail through a compromised internal system, this provides many more sources of evidence on the endpoints used for “pivoting”. Depending on the means of access, Tanium provides sensors that can search for local** Security Event Log** entries, Browser History, and Trace Executed Processes that include user context for historical events. For example, an attacker using Internet Explorer through a backdoor on an infected user’s system may produce browser history entries under a system context’s profile, rather than the custodian’s own user profile. Such entries are often anomalous enough to warrant further investigation.

Harvesting E-Mails from Exchange Server with PowerShell

Given PowerShell’s roots in Microsoft Exchange server management, it shouldn’t come as a surprise that it can be used to access user mailboxes and retrieve or send messages. I’ve witnessed several intrusions in which attackers utilized malicious PowerShell scripts to harvest e-mails. This approach does require a dependency, the Exchange Web Services (EWS) library[1], that is not included with PowerShell by default.

In practice, using EWS simply entails including a single DLL, “Microsoft.Exchange.WebServices.dll”, along with the PowerShell code. A helpful post on Stack Overflow[2] shows how easy it is for a script to retrieve messages in this manner.

Would Encryption Help?

If the attacker runs the PowerShell script from the targeted user’s own system and under the context of their domain account, it would have access to the private key in the Windows certificate store necessary for S/MIME decryption. As previously noted, if another encryption method like PGP were to be used, the attacker would have to undergo additional steps to recover the key and passphrase needed to view the retrieved messages.

How Could Tanium Detect This?

Tanium Trace continuously records network connection activity along with the accompanying process and user context. One of our hunting dashboards uses the Trace Network Connections sensor to provide a filtered view of all instances of PowerShell that have established connections to ports 80 and 443. With the exception of Exchange Administrators, this use of PowerShell would be anomalous on most end-user systems or other types of servers. Our customers typically use Tanium’s Computer Groups functionality, in conjunction with these types of monitoring dashboards, to surface this type of malicious activity with higher fidelity.

Another approach would be to look for the presence or use of the “Microsoft.Exchange.WebServices.dll” library on endpoints. Tanium users can run the Index Query sensors to search the entire hard drive of all systems in seconds for this library by name or hash. In addition, the Loaded Modules sensors can identify any systems that have loaded this library in memory. Once again, computer groups can add further perspective to distinguish expected versus unexpected use of this library.

Messaging Application Programming Interface (MAPI) Tools

MAPI / RPC is the standard protocol that Outlook uses to support Exchange servers. Since it’s documented and available through a variety of APIs, other Windows applications can make use of it. For example, “MAPIGET.EXE”, one of the utilities highlighted in Mandiant’s 2010 report on APT1, connects to Exchange servers via MAPI and stolen NTLM credentials to harvest a targeted account’s messages and attachments. For systems that have Outlook installed, scripting languages such as VBS and VBA can also utilize its MAPI namespace to interact with an inbox and retrieve e-mails – though subject to controls that can vary based on the version of Outlook installed and its settings.

From a network monitoring perspective, note that MAPI’s use of RPC results in clients connecting to Exchange servers using a broad range of high-numbered ports, rather than a single fixed service port. If Exchange is configured with the “Outlook Anywhere” feature, clients can connect via RPC over HTTPs port 443.

Would Encryption Help?

Many MAPI-based tools will simply retrieve S/MIME encrypted messages as the “smime.p7m” attachment. As previously noted in our other scenarios, if the attacker is operating on the victim user’s own endpoint and has sufficient privileges, they can access the Windows certificate store.

How Could Tanium Detect This?

The Established Connections and Trace Network Connections sensors can produce stackable output that lets analysts immediately compare the name, path, and hash of any process that connects to Exchange server addresses and port ranges. Analysts can further drill-down with Trace Executed Processes to obtain the command lines and ancestry for any suspicious events. Monitoring this data can allow an organization to spot rogue applications that are attempting to communicate with e-mail server infrastructure.

Stealing Local Outlook Mailbox and Archive Files

Nearly all Outlook users are familiar with the application’s offline and archive mailbox features. From an attacker’s perspective, these are like any other file on the endpoint – they can be copied, archived, and transferred using native operating system commands or using features common to many backdoors. Two limiting factors may be the size of these files, and whether the user has elected to password protect them.

Would Encryption Help?

If you’ve read this far, you’ve probably already guessed the answer. If the attacker has access to the victim’s Outlook archives on their own PC, they probably can access anything in the Windows credential store or use keylogging or other techniques to retrieve other credentials.

How Could Tanium Detect This?

The Trace File Operations sensor can be used to build a filtered search or dashboard that tracks the creation or modification of Outlook mailbox files in atypical locations – or by outlier processes. Likewise, Tanium’s Index Query sensors can search for mailbox files at rest across the enterprise.

Keystroke Logging and Screen Scraping

Any malware running under a sufficiently privileged context on an infected system can record all keystrokes and periodically capture the contents of windows or the entire screen. Many of these tools can be configured to only capture data that matches attacker-configured patterns or from specific applications or window titles. The contents of any e-mail viewed by the end-user could be exposed in this manner. Of course, this approach is not ideal if the attacker wishes to quickly harvest a large volume of e-mail, and is limited in scope – each victim user’s system must be infected, and the malware may capture a significant amount of extraneous data over time.

Would Encryption Help?

No. If it’s on screen or typed, it’s exposed.

How Could Tanium Detect This?

There are countless ways to implement backdoors, keystroke loggers, screen capture / scrapers, and other related malware – so there’s no single technique to detect everything. However, I’ve often found that analyzing persistence mechanisms is an effective way of tackling such malware’s lowest-common denominator. If the attacker wants to harvest data from an endpoint over time, their malware has to survive reboot.

Many Tanium customers make use of our persistence-related sensors, such as Autorun Program Details, Trace Loaded Drivers, DLL Load Order Hijacking Search, Service Module Details, and WMI Event Consumers to detect suspicious binaries and scripts across the enterprise.

Once an investigator has identified malware that produces keystroke logs or screen captures, they might also determine that it uses a consistent output file naming convention. The Trace File Operations sensor can help identify historical file operations that match a particular name or path format; the Index Query sensors can likewise find files-at-rest matching a pattern – or even a sequence of header bytes – anywhere on disk.

Other Methods and Closing Thoughts

This post only scratches the surface of ways that attackers can steal e-mail from a victim’s computer or a compromised enterprise network. Additional techniques include:

• Configuring Exchange to surreptitiously forward a user’s e-mails to a third-party address
• Users intentionally forwarding their own mail to a personal e-mail address that is subsequently compromised
• Browser exploit frameworks, such as BEEF[3], that can covertly monitor webmail activity and other in-browser data.
• Targeting internal software used for internal e-mail archiving (i.e. for litigation and audit support)
• Deceiving victims into utilizing a malicious mobile application that impersonates legitimate e-mail clients
• … and countless more …

Securing enterprise e-mail, like any other asset, requires careful threat modeling. Consider that attackers will typically pursue the path of least resistance to achieve their objectives – so every avenue of attack isn’t necessarily a likely or practical vector that requires equal investment in countermeasures.

In a typical flat Windows network, localized compromises on a handful of systems can quickly blossom into a more significant domain-wide breach; on the other hand, infecting individual users of interest may be “good enough” for an intruder interested in a narrower scope of data. Likewise, message encryption isn’t a panacea for all of these attack vectors. But it can force an attacker into operating through a narrower set of victim systems, rather than facilitating opportunistic access to any account’s messages from any pivot point on the network.

The breadth of available techniques to steal e-mail are staggering, and it’s not just high-visibility targets faced with this threat. Comprehensive endpoint visibility to detect and combat them is the best way to ensure your e-mails stay secure.

[1] https://github.com/officedev/ews-managed-api

[2] http://stackoverflow.com/questions/4454165/how-to-check-an-exchange-mailbox-via-powershell

[3] http://null-byte.wonderhowto.com/how-to/hack-like-pro-hack-web-browsers-with-beef-0159961/

---

About the Author: In his role as Tanium’s Chief Security Architect, Ryan Kazanciyan brings more than 14 years of experience in incident response, forensic analysis, and penetration testing. Ryan oversees the design and roadmap for Tanium’s Threat Response offerings, and leads the Tanium Endpoint Detection and Response (EDR) team. Prior to joining Tanium, Ryan oversaw investigation and remediation efforts at Mandiant, partnering with dozens of Fortune 500 organizations affected by targeted attacks. Ryan has trained hundreds of incident responders as an instructor for Black Hat and the FBI’s cyber squad. He is a contributing author for “Incident Response and Computer Forensics 3rd Edition” (McGraw-Hill, 2014). Ryan also works as a technical consultant for the television series “Mr. Robot”, where he collaborates with the writers and production team to design the hacks depicted in the show.