2

Attackers like to abuse Outlook for a variety of purposes. For example, an attacker could auto forward emails to a remote address or persist inside a network by creating client-side rules that execute a malicious program/script when a user receives an email. Is there a way to query the Outlook rules stored in Exchange in order to detect potentially malicious rules? Is it possible to block some some Outlook rules types (e.g. executing a program/script)?

tifkin
  • 288
  • 2
  • 7
  • 1
    Do you have any examples of this type of malicious activity? TBH, I've never heard of a hacker targeting Outlook or Exchange rules. – joeqwerty Nov 04 '15 at 16:17
  • I do it all the time as I do penetration testing :) There are other attack scenarios besides the ones I listed, but those are the easiest to understand. Rules are very nice from the offensive perspective as they can be used to trigger on demand access to a network, rather than having a backdoor that continually beacons out. – tifkin Nov 04 '15 at 16:20
  • 1
    @joeqwerty I've seen a client's Gmail account attacked via rules that forwarded and dropped emails from a bank address so the attacker could initiate a bank transfer undetected. I'd imagine similar attacks are done in Outlook. – ceejayoz Nov 04 '15 at 16:20
  • Yeah, I don't doubt that it's a potential target, I've just never heard of it before and am curious to see examples. – joeqwerty Nov 04 '15 at 16:32
  • While not used by commodity malware (yet), more advanced attackers will use them. Here's some public mentions of people using them within the security community: http://www.hexacorn.com/blog/2015/10/20/beyond-good-ol-run-key-part-33/ https://twitter.com/bufferzone/status/613643022249672704 – tifkin Nov 04 '15 at 16:43
  • I've seen a client that had all their mailboxes sending out spam links in signatures as a result of a hack. – Wesley Nov 04 '15 at 16:50

2 Answers2

0

In Exchange

In PowerShell (of course!), there is the somewhat handy Get-InboxRule Technet Link. I say somewhat handy because it can only query against a single mailbox.

  • This can be used to spot-check a single mailbox (Finance Users, Executives, users with privileged access, etc.)
  • It is also possible to use loops and pipes to iterate through an array, such as one from a CSV.

Since you are trying to detect specific types of rules (leaking information outside the organization), I would suggest you look for some specific rule properties.

  • DeleteMessage = True
  • ForwardAsAttachmentTo = (not null)
  • ForwardTo = (not null)

There might be others that are relevant to you. Use Get-InboxRule -Mailbox alias@domain.com | FL to list out all the properties, or reference the Technet article linked.

Not all rules are in Exchange. :(

It's true! Some rule types are in the Outlook client only. This link provides guidance on the rule types that would be more difficult to track down.

blaughw
  • 2,242
  • 1
  • 10
  • 17
  • Thanks. I've taken a look at the Get-InboxRule cmdlet before and unfortunately it only permits you to manipulate a limited number of rule types. In particular, it does NOT allow you to view the execute a program/script rule types. While some rules only run on the client side, the rules themselves are still stored server-side somewhere. For example, if you have multiple computers with Outlook installed and you change the rules on one of the machines, all of the other machines' rules with change as well. – tifkin Nov 04 '15 at 22:46
0

The best solution I'm aware of right now is to use the tool NotRuler. In addition, a half-baked solution is to pull out the binary blob where the rule action binary blob is stored(one example is found here using the Exchange Web Services Managed API) and run strings on the rule action's binary blob and look for any suspicious strings(running strings is a hacky way to analyze the binary block since the structure of the blob is not documented).

tifkin
  • 288
  • 2
  • 7