In our previous post, Red Team Finds A Way – Exploiting The Human Factor, we explored how the human element can often be the weakest link in a security chain, and how with proper authorization, it can be ethically exploited to enhance system security.
Today, we’re shifting our focus to the heart of many systems – the design itself. We’ll be dissecting the intricate web of (in)security that can be inadvertently woven into a system right from its inception. We’ll be exploring common design flaws, understanding how they can lead to vulnerabilities, and most importantly, discussing how to identify and rectify these issues to fortify your systems.
So, buckle up and get ready to navigate the labyrinth of secure and not-so-secure design practices. Remember, the journey to a secure system begins with understanding its potential weaknesses.
During the active recon phase, an ASN scan is performed, and upon checking the scan, the following line pops up:
8080/tcp open http-proxy syn-ack Squid http proxy 5.2
Might not be something interesting, as usually, during scanning internet facing proxies can be identified. However, it’s a good point spending some time trying to see if it can be also an ingress point. So, by editing the proxychains config we can use the proxy to try to access the internal network.
You might be wondering which ranges to scan. Upon looking up for private network ranges, we can see the following here:
For a more comprehensive range list with different destinations, you can also check this out.
By kicking off scans, we manage to have a few hits, one of the IPs being a Domain Controller. Prior to external infrastructure checking, the red team operators looked for leaks, and identified multiple usernames and their naming convention.
Using a password spraying technique, a few users are compromised.
Red teaming does not come only in the form of phishing, or exploiting humans. A way of getting within the organization can be exploiting internet facing systems.
If no critical vulnerabilities are identified that can grant further access within the application, or access to the underlying operating system, chaining vulnerabilities might be the only option.
Below, a broken access control was identified, allowing a low privileged user to view data about other users and organizations.
Trying to access additional functionalities, such as inviting users was tried, however, that was not possible.
Looking further within the application it was noted that it was possible to upload SVG files, leading to a Stored Cross-Site Scripting (XSS).
Another functionality was noted that would allow a low privileged user to assign the documents within the organization to other users. However, stealing the cookies was not an option, as the server had the httpOnly flag set.
Two options were viable at this point:
The uploaded files were stored within the application, and upon further testing, it was observed that the application allows uploading HTML files, and due to missing security headers (such as the CSP header) – which is very common, it is possible to gather credentials.
For the initial Proof of Concept (PoC), a simple HTML login page was created by the offensive team to test the viability of this technique. Upon inputting the user and password, the credentials were successfully acquired by the team.
A custom callback server was created in order to gather the credentials, and the login page was customized in a way to mimic the default login. All that was left to be done was to assign the documents to multiple persons, including administrators.
This resulted in multiple administrator accounts compromises, allowing an attacker to login as an administrator user, resulting in the ability of the attacker to seeing confidential data pertaining to users and organizations.
Another very common technique upon gaining initial access to an internal network is slowly spidering the shares and looking for sensitive information.
The stored information on shares can vary, including:
How shall be this information protected within an Active Directory environment you might ask yourself. Well, one of the best methods of protecting this kind of information is implementing strict ACLs on shares to restrict access to authorized users and groups by using the principle of least privilege to ensure that users only have the necessary permissions to perform their tasks.
Going back to share spidering, there are a multitude of tools that can aid in this matter, such as:
So… you spider the shares, and identify sensitive files. Now what?
You can try using them to access applications or do lateral movement, depending on the type of credentials that are discovered. Below is an example of hardcoded MSSQL credentials, which were further used to gain access to multiple databases.
With access to multiple databases, an attacker would have the ability of exfiltrating sensitive information.
Many individuals believe that red teaming is solely about acquiring Domain Admin / Enterprise Admin. But that is a narrow perspective. In actuality, red teaming is about emulating real-world attacker techniques, identifying vulnerabilities, and upgrading defenses. It’s about thinking like a threat actor, not simply attempting to get the keys to the kingdom.
Red teaming’s ultimate goal is to improve an organization’s general security posture. Businesses may significantly reduce the chance of a successful attack by identifying weaknesses, fixing misconfigurations, and strengthening security. Red teaming is a crucial part of an all-encompassing security strategy. It entails modeling actual attack vectors, spotting vulnerabilities, and bolstering defenses to create a more robust security posture.