Back to BlogDetecting Breaches in the Cloud
Over time, more and more assets and environments are being moved to different areas of the cloud. Whether it is a major service like Azure, AWS, or GCP or smaller companies who may use those services in the background anyway, many times security teams aren’t exactly sure where to even start when applying cloud breach detections for common attacks. Leaving many potentials for cloud breaches to happen.
Where to Even Start: Cloud Inventory & Logs
To start off, an inventory of what cloud services are already being used in an environment should be obtained. Sometimes it is only mail that is cloud-hosted. Other times, an entire environment could be cloud-based, using two-factor authentication (2FA), mail, document storage, server infrastructure, etc.
After an inventory is taken, ideally the proper logs need to be generated and exported to a SIEM for central log management and alerting. Blumira has several guides on sending logs from different cloud environments, including platforms like Duo Security, Google Cloud Security, Azure Active Directory and more in our Integration pages. Many times there are extra security services and licenses that cloud providers will offer as well that include additional configuration.
Mapping detections to a specific standard such as CIS (Center for Internet Security) Cloud or the MITRE ATT&CK Cloud Matrix are great starting points.
Cloud Detection Examples
Inbox Rule Creation
Attack:
The creation of inbox rules can be a sign that an email address has successfully been breached. In this example below, a rule has been created that deleted the emails from the “sent” inbox as to not alert the user that their account was being used to send out mass amounts of spam. Attackers will create this as a method of defense evasion to be able to continue using the account as a spam relay for as long as possible.
Configuration:
In this example, Office 365 is configured to send logs via their Audit Log API. The raw log is passed over with an operation of “New-InboxRule” along with other fields, including what user created the rule and what the rule name is.
Standard:
This cloud detection maps to the following security industry standards:
Failed Attempt at Single Factor PowerShell
Attack:
In Microsoft Azure, it is possible to run administrative commands as well as automations via a remote PowerShell connection to the environment. This is an easy path for attackers to exploit as there are not as many safeguards in place for access by default. With the addition of multi-factor authentication, the configuration would put another step in place for a potential attacker to break through, however, it is still a very high-profile target with the amount of access it provides.
Through this connection, an entire Azure environment can be managed, including any applications, virtual machines, accounts, settings, and key vaults. In this attack example, we see a third-party penetration tester attempting to sign in using PowerShell to an account that does not have multi-factor authentication configured.
Configuration
Using Azure Event Hub will enable a large amount of Microsoft services to relay through all one log connection. In this case, the Azure connection logs are flowing through Azure Event Hub. We see an auth_factor_type of “singleFactorAuthentication” along with a description of “Invalid username or password or Invalid on-premise username or password.” Additionally, the client connecting will show PowerShell or Azure CLI.
Standard:
This cloud detection maps to the following security industry standards:
Plaintext Passwords
Attack:
Grabbing passwords from plaintext files is less of a direct attack, and more of an attack of opportunity. Even with proper user education and policies around storing plain text passwords it will still occur. It’s possible that users may inadvertently store them in their Google Drive or elsewhere. Many assume that they are safely contained behind their login.
G Suite makes it easy to detect passed on keywords in document titles. Not surprisingly, many times the saved passwords are in documents that are named for just that. In the below example, we see a user that had created a document named “Wifi password” to store just that.
Configuration:
For this configuration, GCP (Google Cloud Platform) gives us the ability to fetch logs from their API as well as by using service accounts. Look for data such as the document title and document owner. Words such as ‘password’ or any other words that may be of use can be detected.
Standard:
This cloud detection maps to the following security industry standards:
Risky Sign-Ins
Attack:
Risky sign-ins to different cloud environments is something that should be alerted on. Attackers can come from different geographical locations during an attack. If they are able to successfully log in, they will then have access to known good credentials as well as whatever assets that account may have access to. Below is an alert from Azure Identity Protection that was flagged as compromised.
Configuration:
Several different cloud and non-cloud products have already configured alerts based on geographical anomalies. Where geolocation data is available, it can be leveraged to compare current and prior logins. This is used to calculate the amount of time that would be physically possible to travel between the two points on the map. Many cloud offerings will calculate this on the backend to provide you with a finished alert as Azure does. Other cloud offerings will pass a timestamp and latitude/longitude which then involves more work.
Standard:
This cloud detection maps to the following security industry standards:
- MITRE T1078.004
- CIS Control 16: Account Monitoring and Control, Sub-Control 16.13: Alert on Account Login Behavior Deviation
Learn more about Blumira’s Cloud Security Monitoring and sign up for a free trial of Blumira’s cloud SIEM.