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
Now imagine if from the BeEF framework you could take control of that user's browser (I'm not even talking about controlling the workstation, I'm saying JUST THE BROWSER is hooked by the attacker). Now image if they could use that hooked browser to attack your internal network. Guess what? The capabilities are all there in BeEF and a book like the Browser Hacker's Handbook has working examples to show you how to do it. The attacker could actually launch a network sweep (via javascript) from that 1 gullible user's browser against the servers on your INTRANET. The attacker can then launch port scans (via javascript) right from that 1 gullible user's browser against the interesting INTRANET servers it found. It gets worse. The attacker can then generate and send vulnerability scanner-like requests via javascript (such as SQL injection discovery) again right out of the browser against a server. Finally, from that 1 gullible user's browser the attacker could send an exploit payload (such as a SQL injection request) directly to a vulnerable server on your INTRANET and compromise it. Yeah, that one Windows NT database server you thought it was safe not to patch. Here's one way it could get popped.
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.
