Outlook Web Access based attacks

Published: 2017-08-12. Last Updated: 2017-08-12 06:26:00 UTC
by Mark Hofman (Version: 1)
7 comment(s)

Recently we've started seeing some attacks that utlise OWA. A person in the victim organisation sends an email to one or more of their customers informing them of change in account details. The attacker provides instructions to customers on paying their account utilising the new account details. The email is cc'ed to other internal staff adding a level of legitimacy (also compromised accounts).  

How is this achieved. Seemingly through OWA. A user's userid and password are compromised. The attacker logs in via OWA and monitors emails as well as appointments.  When the user is away to a meeting, the attacker logs in, sends the account change email and then deletes the email from OWA (sent items, deleted items and often including the 30 day store outlook uses for deleted emails). The cc'ed emails are similarly deleted. The customer pays funds into the new account which is controlled by the attacker.

The attack is quite subtle. Companies often do not notice until they request payment from the customer who then provides evidence that they have already paid and that they were requested to change the payment account. The internal staff member will deny having sent the emails. Which they did not. 

The challenge with OWA is that it often needs to be available via the internet and the userid and passwords used to log in are from Active Directory. So your staff email and your organisation is protected by the passwords your users select, or your service desk issues. Using this avenue brute forcing passwords via OWA is not difficult, neither is accessing email once the password is known it is a waiting game to determine the best approach to transfer funds.   

From the protection perspective if you can add multifactor authentication to OWA consider doing so. The usual "use strong passwords" also applies.  

On the detection side you may have your work cut out for you. You should be able to see the login requests in your logs. They will show up as login type 3 requests from the OWA server. Simple counts should show any brute forcing attempts. However, as the attacker will be logging in as other people the one thing you may need to start looking for is multiple users logging into OWA from the same IP address. As well as IP addresses that are not normal for your staff. If you are using load-balancers or reverse proxies you may need to do some voodoo to pass through the original IP address to allow you to trace the origin IP. You can also look for logins to OWA for users who are currently logged in at their workstation.  

Exchange logs will show you the messages they send, but it will only show that the internal user sent the email, which unfortunately does not help that much.  

Happy hunting. 

Mark H - Shearwater 

(shout out to my Hyderabad sec511 class who are currently doing the final day capstone)

Keywords:
7 comment(s)

Comments

We've seen several of these recently using compromised Office 365 accounts. The attacker jumps into the middle of an ongoing conversation asking whether the funds for a home sale can be wired to the title company a few days early because of maintenance at the bank. The response is in the affirmative. The attacker then sends a PDF over with the new wire instructions and includes a couple of PDFs "because I'm not sure if I sent these already", PDFs that are part of the loan package. That's the attempt to prove legitimacy and also proves they have access to a lot of emails containing other confidential data.

The only clue so far is that the X-Originating-IP in the Outlook 365 header is from a different country. The title company, not seeing any emails in Sent or Inbox because the attacker deleted them, claims the emails were just "spoofed".

If an Office 365 admin could post detailed instructions on how to tell these companies where to look in the Office 365 logs to see what IP address actually logged in, that would be great. "We pay Microsoft to manage our email" is the usual response.
When we migrated from Exchange 2003 to 2010, external access to OWA was disabled. It's available internally only.
If you need access to work emails from outside the office, you need VPN access (with two-factor authentication) or a dept-issued Blackberry.
What I have heard discussed is to go to the security portal on Office 365 and look for logins from unusual places. Searching for logins from places where you don't have a presence can be very informative. I know people who have detected anomalous behavior from Nigeria that was an indicator of compromise. Check with the user through a secondary method to validate if it was them. (i.e. call their cell phone on record or their manager).

Multifactor Authentication is a must for OWA and Office 365.
The Audit Log Search under protection.office.com/#/unifiedauditlog should provide information of both the malicious logins, and provide evidence of the 'deleted' comms.

Don't forget to cross-reference the attacker' IP address across your whole estate to ID additional compromised accounts.
Of course, another way to detect this activity is to configure active directory password policy to lockout the account after X attempts (maybe 10, or something more stringent if allowed within your organization...), and then to monitor lockouts. Quick conversation with the user can determine if the lockout is legitimate.
Here's the Microsoft TechNet article about enabling Office 365 mailbox activity audit logging: https://technet.microsoft.com/en-us/library/dn879651.aspx

A few important notes about that:
1. Activity auditing is turned OFF by default on all mailboxes. The article gives PowerShell code for enabling it.
2. Turning on the default level of activity auditing does NOT include activity performed by the mailbox owner (i.e. logged on with the user's credentials). There's another PowerShell command for enabling that, and you need to specify which activities are logged: Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditOwner Create,Move,MoveToDeletedItems,Update,MailboxLogin,HardDelete,SoftDelete
3. There are limitations to what activities are logged. In particular, mailbox owner logons are only captured for POP3, IMAP4, or OAuth.

And here are some unfortunate lessons my organization just learned through a dynamite phishing campaign last week:
1. Web-based mailbox authentication sessions can remain active for up to 24 hours (ActiveSync, OWA for Mobile, OWA, EWS). Changing a user's password may be ineffective if those protocols are still active. You have to disable those protocols to fully cut off attacker access.
2. Attackers with user credentials can enable forwarding to external addresses AND add delegate permissions to mailboxes. Be sure to review and reset these on any suspect mailboxes.
3. EWS mailbox access does NOT appear to be logged. Consider disabling EWS for all user mailboxes, except where required for programmatic (REST API) mailbox access.
4. Don't count on getting an forensically-useful data from the activity audit logging. If you had access to your Exchange server's IIS logs in the past, you could almost re-create the fully user activity story; Office 365 Activity Audit Logging doesn't give you enough detail to do that.
5. Check out the Azure Active Directory admin center. The "Risky sign-ins" report may help you with early identification of suspicious activity.
When it comes to detecting suspicious logons it helps a lot to ship the logs to an external server and geoiptag them.
Your can then build lists and sort per day to check if a user has logged on from a new country today.
I seldomly see reuse of evil ipaddresses.

Diary Archives