Originally Posted by Avonosac
I don't know why you're jumping to conclusions. To process authentication while on the server the credentials will have to be in plain text at some point, or essentially in plain text because the attacker would have access to the salt, salting algorithm and the key for whatever encryption scheme they were running. The attack placed a DLL on the server, it would be super easy to do some AOP pointcuts around the normal functionality and just decode the creds.
Exchange servers use NTLM.
The client then uses the password hash and the nonce to build the digest response. Thus the server side of the transaction does not need access to the client's original (clear text) password in order to recompute the digest and verify that the client has knowledge of the password.
It does not at any given point use plain text.
In addition, the
malicious OWAAUTH.DLL also installed an ISAPI filter into the IIS server, and was
filtering HTTP requests.
This enabled the hackers to get all requests in cleartext after SSL/TLS decryption.
First they say the server gets http traffic (which it doesn't actually). To decrypt that traffic they need access to certificate with private key and not the isapi filters in IIS. And even then decrypting that traffic would not give them any plain text credentials.
This is bogus information.
They could have used ISAPI filter to force everything to http traffic, that would break the IIS however.
Also public facing CAS is still port filtered on firewalls and uses only 443 for access.
Internal CAS would need to undergo more changes/configuration to accept http for owa access.
And both of these require the backend exchange configuration to accept basic authentication in first place to actually not being exposed within half an hour.
Edit: Apparently there is something that can be done with ISAPI filter. However the exact paragraph was copy-pasted from dell secureworks report from two month ago.
The following tools appear to be exclusive to TG-3390:
OwaAuth web shell — A web shell and credential stealer deployed to Microsoft Exchange servers. It is installed as an ISAPI filter. Captured credentials are DES-encrypted using the password "12345678" and are written to the log.txt file in the root directory. Like the ChinaChopper web shell, the OwaAuth web shell requires a password. However, the OwaAuth web shell password contains the victim organization's name. More information about the OwaAuth web shell is available in Appendix C.
ASPXTool — A modified version of the ASPXSpy web shell (see Figure 6). It is deployed to internally accessible servers running Internet Information Services (IIS).
Also some other posts calling their bs and them changing "fact" from their report.
http://eightwone.com/2015/10/08/owa-hack/Edited by DiNet - 10/9/15 at 5:21am