Skip to main content

Insights from Incident Response: The Common Denominator

Insights from Incident Response

Networking & security

shutterstock 544159486
Alex Lewis

Alexander Lewis

Cyber Assessment Services Technical Practice Lead

Over the last 18 months, Softcat have offered its customers an Incident response service. We’ve recently looked back at the different interactions we’ve had with customers in this service, and we found a raft of lessons learned, as well as a single common denominator across incidents: Office 365.

Now to be clear, this common denominator is not the platform itself. Although not without its own vulnerabilities, the root cause of the issue consistently found across incidents was the user configuration of O365. Looking over the array of customers, industries, and incidents, we found our customers usually fall into 1 of 3 categories when it comes to security incidents within Office 365.

The ‘Default’ Customer

Being transparent, configuring Office 365 for optimum security is easy for me to say, and not simple to do. These customers will initially migrate to Office 365, and, for the most part, stick with default settings, owed either to diverted attentions, or lack of expertise. Unfortunately for these customers, the chances of survival in an incident, if they’ve not configured baselines, or additional controls is close to zero. Here’s why.

One of the first steps an attacker will take is called reconnaissance, and before O365 this meant understanding which version of exchange, Active Directory, etc. you were using, to then understand the potential vulnerabilities available to them for exploit. In the days of Office 365, any attacker with a credit card and a keen attitude can spin up an instance and for these first customers, the reconnaissance is done. Attackers are standing up instances just like you, they know what will and will not work if enabled by default. Of the incidents we’ve seen, 70% of customers fall into this category.

Here we are regularly seeing some simple steps being missed such as multifactor authentication (MFA) not being deployed. To reiterate – deploying MFA is a security must, and has been shown to block 99.9% of account compromise attack. The number one reason for not deploying this control is concern about potential user disruption, or concern over systems failing. Whilst a legitimate concern, with the right preparation and the correct amount of user training, MFA can be deployed relatively painlessly and mitigates a huge amount of risk.

The ‘Intermediate’ Customer

These customers build on the above – after migrating to Office 365, these customers get the basics right – deploying MFA, some security controls, and even some of the solutions provided within E5 licencing. Additionally they may have one or two other security controls deployed, such as switching

on advanced logging. These customers make up approximately 30% of incidents we see. The challenge here is that customers are lulled into a false sense of security under the belief that “the controls in E5 are good enough.” Sadly, defence in depth architecture, and in our own experience of dealing with incidences you ideally need two- three additional layers to survive email-based attacks. Whilst having steps such as DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) are both good controls, these only look at the header – the envelope of the message. To survive email-based attacks the key is content based email security inspection.

Another trend we’ve found in the ‘intermediate’ customer is that of visibility. Whilst the deployed controls are all well and good, it only works if solutions are available that raise alerts, and that technicians are actively looking at and acting on those alerts. Broadly the key visibility can be grouped into three areas:

  1. Visibility of Vulnerabilities – as previously mentioned, whilst an excellent platform, Office 365 is not without its vulnerabilities. For example, just under a year ago there was a brief vulnerability wherein there was no filtering within Simple Mail Transfer Protocol (SMTP) routing within same geographic Microsoft instances. Whilst quickly resolved, customers need visibility of these to react appropriately.
  2. Visibility of Suspicious Activity – more and more we’re seeing attackers using legitimate infrastructure to cloak their nefarious activities – across multiple incidents we’ve seen attackers stand up valid Azure services with signed Microsoft certificates to appear legitimate. Whilst not the easiest to detect, the best defence is to have a solution enabling alerting, and if necessary, quarantining of suspicious emails for multiple factors.
  3. Visibility of Attack Methods – one element we see time and time again is that of outlook forwarding rules. As soon as an account is successfully compromised, it is commonplace for these to be configured to give the attacker visibility of all communication whilst remaining relatively silent. It is one of the less thought of methods of data exfiltration, but with the prevalence of email-based threats, it can be hugely valuable to be on the lookout for this.

The ‘Mature’ Customer

This customer has everything switched on and optimised, and operate, for the most part, a reasonably secure infrastructure. Unfortunately the challenge now presented is that of business email compromise (BEC) between trusted organisations. Unfortunately this one is really difficult. The focus here is all about supply chain security, which is an issue that cascades. Whilst you may be happy your supplier is secure, the supplier of your supplier, could be vulnerable.

For these customers, the key comes down to the devil of Active Directory. As mentioned before, if you have not configured MFA across the domain you have a very large attack vector exposed, but we’ve seen attackers go further even when MFA is deployed. Active Directory Federation Services (ADFS) essentially serves as the proxy between active directory and the web. Some attackers, when realising you run MFA in Office 365, will look to find an intranet site, or portal etc. that uses ADFS, but doesn’t use MFA. Then it is just a question of brute force, credential stuffing etc. until the account is exposed. We’ve even seen attackers going after outlook web app, and other sites, to this effect.

The ‘Softcat’ Customer

For our customers, this doesn’t have to be the case. For Softcat customers (and I’m pleased to say, the customers that have utilised our incident response services) when it comes to security, and specifically Office 365, you have oodles of support available to you, detailed below:

  • Security Assessment – If you’re reading this, and thinking “I don’t know which of the three I am” or “I don’t think I’m any of those customers”, we can help. Our assessment services help you clearly and simply understand your security posture, and build a plan to get you to operational maturity.
  • Office 365 Configuration – we’ve got a large number of industry leading consultants available to help you understand your Office 365 environment, and to help you configure the platform securely.
  • Softcat Incident Response – if the worst happens, and you believe yourself to be compromised, get in touch. We will work with you to get you back on your feet, understand what, if anything, went wrong, and help ensure it doesn’t happen again.

If you’d like to discuss this in more detail, please contact your account manager, of If you’re new to Softcat, via the button below.