Objectives:
- Understand the attack and automated response scenario
- Configure the prerequisites for automated Azure VM isolation
- Discuss ways to test and validate
As we wrap up our exploration of Azure ways to automate in the domain of security related tasks, we find ourselves looking into Azure Threat Alerts. A common attack that still occurs in the cloud is brute force attacks against the Azure VMs management ports like SSH for Linux and RDP for Windows. While most organizations use Azure Security Center Just in Time access feature there are some that do not.
Before we dive deeper, I want to thank Yuri Diogenes and Yoav Francis who have provided a unique set of challenges that helped spark these articles in the workflow automation series.
The Adventure of Automating Azure Security Center Part 1
Closing an Incident in Azure Sentinel and Dismissing an Alert in Azure Security Center
Send ASC Recommendations to Azure Resource Stakeholders
Understanding the Scenario – Triggering of Security Playbook
In the following scenario we have a 2-tier application consisting of virtual machines in a Spoke Virtual Network. One virtual machine is acting as a SFTP server on the Internet. The second server is acting as a SAMBA NFS and SMB file server for SFTP server.
As discussed, the SFTP virtual machine is Internet facing and has a Public IP Address. Both virtual machines have a Network Security Group applied to the NIC of the Virtual Machine. The network Security Groups are the default ones created from the Azure Portal.
In our scenario an engineer is troubleshooting connectivity issues with SFTP server and decides in the course to update a NSG Inbound Rule Port 22, TCP, Any, Any, Allow
The engineer was called away and forgot to update the NSG rules to harden them against publicly exposing the SSH management port of the Linux VM on the Internet.
Within a matter of an hour an offensive security tool that was scripted as a bot starts attempting to SSH Brute Force itself into the company and the exposed Azure virtual machine over the Internet. After many attempts it is successful as the Linux VM had a sudoers user with a weak username and password set.
Azure Security Center Standard Tier is applied and detects the Successful SSH Brute Force attack. At this point the Workflow automation triggers the security playbook Isolate-ASCAlertAzureVM.
In this scenario and blog we are focusing on Target and Attack (Exploitation) in the cyber kill chain or in MITRE’s ATT&CK Framework the Credential Access – T1110
Understanding the Scenario – Security Playbook
As the Security Playbook is triggered the Logic App will perform the following
(1.) Read information from the ASC detection alert and will now check and create within the Virtual Network new IP Address Space at 100.64.0.0/24 – an uncommon range to avoid any IP Address overlap within the virtual network and any routes propagated to the virtual network from Express Route (BGPs), Site-to-Site VPNs (BGPs or Static) and Vnet peerings (BGPs)
In addition it will carve within the new 100.64.0.0/24 ip address range two subnets one called ISOLATE at 100.64.0.0/25 and another called AzureBastionSubnet at 100.64.0.128/25.
(2.) A new Network Security Group will be Generated and attached to the Isolate Subnet. The security rules are both inbound and outbound Any, Any, Any, Any, Deny at earliest priority in the rule set at 1000. This essentially disconnects all traffic to and from the 100.64.0.0/25 Subnet providing a nice isolation zone away from business services and other adjacent servers.
Another security rule is added at a later priority 2000 allowing only the management port of the virtual machine access from calls made in the AzureBastionSubnet
(3.) The Logic App will take the Azure virtual machine’s NIC and update it to move it to the ISOLATE Subnet. This type of subnet update of the VMs NIC will restart the virtual machine as it comes up in 100.64.0.0/25 with an IP 100.64.0.4 After the restart the VM will be unable to communicate inbound or outbound essentially isolated from the rest of your virtual networks. The added bonus is that the restart also drops any persisted connections into or out of the VM connections like SSH or RDP that may have existed. This forces a reconnect and the traffic now passing through the Network Security Group at the subnet level and the rule set 1000 denies the traffic.
(4.) Finally the Logic App will spin up a Azure Bastion host in the AzureBastionSubnet at 100.64.0.128/25. This can be used for forensically investigating the Azure VM safely.
Setting up the prerequisites for testing
You will need to have Azure Security Center – Standard tier turned on the Azure Subscription. Microsoft offers a 30 day opt out free trial of Azure Security Center – Standard Tier per each Azure subscription. This provides a good amount of time to test the detections and allow anomaly detections to occur based on your environments data patterns.
Please also deploy the following Azure Security Center Logic App playbook in your subscription.
Link to Isolate-ASCAlertAzureVM Logic App
Once deployed you will need to authorize the web api connection for Office 365 by going to the logic app and going to the API connections blade, and choosing the ascalert-Isolate-ASCAlertAzureVM
Go to the Edit API connection blade to authorize, enter your credentials to Azure portal and click on save.
*Be sure to save the authorization
We will now setup Azure Security Center’s workflow automation. This new capability in preview today allows alerts or recommendations that you can filter on and sends the alert/recommendation and some rich information to a Logic App. This allows for some interesting full security automation scenarios like isolating an Azure VM.
Within Azure Security Center we will go to the workflow automations blade and add a new workflow automation
Filling the details of the workflow automation by giving it a logical name, use the pickers below to choose where the workflow automation will be deployed, finally we want to use the Select Security Center data types of Threat detection alerts and set the Alert name contains for Successful SSH brute force attack
*In addition if you want you can setup additional workflow automations for other types of alerts, be careful as this Logic App will isolate the VM so choose additional workflow automations that align with Azure Security Center’s Intentions that map with MITRE ATT&CK framework.
Finally select your Logic App name note that in the picker you will see existing logic apps in your environment and the ones coded for use with Azure Security Center, in this case we will select the newly created one Isolate-ASCAlertAzureVM (Security Center Alerts connector)
Go ahead and press create and now we have tied the Azure Security Center Alerts for ‘Successful SSH Brute Force Attack’ to our security logic app playbook. Any Virtual Machine that has this alert will now trigger and fire off the Security Logic App playbook.
Validation and Test
To test this out yourself you can use Azure Security Center Playbook: Linux Detections. This playbook goes into much detail on how to setup the Azure VMs and describes the nature of the attack and how to use the tools in more detail.
Cleanup
Once the playbook is tested and the workflow automation kicks in, you can use Azure Bastion or the SerialConsole to connect and check out the Azure VM. In the email you receive from the playbook you will get both links to use
*Note the priority rule in the Network Security group to allow Azure Bastion host is set at 2000 so it is higher and traffic will hit Deny All first rule in the NSG – you need to manually change priority rule to 900 when ready to investigate.
Operationally if you want to return the VM back to production, you can go to the isolated Azure VM’s NIC and change the subnet it is talking to in the Azure Portal.
To do this go to the Azure VM and the Networking Blade. On the networking blade go to the Network Interface link
On the Network interface resource go to the IP Configurations blade and select the Subnet you wish to move the isolated VM back into.
Be sure to press Save and note that the Azure Virtual machine will restart and come back into the subnet selected out of isolation.
You may also want to keep the azure resources created (NSG, PIP, AzureBastionHost). The automation works if the resources exist or are not there. The automation does generate a new Resource Group and GUID to store these resources. To clean those resources up you can do so by deleting the ResourceGroup.
The Azure virtual machine, virtual networks, and subnets that were modified and their modifications however do remain.
Conclusion
We have now walked through attack and automated response scenario. We have deployed the Logic App and we are using Azure Security Center’s Workflow automation for a Security Alert ‘Successful SSH Brute Force’. The workflow automation triggers the Logic App to automate a security response which checks and generates the necessary virtual networking constructs and places the attacked Azure VM in Isolation. We also reviewed how you can test this out and a few post operationally things you can do to bring the Azure VM back into production.
I hope this series has been inspiring and you see all the potential Azure Security Center has to offer when it comes to automating from recommendations and security alerts. Please visit Azure Security Center Github where there is a lot of great material to remediate security posture and implement workflow automations.
Also check out Charbel Nemnom’s article on enabling JIT VM access with ASC Workflow automation.
Until next time lets automate our security responses with Logic Apps and Workflow automation.
Special thanks to:
@YuriDiogenes for testing, collaborative input, and reviewing this post
@StephenHelwig for testing security playbook and scenario and proving feedback
@AndresUrrutia for testing security playbook and scenario and proving feedback
Updated Mar 25, 2020
Version 1.0
Nathan Swift
Microsoft
Microsoft
