As more organizations move to cloud infrastructures and SaaS software, it’s important that security teams have visibility into the user accounts accessing them. The established techniques that are well known on prem are still really dangerous since cloud services are built for anywhere, anytime access.
In fact, hijacked cloud accounts, or cloud “account takeover attacks”, are on the rise. The recent Verizon DBIR noted an increase in the use of stolen credentials to access cloud-based email servers. And these suspicious authentications are also a repeat top offender on our Rapid7 Quarterly Threat Report as well.
So why is this? In addition to the growing adoption of cloud infrastructure and software:
- One reason is the uncertainty of who owns what when migrating to the cloud. Many people incorrectly assume that the Cloud Service providers are protecting them end to end out of the box. This is unlikely to be the case. And this misunderstanding can create potential gaps in security that attackers can exploit.
- Secondly, the weak passwords that float around our on-premises environment, such as Password123 or Spring 2019, they are unfortunately following us into cloud accounts as well. Attackers can check open-source intel, like MX records, to determine an organization’s email provider, and then try common passwords across those accounts or phish for them.
- And really the other big reason we’re seeing an increase in compromised accounts is simply that attackers love the cloud. Your cloud is accessible from anywhere, and the parameters used to protect your on-premises environment will look different in the cloud. Azure Active Directory, for example, looks a lot different than your on-prem AD.
So what can you do to protect your cloud accounts?
- Let’s start with detection. The first step is visibility into the logging that’s available to you from the cloud service.
- In some cases, important logs may not be turned on by default. For example, when monitoring Microsoft services, a few valuable sources, like User Activity and Admin Activity, need to be tinkered with to ensure logs are flowing appropriately.
- While you’re at it, check the retention policy for those logs. Retention may be as little as 7 to 30 days depending on your subscription, so it’s a good idea to review your policy and check what yours is set up as now.
Once you have the appropriate logging turned on, you can begin sending that information to your SIEM. Some of the alerts and data you’ll want to look at include:
- Suspicious authentication — things like users logging in from locations not based near an office.
- Admin behavior, which can help identify anomalous behavior within these privileged accounts.
- And, ideally, threat intelligence applied to the logs. For example, many teams match employee emails to those exposed in third-party data breaches, and inform employees of any matches.
Once you have logs and centralized visibility inside of your SIEM, we suggest promoting awareness around compromised cloud accounts to your employees. To increase your defenses on the front lines, educate your employees on spotting phishing attacks, the importance of strong passwords, and what can happen when cloud accounts are compromised.
Want to learn more about staying protected with Rapid7? InsightIDR, our cloud SIEM, is built for your modern network to fully ingest data from cloud services and infrastructure, as well as your on-premises and remote environment. You’ll be able to reduce the risk of phishing and quickly identify when stolen credentials are used across your network.
That’s it for this week’s Whiteboard Wednesday. We’ll talk to you next time.
