OFFSEC – Pen-testing Azure Firewall IDPS & Threat Intel features (Azure Lab 2)

Setting Off Alarms

Have you ever seen an “alarm will sound” sign and think to yourself, “I feel like gambling today” and push the door open just to find that nothing happens and the sign was put there as a deterrent? Or maybe they pulled the wires to it because they were sick of people using the door? Yea this post is kinda like that….I want to know if the alarm will sound ….I would have loved to test the Enterprise Defender functionality too but I’m waiting for a license … )-8

By the end of this lab, I had performed everything from basic NMAP TCP scans, to NMAP SMB enumerations, TOR enumerations, NIKTO HTTP enumerations, BURP INTRUDER, Browser Botnet, installed PUPs w/ unwanted packed VPN software and detonated off like 10 different strains of malware from this decade…. thinking surely this product will light up like a Christmas tree ….

Or will it???

the azure firewall idps and threat intel

Here’s a few Blurbs about the features I tested

IDPS – A network intrusion detection and prevention system (IDPS) allows you to monitor network activities for malicious activity, log information about this activity, report it, and optionally attempt to block it.

– MICRSOFT

Firewall Threat Intelligence – filtering can be enabled for your firewall to alert and deny traffic from/to known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed

– MICROSFT

Disclaimer: I did not intend this lab to be a thorough and all inclusive multi staged type of test. This was personal and just-for-fun… The goal is to create a bunch of noise and see how well the product did at the basics when detecting network and port enumerations, SMB attacks, shell code, HTTP enumerations and remote Command and Control using relatively recent/active malware. Also, all tools and attacks were performed on assets I own and pay for, with my permission and under the acceptable use policy of Microsoft. I do not condone or advocate for using these tools or techniques in way that violate federal or local law.

what’s the summary

Business Analysts can create Executive Summaries, but... > Business Analyst  Community & Resources | Modern Analyst

testing scenArios

In this lab, I performed two network type of scenarios ….

External (Internet) –> Internal (Azure) – The internet DNAT access path which tested the IDS/IPS functionality on both my SOHO inline IDS/IPS and the Azure Firewall IDS/IPS public internet address ingress point.

Internal (Azure) –> Internal (Azure) – Which tested the Azure IDS/IPS for all traffic staying within Azure VNETs and attempting to egress to the internet from within Azure.

I also tested a few type of specific attacker use cases to generate “noise” hoping for an alert …

  • From the Local Office(Lab) to the Internet FW endpoint
    • NMAP TCP enumeration
    • NMAP –script using SMB enumeration, Tor enumeration, Bitcoin minor enumeration, TOR enumeration, STUX enumeration, SMTP enumeration, NETBIOS enumeration
    • NIKTO fully authenticated Web Enumeration
    • BURP Intruder brute force of Top-1050 passwords
  • From “Within” Azure VNET on Windows 10 Preview machine
    • NMAP TCP enumeration
    • NMAP –script using SMB enumeration, Tor enumeration, Bitcoin minor enumeration, TOR enumeration, STUX enumeration, SMTP enumeration, NETBIOS enumeration
    • NIKTO fully authenticated Web Enumeration
    • PUPS
      • Installed MagicISO and Alcohol120% PUPs with LUMINATI VPN
    • Malware
      • WannaCry
      • Trikbot
      • Petya
      • LoveYou
      • ZeusBot
      • AgentTesla
      • VBS – Carnival, Hopper, LoveLetter

** A few caveats here, not all the malware executables could be detonated on the machine because I had a relatively newer “somewhat patched” Azure Windows 10 preview system. Without putting much effort into it, I monitored Process Explorer, PCAP traffic, Azure FW for any indicators that the malware executed to ensure the Azure FW had a chance to perform ints inspection.

** Also, I disabled every security feature you can imagine, from Defender Firewall, ASLR, DEP, Web/Browser mitigations and everything in between. This lab wasn’t meant to test the endpoint security posture.

nmap enumeration from internet

In all honesty, I thought this was going to be the low hanging fruit. If there was ever a tool to detect based on network signatures it would be nmap. I configured the nmap to run on ports 1-30,000 and perform agressive TCP interrogation within a bunch of different very noisy –script options that you would expect to set of alarms ….

RESULT: The Azure FW IDPS seemed to create a false positive for the Win32.Tofsee trojan from my client IP address because that trojan is normally associated with SMTP. I’m assuming that it may be from the Conficker or Bitcoin nmap –script, either way, this alert can’t be trusted as legitimate, so I’m chalking this up as a failure in Azure FW IDPS feature to detect simple aggressive nmap scans over DNAT ports.

However, my office/lab in-line IDS/IPS detected some of the nmap –script behavior when running Conficker enumeration, SSH enumeration and MySql enumeration scripts ….

nikto from INTERNET

This was a long shot. I didn’t seriously expect the Azure FW to act as a layer 7 type of inspection point but then again Microsoft hasn’t published their signatures / rules list…. so I thought maybe the platform would pick up excessive tcp client attempts or less likely maybe pick up HTTP user agents … so I proxied all NIKTO traffic through a Burp proxy to confirm the traffic was moving then point and clicked ….

RESULT: NO ALERTS IN THE NATIVE IDPS FEATURE, BUT THE FIREWALL LOGS WERE AVAILABLE WITHIN MINUTES …. My local inline IDS/IPS running community edition Emerging Threats (ET) Suricata rules did not pick up HTTP nikto user-agent either which I found interesting since the attack was over unencrypted HTTP traffic …

To be fair, Microsoft never claimed to provide Layer 7 signatures, in fact they haven’t published any signatures as far as I can tell….

hydra / burp intruder from office

I attempted some 1,000 brute force attempts using hydra from the internet ingress to the Azure FW public IP over a SSH DNAT assuming it would have some rate detection built-in or possibly some user-agent detection.

RESULT: NO ALERTS IN THE NATIVE IDSPS FEATURE, BUT THE FIREWALL LOGS WERE AVAILABLE WITHIN MINUTES …. My local inline IDS/IPS running Emerging Threats (ET) Suricata and snort rules did not pick up TCP attempts either, as I suspected any client-server response data would be encrypted any-how making in-line MitM detection difficult …

To be fair, Microsoft never claimed to detect HTTP attack signatures with the Azure FW product and I suspect they’d point you to competing Microsoft products like CDN DdoS protection, WAF and Sentinel .. but because this device requires a public IP …. I’d expect some L3/4 indicators of compromise as a starting point before peeling back the logs from the other layered systems

I attempted some 1,050 brute force attempts against the Damn Vulnerable Web Application (DVWA) hosted in Azure using Burp HTTP Intruder. This attack originated from the internet ingress to the Azure FW public IP over a SSH DNAT and I wanted to test whether the product could pick up TCP brute force client tcp rates or user-agents…. I doubted the product would alert on brute-force given the high transactions rates expected from the internet to HTTP typically to support most business functions but maybe HTTP client user-agent since the traffic is unencrypted?

RESULT: AS EXPECTED, NO ALERTS IN THE NATIVE IDPS FEATURE, BUT THE FIREWALL LOGS WERE AVAILABLE WITHIN MINUTES …. My local inline IDS/IPS running Emerging Threats (ET) Suricata and snort rules did not pick up burp user-agent either which I found suspicious as well.

nmap from within azure vnet

Okay, so I began to suspect that the detection functionality from the internet is somewhat constraining the features of the Azure FW IDPSs. As an educated guess, I suspected that the signatures needed more handshake data between client and server. I had a strong suspicion that Microsoft would excel at SMB type of attacks and enumerations as well…. So I deployed a Windows 10 preview in Azure, stood up a few other VMs, had disabled some local security features to get NMAP to run and then point and shot off the same scripts as before ….

RESULT: THIS TIME AZURE IDPS DETECTED A FALSE POSITIVE ON TOFSEE TROJAN AGAIN, POSSIBLY ASSOCIATING THE CONFICKER P2P NMAP –SCRIPT.

ODDLY, A NEW FALSE POSITIVE SOUNDED REGARDING WINDOWS USB METADATA DATA EXFILTRATION. HOWEVER, THE DEVICE METADATA RETRIEVAL CLIENT USER-AGENT MAY INDICATE THE NMAP CLIENT ENUMERATIONS… (-;

nikto from within azure vnet

RESULT: SAME RESULTS AS FROM INTERNET. NADA. NO ALERTS IN THE NATIVE IDPS FEATURE, BUT THE FIREWALL LOGS WERE AVAILABLE WITHIN MINUTES …

To sound like a broken record… Microsoft never claimed to detect HTTP attack signatures with the Azure FW product and I suspect they’d point you to competing Microsoft products like CDN DdoS protection, WAF and Sentinel …. but because it has TLS inspection with IDS, maybe the product picks up well known user-agents or traffic rates …

browser botnet within the azure vnet

This was another long shot. I doubted the Azure firewall would be used as an inspection point for HTTP Javascript client-side infections. However, because Microsoft advertises the TLS interception and IDS signatures … maybe it is fair to assume they could break open packets to inspect headers or other payload content to common signatures. In this exercise, I set up the Browser Exploitation Framework (BeEF) 0.5.0.0-alpha-pre, hosted it internally to Azure VNET and hooked two Windows machines.

After hooking into the user’s web browser, I was able to capture the user’s key strokes and send them back to the C&C machine.

RESULT: AS EXPECTED, NOTHING FROM THE AZURE IDPS.. THIS WASN’T A SURPRISE

pups from within azure vnet

In addition to to various pen testing tools, I installed some well known “potentially unwanted programs” (PUPS) on a Windows 10 preview virtual machine. This lab exercise was meant to replicate users downloading software on a Windows Jump box, Development box, or maybe a remote VDI.

Yes, normally the Windows 10 client software would pick these programs up… and Yes …. various Windows features both in browser, AV scanners, and Defender FW picked up the programs and blocked them and alerted…. I had to disable local windows protections…

My thought is that one of these programs would likely come from a insecure download site or domain that would get flagged by the Windows Threat Intel reputation service or would install some backdoor software that would communicate out on a network protocol to a command and control service that the Azure IDPS would catch…

Luckily, Alcohol 120% free version requires you to install Hola VPN, which acts like a mesh proxy network which makes you computer the exit node… (More on Hola VPN here) …. then Hola resells the proxy network to those wishing to masquerade their traffic… bingo.. this sounds like it would get flagged by Azure IDPS feature, right?

RESULT: SUCCESS. The firewall alert logs show the AzureFirewallIDSLog ET signature match on IP address data exfiltration and a questionable HOLA VPN communication against lumati.com. Unfortunately, Microsoft Threat Intel service did not flag any suspicious domains during the download or post compromise during the VPN communication to luminati.com…

REVERSE SHELL FROM WITHIN THE VNET

I did not test this extensively, however I did perform two type of RFI shell attacks. A tcp/bind shell and a reverse meterpreter shell using PHP remote file inclusion as the delivery channel. I left the traffic unencrypted intentionally to see if the BIND payloads or the METASPLOIT paylods would be detected. METERPRETER is pretty commercial, so I assumed that the generic MSFVENOM payloads would be detected over unencrypted TCP comm channels.

The malware serving machine

The C&C machine

RESULT: ANOTHER FAILURE. The IDPS failed to detect the PHP initial staged delivery and the reverse and bind / reverse TCP channels established during second stages. That’s not to say that this product can’t detect any of the MSFVENOM/METASPLOIT delivery payloads but it failed to detect them in this particular case.

malware from within azure vnet

The final test was to find some old and recent malware and see if I could replicate any network communication or command and control communication to get the Azure IDPS to alert. Honestly, I thought detecting more serious malware events and port scanning would be where this virtual device shines.

DISCLAIMER: After downloading the malware ZIP, I initially severed network communication to the internet and ensured all other virtual machines were turned off. Additionally, I used a random local password and ensured the device was not used for any other personal use.

I’m not an expert on malware except for understanding the basic delivery mechanism the sosftware follows and a limited knowledge of their exploits. However, I did understand that most of these strains do attempt enumeration of the local systems, communicating to external malicious domains/proxies/tor networks etc in order to delivery their second staged payloads. Some of these malware strains attempt to perform NETBIOS and SMB enumeration as well. This was the type of network behavior I was hoping the IDPS would alert on.

I downloaded multiple strains of malware in an isolated environment, disabled all the security features on Windows 10 machine to ensure the malware executes and captured packets locally in Wireshark to compare local traffic against traffic on the Azure IDPS.

INITIAL MALWARE RESULT: After detonating AgentTesla, Loki, Dridex, Emotet, Trikbot there were no alerts on the Azure IDPS. Windows defender had no problem detecting their signatures before I disabled many of the security features… although these are well known malware without polymorphism or obfuscation …

After detonating the malware, I saw unusual TLS 1.2 / TLS 1.3 communication to network addresses which ultimately resolved to AWS EC2 instances mapped to the HOLA VPN (LUMINATI) and content delivery networks such as Fastly, Akamie, Edgecast and Geocities (Old VBS malware) …

Although many of these domains were associated with malware distribution in VIRUSTOTAL, they also provide legitimate proxy and caching services world-wide. Unfortunately, many clients and service may resolve to shared CDN proxy infrastructure making attribution difficult and difficult in confirming whether C&C is occurring. In my particular case, I could confirm that the local EXE and VBS scripts did execute and then watch this unusual network traffic attempts. I wanted more empirical evidence that the malware worked to ensure that the Azure IDPS had an opportunity to detect the C&C communications.

WANNACRY

Finally, I used a relatively recent strain of WANNACRY to put the final nail in the coffin. I wanted to be sure I threw everything but the kitchen sink as this Azure IDPS and Threat Intel feature. Everything within reason given this is on my spare time for fun and for free (-:

WANNACRY MALWARE RESULT: Azure IDPS did successfully detect the WANNACRY malware C&C communication over TOR networks but the Azure Threat Intel feature did not alert on the suspicious and dangerous domains that VIRUS-TOTAL and the community had already flagged. Azure IDPS also detected some EXE download and PYTHON C&C communications that occurred post exploitations as well. Nice…

take-aways

  • The Azure firewall requires a public IP (at the time of this writing) by default which depending on your philosophy, may be be a show stopper based on the increased attack from from the internet.
  • As far as I can find, Microsoft does not provide a complete list of their signatures online but maybe I’m missing something. If you reverse engineer the detection and signature IDs from these labs, I found they appear to use Emerging Threat signatures in some cases
  • The Azure firewall IDPS had a difficult time detecting basic nmap network enumerations from the internet but did provide the logs within a few minutes. In theory the Azure FW logs could be scripted for automated alerts or sent to Azure Sentinel / Splunk etc for pattern matching
  • The Azure firewall IDPS did not provide any Layer 7 HTTP type of detection of Burp brute force attempts or BeeF javascript botnets distribution over unencrypted HTTP channels. Although Microsoft would likely point you to their WAF, the Azure Firewall IDPS also offers TLS interception which begs the question, why break open the packets here then? Or do you break open the packets on Azure FW and WAF and pay for more features and licensing? Seems like a crazy architecture …
  • The Azure firewall IDPS did not detect Hydra TCP SSH brute force attempts from the internet over DNAT. I expected an excessive transmission alert to port 22 within the VNET at the very least but I did not expect them to alert on agent headers given the encrypted nature of RDP/SSH.
  • The Azure firewall IDPS did not detect web crawling and http server enumeration from Nikto both from the internet and from within the internal VNET. Although this finding shouldn’t come as a surprise seeing that they sell a WAF product and that most HTTP traffic is encrypted already. Although, Microsoft does market TLS interception which could in theory be used to monitor for common crawling behavior and user-agents.
  • The Azure firewall IDPS did detect unusual traffic from PUPs (Hola VPN/Luminati) which were installed with an Alcohol 120% installation. However, the Azure Threat Intel feature did not flag those domains as potentially dangerous even though complimentary Microsoft Defender endpoint will not let you install the software directly on the endpoint (by default) knowing full well it’s malicious software.
  • The Azure IDPS did not detect two forms of Metasploit MSFVENOM payloads over unencrypted channels to a Linux server. It’s possible, they can detect some of the other EXE staged payloads and C&C communication but I did not test them all.
  • The Azure IDPS did not appear to detect many variants (Loki, TrikBot, AgentTesla) of malware network communication, however it’s possible that I misinterpreted the network traffic and the malware did not properly execute as well.
  • The Azure IDPS did detect WannaCry communication, ToR communication. However, the Threat Intel feature did not flag any domains associated with WannaCry malware delivery or C&C communications.
  • The Azure IDPS did detect EXE downloads, post exploit python HTTP communication, drop box communication, IP lookup data exfiltration communication.

To be fair, the default Windows Defender (Basic) did detect some of the malware strains when on the machine and attempted to block payload download using their Browser mitigations. Also, some of the attack patterns would be better suited for log aggregation in a SIEM or possibly scripted using serverless functions for detection. I say all of that because I certainly wouldn’t rely on the Azure IDPS alone.

Which begs the question how you would layer the typical Microsoft security stack together? Do you break open TLS on Azure IDPS on ingress or egress? Do you layer the Azure IDPS with the Azure WAF and TLS interception there? Now that’s two points of certs/keys and MitM to maintain? Presumably the Architecture is to layer the alerts from Azure platform logs, Azure AD logs, Azure WAF, Azure IDPS and Defender all in Sentinel… Balance that architecture that with the fact that you must use a the Azure Firewall with a public IP and you don’t control the IDPS signatures…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s