In the brief A Red Teamer View of Attack Surfaces, I laid the groundwork for the conversation about attack surfaces. More recently, in the second part of this series of briefs, A Red Team View of Attack Surfaces: Public, I talked about how Red Teams see your public attack surface. Both provide a more adversarial view of your attack surface to better align the conversation with the real-world threats you need to consider when protecting both. With a better understanding of public attack surfaces and how they can open the door to your internal network, we can move on to internal attack surfaces.
How Red Teams see your attack surface
Red Teams target your internal network when they can only achieve their objectives with internal access. To reiterate, your internal network is where you keep assets you don’t intend to have publicly accessible (see my previous briefs linked above for more details). The biggest misconception, and one that is heavily leveraged by Red Teams, is that your internal network is free from threats and “more secure” than your public attack surface. Once a Red Teamer gains a position inside your internal network, they tend to face a very different situation than the public attack surface. Systems are less hardened, less frequently patched, and in most cases access is much more open. Once again, I will simplify the Red Teaming process by removing technical details and help you understand, at a high level, how Red Teams operate within internal networks.
Stage 1 (situational awareness)
After a Red Teamer gains a foothold inside your internal network (e.g., via a phishing attack), they gain control of a single system (we will call it system A). This means they can partially act on behalf of the user whose system they compromised. I say partially because you don’t immediately gain access to all credentials, hardware devices used for authentication, and applications authorized to perform actions. From this position, a Red Teamer needs to achieve a few things. One they need to understand the system they’re on, where they’re in the network, and what permissions they have gained or can gain from this system. Once they have this information, they can determine whether the next stage is necessary or whether they can achieve their objectives with the access they already have.
Stage 2 (lateral movement)
After collecting enough information from the initially compromised system, a Red Teamer may decide they need to “laterally move.” This concept is tricky for people to understand who don’t work in or with Red Teams, but put simply, it’s using their access to move to another system in the network. As an example, if I don’t believe I can achieve my Red Team objective on system A (Our initial position from stage 1), I will need to move to another system that may have more permissions, access to different networks, or one that is authorized to access the asset I am trying to reach. To keep the example simple, let’s say the Red Team moves from System A -> System B to position themselves to achieve the Red Team’s objectives.
stage 3 (action-on-objective)
Action-on-objective is the final step, where we carry out our objective. All prior steps served to complete our final objective (in this example, we will use a database called Database C). System B, which we “laterally moved” to from System A, gives us access to the asset we intend to access. We can now use System B to verify access to Database C. Exfiltration of this data to our Red Team-controlled server will be the final step. After this step is complete, the organization will have lost the data. If further goals are needed, the Red Team would move back to stage 1 to start the next steps.
What makes it easier for Red Team, and therefore adversaries
Internal attack surfaces can be very complex and difficult to manage. In my 10 years of experience as a Red Teamer, however, it seems that 3 characteristics make my exercise objectives much easier to achieve and, therefore, much easier for an adversary to achieve. I’ll walk through each one below.
credential access
When a Red Teamer gains their first position, they begin collecting any credentials that may be useful to their objectives. In many cases, credentials are easy to access, and some even grant access to larger stockpiles of credentials. For example, on system A referenced above, the environment variables (credentials loaded into the system required to run the service or application) may provide several useful credentials that can be used to access other systems and enable potential lateral movement. In many cases, the credential itself isn’t the problem, since some systems require them to operate. The bigger problem is that many credentials are scoped for broad access, making the compromise of a single credential devastating.
Excessive permissions on group access
As referenced before, widely scoped permissions can be devastating to an organization. However, this isn’t limited to credentials. In some cases, actions such as access to build software are unnecessarily scoped to huge audiences. For example, a build group we will call Build Group A may grant most of the organization the power to build and ship software. For a Red Teamer, this means that if they carry out a successful phishing attack, such as the one described above, and gain access to System A, that alone may be enough to carry out a supply chain attack because of the overly permissive group access.
lack of network monitoring
When network monitoring and controls don’t exist, it becomes far too easy for Red Teams to get into your network and maintain long-term access. It also makes exfiltration (removal) of data from your network easy and allows an adversary to do this continuously without resistance. At a minimum, organizations should collect logs on outbound traffic and correlate them with threat intel so they can understand when their systems are reaching out to known threat-actor-controlled servers. However, more robust network monitoring is required to disrupt a more advanced Red Team and other adversaries from carrying out their objectives.
the competitive advantage of managing your internal attack surface
Your internal network is intended to protect your most critical assets, including data, build systems, and source code. If these critical assets are removed from your network, you can lose intellectual property, suffer reputational damage, and incur financial losses from market disruption. Protecting these from competitors, nation-state threat actors, and criminals can help you maintain a competitive advantage in the market. Not to mention, incident response exercises, ransomware payouts, and regulatory fines can be huge (More details in my brief about public attack surfaces). Organizations with mature security protect their internal networks the same way they protect public networks and don’t assume they’re impervious to attacks.
You can look forward to more content on attack surfaces in the future…