Category: Recon
Hunting for SAP

Hunting for SAP

By |

SAP systems, especially Internet-facing ones, are often an overlooked attack surface for many organizations. SAP systems can contain several misconfigurations such as:

  • Outdated software
  • Sensitive information set to “Public”
  • Weak and/or default login credentials
  • Other good stuff

When analyzing the attack surface of your organization, or during a penetration test, it is important to look for these SAP systems. Generally, a web-facing SAP system will run on port 80, 443, 8080, or other common web ports. Internal SAP systems may use ports 3200-3399, 3600, 8000, 8100, or 50013-59914. To find these systems, simply run an Nmap scan such as the below. (DISCLAIMER: Only run the suggested tools on systems you have permission to scan!)

Example: “nmap -sV -p 80,443,3200-3299,3600,8000,8080,8100,50013-59914 “.

Be on the lookout for services that have “SAP” or “Netweaver” in the name.

Once some potential SAP systems have been identified, boot up Metasploit and look for the “sap_icm_urlscan” module. This module is very useful for “scanning” an SAP web server for directories that potentially should not be publicly accessible.

The above outputs show several SAP directories discovered. Some of these directories look pretty juicy (admin, soap_management, etc.)!

Now, open up a browser and take a look at a few of those directories. You may find some information that should not be Internet accessible. A few examples of what should not be on the Internet:

Some of the information that can be gathered from the above pages is:

  • System monitoring and status
  • Internal network hostnames and IP addresses
  • Detailed SAP software version information
  • SAP system logs
  • Host operating system versions and information

Attackers can use this information to launch other attacks on the SAP system, or potentially use this information to exploit a flaw in a connected system.

Well, that’s it for now. Hopefully this has motivated you to look into your Internet-facing SAP infrastructure. Good luck!

 

Subdomain Attack Surface Discovery – Part 2

Subdomain Attack Surface Discovery – Part 2

By |

Welcome to Part 2 of Subdomain Attack Surface Discovery! If you haven’t read Part 1, I would do that first… Otherwise confusion may follow. Assuming you are continuing after Part 1, let’s get back to our list of subdomains.

But first, a much-needed disclaimer.

DISCLAIMER: The tools and techniques in this post should only be run against hosts that you have permission to scan!

Ok, back to business.

In order to start taking a deeper look at the Internet attack surface to see what’s out there, we need to perform some light enumeration of the targets. My chosen tool for this is Nmap. Some have suggested the use of masscan for this instead of Nmap. I like masscan for extremely large quantities of hosts, but Nmap tends to work for me just fine for a “normal” number of hosts.

Generally, I only scan for the top 20 ports (nmap Top 20) to keep the scan quick and not to attract unwanted attention, but you can tailor this to fit your recon style.

Command: “nmap -vvv -sS –open –top-ports 20 –max-retries 2 -iL import_filename.txt -oA export_filename”

Let’s quickly dissect this nmap command. The “-vvv” puts Nmap in “very verbose” mode, meaning that there will be a lot of output and feedback. The “-sS” tells Nmap to run a more stealthy SYN scan. “–open” tells Nmap to only show open ports. “–top-ports 20” tells Nmap to only scan for the most common 20 ports – these are generally all we need for this initial reconnaissance. The “–max-retries 2” tells Nmap to stop probing a target port if a certain number of “retries” occurs. In a nutshell, this will speed up the scan. “-iL import_filename.tx” is the list of IP addresses and hostnames that you want to scan. From Part 1, this is the list of subdomains we discovered. Finally, “-oA export_filename” is the export file name. This will send the output of Nmap to 3 different file formats that can later be used.

Here is some of the information returned from the Nmap scan:

Here we see some standard web ports such as 80 and 443. These ports are hosting web services. Sometimes you will find more peculiar ports open, such as the below output:

Hosts such as this should be looked at more closely to ensure the open ports have a good reason for being open (e.g., providing services to the end-user).

Next, I run my favorite recon tool – Eyewitness. Eyewitness was written in Python and it simply takes screenshots of websites, and RDP and VNC login screens, and is a GREAT tool for quickly figuring out which hosts and subdomains look interesting and warrant further “review”. Let’s run an Eyewitness “scan”.

Since Eyewitness will navigate to all the subdomains and attempt to screenshot them, this tool can take quite a while to complete. Usually I will start an Eyewitness enumeration and go do something else for a few hours (or the day).

Command: “python EyeWitness.py –all-protocols -x nmap_file –timeout 15 -d output_file”

The Nmap input file should be the output of our Nmap scan from above. The output file name can be named anything.

Eyewitness reports output in HTML format, so you can open the result files in a web browser. After open the results in Firefox, I can see that various types of web pages were discovered. What we want to look for here are login portals, misconfigured web pages or applications, weird errors, or obvious potential issues such directory indexing and SQL errors.

Let’s take a look at our results. This is the type of stuff to look for:

Login portals, such as these:

Error Messages / Strange Output, such as these:

Misconfigured Web Pages, such as the below:

Or, Information about the backend infrastructure, such as the below:

These are only examples – Anything that looks out of the ordinary or peculiar should be inspected further. Usually this combination of tools and techniques can help you get a quick overview of the Internet attack surface of your organization, and can also be used in bughunting.

Please leave comments if anything is incorrect or if you have a better idea for the execution of these techniques!

I am currently working on a Python script that automates this tool chain and will write about it in the another post.. I know there are many tools and scripts out there that do similar recon, but I always find it safer to rely on a tool chain instead of a single tool that does it all – you never know when the developer stops supporting the “do-it-all” tool. With a tool chain, you can also include new tools and scripts (or take them out) in the chain any time you need!
Subdomain Attack Surface Discovery – Part 1

Subdomain Attack Surface Discovery – Part 1

By |

Analyzing your Internet attack surface is an important step in an overall security program for any organization. If you are a network defender or attacker and haven’t analyzed the Internet attack surface of your organization, you are doing security wrong. But that’s ok – I am here to give you a few simple tips on how to discover the subdomains your organization owns, and how to enumerate these subdomains and find potential attack surface that the bad guys can use to infiltrate the network.

Ok, let’s get started.

DISCLAIMER: The tools and techniques in this post should only be run against hosts that you have permission to scan!

Subdomain Discovery

There are many great tools for subdomain discovery, but for the purpose of simplicity, I chose to focus on a few of my favorites. These are:

The first step in discovering your Internet attack surface is identifying your organization’s subdomains. These pesky subdomains can pop up all over the place (shadow IT, developers bringing “test” and “development” systems online, etc.) and need to be wrangled in order to discover what’s out on the Internet Wild Wild West that attackers can target.

Sublist3r is a great Python script that performs various recon techniques to gather subdomains from the web. It utilizes search engine reconnaissance, various domain information sites like Netcraft, and threat research repositories such as Threatcrowd and Virustotal. Download it and try it out now:

Command: “sublist3r.py -d example.com -o sublist3r.out“

Make sure to replace “example.com” with your target domain.

Next, I bring in the big guns – subdomain brute-forcing. This technique will attempt to resolve a list of subdomains for the target domain. I generally use Subbrute.py as my go-to tool for this technique, but there are many other options. (Hint: Do a Google search and find some more tools!).

Command: “subbrute.py -v -s names_small.txt -o subbrute.out example.com”

Subbrute found a number of additional domains that you can now add to your ongoing subdomains list. Subbrute supports the ability for you to choose the list of subdomains to brute force – in my case, I used “names_small.txt”, which comes prepackaged with Subbrute. This is a smaller list that takes roughly 15 – 20 minutes to complete (your mileage may vary), but you can use a larger list as well, such as the default “names.txt”. The larger your list, the more subdomains you will potentially discover.

After subdomain brute forcing, I sometimes use various Recon-ng modules to catch the subdomains that may have slipped through the cracks. Recon-ng is an awesome suite of tools for performing all kinds of reconnaissance and OSINT. I will not be covering Recon-ng in depth here, but there are a lot of great resources on the net.

My favorite Recon-ng module is the Shodan module, which queries Shodan for target subdomains. This module will require a Shodan API key, which you can get for free when you register for a free Shodan account. Let’s use the Recon-ng CLI to run a Shodan search for other subdomains.

Command: “recon-cli -m recon/domains-hosts/shodan_hostname -o source=example.com -x”

As you can see, Recon-ng and Shodan picked up some additional subdomains! Recon-ng has a ton of additional modules so make sure to research this a bit more.

Now we need to output the list of subdomains from recon-ng into a useable format. The following command will export the results to a nice text file:

Command: “recon-cli -m reporting/list -o column=host -x”

Finally, I combine the output from Sublist3r, Subbrute, and Recon-ng into a single text file, ensure there are no duplicate subdomains, and I now have a nice list of subdomains!

And that wraps up Part 1 of Subdomain Attack Surface Discovery. In Part 2, I will discuss how to weed out the invalid subdomains, enumerate these subdomains, and find potential vulnerabilities to look at more closely. Stay tuned for Part 2!