In my recent, demo-focused Windows Attack and Defense webinar, I attacked a Capture the Flag (CTF) challenge that I designed around the Windows-based Metasploitable 3 virtual machine.
After the attack, I demonstrated how you can break the attack using the open source OSSEC’s active response rules to block the attacker’s IP at the sign of their first port scan. There are a number of other systems hardening measures we could use to block the attack.
- Configure ModSecurity to block an exploit against ManageEngine
- Use an egress ruleset to prevent the shells from connecting back to us
- Apply stronger permissions on the Tomcat configuration file to prevent the password theft
Let’s think about the egress ruleset. In the webinar’s cyberattack path, we use a vulnerability in ManageEngine to get the victim machine to run Java code. For convenience, we have that Java code connect back to our command and control (C2) framework to ask for commands.
What if the defenders had set up a strict egress firewall, ideally on both the victim system and on the data center / cloud provider that hosted that victim system? Our Java code couldn’t connect back to us to ask for commands and send back the output of those commands.
I can imagine that many of you are thinking, “wait, why can’t you just have the Java code listen for C2 on another port?” Well, almost all data centers block incoming traffic very strictly, so it’s highly unlikely that we could send traffic in without having to replace whatever program already listened on that port.
I’m betting that a smaller number of readers are now thinking, “that’s ok – just start up a network sniffer on the target machine and eavesdrop on allowed network traffic, without replacing the programs that should be listening!” Well, you could do that, as long as the victim software has sufficient privilege, but that won’t give your code on the victim machine a way to show you the output of commands. It’s not nearly as useful. Even better, many of your attackers won’t think to or be able to apply the network sniffer-based C2.
So, the egress rule set won’t entirely stop every attacker every time. What will it do? Well, this is where defense is a game of probabilities. The egress rule set will cut the percentage of the world’s attackers who can establish functional C2 on your machines down to a much lower number. If your program didn’t run with enough privileges to establish a sniffer, it might cut them down to near-zero. So, you’re still rolling the dice every day, hoping you win the game, but you’re acting like a casino, choosing the rules of the game so they’re more in your favor. It’s definitely worth the effort.
So, check out the on-demand webinar here and play along using your own copy of Kali Linux, attacking the Metasploitable 3 Windows virtual machine, then pick a defense to break the attack!
Jay Beale, CEO, CTO at InGuardians, Inc.
Jay Beale has created several defensive security tools, including Bastille Linux/UNIX and the CIS Linux Scoring Tool, both of which were used widely throughout industry and government. He has served as an invited speaker at many industry and government conferences, a columnist for Information Security Magazine, SecurityPortal and SecurityFocus, and a contributor to nine books, including those in his Open Source Security Series and the “Stealing the Network” series. He has led training classes on Linux Hardening and other topics at Black Hat, CanSecWest, RSA, and IDG conferences, as well as in private corporate training. Jay is a co-founder, Chief Operating Officer and CTO of the information security consulting company InGuardians.
