An insight into a hacked Exchange server

Matthieu Faou just wrote a whitepaper at ESET detailing the process where the sophisticated spy network Turla quietly exploited a backdoor in Microsoft Exchange servers that gave attackers unprecedented access to the emails of at least three targets over several years! The fascinating whitepaper is located here: ESET Lightneuron Whitepaper

Emails arrive on mobile device but not Outlook client

In a single AD Domain with an Exchange 2016 environment that was hosting multiple email domains, there was a power user that has several mailboxes with different email suffixes that would sporadically stop receiving inbound emails to his fully patched, Outlook 2016 client. (The 2013 client behaved exactly the same.)

The Exchange server system is a simple 2 server setup, the databases are replicated in a DAG array, with several different databases split out by company/department.

Exchange DB1

 

As you see in the figure, User1 has four different user accounts with four different mailboxes with different suffixes hosted on the same database, as he is from Company1, but needs to receive separated email to different mailboxes (reply with those unique email addresses), and authenticate separately.

After several hours of combing through the environment, and Microsoft support services unable to find anything amiss, one of the tests were creating a new Outlook profile, adding just one user account, and testing, well what do you know, it works! When a second mailbox is added to the profile, inbound mail stops to the client though. (Again, a mobile device receives the inbound mail immediately, but nothing occurs for the desktop Outlook client)

A hint on how to fix it came when I looked at User2. In this case, User2 also was opening up multiple mailboxes with the same clients, but there were no issues at all. As is evident, even though the mailboxes open from the same Exchange environment, the back end databases are separate.

After creating a new database for “@Othersuffix.com”, and migrating the User1 mailbox over to it, when that additional mailbox was opened in Outlook, mail flow continued!

The Exchange environment pictured has a lot more complexity, to end users it is completely separate, seemingly different Auth Domains, DNS, URLs, etc., but in reality is all the same back end infrastructure for ease of maintenance, (hint, KEMP is used to do a bunch of backward and forward URL rewriting) so adding some additional mailbox databases in the back end didn’t really complicate efforts too much.

Inside access to external NAT IP services

The corporate office has an environment where there is a separate “guest” network for vendors, visitors, etc. that can use their own devices, to use internet services through Wi-Fi.
Due to the fact some internal services are needed such as joining internal Audio/Video conferences, and access to collaborative services, we had a requirement that access to those services be available through this semi-public network that is “external”, i.e. uses external DNS resolution, but is still “inside” the firewall boundary as shown below.

Access from GuestNet-Diag

To spell it out, we had the following infrastructure:

  • Internal services only accessible from inside the corporate network and internal devices.
  • External services accessible from outside the corporate network.
  • Guest network with external/public DNS resolution.

The requirements are as follows:

  • Internal services accessible externally if secured with boundary extending services, primarily Microsoft Direct Access, or if explicitly approved, Cisco VPN software.
  • Skype for Business availability for Guest Wi-Fi to join conferences and collaboration.
  • SharePoint services (specifically Office Online Server) for collaboration access from Guest Wi-Fi.

Cisco has a good article here: https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html to make this process work, the D-NAT methodology was used, but the article can a bit confusing, so I just wanted to explain a couple things to clarify it, and show how the final NAT rules end up looking.

The following are the relevant NAT rules:

Access from GuestNet

  • For the Match Criteria:
    • Source is the Guest network.
    • Destination for the Skype for Business services is the “inside” DMZ interface, as in this case, the DMZ is sandwiched, has an internally facing network, and an externally facing network, or wherever the service resides, as some services are on the “services” network.
    • IP source is the Guest network object.
    • IP destination is the External IP of the service.
  • For the Action:
    • Source is wherever the service resides.
    • Destination is the Internal IP of the service.

I hope this helps clarify the Cisco article.

 

Broken ADFS! Service Unavailable – Error 503

Came in this morning to a lovely issue, ADFS authenticated services were completely unavailable! Office 365 archive mailboxes, hosted CRM, etc.

Upon testing the URL: /adfs/services/trust/mex a lovely “Error 503” was displayed!

Key prob 1

I changed the internal ADFS certs to use the new EKU requirements (Server and Client Authentication), verified NT SERVICE\drs and NT SERVICE\adfssrv had the correct permissions on the private keys, but still no dice for external usage.

After using my trusty bing.com, I came across this lovely Microsoft article about the KeySpec property for the Web Application Proxy server: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/ad-fs-and-keyspec-property

Checking the server’s keys using the Powershell command dir cert:/LocalMachine/My reveals the following problem:

KeySpec = 0

Ext Cert wrong

Ok, so the fix is easy right? Just export the cert to a pfx file, import it with

certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx

or as the article says:

certutil –importpfx extcert.pfx AT_KEYEXCHANGE

In this case, I got a lovely -importPFX command FAILED: 0x80090029 The requested operation is not supported. error message as shown:

Key prob 3

After looking around for a while, I remembered the article I wrote back in September 2017: LS Audio/Video Authentication Server Error 19008 – Private Key not found, went through that process, and what do you know, it worked!!

Ext Cert right

The URL: /adfs/services/trust/mex now works perfectly, and all services that depend on ADFS are up!