Did you know that your virtual machines are targeted for attacks before they actually come online? For virtual machines running on Microsoft Azure, you can notice quite fast when they are online and ports like 3389 / RDP is publically available you get a lot of failed authentication attempts quite fast, flooding with random username and passwords to try to gain access. Of course, bots nets are constantly scanning the public IP ranges of Azure to see if they are any vulnerable targets.
Now as part of some research for this blog post I decided to try and figure out the following.
- Are Virtual machines targeted before they even come online?
- What kind of traffic is the most typical? (Ports and Protocols)
- Where does the most malicious traffic come from?
In order to properly figure out of these issues, I wanted to test the more in-depth use of Traffic Analysis in Azure. Traffic Analysis is a combination of Flow Logs from Network Security Groups (NSG), Log Analytics and Network Watcher feature. So when a packet is destined for a public IP address in Microsoft Azure and that IP address is attached to a virtual machine, it has to be processed by the NSG rules regardless if it is denied or allow rules that take effect. These flow logs are written in JSON format and show outbound and inbound flows on a per-rule basis, the NIC the flow applies to, 5-tuple information about the flow (Source/Destination IP, Source/Destination Port, Protocol), and if the traffic was allowed or denied.
This means that we can see what kind of traffic is actually coming to a virtual machine based upon the flow logs, and can see what kind of traffic (even though we cannot see what kind of traffic the packets are actually transmitting as part of the flow logs, part of a later blog post...)
Now Flow Logs can be configured to be stored in a Storage Account and if you want to use Traffic Analysis to a Log Analytics Workspace. Now Traffic Analysis allows it to easily aggregate all the logs to map the information to other data that is gathered by the Microsoft Threat Intelligence Center (MSTIC) and also visualize the data.
NOTE: If you want you can also use ELK or Graylog or Grafana (You can read more about configuring them to process the data here –> https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-grafana
Setting up Traffic Analysis
Setting up Traffic Analysis consists of multiple parts.
- Enabling Network Watcher (New-AzureRmNetworkWatcher -Name “NetworkWatcher” -ResourceGroupName “NetworkWatcherRG” -Location “Location”) https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-create
- Re-register the resource provider (Register-AzureRmResourceProvider -ProviderNamespace “Microsoft.Network”)
- Register the resource provider for Insights for your subscription if it isn’t already done Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Insights
- Enable flow logs for Network Security Groups (This requires that you have a storage account to store the Flow logs and a Log Analytics workspace to process the data)
this configuration is done under the network watcher in the Azure portal.
- Once Flow logs are enabled it will create a container on the storage account under the name insights-logs-networksecuritygroupflowevent which will create the data based upon Subscription/RG/NSG
So what did I see after 24 hours of traffic against two virtual machines running in West Europe region which only had standard RDP 3389 open?
So Inside Traffic Analysis, I get a good overview of what kind of traffic is actually going on. I expected to see a bunch of RDP traffic against the two hosts. Here is a screenshot of the overview inside Analysis after a couple of hours. I can see all traffic based upon region.
Large picture of the screenshot here –> https://i.imgur.com/T0ln1kP.png (and you can see that Norway, Sweden and Russia are the sources so far for malcious traffic)
It also lists out Malicious traffic if I dig a bit deeper into the dashboard. This information comes from the Microsoft Threat Intelligence Center (MSTIC), Log Analytics gets hourly updates about the latest known malicious IP’s and this information is then cross-referenced with source IP’s from the flow logs and therefore visualized inside the portal.
Now after a couple of hours I did a quick dump of the flow logs to see what kind of traffic was coming in.
NOTE: 3389 is excluded from the query that I did to not clutter the results.
- A lot of traffic against port 445
- A lot of traffic against port 80
- A lot of traffic against port 22 and 23
Which of course are all know ports for known services. Of course there was also some other interesting traffic coming to
- port 1433 ( SQL Server)
- port 2323 (Typically alternative to 23 telnet https://isc.sans.edu/port.html?port=2323)
- port 5060 (Usually UDP/SIP traffic)
- port 5555 (Route Remote Admin) https://isc.sans.edu/port.html?port=5555
A large picture of the screenshot here –> https://i.imgur.com/pAn8ITs.png this screenshot shows a query from log Analytics displaying flow counts against different ports.
So after 24 hours, I had about 1 million flow packets that I could analyze using Log Analytics, to do some more in-depth analysis on what was going on. Here is my conclusion.
Most traffic was originated from (Known country based upon IP source: China)
Most flooded port was: (445 using microsoft-ds)
Most Malicious traffic was targeted against port: 445 By a large percentage.
So to summarize this is was an interesting exercise and just shows the importance of proper configuration of your ACL’s in Public Clouds and that you will be targeted as soon as your resources are online and available. I also hope that as part of a future integration that third party NSFW vendors can integrate with flow logs to visualize data that is coming in through the flow logs combined with the kind of Netflow capabilities that most of them have, or integrate with the information that Microsoft has to see more how the traffic flows and where malicious traffic is coming from.