I’ve often been in the situation of explaining lateral movement to people who do not work in the offensive security field on a daily basis or have a different level of technical understanding. A lof of these times I’ve not really talked about the ways in which lateral movement is performed, but I’ve taken a step back and first talked about the ‘freedom of movement’ that an attacker obtains when they first enter your environment.
This small nuance helps a lot of people to shift their mindset from ‘I’m not an attacker, I don’t know how they move laterally, that sounds technical’ to a more curious thinking ‘How do you mean, freedom? Do you mean what the attacker can do to move around in our environment?’. Depending on their background & knowledge they’ll then be able to name some ways in which they think that an attacker has ‘the freedom to move’. Now don’t get me wrong, I’m not advocating to change the terminology, but helping people to shift their frame of reference goes a long way.
I think it would help a lot of those people to look at lateral movement from a conceptual point of view, instead of trying to understand all the techniques and ways in which lateral movement is achieved. Thus, here you are reading my attempt at explaining lateral movement in a conceptual manner. The goal is to hopefully enable more people to learn about how they can restructure or design their environments to be more resilient against lateral movement.
In the most basic form, the above image is what many people envision when we talk about lateral movement or network propagation. This however, is open to many interpretations, it also feels outdated, since we now have the cloud and the cloud isn’t a network right? Before we jump to conclusions, let’s first generalize lateral movement into the different areas that are always at play when somebody moves inside your environment. This blog post will explain the concepts of:
- Network
- Identity
- Functionality
After which real world examples will be given of the (ab)use of these concepts to achieve lateral movement. The combination of these three concepts allow attackers to move within networks.
The concepts
The following paragraphs explain the three concepts, please be aware that the concepts can be used on their own or in conjunction to allow an attacker to move laterally through your environment. Usually a combination of them increases the speed with which an attacker advances, but this is not a requirement.
This blog illustrates the concept using nodes, a node can be any entity within an environment. Even though your first instinct might be to place this within your frame of reference of ‘on-premise infrastructure’ it also applies to cloud infrastructure or a single webapplication where an attacker could move horizontally or vertically within just a single application.
Network
A network is what connects different parts of your environment, whereby each node on the network normally receives a unique ID so that it can be addressed by others. We are usually acostomed to TCP/IP or UDP, but other protocols and solutions exist to create networks on which the different nodes can communicate with each other. Whereby each node can send as well as receive multiple incoming connections with a wide variety of protocols.
Like we can see in the simplified image above, depending on which node the attacker lands, they will have a different form of freedom of movement. We are assuming that lines not drawn, are not possible. Which unfortunately is a very big difference compared to real world networks, where we usually do not know what is possible.
What we can also observe, is that each node can potentially provide or reduce the freedom that an attacker obtains. For example, pivoting onto node C, doesn’t seem to yield any extra freedom to the attacker, on the contrary it is a dead end. However if the attacker pivots onto node B, the attacker is able to reach node D, which is otherwise impossible directly from A.
All of the above is regardless of the ability of the attacker to exploit the other nodes. The network provides the freedom the attacker requires to at the very least be able to communicate with the other node.
Identity
An identity governs many things, amongst others who you are and what you are allowed to do. You should interprete this in the broadest sense possible, varying from who can logon to what computer or who can read a file to who is allowed to make a specific API call or request certain privileges within the environment.
The image above illustrates that this particular user doesn’t have access to finance information. A different user might very well have access to only finance information, but not the rest. Now, unfortunately this concept is an overly simplified example. Why unfortunately, you might be asking? Well even for just folders imagine thousands of files, folders, some nested some not and with different identities having different privileges on what they can do with those files and folders. A true horror story.
If the above boggles your mind, then what about if we extend identities to what happens on the machines, things like process creation, memory access or if we extend it to applications instead? Who can read the log files, who is allowed to create users? What exactly is an ‘admin’ privilege, this might mean different things depending on the context.
In addition, most of the time we don’t have control over the identities in the environment, we pretend that we have control, while in reality we don’t really know what exactly constitutes the identity! What exactly determines who the identity is and what exactly enforces the privileges, this changes very rapidly depending on the context in which the identity is used!
In the above image we can see that depending on which node the identity is used, it can have different privileges. This applies to a lot of different setups and environments, thereby making it difficult to sometimes ascertain exactly what privileges an identity has. Identities also don’t exist just in the central place where they are configured and assigned their privileges, they also live on the nodes or environment on which they are used. The following image depicts this:
The above also further complicates the secure management of identities, since if an attacker compromises this node, they achieve access to multiple identities with different privileges. Since we want to understand the concept, we are for now ignoring additional security measures. By now, you have probably guessed it, the more identities an attacker collects,the more freedom the attacker obtains. Try not to go into defense mode now thinking about MFA or other security measures, conceptually if an attacker is able to get hold of an identity the attacker will have increased their freedom of movement.
An identity allows the attacker at the very least to pretend to be that identity and exercise the same privileges that belong to the identity.
Functionality
Functionalities are often the least understood concept in the realm of lateral movement, when we want to understand the freedom that our environment provides to an attacker. A functionality is just that, a functionality offered by anything in your environment, whereby the functionality can be known or unknown. OK, I admit, this is a pretty fuzzy explanation, but stick with me, I’ll clarify using the following image:
On the network level the firewall ensures that the client is only able to use the required protocol on the required port on the node that requires it. On the identity level, we have almost reduced the amount of identities to the only ones required, but due to some oversight the server side contains two identities: a regular user and a user with adminstrative privileges.
If we assume that we conceptually understand the network aspect as well as the identity aspect, we are left with the aspect of which functionality are we allowing to exist in our setup?
For starters the used client software, the used server software as well as the implemented protocol can contain functionalities that are:
- Documented, but we are unaware of the functionalities or unaware of their configured state
- Not documented, thus we don’t know about the functionalities or their configured state
- Unintended, thus we might learn about the functionality, but this is not guaranteed
Now the important, mind-bending concept to grasp is that vulnerabilities are unintended functionalities. So, we need to not only worry about legitimate documented or undocumented functionalities, but we should assume that any part of our setup could contain vulnerabilities. These are either unknown, or known but unaddressed since we could not or would not want to apply the appropiate patch or mitigating security control.
Functionalities can be anything ranging from intended functionalities like for example the ability to transfer files, to unintended like forgetting about old functionality that allows for code execution after authentication to like really unintended by having a vulnerability that allows to remotely read sensitive information.
Real world examples
The following paragraphs will apply the previously explained concepts of network, identity and functionality to real world examples. These examples are not intended as examples that can always be fixed, but as examples to practice the application of the concepts that we just learned. For all the examples, this setup will be used as the base upon which we will expand:
Remote Desktop
The Windows remote desktop solution allows a person to connect with a server and it will be as if the user is sitting behind the keyboard. This allows a wide variety of valid business designs which are things like finance applications that due to licensing must be shared, or remote administrative work or provide working from home setups (not recommended from a security perspectice, but valid from a business perspective).
The remote desktop protocol and software implementation also allows users to share their own hard disk and all the folders and files on it with the remote server that they are connecting with. This is not specific to the Windows implementation, different solutions like Citrix and others, also contain similar functionality.
If all users when connecting to node-B have that functionality enabled, it creates an interesting situation. Even though network access is restricted by the firewall, user-A can access node-B since it is intended functionality. The question then becomes:
- Does user-A have sufficient privileges to write on the shared folders that the other users have exposed?
If the user does have sufficient privileges, and this really depends on how the drive is shared, user-A can place malware onto the computers of user-B, user-C and thereby move laterally as well as escalate privileges.
If the user doesn’t have sufficient privileges then the vulnerability question or as we have conceptually learned: unintended functionality; starts to play a role. If the server is not patched or the attacker has an unknown vulnerability they can acquire more privileges that allow them to write to the shared disks and move laterally. The end result being that user-A can collect the identity of user-C and thus obtain administrative privileges.
However, what happens if the network concept would be less strict, like in the following version of our initial setup:
Suddenly, the attacker has more freedom of movement, since there is no firewall between A->C and B->D, they can try to setup a remote desktop session to those nodes. It then boils down to the question: Does their current identity have those privileges? Of course, assuming that node C, D don’t have their local host based firewall enabled.
The other freedom obtained by the attacker in this new situation is that they can freely poke, probe & experiment with those nodes. If the nodes expose anything that can be used to compromise them, the attacker will have successfully gained lateral movement. For example a protocol that allows the attacker to negotiate a ‘no password check’. Reality really is weirder than fantasy.
File transfer protocol
In a Windows environment a lot of people are familiar with a file share and the corresponding SMB protocol. For the security geeks, don’t panic, I’m consciously taking a shortcut on the technical correctness to enable the readers to understand the concept.
However, what if this protocol also allows for the execution of code remotely as long as the user has sufficient privileges? This is again an example of documented, but maybe unaware functionality that can be used for lateral movement.
The Windows SMB example is the most known example, but depending on the implementation there are examples of FTP software allowing the execution of commands on the remote server. A protocol of which we often think it can only transfer files from A->B.
If we stay in the conceptual realm, this also applies to for example database protocols and their implemnentation which also allows for remote command execution depending on the exposed functionality and the used identity.
Application servers
not it! Or at least, sometimes that is the common thought within corporate environment of who is responsible for the application servers or middleware. Our setup has again been expanded:
We now have an extra firewall, so we are secure again! Well no, like we know by now. We do have an uncertainty however, which identities have privileges on nodes C, D, E? Just like in many real world examples, this is unknown.
So if we assume that our previous real world examples have been successful for the attacker it means they have control over three identities as well as nodes A, B. So they still have to compromise C, D. In this example that could happen by applying any of the concepts that we have been talking about, since they have full freedom. Yes, they could fail, but it sure is a lot of freedom for the attacker to explore and try to find that one hole to gain access.
Conclusion
Hopefully this blog has equipped you with a conceptual understanding of lateral movement as well as the freedom that attackers have in networks that are not designed or configured with these concepts in mind.
As a bonus, I hope that you concur with me that we can conclude that things like ‘just microsegmentation’, ‘just zero trust’, ‘just patching’ do not really solve the lateral movement problem. They diminish one or multiple dimensions, but don’t solve it. Since by now, we should have learned that general measures like segementation and least-privilege (don’t quote me) probably reduce like 70% of the lateral movement options, but the available functionality still has a big say in how an attacker can go from node-A to node-B or from identity-A to identity-B.
DiabloHorn 
One thought on “Lateral movement: A conceptual overview”