The Hurricane Labs Foundry: Volume 8, Automata

Welcome to another edition Hurricane Labs Foundry! I’m Tony Robinson, one of the security operations analysts at Hurricane Labs. The goal of this series is to inform readers about current security news and innovations to keep you aware of the latest threats and technology. Additionally, this series discusses various aspects of Splunk deployment, as well as observations and projects from the Hurricane Labs SOC.

The stories presented here are mostly short digests with links to source material in order for readers to get the full scoop, and additional context as required.

Please note: Tools, signatures, patches, resources, etc. that are linked to in this blog post are not the property of, and are in no way officially supported by, Hurricane Labs. Remember to do your due diligence and test before deploying any new tools, signatures, patches, or countermeasures!

Do not compromise the Domain Controller, become the Domain Controller

Recently, news of a new persistence method has been making the rounds. Dubbed “DCShadow”, it is being considered a new method of persistence for attackers in Microsoft active directory environments.

In a nutshell, the persistence method, which requires either domain admin, or enterprise admin privileges to be performed in the first place (squarely placing it into the realm of post exploitation and long-term persistence methods), temporarily creates a fake domain controller and adds it to the existing active directory network. This new “fake” domain controller then injects objects into the existing active directory configuration, or modifies already existing objects in the active directory schema. While creating users using a privileged account in active directory networks is a common tactic for long-term persistence, most admins and security teams know to look for, audit the relevant logs, and question the creation of new users – especially when and if it doesn’t fit normal activity for that particular account. The creation of active directory objects on the other hand isn’t as well audited or monitored, allowing this persistence method to stay “under the radar”, relatively speaking.

Researchers are being quick to say that this isn’t a Windows vulnerability, nor is it a vulnerability or problem in active directory environments. It is the abuse of the replication mechanics inherent to any active directory-based network. Admins can make a change on any domain controller in an active directory network and the change is, and should be, replicated to other domain controllers.

Cisco ASA WebVPN vulnerability

Recently, Cisco has announced a critical vulnerability in their ASA security platform. The vulnerability, targeting the VPN functionality of the ASA platform, has been rated a full 10 out of 10 on the CVSS scoring system, meaning that the vulnerability has a low barrier to exploitation and a high potential impact (e.g. full ASA system compromise/remote code execution) if successfully exploited.

The vulnerability was initially discovered and reported to Cisco through the NCC group. Upon announcement, security researchers took to Shodan, sometimes referred to as “The internet of broken things”, to determine the possible scope of this vulnerability. Upon initial announcement, nearly 200,000 Cisco ASA devices worldwide were thought to have been vulnerable.

As always, the best way to plug a hole is with a patch – and this instance is no different. Grab the ASA patch available from Cisco and patch as soon as feasibly possible for you and your organization, making sure to perform the necessary change control and testing before rolling out the patch. At this time, the only other remediation method available would be to disable access to VPN services on ASA devices. As far as detection is concerned, Fox-IT’s SRT (security research team) has published snort rules to detect this attack, while Cisco states that official TALOS Snort rules are forthcoming, and ProofPoint has made no comments with regards to rule availability for Suricata via the Emerging Threats ruleset.

While Cisco has been quick to issue patches for the vulnerability, not every customer has been satisfied with Cisco’s response. In one case, Dan Tentler (aka “Viss”), security researcher and founder of the Phobos security group, stated that it took talking to Cisco’s TAC (technical support group) for 24 hours, several phone calls and emails before he could be issued a download link to patch ASAs he was responsible for. This was in spite of Cisco announcing that the patch would be made available for everyone, even those without active support contracts. Moral of the story? Be persistent. The security of your network depends on it.

Edit 2/6/2018: Cisco has released a new warning, expanding the scope of affected services and products related to this vulnerability, and have released a new patch for this vulnerability in response to the expanded scope of affected services and devices. The Cisco security advisory page was updated yesterday to reflect this new information.

Autosploit: Just because we could, doesn’t mean we should, or serving to highlight the problems at hand?

Speaking of Shodan – the favored computer search engine of hackers and security researchers worldwide – a new tool leveraging the capabilities of power of both Shodan, and the ever-popular Metasploit framework, has been released. This tool, dubbed Autosploit, allows users to harvest data from Shodan through its search API (and an API key), and input the systems gathered into Metasploit for mass exploitation. Many security engineers and researchers all over the world are arguing whether or not this was a well-considered and/or ethical decision.

Why the debate? Let me propose a scenario for you:

The Cisco vulnerability mentioned above? Let’s assume that the same day the vulnerability was announced, that there was a simple proof of concept released that exploits ASA targets with a near 100% success rate against vulnerable targets, with next to no chance of crashing the target. The exploit gets added to the Metasploit framework the same day, or the day after. Now, imagine that Autosploit was released on the same day, or maybe even the day after the exploit was added to the Metasploit framework. An attacker crafts a query for Shodan to return a list of Cisco ASA devices vulnerable to the newly released exploit, pipes the IP addresses returned through Autosploit, and into the Metasploit framework then simply fires at will. Within moments, reverse shells start coming back to the attacker. Within a matter of hours, thousands of systems are compromised, and a single attacker, or group of attackers has complete control of a humongous number of firewalls all over globe. The attacker(s) could choose to use these firewalls as an initial foothold for deeper network access, manipulate traffic on the firewall for eavesdropping and/or packet capture, modify firewall rules to allow themselves easier access to the internet network, or even drop tools/implants to turn the firewalls into bots for other purposes.

In this scenario, defenders have maybe 3 days from patch release to Metasploit framework availability to test and patch before mass exploitation across the internet occurs. What happens when the next zero day vulnerability with easy proof of concept is released? That turn-around time becomes even smaller, because the means for mass targeting are already in place. Scary to think about, huh? Well then, let me blow your mind:

What if I told you that Shodan API support is already built into the Metasploit framework? Not enough for you? What if I told you that certain actors (e.g. Xor.DDOS, ChinaZ, and well, most moderately organized skids–script kiddies) utilize their own scripts that more or less do the same thing?

Don’t believe me? Let me share an experience with you:

A few years back, I was looking at my SSH attack logs from running Cowrie, an SSH honeypot. I was searching through my logs for all attackers who successfully logged in and issued commands. Sometimes, all an attacker will do is run whoami, or ps and just disconnect. Other times… they run wget, grab their toolkit, and begin their dark work. A group referred to as “ChinaZ” was running rampant across the internet. Their goal was to find and brute-force their way into systems running SSH, then drop implants that would register the compromised host as a DDOS bot. Since they used wget to retrieve their payloads, the payloads would be hosted on random IP addresses all over the place in China. Browsing to the IP address would occasionally net very interesting finds.

The attackers used a web server called HFS – HTTP File Server. It was a free application for windows whose only purpose is to serve files over HTTP. More than once I would find several executables for different system architectures. Several times I found post-exploitation tools that could be run on windows to determine what security countermeasures were installed on the infected Windows host.

Other times, I found their automation tools for scanning network ranges for SSH servers, along with tools utilizing SSH2 libraries to brute-force through  SSH servers as quickly and efficiently as possible. Alongside these SSH brute-force tools, were several tools to automate scanning and exploitation for low-effort and high impact remote code execution vulnerabilities. One of these happened to be an easy to exploit vulnerability in ElasticSearch. All you had to do was connect to an ElasticSearch system on port 5900, issue a simple command, and you got remote code execution. The attackers started scanning for port 5900, launching the exploit against any system that responded, and waiting for those systems to respond to be implanted with their DDOS payload. This was proof that the attacker TTPs were capable of evolving to integrate these new vulnerabilities into their day to day operations.

So this is all fun and good, but what is the moral of the story? Pentesters, attackers, and adversaries have been automating their operations for years. The only difference between then and now, is that toolkits have been open-sourced for anyone with the time and resources to install Kali Linux, and stumble their way through it. Metasploit, Armitage (fastandeasyhacking[.]com) /Cobalt Strike, Social Engineer Toolkit, Maltego, Powershell Empire, Masscan, Mimikatz, Bloodhound, and the list goes on. Every step of the process from information gathering to post-exploitation has some form of automation available, with some sort of an integration method from one tool to another. They have been around for years now.

This shouldn’t be news to most security researchers or security operations anywhere. The bigger questions and concerns for you and your enterprise are:

• Why are your company’s assets exposed via Shodan in the first place?
• Did you know that there is a Shodan app for Splunk that we developed that you could use to audit what is exposed, and that we’re working on an open port/services detector app as well?
• Did you not block the Shodan and/or censys.io scanners?
• Have you taken a look at greynoise.io?
• What is stopping you from doing so now (before it becomes suggested that this is merely “security through obscurity”, it is a part (albeit a small part) of a multi-tiered, defense-in-depth strategy)?
• What are you doing to mitigate your risks as quickly as possible?
• How quickly are you standing up alternative mitigations and/or detections to safeguard the systems that cannot be patched in a timely manner?

MineMeld, for all your threat intelligence feed needs

Speaking of recently released material, Hurricane Labs has decided to graciously host some documentation I wrote for an open-source threat intelligence platform produced by Palo Alto Networks, called MineMeld. I’ll spare you the details here, since I wrote a blogpost describing it. Go take a look!