How the heck do you keep an attacker from getting to your credentials when you're working on a computer?
That's what I want to talk about today. Credential cashing and making sure that attackers don't use your credentials against you.
Getting onto the device is the first step.
Let’s pretend you’re the hacker, and you actually get onto a device. Maybe you phish your way in, and you access a machine.
Chances are when you did that—you phished your way in—you didn't land with domain admin rights.
You didn't land on the user that has rights to the entire system. You didn't land on a user that has the master key to the entire company that you tried to get to. But you did land on a user device.
Your ultimate goal is to gain persistence on the network.
Getting on one computer might be okay but to a hacker, one is none, and 2 is 1. What I mean by that is if you get one device, you really don't have much.
If you have two devices, now you have persistence.
You can stay in that environment. If one of them goes offline or something like this, you can still get back to that original computer. You can still get back to that original attack vector.
I always want you to think whenever you're thinking like a hacker, one is none into is one now, what if you could get to the domain admin? Wouldn't that make you happy as an attacker? Absolutely.
How do you get to the domain admin if you’ve landed on a device, and the user on that device doesn't have a whole bunch of rights?
If you did get to domain admin? All of a sudden, instead of being able to hit just one device, you'd be able to go through and you'd be able to access every single device inside of that network. Instead of putting ransomware in like one device, you're able to go through and hit every single device with ransomware.
You’d be able to go and hit every single device looking for other credentials, and going, and looking for personally identifiable information, or any of that other stuff.
You’ll probably use pass the hash to get to two or more devices (this is where things get interesting).
Pass the hash comes in to help you move laterally throughout the environment.
What you’re looking at here is the passwords that people type into their systems are stored as hashes. When you log into your computer, you type in your username and password. That username and password is then stored on that computer as a hash.
Why would you store a password as a hash? Why not just encrypt it?
The answer is straightforward. When you take something, and you encrypt it, there's an encryption algorithm on the left-hand side that then gets you encrypted text. But you can take that encrypted text, and you can decrypt it. Then it becomes plain text again.
The question now becomes, if you're the attacker, how do you get to the hash? I've gone through this in other SecOps (we’re not going to get into the details here today).
When you login as a normal user, you type your username, and you type your password. Then you go ahead and log in. When you login, there's a process called when login.exe. It takes your data compares. It will convert it into a hash.
That's a one-way function. That creates a bunch of gobbledygook. It compares it to a hash inside of your SAM database. What that does is that authenticates that you are who you say you are. Because the only way that you can get to that hash, supposedly, is by typing in your username and password.
Your two passwords may be different, but they have the same hash. That doesn't happen very often, but I just want to mention it, because that is a possibility.
Let's say, you wanted to connect to another computer in the network, your computer, Computer A, doesn't have your password. It only has the hash.
When you connect to that other computer, you connect via SMB.
Let's say you're connecting to it by sending your password across the wire, but instead of sending your password, you send a hash of the password because you really don't have the password. When you get to that other computer, it takes your past hash, the one that you sent across the wire and compares it to the one that it has stored locally on the device.
It takes the two of them, compares them and says, ‘Ah, I trust you. You're that normal user guy or gal’, and lets you in.
When an attacker lands on the device, you’d see a situation where the attacker tricks the user into clicking a link and ending up on the device as a normal user.
If they’re able to do that read export that I went through, now all the sudden, they're able to take that information, pull it back to their machine, run that Python script that we talked about earlier, and then they're able to dump out those domain administrator credentials that were cached on this network.
They can use that instead of the normal user to move to the other computer.
They're able to go through and hit every other computer in the environment with those domain admin rights. This is exactly what we don't want to have happen in the environment.
Not sure what credentials a hacker might find on your network?
Consider a free cyber stack assessment to see if your network is vulnerable to cached credentials. Showing your users what’s at stake if a hacker gets onto their machine is the easiest way to get across your security concerns.
