Security operations · 7 MIN READ · ANTHONY RANDAZZO · MAY 25, 2021 · TAGS: Cloud security / MDR / Tech tools
Well, 2020 is getting smaller in our rearview mirror as our journey into 2021 takes us closer to summer.
Good riddance.
We’d be remiss, though, if we didn’t take some time to reflect on the things we observed and learned over the last year at Expel.
So, we decided to take a close look at the cloud threat landscape. While we can easily get hung up on the black swan events of the year, we took a more data-driven approach to find the greatest threats to the majority of orgs today.
At Expel, we view the cloud as any infrastructure, platforms or applications living in some data center that your org doesn’t wholly manage. This might be your Amazon Web Services (AWS) or Microsoft Azure cloud infrastructure; an O365 or G Suite tenant; your GitHub repositories or perhaps the Okta instance that manages identity to all of your end users.
During the COVID-19 pandemic, our SOC saw that bad actors wasted no time thinking of more evil ways to attack in the cloud and take advantage of people using phishing tactics.
See full “Top cybersecurity attack trend during COVID: Phishing” infographic
And the IC3’s 2020 Internet Crime Report echoes our findings.
It’s disheartening to see that attackers used a crisis to their advantage to infiltrate cloud apps and increase their phishing efforts.
But it’s also not surprising.
Bad actors will continue to evolve their tactics, using health and economic crises to manipulate unsuspecting people into surrendering their credentials and other information.
That doesn’t mean hope is lost. There are ways to remediate and stay resilient against the inevitable attacks in your cloud and phishing ploys.
In this blog post, I’ll cover the top three types of attacks we saw between March 2020 and March 2021, how to respond to an attack if it happens to you and share some steps you can take today to drastically reduce the chance of it happening to your business.
Attack trend: Business email compromise
If you’ve taken a look at our “Top cybersecurity attack trend during COVID: Phishing” infographic, you’ll know that business email compromise (BEC) is still public enemy number one.
Here at Expel, the scale tips favorably toward BEC incidents in O365 versus G Suite. And there’s one primary reason for that: O365 has some initial configurations that need to be changed by default, whereas G Suite’s settings out-of-the-box are pretty straightforward.
We previously covered these configurations but here’s the TL;DR:
With original deployments of O365 tenants, IMAP and POP3 were enabled by default in O365 Exchange as well as BasicAuthentication.
IMAP and POP3 don’t support multi-factor authentication (MFA), so even if you have MFA enabled, attackers can still access these mailboxes.
BasicAuthentication allows attackers to authenticate with clients past any pre-authentication checks to the Identity Provider which could lead to unwanted account compromises or account lockouts from password spray or brute force attacks.
Microsoft intended on doing away with BasicAuthentication by default but has postponed this rollout due to the COVID-19 pandemic. This is now expected to rollout before the end of 2021.
Google, on the other hand, disables these configurations in G Suite by default but allows them to be enabled ex post facto.
Remediation
What should you do if you identify someone that shouldn’t be in your O365 Exchange?
Fortunately, it’s pretty straightforward.
- Reset the user’s credentials;
- Review the mailbox audit logs to determine if any unsavory activity occurred; and
- Remove any mail forwarding rules (if applicable).
Resilience
There are quite a few things you can do to prevent these BECs from being commonplace in your cloud email.
First and foremost, ensure that you’re using MFA wherever possible.
While it’s not a silver bullet, it’s absolutely critical in today’s cloud-first environments. Our data infers that 35 percent of the BEC attempts we’ve spotted could have been prevented by enabling MFA.
Next, disable legacy protocols such as IMAP and POP3.
Again, these don’t support any sort of Modern Authentication (Modern Auth) which means an attacker can bypass MFA completely by using an IMAP/POP3 client. Once those are turned off, strongly consider disabling BasicAuthentication to prevent any pre-auth headaches on your O365 tenants. Seven percent of BEC attempts could have been stopped by enforcing modern authentication.
If you’re still not sleeping well at night, then consider implementing some extra layers of conditional access for your riskier user base. You can even create a conditional access policy to require MFA registration from a location marked as a trusted network. This prevents an attacker from registering MFA from an untrusted network.
Lastly, don’t neglect your secure mail gateway.
We recently helped a customer make some configuration changes that ultimately lead to a major drop in volume of phishing emails they received on a daily basis – reducing their BEC incident count.
Attack trend: Cloud access providers
If we remove the explicit BEC incidents, the next biggest target we see are cloud access identity providers like Okta or OneLogin.
While some attackers might just want access to your email for fraud purposes, others have their eyes on a bigger prize: the data behind your applications.
Many orgs already migrated to SSO (SAML) authentication, and this is especially the case in a post-2020 working environment where many employees work remotely.
Which means that attackers can hit more than just mail providers as an easy target to harvest credentials.
During 2020, we saw attacks on Okta quite a bit. So we’ll focus our remediation recommendations there.
So, how are all of these Okta accounts getting compromised?
A couple ways.
First, it’s entirely possible to intercept session tokens for Okta after MFA has been established.
We’ve talked about this tactic a bit in the past (and yes, U2F will prevent this). These session tokens can then be used to maintain access indefinitely depending on the refresh token and any limitations it might have.
But there’s an even simpler approach: hoping unsuspecting end users will click that push notification. You might be amazed at how frequently this occurs. And the results can be disastrous (we personally have over 50 published applications for certain users in Okta).
Remediation
Remediation after a confirmed Okta access compromise may be a bit more involved than a BEC limited to a single Exchange Online mailbox. Here are the high level tasks:
- Terminate the user’s active sessions to disrupt existing authenticated entities;
- Reset the compromised credentials; and
- Determine if an attacker accessed any published applications (hopefully not as this will require subsequent remediation and responses against those apps). We have a quick workflow here at Expel that will grab all of the associated SSO activity.
Resilience
Okta, in particular, has a feature called Adaptive MFA which creates behavioral profiles of each of your users and introduces a little bit of friction when an anomalous login occurs. This friction might be the difference between a compromise or not.
If you’re running sensitive applications in Okta, then you might consider applying application-level MFA.
Lastly, while we have become more distributed in a post-pandemic world, you might also consider implementing Network Zones to effectively develop an allow list for access in your sign-on policies.
Cloud attack trend: Cloud infrastructure
When we started theorizing where to focus detection efforts in cloud infrastructure, it was apparent that most risk lied on access within the control (management) planes.
It turns out that attackers are, in fact, interested in this sort of access.
Excessive access to the control plane opens organizations up to a bunch of problems and the reality is that all of the “shift left” security in the world doesn’t prevent the use of compromised credentials.
We know this access may be for financial gain or perhaps even persistent access. The good news is that there are a variety of ways to prevent this.
Remediation
Cloud infrastructure response can have a bit of variance given that they each have completely different Identity and Authentication Management (IAM) implementations.
In AWS, it’s a little more straightforward.
- Identify all compromised access keys. Some exposed or compromised access keys may happen en masse so it’s best to make sure you’ve found them all. This can be done by pivoting based on the attacker access indicators such as IP address.
- Snapshot and remove any new infrastructure created by the attackers.
- Determine if any data plane access occurred (i.e. SSH access to your EC2) and respond as necessary.
Resilience
Inadvertently exposed secrets can exacerbate this problem so it’s important to to get a hold over your public git repositories.
There are commercially available products to identify exposed secrets such as GitGuardian, or you can go at it yourself and use open source projects like truffleHog.
The good news is that repositories like GitHub delay the public API by five minutes to give organizations a head start to remediate these sorts of exposures.
Another thing to think about is subscribing to AWS Security Hub to develop your own use-cases for automated incident response, or again, you can run at this alone via custom Lambda, CloudWatch or even your own SOAR platform.
Another great AWS Organizations’ feature: develop least privilege access control with Service Control Policies to limit the blast radius of compromised credentials.
New attacks. New resources.
So what’s in store for us for the rest of 2021?
Well, we wish we had a crystal ball to say for sure but we can make some pretty educated guesses based on what we saw over the last 12 to 18 months.
Events like the SolarWinds breach reminded us that the cloud is absolutely a target (golden SAML in Azure) and that we need to stay diligent – and prepare for what might be around the corner.
While attacks in the cloud and phishing aren’t new, we know that bad actors will continue to get creative. And one thing is for sure: we’ll continue to see BEC attacks at the same volume or even increase this year.
Microsoft will hopefully roll out their more proactive controls such as deprecated support for BasicAuthentication for Azure Active Directory (AzureAD) in 2021. Although, it seems like it’s going to be at least a year before that comes to fruition for orgs that have mail clients actually using those authentication protocols with Exchange Online.
Fortunately, we’ll continue to see the development of resources and services that address new and changing security needs.
At Expel, we’ve been working on providing new products and services to help our existing and new customers endure the onslaught of 2020, and the new challenges it presented.
When our customers let us know that they were drowning in phishing emails, we created the Expel Managed Phishing Service. So, in addition to our analyst providing 24×7 managed security, they’ll also have eyes on every single email someone at your org reports as a potential phishing attempt.
While we can’t stop attackers from being cunning, we can use our expertise (as a community) to help each other not only keep our heads above water but also prevent getting blindsided again.
