Outlook Web Access based attacks
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)
Comments
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.
Anonymous
Aug 12th 2017
7 years ago
If you need access to work emails from outside the office, you need VPN access (with two-factor authentication) or a dept-issued Blackberry.
Anonymous
Aug 12th 2017
7 years ago
Multifactor Authentication is a must for OWA and Office 365.
Anonymous
Aug 12th 2017
7 years ago
Don't forget to cross-reference the attacker' IP address across your whole estate to ID additional compromised accounts.
Anonymous
Aug 14th 2017
7 years ago
Anonymous
Aug 14th 2017
7 years ago
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.
Anonymous
Aug 14th 2017
7 years ago
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.
Anonymous
Aug 24th 2017
7 years ago