The new Microsoft Exchange vulnerabilities disclosed earlier this month highlight the importance of architecting for security visibility on the network.
At most organizations the communications between users and Exchange servers are encrypted. The initial malicious payload and web shells planted upon successful exploitation of these vulnerabilities also run across those encrypted channels, which means organizations reliant on common points of network visibility such as IDSes or proxies can only look for transient and easily-changed indicators of compromise like known attacker IP addresses.
Relying on purely endpoint-driven security to respond to major server-side compromises like these has its own set of drawbacks. Many organizations choose not to run security agents directly on critical servers for performance and stability reasons, and the list of exceptions recommended by Microsoft when running security software on Exchange servers is long enough that it can easily result in agents missing critical items. The web server logs that are being commonly used for detection of the current vulnerability are not only prone to being tampered with by sophisticated attackers, but also to bureaucratic problems between application and security teams that complicate proper response. Sophisticated teams will use the best of both endpoint and network-driven security technologies to balance out the issues each individual approach has.
Fortunately there’s a simple, well-proven architecture that can restore network security visibility for major production servers: terminating encryption on a load balancer or reverse proxy before reaching the Exchange server. This allows security or other monitoring systems to see all traffic in plaintext, while preserving privacy across the Internet. Unlike client-side man-in-the-middle decryption, which requires pushing trusted certificates throughout an organization and has problems with TLS 1.3, encryption termination has no client-side requirements and is unhampered by obfuscation of the certificate exchange process. This approach also has the benefit of reducing CPU load on application servers (by letting the devices in front of them do decryption) and improving service reliability for larger environments, so it’s a favorite of security, application, and network teams alike.
For those already running with the security visibility architecture described above, Suricata signature IDs 2847421 – 2847423, as well as 2847418 – 2847420, will detect compromise attempts against their Exchange servers; SIDs 2031812, 2009146, 2009147, 2009149, 2822303, 2017313, 2027393, and 2027341 will find some of the common web shells being dropped by successful attackers.
Those with Zeek data can look for a host of additional indicators outlined by CISA, as well as applying some of the proactive hunting techniques outlined in our Threat Hunting Guide to search for other malicious payloads dropped on compromised servers.
