How were we Hacked? Part 2

How were we Hacked? Part 2

I wrote recently about how Office 365 accounts are most commonly breached - through leaked credentials.  This covered the different ways that credentials can be breached through various factors, including many human misconceptions and failures can be mixed with other internal and external forces.

This article is going to cover the anatomy of what happens after the hacker has gained access.   There are many things a hacker may be seeking including information extraction or means of corporate espionage. However, we are going to focus on a more typical example of financial gain.  It covers what they want and how they manipulate both the mailbox and the interacting people to engineer the gain.

Here are our (new) bank details - Please pay

I’m basing this story on a real case that happened to my mate's company. It surrounds a typical business deal 'X' where we, the vendor, are selling (and invoicing) a product to our client.  

1)  PICK THE RIGHT MOMENT

The conversation has been going on for some time, over and back, between the respective parties and deal has been arranged but not yet paid.  At any given time there might be a number of these deals ongoing, so it's not hard for hackers to pick one to enter at the right time.  The hacker, who often can lie undetected for some time, monitors the hacked mailbox, read the emails about deal X, and waits for the right moment to strike.  In this case, when the deal was about to close. The client is expecting an invoice, but the vendor has not yet issued it.  

2)  THE NEW INVOICE LOOP

The hacker sends an email from the mailbox to the client asking them to pay the invoice but requesting can it be paid to a different bank account (theirs). However, before they send this mail, they first ensure the interception of all new queries coming back from the client. These interceptions keep the vendor in the dark while the attacker can simultaneously pretend to be the vendor and ease the client’s concerns.  

3)  CAPTURE AND CONTROL THE CONVERSATION

The hacker may use many different inbox rule combinations to control the conversation and ensure that only they and not the vendor receives the client’s responses.  In each case, we will note the inbox rules and the mailbox action that may pinpoint the attack. you can retrieve the audit of these from the Mailbox Audit Log or the Universal Audit Log

INBOX RULE COMBINATIONS

1. Move to an obscure folder.  Inboxes contain multiple folders, some of which we never look at, let alone open.  The “RSS” or “Archive“ folder, for example, maybe a perfect place to hide a mail which the attacker can then later read and react to.  An attacker may set up a new move rule so that all mail coming from the client and where the subject contains “Invoice” to be moved (not copied) to such a folder.  The hacker may then log in periodically to check this folder for such client responses and respond directly.  
2. Tell-Tale signs:  Obviously we should look for move rules to strange folders by checking for them directly or their prior creation (Mailbox action: UpdateInboxRules), or the moving of the mail (Mailbox action: Move). Besides this, we would look for log-ins (Mailbox Action: MailboxLogin) and mail reads (Mailbox Action: MailItemsAccessed)
3. Forward it externally.  The attacker may want to minimize the number of times they enter the mailbox and risk exposing themselves to detection.  An external forward or external redirect can be used in conjunction with move rules or on their own.  In this hack, it may be used to notify the attacker that they should act.  
4. Tell-Tale Signs: a forwarding or redirect rule to an external domain is required here. (Mailbox action: UpdateInboxRules).  These rules are often flagged as very dangerous, or downright not allowed in some organisations.  As such hackers may avoid them for fear of detection.  Here we simply look for the creation or presence of the rule where the destination is not our domain(s)
5. Deletions.  These can be important to ensure that mail is never seen by the intended recipient at the vendor and that the new outbound mails to the clients from the hacker are not present in the sent box.
6. Tell-Tale Signs: Deletions may be done manually by the hacker after the mail is sent however we can look for such events with Mailbox Action: HardDelete, SoftDelete

4)  HIDING INBOX RULES

A strange and worrying loophole can be exposed in Office 365 where attackers can hide inbox rules.  This may seem elaborate when you read the documentation of how it is achieved however we have seen this in the wild with clients.  I will blog on this soon in more depth.

5)  QUERYING THE NEW BANK DETAILS

This part is all down to the client and relies on the client’s procedures around verifying new bank details.  The attacker will hope that the client is unwitting and simply respond to the email with any queries about the new details.  The attacker will then use their charm, and information gleaned from previous conversations to convince the client that all is well.  In my friend’s example, the client took the due diligence to call the vendor and asked them if the details were all in order.  Unfortunately for all involved, the call was received by the very busy account manager who, thinking the query was innocuous, and that the invoice must have been properly issued by one another employee, simply dismissed the caller saying the details were correct and to just process the payment.  I guess he was eager to close his deals.  

6) PAYMENT AND AFTERMATH

The money was paid to the hacker.  Ouch!  Later the vendor and client figured out what had happened after much blaming of each other.  The money was not retrieved and the vendor agreed that they both were complicit and to meet the client halfway splitting the loss.  

Conclusion - What can be done

It is clear here from the last paragraph that this type of breach requires not only the engineering of the mailbox configuration but also the engineering of human weaknesses or weak procedures.  The fact is that even given good procedures around payment handling, a skilled attacker may still engineer a win at some point.  A business cannot afford even one of these payments to go missing regardless of who pays (client or vendor).

Naturally prevention is best.  Secure your people and accounts properly.  However breaches still can happen.  The above steps list a number of rules and audit events that can detect the incident.  Such auditing is usually only performed after the fact during incident response  or using our product.

Be Proactive - Octiga Office 365 Detect to the rescue

Timely Knowledge is key. After the fact is too late to save the business from such a loss. Octiga's detect feature can find and alert to these incidents in real-time. Stay tuned for upcoming details and contact us to access our free to use “Early Adopter” program.

Stay Safe!