I love dashboards, yes the likes that gives me useful information, and bless God that Azure has such dashboards in place with rich detail that helps you the engineer to truly know what is happening on your network.

Deployment in an Azure Region showing Benign and Malicious traffic from different Regions

So here is the whole story. I had a project to deploy a new infrastructure which I gladly did in Terraform. There are a set of practices where cloud infrastructure is concerned. Spinning up virtual machines or instances is only a piece of the story.
NSGs as we call them have the ability to show you a great deal of information which by default is not enabled until certain pieces of configuration are set in place.

To test access to the virtual machine, I had created a Public IP and attached to the Network Interface of the Virtual Machine temporarily.

I had created a Public IP and attached to the Network Interface of the Virtual Machine temporarily.

Most problems originate from temporary rules, configurations in the name of tests. I had forgotten to test and also to remove the rule. This is the reason why it is of utmost importance to enable NSG Flow Logs and also to keep an eye on your Network Watcher. Never assume full protection until you have worked to attain it.

Create NSG Flow Logs to Capture Traffic Flows into NSG on Azure

Download Sample Script to Check for Malicious Traffic

AzureNetworkAnalytics_CL
| where SubType_s == 'FlowLog'
    and (FASchemaVersion_s == '1' or FASchemaVersion_s == '2')
    and FlowStartTime_t between (datetime('2022-06-03T04:44:29.994Z') .. datetime('2022-06-04T04:44:29.994Z'))

Figure 1.0 – Showing Malicious Traffic to Ports 22

Deployment in an Azure Region showing allowed Malicious Traffic

Identifying Source of Attacks

Checked the NSG for allowed Inbound Rules – SSH Inbound Was to Blame

Use Azure CLI to query this information – Include the Default Azure NSG Rules

az network nsg rule list --include-default --resource-group  --nsg-name 

Check Malicious Traffic Flows

What I did to mitigate this security failure.

1. Removed offending SSH rule on the NSG
2. Removed the Public IP

Network security group security rules are evaluated by priority using the combination of source, source port, destination, destination port, and protocol to allow or deny the traffic. A security rules can’t have the same priority and direction as an existing rule. You can’t delete default security rules, but you can override them with rules that have a higher priority.

Check Inbound Security Rules and delete the offending SSH Inbound Rule

Disassociate and Delete the Public IP attached to a Virtual Machine Network Interface

These articles are extremely useful;
Enable Azure Network Watcher
Traffic Analytics – frequently asked questions