We’ve spent a lot of time creating Ruler and turning it into, what we think, is a useful attack tool. The goal behind the project was to highlight the command execution potential around weak credentials when combined with Exchange and Microsoft Outlook. That goal has largely been met, with the ability to now demonstrate that compromising user credentials can be much more than “just” reading email. Microsoft has also been great in their response to the issue, with both client-side rules and forms having been effectively mitigated  through patches to Outlook.

Hopefully this also helped push MFA/2FA in organisations. Again, Microsoft has been great here with MFA on both Exchange 2016 and Office365 being rolled out and adoption being heavily encouraged.

One thing that has been lacking up to this point, has been an easy mechanism for administrators or responders to detect when Ruler  or similar tools may have been used against their organisation. As a general move towards better directly enabling defenders, we created NotRuler.

tl;dr NotRuler is a tool to aid in defence, and detect attacks through Ruler. NotRuler source and binaries: https://github.com/sensepost/notruler

A Hypothetical Use-Case;

This is all speculation and “what-ifs” – we have no evidence that this is actually the case

A prime example of the value of protecting Exchange access would be the Deloitte breach, where attackers were able to gain access to administrator email accounts. This would have allowed attackers to gain access to every mailbox in the organisation, which in turn could be backdoored using Ruler. This would or could go undetected for a long time and would not even require attackers to activate their backdoored accounts. As much of the reason for Ruler’s success is the synchronisation functionality built into Exchange, the backdoors would remain active in the user’s mailboxes over time and would even be resynced to any hosts that may have been reimaged post breach. At this point, the attackers would no longer need credentials and could send trigger mails to any of the backdoored accounts to restore their access to the internal network.

Should the responders want to determine if Ruler, or a similar tool, had been used, they would have no simple way to do it for each account. This is because the current Exchange administrator scripts do not provide insight into client-side rules, since client-side rules are stored as binary blobs on the Exchange server and the server is blind to what actions are performed by these rules. The same holds true for custom user forms, unless these forms are in organisation folders, we don’t believe it’s possible to easily extract them. One way that administrators could find information about possible Ruler backdoors, is to use Ruler itself. Currently Ruler has the “display” and “form display” functions built in, which could list all rules and forms associated with a users’ mailbox. The information returned would be limited, with Ruler only stating that those rules/forms exist and not what they do.

Great, this would allow some interrogation, but would also be extremely time consuming as each account would need to be checked manually.

NotRuler

Since Ruler already can display information about a mailbox and the changes that Ruler has made to that mailbox, it was be pretty simple to wrap a new interface around the Ruler library and provide a defensive tool.

Also Ruler has a little hidden feature no-one seems to spend time with, “–admin”. When this flag is specified, Ruler uses the provided credentials to log in as an administrator (given that the credentials had Exchange/Domain admin rights). With these privileges changing the targeted email address, Ruler would be able to log into any mailbox and impersonate that user.

Taking this functionality and inserting it into a loop, resulted in a rather nifty little defensive tool that allows you to supply a list of mailboxes to interrogate and detect backdoors.

When you run NotRuler, you can ask for information about either rules, forms or homepages (more on this in future post)

As a user, you can also do a “self check” to verify if your own account has been backdoored. This looks as follows:

 ./notruler-linux64 -k --mailbox john.ford@evilcorp.ninja --username john.ford --self rules

The great thing here is that it uses the exact library that Ruler does, so if any new attack is added to Ruler,  it takes 10 minutes of effort to add detection for that attack.

The output is not great at the moment and this should be expanded to allow CSV or similar formats. I’ve also not had the opportunity to test it against a significant set of mailboxes, in theory it should be fine. But feedback would be great!

NotRuler is OpenSource and available on Github, I would love some PRs: https://github.com/sensepost/notruler

Ruler IOCs

As a little bonus, we created a list of possible IOCs for Ruler. Maybe NotRuler doesn’t work for you, or you want to use your existing data to try find Ruler.

Canaries

Canaries are great, they are supposed to tell you something is wrong, so why not build them into Ruler? Since the first release of Ruler, these have been present. There are two canary values built into Ruler, which should allow defenders to parse their logs and identify some Ruler traffic.

User-Agent, the Ruler User-Agent is hardcoded to “Ruler” – thus parsing your webserver logs for Exchange should help you identify both brute-force attempts and actual exploitation via Ruler.

NTLM-Workstation, the Workstation value used when NTLM auth is required has been hardcoded to “Ruler” – resulting in this value ending up in your Exchange/Domain-Controller event logs. These will be authentication events 4776 (in Event logs for DC) and 4624 (in Event logs for Exchange). I’ve written two small Powershell scripts to parse event logs and flag these values.

Detect ruler in Event-log: https://gist.github.com/staaldraad/a7de22afa69ec10f1ec7d995d2bd913c

Forms

When forms are used, some data is written to disk. This can be used to identify Ruler/VBScript forms on the client-side.

For each form created, a cache entry is written to

%localappdata%\Microsoft\Forms

which contains a full copy of the form and all associated VBScript. You could parse this to get the Scripts used by an attacker.

Rules

The “rules” attack typically requires the use of WebDav for payload delivery. WebDav writes to disk, and this location should be monitored:

%systemdrive%\windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore

If you have any more Ruler IOC’s I’d love to hear about them and will update this post with them. We’ve added this list to the NotRuler repository as well, so please submit your pull-requests with updates.