As we’ve been writing about forever, hackers are relying more on malware-free techniques to fly below the radar. They’re using standard Windows software to live off the land, thereby getting around AV or other anti-malware monitoring tools. We as defenders now have to deal with an unfortunate consequence of this savvy hacking technique: a well-positioned employee can also use the same LoL ideas to sneakily steal data (corporate IP, credit card numbers). If they take their time, and go low and slow, it’s very difficult — not impossible if you have the right mindset and software — for IT security to detect their activities.
I don’t want to demonize employees, and on the other hand, no one wants to work in a business environment straight out of 1984. Thankfully, there are a few practical steps and tips to make insiders threats far more difficult to pull off. In this multi-part series, let’s first look at the stealthy techniques used by hackers that can also be easily grasped by employees with some tech background. Later on, we’ll discuss ways to reduce the risk — exploring both technical and administrative approaches.
Get the Free Pentesting Active
Directory Environments E-Book
What’s Wrong With Psexec?
Edward Snowden, rightly or wrongly, became synonymous with insider data theft. By the way, take a look at this write up of other insiders, who also deserve some notoriety! One very important point to emphasize about Snowden’s techniques is that, as far as we know, he did not install any external malware!
Snowden instead applied a little social engineering and took advantage of his position as a sys admin to gather passwords and create credentials. Nothing very sophisticated — no mimikatz, man-in-the-middle , or metasploit.
Employees may not be in Snowden’s unique position, but there are lessons in terms of LoL , not producing any detectable events, and particularly in cleverly using credentials that are all worth knowing about. Hold that thought.
Psexec and its close cousin, crackmapexec, have impressed zillions of pen testers, hackers, and infosec bloggers including this one. Used in combination with mimikatz, psexec allows the attackers to make a lateral move without requiring a plaintext password.
Mimikatz grabs the NLTM hash from the LSASS process, and then passes a token or credential — “pass the hash” — to psexec, allowing the attacker to login to another server as a different user. On each subsequent move to the next server, the attacker collects additional credentials, opening more possibilities for finding accessible content.
When I first started with psexec, it seemed magical —thanks to Mark Russinovich, psexec’s brilliant developer—but I now know more about its noisy gears. It ain’t stealthy!
The first interesting point about psexec is it uses Microsoft’s immensely complicated SMB file network file protocol. With SMB, psexec transfers a small binary to the target system, placing it in the C:\Windows directory.
The next point is that psexec creates a Windows service, using the copied binary, and then launches the service, under the surprisingly shocking name of PSEXECSVC. You can actually see all this, as I did, from the vantage point of the remote machine (below).
Finally, the copied binary opens an RPC connection to the target and then takes a command (Windows cmd shell by default), running it with the input and output redirected to the attacker’s home machine. The attacker sees a basic shell prompt — the same as if she we were directly logged in.
A lot of gears and a very noisy process!
The complicated machinery underlying psexec explains the message that puzzled me during my initial test drives a few years back, “Starting PSEXECSVC …”, and then the noticeable pause before the command prompt showed up.
No wonder: psexec was doing an incredible amount of work under the hood. If you want a good explanation with more details than I can go into in this short post, there’s a wonderful description here.
Obviously as a sys admin tool, which was psexec’s intended goal, there’s nothing wrong with all this Windows machinery whirring away. For an attacker, though, psexec is problematic, and for a careful and smart insider, like Snowden, psexec and similar tools would be too risky.
Along Comes Smbexec
SMB is a clever and stealthy way to move files across servers, and hackers have been logging directly into SMB for about forever. At this point, we all know not to expose the SMB ports 449 and 135 on the internet, right?
Back in 2013 at Defcon, Eric Milman (brav0hax) introduced smbexec to let pentesters try out stealthy SMB hacking. I’m not sure of the complete history, but smbexec was further refined by Impacket. In fact, I downloaded the Impacket python scripts from Github for my own testing.
Unlike psexec, smbexec avoids transferring a potentially detectable binary to the target site. Instead, it lives completely off the land by running the local Windows command shell.
Here’s what it does. It transfers commands from the attacker’s machine via SMB into a special input file, and then creates and runs a complex command line (as a Windows service) that should look familiar to Linux-people. In brief: it launches the native Windows cmd shell, redirecting output to another special file, and then SMBs the file output to the attacker’s machine.
The best way to understand this is to gaze at the command line, which I was able to dig up from the Event log (below).
Like psexec, is also creates a service that does the actual work, but the service is then deleted — it’s used for just one command execution and disappears! A security staffer observing the victim’s machine wouldn’t find obvious evidence of an attack: no malware binary, no permanent service installed, and no evidence of RPC usage since SMB is the sole means for transferring data. Brilliant!
On the attacker’s side, there’s a “pseudo-shell” experience with delays between the command being sent and output received. But it’s enough functionality for an attacker – either an insider or outsider who has a foothold — to search for interesting content.
(For those who remember my pen testing posts from last summer — you know who you are! — smbexec’s pseudo-shell approach is very similar to the way Koadic conducts remote code execution.)
To pull data back from the target to the attacker’s machine, there’s smbclient. Yeah, it’s the very same Samba utility but now turned into Python script by Impacket. In effect, smbclient lets you stealthily FTP over SMB.
Let’s step back and think about how this would work for an employee. In my imaginary scenario, say a blogger or financial analyst or a high-priced security consultant is allowed to bring their own laptop to work. Through a magical process, she becomes disgruntled and “breaks bad”. Depending on the OS on her laptop, she either has Impact’s Python or Windows .exe versions of smbexec and smbclient.
Like Snowden, she learned about another another user’s password either by shoulder-surfing or getting lucky and finding it in a text file. With this credential, she’s able to start poking around the system with new access rights..
Cracking DCC: We Don’t Need No Stinkin’ Mimikatz
In my previous pen testing outings, I made heavy use of mimikatz. It’s a wonderful tool to grab credentials—NTLM hashes and even plain-text passwords – that are lurking on laptops waiting to be exploited.
Times have changed. Security monitoring software has become better at detecting or blocking mimikatz. Security admins also have more options available to reduce the risk of PtH-based attacks. I’ll go over this in another post.
So what does a clever employee do to gather additional credentials without using mimikatz?
The Impacket toolset has a utility called secretsdump that pulls credentials from the Domain Credential Cache or DCC. From what I understand, if a domain user logs into a server, but the domain controller is down, the DCC lets the server authenticate the user. Anyway, secretsump lets you dump these hashes when they’re available.
DCC hashes are not NTLM hashes, and can not be used in PtH.
Well, you could try cracking them to get the underlying password. However, Microsoft became smarter with DCC and salted the hash. In short, DCC hashes are very hard to crack. There is hashcat, “world’s fastest password cracker”, but it requires GPU support to work effectively.
Instead, let’s think like Snowden. An employee could conduct in-person social engineering, and perhaps learn some details about the user whose password she wants to crack. That’s certainly a possibility — find out about their favorite teams, movies, name of pets, children, etc.
Or even better, the insider could use Maltego, the OSINT software I recently wrote about, to gather more context about the employee. Specifically, find out whether this person’s online account had been previously pawned, and then examine the clear-text password for clues.
And that’s the scenario I went with. Let’s say our insider learns that her boss, Cruella, had been hacked multiple times on various web accounts. After analyzing a few of the passwords, she realizes Cruella favors a format of “Yankees” followed by a recent year — “Yankees2015”.
If you’re playing along at home, you can download this small bit of, cough, “C” code that implements the DCC hashing algorithm and, gasp, compile it. John the Ripper, by the way, has added support for DCC, so that can be used as well. Let’s say our insider didn’t want to deal with learning about JtR and enjoys running “gcc” on legacy C code.
Playing the part of the insider, I ran a few different combinations, and finally discovered that Yankees2019 is Cruella’s password (below). Mission accomplished!
Let’s call it a day. I’ll go over some of this again next time, and introduce more low and slow techniques while continuing to leverage the amazing Impacket tools.
Want to see how Varonis can detect and stop a rogue insider? Register for our Live Cyber Attack webinar!
