By default, there are over 30 recommendations pertaining to database resources spread across Azure, AWS, and GCP. Quite often, the Cloud Security Admin who is spending time in Defender for Cloud isn’t the person responsible for the configuration or remediation of a database resource. If your Database Administrators are swamped with work (highly likely), the Cloud Security Admin needs to ensure that their asks of the Database Administrators have a high return on investment. With the combination of Defender CSPM + database protection plans, we can achieve that ROI with Attack Paths and Cloud Security Explorer.
Attack path analysis is a proactive cybersecurity approach that identifies and assesses potential attack vectors within IT environments. By simulating the behavior of an attacker, Attack path analysis allows security professionals to gain insights into the ways an attacker might exploit vulnerabilities or misconfigurations to gain unauthorized access to critical assets. Microsoft Defender for Cloud - Defender CSPM's Attack path analysis consumes telemetry data collected and stored within a Graph-Based database called Cloud Security Graph.
Microsoft evaluates these and will render them to the user as they become applicable (read: we won’t show you an attack path if the conditions are not present in your environment).
Using these attack paths, Cloud Security Admins can make sure that they are getting the highest value such as finding ‘hidden’ databases, exposed open ports, commonly used usernames, etc.
In my environment, I have a regular virtual machine (resourceType: Microsoft.Compute/virtualMachine) and have installed a database on it. Unless I were to use some naming convention for the VM name or apply resource tags after the fact, there is no indicator that this server runs a database workload.
With DCSPM I’m now able to uncover this hidden resource and report on it (I‘ve filtered the results to show only where the Target is either Hosted MySQL, Hosted PostgreSQL, or Virtual Machine and the Risk factors is lateral movement.
If we select the Virtual Machine and look at its Insights we can see all of the high severity vulnerabilities that were identified on this machine with Microsoft Defender Vulnerability Management
And because we are scanning this machine (in an agentless manner), we can also identify that it is running a PostgreSQL database.
With just DCSPM (Defender for SQL on Virtual machines isn’t required in this instance), we now have visibility into internet exposure and we were able to uncover a database resources masquerading as a virtual machine.
Remember that with Attack Paths, we want to contextualize the recommendations so that you can focus on the biggest risks first. Having a publicly exposed VM with SQL installed that uses a commonly used username which also allows for xp_cmdshell usage definitely fits the bill.
Now Defender CSPM + Defender for SQL on Machines is letting us know that a commonly used username is in the system SQL logins table (VA2201) as well as that xp_cmdshell is enabled in system configurations (VA1059).
It is not unreasonable to assume that an attacker could:
Attack Paths are a great starting point for finding and fixing misconfigurations in your environment, but you want the ability to hunt through your environment. For that you can use the Cloud Security Explorer to proactively identify risks in your environment.
We can recreate the attacker’s path through our environment using Cloud Security Explorer and start to expand upon it:
Original Attack Path:
We know that xp_cmdshell is enabled, so one of options for an attacker would be to use the Azure Instance Metadata Service (IMDS) to leverage a managed identity’s JWT to pivot around into the cloud. So we can add a condition that this resource should also have an associated managed identity.
We can take it even further to check to see if an attacker would have access to sensitive data.
What would all this look like if you were purely being reactive and looking at alerts?
It took less than 24 hours from time of deployment to the time a gracious person in China decided to help me in my demo:
Had the brute force been successful, it would have instead raised a ‘Suspected successful brute force attack’ instead.
Since Defender for Servers is also enabled on this machine all of my attempts to throw a reverse shell by abusing xp_cmdshell were blocked.
Just because one avenue of attack is closed off to an attacker, it doesn’t mean they will just go away. Instead of pivoting to the OS and attempting to exploit the environment that way, an attacker who has done proper enumeration would be able to discover that this instance has a managed identity and they can leverage IMDS to retrieve the JWT to use for future attacks.
But this too was detected by Defender for SQL
The combination of Microsoft Defender CSPM and Microsoft Defender for SQL provides a comprehensive security solution for your cloud and database infrastructure. Microsoft Defender CSPM, one of the main pillars for cloud security, provides hardening guidance to efficiently and effectively improve your security and gives visibility into your current security situation. It identifies and remediates risk by automating visibility, uninterrupted monitoring, threat detection, and remediation workflows to search for misconfigurations across diverse cloud environments. On the other hand, Microsoft Defender for SQL helps discover and mitigate potential database vulnerabilities and alerts you to anomalous activities that might indicate a threat to your databases. It protects your IaaS SQL Servers by identifying and mitigating potential database vulnerabilities and detecting anomalous activities. Together, they provide a robust security posture management system, ensuring the robustness of your cloud and SQL server deployments.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.