CompTIA CYSA+ CS0-002 – Analyzing Lateral Movement and Pivoting IOCs Part 1
In this section of the course, we’re going to discuss how we can detect and analyze lateral movement and Pivoting indicators of compromise. Now, in this section, we’re going to continue to focus on domain four with our focus on Objective 4. 3. Objective 4. 3 states once again that given an incident, you must analyze potential indicators of compromise. In this section, we’re going to focus on lateral movement and Pivoting IOCs. Now, as we move through this section, we’re going to start with looking at what lateral movement and Pivoting really are and how detecting them can help us identify malicious activity within our workstations and servers and our networks.
Now, after we do that, we’re going to move into some common IOC types and how we can best identify them. This is going to include attacks like passing the hash, the use of a golden ticket, as well as other lateral movement and Pivoting techniques. Finally, I’m going to perform a demonstration where we’re going to analyze some lateral movement and Pivoting activity inside our lab so that we can better understand what various attacks look like when we’re working as an analyst. All right, let’s get started analyzing our workstations and servers to see if we can find any lateral movement and Pivoting across our systems.
Lateral movement. And Pivoting, if you’ve ever watched American football you’ve probably seen a lateral pass. Now, a lateral pass occurs when the player tosses the ball to a teammate by throwing it to the side or behind them and that way you’re moving the ball to another player instead of towards the goal. Now, this doesn’t mean they aren’t still trying to make further progress towards the goal but at this particular point in the game it’s more important to get that ball to another player and away from the one who’s holding it for example, the quarterback because somebody might be trying to tackle them. Now, by going laterally you’re not really making forward progress but you are getting it to a new position where you can then see if there’s another opportunity to move the ball forward.
If you’re lucky, you may be able to get an additional five or ten yards closer to the goal line because once you catch that lateral pass you can turn and start running forward. Now, why am I bringing up this idea of a lateral pass? Well, because it’s very similar to the concept known as lateral movement than an attacker might do inside your network. Now, lateral movement is a technique to progressively move through your network to search for key data and assets that are ultimately the target of the attack campaign. As the attacker does this they’re trying to search for more and more ways to get to their end goal. And a lot of times that just means they’re moving to the side and not forward and deeper into your networks. For example, let’s consider the following network.
Let’s say that an attacker got one of your wireless clients and they were able to exploit it. They may have used an exploit or a phishing campaign or something else but for whatever reason they now have control of that particular system. Now, from that single point they can start searching out the rest of the network. This is what we’re doing as part of lateral movement. So they start looking at the other clients in the wireless network by doing reconnaissance and doing port scanning and doing pinging and doing all sorts of things like that. And then they might go further and they go after the backbone switch and then they start doing reconnaissance against the other switch. And there we see three more machines in a printer. And then they look and they see a bunch of servers.
And as they keep going through and doing this reconnaissance and searching they’re doing this as a means of preparing for further movement. This is the whole idea with lateral movement. Now, one of the ways you can start identifying lateral movement is to identify any irregular peer to peer communication. This can help you identify lateral movement because, again, most of the time when attacker gets an initial point on your system that first laptop they’re going to then start searching what else is out there that they can further exploit and laterally move on to. Now, another concept that often comes up when we talk about lateral movement is the concept known as pivoting. Now, Pivoting is the use of one infected computer to attack a different computer.
Now, this is an important concept because pivoting is going to use the compromised system to attack other systems on the same network to avoid the restrictions, such as firewall configurations that prevent them from attacking from the outside directly. Now, we’re going to cover more about lateral movement and pivoting as we go through the rest of the lessons in this section. And I want you to keep in mind that oftentimes lateral movement and Pivoting, although they sound very similar, they are distinctly different. But security professionals will often use them interchangeably. As we go through this section of the course, I am going to use them in their unique method of lateral movement, moving laterally and Pivoting being to use a single system to attack other systems on the network.
Pass the hash. In this lesson, we’re going to talk about the Passthehash attack. Now, Pass the hash is a network based attack where the attacker steals hash user credentials and uses them as is in order to try to authenticate to the same network that the hash credentials originated on. Now, this is a really complicated way of saying that somebody can steal your password without actually stealing your password, but instead there’s stealing your password hash and they’re using that to authenticate to your network. Now, this allows them to have the possibility of presenting that hash without cracking the original password and still be able to authenticate to network protocols such as SMB or Kerberos on a Windows network. So how does a Passthro hash attack actually work? Well, first we have a regular user, in this case our victim, who’s going to log on to a machine.
When they do that, the DC, the domain controller, is going to verify that user using Kerberos. This takes their username and their password, or more accurately, the hash of their password, and verifies it with the domain controller. Then we have the user that logs on again a second time. And whenever they log in a second time, instead of going back to that domain controller, it just uses the actual cache that’s stored inside the Sam on that workstation. This is done through Kerberos. So by having that, we don’t have to go back to the domain controller each time. Now, in our third step, we have an attacker who’s actually going to gain access to that workstation using some kind of exploit. Now, whatever specific exploit they’re using doesn’t matter here.
It’s just that the attacker gains access to that workstation, and that workstation. Once they’re on it, they can dump the Sam, which has those hash credentials stored on that victim’s computer. Now, once the attacker has dumped that Sam, they can use tools to get those hash credentials and reveal what they are having those hash credentials, the attacker can then use that hash on another computer by being able to log in as that user or on that same computer. If that computer happens to be part of a domain, we can also use those hash credentials that are recognized by Kerberos on other servers within that domain. And so this is the danger here when we start dealing with past the hash. Now, Pass the hash can be used for lots of different things, but one of the most common things it’s used for is to elevate privileges.
This is done because a lot of times on those local workstations, the attacker is able to gain local admin privileges because at some point, some admin had logged in locally to that workstation, and those credentials are going to be stored inside the Sam that the attacker was able to dump and then gain the credentials. From now, to do this, they’re usually going to use some sort of a tool because it’s easier to use an automated tool to do this for you. And as an attacker, one of the most common ones we’re going to use is Mimi kats. Mimi cats is an open source application that allows users to view and save authentication credentials in order to perform past the hash attacks and other types of attacks like that. Now, the way Mimicats works is to scan the system memory for any cache passwords.
All these passwords have been processed by the local Security Authority Subsystem Service, or LSASS Exe. Now, once they’ve been stored in this cache memory, mimikats can grab those and find those hashes and then pass those to log you into other services. Now, Mimikats has been incorporated into a lot of different penetration testing tools and other tools that attackers use. For example, the Metasploit Framework as shown here on the screen. Notice with one simple command use post Windows, gather smart hashdump, we’re able to run this command and it will go through and it will run this module against a given target. In this case, it’s going against this Windows machine shown here. It’s going to go through and grab any of the hashes it finds and dump those to the screen as well as into a file.
And in this case, we find the administrator’s hash shown here on the screen. Now, using Mimicats, we can use that hash and use that to log in as the administrator and perform further actions. Now, for the exam, it’s important to remember that specific tools like Mimikats and the Metasploit Framework are not covered by the CompTIA’s CYSA Plus exam. But if you do move into CompTIA’s Pentest Plus certification later on, you will be expected to know them and how they operate.For this exam, though, you just need to understand the concept of pass the hash and what it looks like. Now, let me give you a quick warning here for the real world. In the real world, you want to make sure that you’re only using your domain administrative accounts to log into domain controllers.
This will prevent past the hash from exploiting your domain, because if you use your domain administrative accounts and use them on a regular workstation, and that workstation is compromised, at some point they can grab your credentials from that workstation and use it across the entire domain. For this reason, again, domain administrative accounts should only be used to log on to your domain controllers. Now, you may be wondering, this sounds really bad, Jason, but how can I detect and mitigate against a passthash attack? Well, there’s a couple of things you can do. First, it’s important to remember that detecting these types of attacks is extremely difficult because the attacker activity cannot easily be differentiated from legitimate authentication because these stolen credentials are allowing the attackers to use standard authentication mechanisms with valid credentials to log in.
This creates audit logs that appear to be legitimate user activity. And so this is something that is very hard to detect in real time and instead is easier to find after the fact when you’re trying to put together your timeline of a breach that’s already occurred. The second thing is that most antivirus and antimalware software are going to help you mitigate this by blocking any tools that allow past the hash attacks. Things like Mimikats or the Metasploit framework. Those will all get blocked by most antivirus and antimalware softwares. Now, even though this is true, some attackers will try to still use these tools, and they’ll try to evade signature detection by doing binary packing and other techniques.
But again, these antivirus and antimalware tools should be able to detect most of those tools and try to prevent them from being used on your systems. The third thing to keep in mind is you want to restrict and protect high privileged domain accounts. As I said, your domain accounts should only be logging on to your domain controllers or specific workstations. By limiting the number of workstations you’re logging on to with those domain accounts, you can protect those credentials and make sure they’re not used in one of these types of attacks. The fourth thing is to restrict and protect local accounts that have administrative privileges. Again, by reducing the number of accounts administrator privileges, you can end up minimizing the attack of a pass to hash attack.
And our fifth thing we want to think about is to restrict inbound traffic using Windows Firewalls on all of our workstations except for specific ones for the help desk security compliance scanners, and other servers in your domain. By restricting inbound traffic going towards your workstations from the outside, you can cut off a lot of these attacks before an attacker can get into your system. All right, so now that we’ve talked about our five mitigations, let’s talk about how we can detect a paSsth attack in real time using an IDs signature. Can we do that? Well, maybe. Let’s take a look at a sample signature. Here on the screen we have a sample IDs alert. Now let’s take a look at this rule and see if it could be effective for us. First, we see alert syslog HomeNet any to external net any.
What does this mean? Well, it simply says that we have an alert that’s going to be used for syslog anytime traffic goes from the internal network or HomeNet into an external network like the Internet. And if it meets those conditions of the rule that we’re going to now specify as we move into the rule, we’re going to first put out a message. If this rule alerts, we’re going to put the message of Windows authentication pass the hash detected into the logs if the perl compatible regular expression known as pCRE matches the Windows Event IDs of 4624 and 4625.
Now, these two events are something you should be familiar with as you study through Security Plus and you become a Windows administrator. Windows Event ID 4624 means an account that is successfully logged on and Windows event 4625 means an account that failed to log on. This rule will monitor for both of these in order to detect both the successful and unsuccessful pass the hash attempts. Next, we’re going to look at the content and we look at the content that we want to match, in this case, the logon type of three, which is an interactive login attempt. This means somebody put in their username and password and tried to log on to the system.
We’re also going to monitor for the authentication package of NTLM and check that its content isn’t associated with an anonymous log on. Since we have the content exclamation mark here, which signifies a logical not match being used, saying we don’t want to match this condition, the next line goes on to make another not match, this time ensuring that the domain isn’t matching a real domain, which would be listed in our variable under the windows domains for any authorized domains that we want to match inside of this rule and inside of this IDs program.
Now, as we go through and we start thinking about all this, I want to give you a quick exam tip here. Now, I know the signature looks really complicated, but the good news is, for the exam, you are not going to be asked to dive deep into an IDs signature like this on the exam. I just wanted to show you this so you can see what is possible as you start looking to identify a pass the hash event using something like an IDs rule. Now, as we go through and we look at this in the real world, could you use this type of an IDs signature to go through and detect a pass the hash attack? Well, the answer is yes, but this is a big butt here. You need to be prepared for a mountain of false positives.
Why? Well, if you remember back to earlier in this lesson, I said that a passtha hash attack is using someone’s real credentials, the hash of their password, to authenticate with the system. So as far as the system is concerned and the security logs, look, they’re all going to see valid authentication and nothing abnormal. Therefore, this rule is best used after an attack has occurred. And this way you can start determining exactly how the attacker got in and build your timeline of events for further mitigation and incident response actions. So could you use this? Yes, but in real time. It’s really going to bury you under a mountain of false alerts. So I wouldn’t recommend it.
Golden ticket. Now, in the last lesson we talked about the passthahash attack. Now, a passthahash attack will work on local workstations, but if you’re going to be using something on a domain environment, you’re really going to need to attack a Kerberos ticket because this is what’s used in an Active Directory environment. The pass, the hash attack can work on multiple workstations across the domain if those systems have all been logged into by the same user. But if they haven’t, then you’re going to need to work on a golden ticket instead. Now, what is a golden ticket? Well, if you’ve ever read the book Charlie and the Chocolate Factory or seen the movie, you’ve probably heard of a golden ticket. Essentially, this was the winning ticket that got you unlocked privileges to anything you wanted inside their factory.
It was a universal skeleton key, essentially. And essentially in our networks, that’s what a golden ticket is. When I talk about a golden ticket, a golden ticket is a Kerberos ticket that can grant other tickets in an Active Directory environment, and so it can create keys that allow you to get access to anything you want. Golden tickets can grant administrative access to other domain members and domain controllers within the network. And so they are really, really powerful. Before we talk about exactly how a golden ticket attack works, I think it’s important for us to revisit a key concept about how Kerberos works. Now, this is going to be a very quick review because this is something you should have already learned back in Security Plus. But I want to provide a quick refresher so you can better understand how this attack works.
First, we have something known as a KRB TGT hash, which is essentially a Kerberos ticket granting ticket. Hash is what it stands for. Now, this is the trust anchor of Active Directory domains. And these function like a private key of a root certificate authority. And they’re used to generate ticket granting tickets that are used by users across the network to access services within Kerberos. Now, under Kerberos, a client is generally going to be a user or a service, and they’re going to send a request for a ticket to the KDC, the key distribution center. The KDC will then create this ticket granting ticket, or TGT, for the client. It’s going to encrypt it using the client’s password as the key, and then send the encrypted ticket back to the client.
The client will then attempt to decrypt the TGT or the ticket granting ticket using the client’s password. If the client successfully is able to decrypt the ticket granting ticket, this means the client gave the right password and the ticket grain ticket will be decrypted, which indicates proof of the client’s identity. Now, the ticket grain ticket will expire after a certain time, and this will allow the user to be able to obtain additional tickets whenever they need them and get permission for specific services. The requesting and granting of these additional tickets is considered user transparent and happens all the way in the background in these Windows environments.
Now, as I said, the Kerberos ticket grading ticket hash is the trust anchor to this whole thing on the server as it is generating the ticket grading tickets. So if an attacker could compromise that, this whole system could be used to create their own tickets and gain authorization to anything they want. And that’s exactly how a golden ticket attack works. They go after this Kerberos ticket grading ticket hash. So let’s see how that works first. How does a golden ticket attack work? The first thing is the attacker is going to try to access the NTDs dit file. This allows the attacker to gain access to this file that contains the active directories data store. And inside of that is the Kerberos ticket grading ticket hash and all of the hashes for the administrative accounts.
Now that the attacker has this NTDs dips file, they can dump it and identify the Kerberos ticket grading ticket hash and those administrative hashes. Once they’ve done that, they can move on to the fun part. And as an attacker, this is going to be really good for them, but really bad for our defenders. As defenders, we may identify that a breach has occurred and we go forward and make everybody with an active directory account reset their passwords. But if we don’t reset the Kerberos ticket grain ticket hash, then the attacker will still have access and often responders will forget to do this. And this allows attackers to stay in these systems for a really long period of time.
So our attacker, who still has a valid Kerberos ticket grain ticket hash, can use an exploit module to create golden tickets for a user in the administrative group. Now that they have that golden ticket created with the Kerberos ticket grain ticket hash, they are now ready to do whatever else they want to do on that system, because the attacker can use that golden ticket to assume an administrative identity. So they can now do follow on exploitation and do whatever they need to do on that system or even across the domain, because those tickets work with Kerberos, which works across the domain. Now, for example, they might go ahead and compromise your domain controller.
They could log in using that golden ticket and perform PowerShell or command line actions on that server or whatever bad action they want using that administrative level control. And this is why golden tickets are just so dangerous. So when you think about golden tickets, I want you to remember that golden tickets allow attackers to laterally move across the entire domain with ease. It is basically a skeleton key that can open any door they want on your network. So it’s really important that administrators make sure that they reset the Kerberos ticket granting ticket account password regularly. This will make sure that if you have been compromised, you can clear out the ability of an attacker to create new golden tickets.
Also, if you need to change the Kerberos Ticket grain ticket account password, you need to reset that password twice in a short period of time to invalidate the golden ticket. If a breach is suspected, essentially you’re going to change the password, reboot the computer, change the password again, reboot the computer. By doing that, you are revoking all the existing golden tickets and making sure the new ones are being issued with the new password, and that removes any ability of the attacker to use it inside your system anymore. Now, as we finish up this lesson, I want to leave you with one quick warning. As you’re reading up on a golden ticket attack, as an analyst in the field, you may come across some older articles that talk about this technique.In those articles, they may mention that you should be looking for a domain name field being left blank as an indicator of compromise.
And that is true for older golden ticket programs because they didn’t include a domain name field when they made those golden tickets. And that way it made it very easy for us to detect them in the logs. But most of the newer golden ticket programs have fixed this and they actually include a domain name now. So this isn’t the easy IOC that it used to be, but it is still one that you should look for. Remember, all your log on and log off events are recorded in your Windows event log, and so you can actually look at them with the username and the domain name of the account that’s logging in and out. If you see one that doesn’t have a domain name, that could be an indication that somebody is using an older golden ticket program and they are using a golden ticket attack. Again, sense to you.
Popular posts
Recent Posts