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.