I was reading the Browser Hackers Handbook and thought it gave a great example of why you should take hardening your internal INTRANET seriously. By INTRANET, I mean all those servers inside your network, such as the ones that handle employee email, payroll, ERP systems, file servers, print servers, database servers, collaboration, etc. Why? Well my story starts with BeEF, the Browser Explotation Framework, which automates and simplifies attacking a browser for the bad guys. In many cases it can turn an attack against a browser from lots of lines of complex scripting language code into a simple mouse & click for the attacker. One feature in BeEF is the BeEF Bind shellcode which as I see it is a great example of why you need to take hardening your internal INTRANET seriously. Here is a diagram of how it works. I'll walk through in a bit more detail below.
Phase 1, the click-happy employee
Imagine you have 1000s of employees at your company, but just 1 gullible employee. That's all the attacker needs. Imagine they tricked that user via a phishing email to click a single malicious link. That link hooks the user's browser (could be Chrome, FireFox, Internet Explorer, etc.) with the BeEF framework. Now you're probably thinking that the user's workstation could get compromised somehow, maybe some ransomware gets installed, etc. But what if there were more possibilities?
Phase 2, a compromised browser can be as powerful as a compromised computer
Phase 3, the compromised server never phones home, it just talks to the employee's browser!
Now all of that is fascinating and scary especially since it's highly like that of your 1000s of employees, at least one of them is going to accidentally click on a malicious email. But what if there was more? Imagine that the attacker somehow managed to successfully use the scenario above and compromise an internal server. What if your networking team was amazing and awesome and has egress (outbound) network traffic from servers locked down tight. So the attacker is stuck. He has a compromised box, but he can't actually get it to communicate out or phone home to his C&C (command and control). No problem, the BeEF Bind Shellcode actually delivers a solution to that problem. That compromised server can still communicate with the gullible user's workstation, right? So the BeEF Bind Shellcode actually proxies or funnels all communication in and out to that compromised server via that 1 gullible user's browser. That is the part I find fascinating and the scariest of all is that all this malicious traffic, compromised activity, command and control traffic, data exfiltration, etc. is all essentially happening through a browser over port 80/443. That's a big problem.
Imagine you were the good guy trying to determine when this type of activity happens. It might be a bit of work but relatively speaking not too difficult to lock out egress (outbound) traffic from servers or to monitor it with an IDS or other devices looking for suspicious traffic. But it becomes harder to monitor a user's workstation web traffic. There's just soooo much of it, every page generates soooo many requests. But it becomes incredibly more difficult if you also have to also watch the traffic from a user workstations to internal INTRANET servers. And it also makes it hard if that traffic you have to watch is web traffic (port 80, 443) and intermingled and mixed in on the same port and protocol as all the legit normal traffic. Yikes.
While several monitoring tools like IDS, endpoint agents, etc. can do a lot towards catching this kind of traffic, one of the most important pro-active steps you need to take in order to prevent this type of issue is to harden your INTRANET just like it's the wild west, just like it's on the Internet, patch early and often. Assume that your internal INTRANET has attackers already inside lurking around every corner, hooking random browsers , workstations, and other devices ... and harden your systems to make it difficult for them from to pivot and move around and find what they want.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.