Why I love Nmap

NMap & Why I love it!

‍

Where can I get this tool?

Where can I learn more about this tool?

Everyone has a favorite tool they enjoy using for one purpose or another. Today I wanted to go over a tool that I really enjoy and find hard to beat given alternatives. I’m not going to go over every option, but I did provide two links above where you can read and learn more about the tool. I just wanted to show two practical scans and how one of those scans can lead to additional stages in our attack pipeline. Sometimes an old hammer is simply better than a new lightweight hammer. Let’s dive into a few uses of Nmap and walk over the simplicity and effectiveness of the tool itself. I’ll spare you the details of performing some recon work before the enumeration phase of our attack. Let’s set the stage!

‍

We have a host running Docker and a host running Jenkins for CI/CD workflows.

‍

Our Docker host resides at: 10.10.1.10

nmap -sV -p- -T5 10.10.1.10
Nmap scan report for 10.10.1.10
Host is up (0.00067s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
--- Omitting non-relevant data ---
2375/tcp open docker Docker 19.03.8
--- Omitting non-relevant data --- 

Well, how embarrassing is that? It looks like a DevOps engineer has exposed the Docker engine port on TCP 2375, which means we can most likely utilize it remotely by creating containers and doing nefarious things with malicious intentions! Let’s hope Jenkins fairs much better.

‍

Our Jenkins Host resides at: 10.10.1.15

nmap -sV -p- -T5 10.10.1.15
Nmap scan report for 10.10.1.15
Host is up (0.00089s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
--- Omitting non-relevant data ---
8080/tcp open http Jetty 9.2.z-SNAPSHOT
50000/tcp open http Jenkins httpd 2.60.3
--- Omitting non-relevant data --- 

‍

It looks like there isn’t much here other than Jenkins running, and nmap can’t detect the Jenkins service that is serving web content on port 8080. Jenkins services the administration web content on port 8080, and port 50000 is used to connect other nodes. Not much can be furnished from the scan results since we only discover the services running with the given output.

So now what? We could enumerate those services further and certainly look for exploitations with the docker exposure discovered. The whole reason I love Nmap is that you can get some quick information on a host or service and then run with it to further your attack surface. This is great for red teaming or blue teaming, and let’s not forget a worthy mention of purple teaming! It’s simply a tool that you can find on just about every Linux distribution, and it’s a quick install for Windows. You can take the tool further if you work with the scripting engine, which can be pretty useful. For these two reasons, I really love Nmap as a tool, and it’s practically on every system I own and operate with for CTF events.

But wait?!?! You stated the docker port was a “NO NO.” Yes, and I did mention I was sticking to Nmap here. But let me give you this Gem. If you install Docker on your system, then you can attempt to interact with the remote system by issuing the following command in your terminal of choice: docker -H 10.10.1.10:2375 ps -a

Now, if you get back a listing that shows some running containers, then you’ve pretty much hit the jackpot and can now work on gaining some remote functionality with your very own nefarious containers. For example, pulling down the Kali Linux image “docker -H 10.10.1.10:2375 pull kalilinux/kali” and then checking to see it downloaded fine with “docker -H 10.10.1.10:2375 images” and from here, if you’re seeing a pattern it’s this: You can use docker commands remotely the same way you use them locally, so enjoy your new kali container and have fun working on the remote Docker network.

‍