Exchange and the Turla LightNeuron Attack
Another Day, Another Attack
May 7 brought news of an attack on Exchange (on-premises) servers by Russian hackers. The attack uses a transport agent and is the first known of its type. Before anyone gets too excited, it’s important to underline that the attack can only happen if an Exchange server is already fundamentally compromised.
Every message passing through an Exchange server goes through the transport service. Having a single pipeline means that you can have confidence that every message goes is processed in the same way, including passing through all installed transport agents, which can examine and update message properties. However, it also means that if an attacker can introduce a transport agent, they have access to every message.
In the past, transport agents were used for purposes such as the enforcement of ethical firewalls or to apply auto-signatures to outbound messages. The introduction of transport rules in Exchange 2010 removed the need to use transport agents in many cases, but some examples still persist and agents are supported in all current versions of the product (here’s the API documentation).
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Exchange Online doesn’t allow Office 365 tenants to install transport agents, so this avenue of attack is closed off in the cloud.
As explained in a very thorough analysis by cyber-security firm ESET, Turla, a cyber-espionage group with a history of attacking high-profile targets, created a transport agent (LightNeuron) sometime around 2014.
To get the transport agent onto a server, the attacker must copy a DLL called Microsoft.Exchange.Security.Interop.dll to the /bin directory under the Exchange root. They then install and enable two transport agents from the DLL. The agents are called “Security Interop agent” and “Content filter agent.” Neither name would attract much attention unless you were looking for something specific.
Before they can install anything, the attackers must have privileged administrative access to the server. In other words, a fundamental security breach has already happened.
The presence of the DLL in the \bin directory or the agent in the list returned by the Get-TransportAgent cmdlet are obvious signs of infection. However, it’s fair to ask how often server administrators check one file among many in the multitude installed by Exchange on a server or examine the list of transport agents configured on servers.
The details of what the malicious agent does are explained in the ESET analysis. I won’t repeat them here. One interesting aspect that caught my attention was the use of a file named Winmail.dat, a file well-known to all Exchange administrators, to hide an encrypted configuration file. The intention of the agent seems to be to capture messages for specific named users. However, the configuration file allows for customized actions for each user. ESET believes that the attackers copy the captured messages via another backdoor.
Another interesting technique is the use of steganography (the practice of concealing instructions in files) to allow the backdoor to receive instructions in messages containing PDF and JPEG content.
A Microsoft spokesperson said that “an attacker would need to have administrative access on an Exchange server as a member of the Exchange Administrator group in an organization’s Active Directory. Exchange Administrator accounts are tightly controlled, and membership cannot be obtained by persuading a victim to click through a security warning or elevation request.”
In other words, it’s your own fault if you allow your network to be penetrated to such an extent that an attacker can take control of a tightly controlled administrator account that can install transport agents.
Given that attackers must gain privileged access to a server before they can install the necessary files, the only mitigation is to make sure that privileged access is secure. In other words, it’s belt-and-braces security 101.
Another thing to remember is that non-standard transport agents must be reinstalled following an upgrade to a new version of Exchange (for instance, from Exchange 2016 to Exchange 2019). Alarm bells might just go off when administrators inventory the third-party software running alongside Exchange in preparation for a migration. Installing a cumulative update on an infected server won’t do anything to fix the problem.
Even if alarms don’t sound when you prepare to deploy a new version of Exchange, the installation of the software on new hardware will eventually result in the removal of the bad transport agent when the servers the agent is installed on are decommissioned. Of course, your network might still be compromised and invite another visit from the attackers unless you fix that problem.
Probably Not Many Servers Affected
The attack is interesting because it uses a new technique. I hope and doubt that many servers have been infected in this manner, but it’s certainly wise to review Exchange server configurations to look for any unexplained transport agent. After all, if you can’t explain why a transport agent is present, should it be there?