We write regularly about how hackers often rely on using to avoid detection. They literally , using standard Windows tools, thereby bypassing antiviruses and other utilities for detecting malicious activity. We, as advocates, now have to deal with the unfortunate consequences of such cunning hacking techniques: a well-placed employee can use the same approach to covertly steal data (company intellectual property, credit card numbers). And if he does not hurry, but works slowly and imperceptibly, it will be extremely difficult - but still possible if the right approach and appropriate , to detect such activity.
On the other hand, I wouldn't like to demonize employees, since no one wants to work in a business environment straight out of Orwell's 1984. Fortunately, there are a number of practical steps and life hacks that can make life much more difficult for insiders. We'll consider covert attack methods, used by hackers by employees with some technical background. And a little further we will discuss options for reducing such risks - we will study both the technical and organizational options for action.
What's wrong with PsExec?
Edward Snowden, rightly or not, has become synonymous with insider data theft. By the way, don't forget to take a look at about other insiders also deserving of some notoriety status. One important point worth emphasizing about the methods used by Snowden is that, as far as we know, he did not install no external malware!
On the contrary, Snowden applied a bit of social engineering and used his position as a system administrator to collect passwords and create credentials. Nothing complicated - no , attacks or .
Employees of organizations are not always in Snowden's unique position, but there are a number of lessons to be learned from the concept of "grazing survival" - not to perform any malicious activity that can be detected, and to be especially careful in using credentials. Remember this thought.
and his cousin have impressed countless pentesters, hackers and security bloggers. And when combined with mimikatz, psexec allows attackers to roam within a network without having to know the password in plaintext.
Mimikatz intercepts the NTLM hash from the LSASS process, and then passes the token or credentials - the so-called. "pass the hash" attack - in psexec, allowing an attacker to log into another server on behalf of another user. And with each subsequent move to a new server, the attacker collects additional credentials, expanding the range of his capabilities in finding available content.
When I first started working with psexec, it seemed like magic to me - thanks , the genius developer of psexec - but I also know about his noisy components. He is never hidden!
The first interesting fact about psexec is that it uses an extremely complex network file protocol SMB from Microsoft. Using SMB, psexec transmits small binary files on the target system by placing them in the C:Windows folder.
Next, psexec creates a Windows service using the copied binary and runs it under the extremely "unexpected" name PSEXECSVC. In doing so, you can actually see all of this, as I can, by watching a remote machine (see below).
Psexec calling card: "PSEXECSVC" service. It runs a binary file that was placed via SMB in the C:Windows folder.
As a final step, the copied binary opens RPC connection to the target server and then accepts control commands (via the Windows cmd shell by default), running them and redirecting input and output to the attacker's home machine. In this case, the attacker sees the basic command line - the same as if he was connected directly.
Lots of components and a very noisy process!
The complex workings of psexec's internal processes explain the message that puzzled me during my first tests a few years ago: "Starting PSEXECSVC ..." and the subsequent pause before the command prompt appears.
Psexec from Impacket really shows what's going on "under the hood".
No wonder: psexec did a lot of work under the hood. If you are interested in a more detailed explanation, check out here. wonderful description.
Obviously, when used as a system administration tool, which was original purpose psexec, there is nothing wrong with the “buzzing” of all these Windows mechanisms. For an attacker, however, psexec would create complications, and for a cautious and cunning insider like Snowden, psexec or a similar utility would be too much of a risk.
And here comes Smbexec
SMB is a clever and stealthy way to transfer files between servers, and hackers have been infiltrating SMB directly for centuries. I guess everyone already knows what not to do. SMB ports 445 and 139 to the internet, right?
In 2013 at Defcon, Eric Milman () brought to light so that pentesters can try out a sneaky SMB hack. I don't know the whole story, but then Impacket further honed smbexec. In fact, for my testing, I downloaded the scripts from Impacket in python with .
Unlike psexec, smbexec avoids transferring a potentially detectable binary file to the target machine. Instead, the utility lives entirely from "grazing" through the launch local Windows command line.
Here's what it does: passes the command from the attacking machine over SMB to a special incoming file, and then creates and runs a complex command line (as a Windows service) that will seem familiar to Linux users. In short: it launches a native Windows cmd shell, redirects the output to another file, and then sends it over SMB back to the attacker's machine.
The best way to understand this would be to study the command line, which I was able to get my hands on from the event log (see below).
Isn't this the greatest way to redirect I/O? Speaking of which, service creation has event ID 7045.
Like psexec, it also creates a service that does all the work, but the service then removed - it is used only once to run the command and then disappears! An information security officer watching the victim's machine will not be able to detect obvious attack indicators: no malicious executable, no persistent service installed, and no evidence of RPC being used, since SMB is the only means of transferring data. Brilliant!
At the same time, a “pseudo-shell” is available from the attacker’s side with delays between sending a command and receiving a response. But this is quite enough for the work of an attacker - either an insider or an external hacker who already has a foothold - to start looking for interesting content.
To output data back from the target machine to the attacker's machine, use . Yes, it's the same Samba , but only converted to Impacket's Python script. In fact, smbclient allows you to covertly arrange FTP over SMB transfers.
Let's take a step back and think about what this can do for the employee. In my fictional scenario, let's say a blogger, financial analyst, or highly paid security consultant is allowed to use a personal laptop for work. As a result of some magical process, she takes offense at the company and "indulges in all serious things." Depending on the laptop's operating system, it either uses the Python version from Impact, or the Windows version of smbexec or smbclient as an .exe file.
Like Snowden, she learns another user's password either by looking over her shoulder, or she is lucky and stumbles upon a text file containing the password. And with those credentials, she starts poking around the system at a new privilege level.
DCC Hack: We Don't Need Any "Wacky" Mimikatz
In my previous penetration testing posts, I used mimikatz a lot. It's a great tool for capturing credentials - NTLM hashes and even plaintext passwords lurking inside laptops just waiting to be used.
Times have changed. Monitoring tools have gotten better at detecting and blocking mimikatz. Information security administrators also began to have a large number of options to reduce the risks associated with "pass the hash" attacks (hereinafter referred to as PtH).
So what should a smart employee do to collect additional credentials without using mimikatz?
Impacket comes with a utility called , which retrieves credentials from the Domain Credential Cache, or DCC for short. As far as I understand, if a domain user logs on to the server, but the domain controller is not available, DCC allows the server to authenticate the user. Anyway, secretsdump allows you to dump all these hashes if they are available.
DCC hashes are not NTML hashes and their cannot be used for PtH attack.
Well, you can try to crack them to get the original password. However, Microsoft has gotten smarter with DCC and cracking DCC hashes has become extremely difficult. Yes, I have , "the world's fastest password cracker", but it requires a GPU to work effectively.
Instead, let's try to think like Snowden. An employee can conduct face-to-face social engineering and possibly find out some information about the person whose password she wants to crack. For example, find out if this person's online account has ever been hacked and examine his password in plain text for any clues.
And this is the scenario that I decided to go with. Let's assume that an insider found out that his boss, Cruella, had been hacked several times on different web resources. After analyzing several of these passwords, he realizes that Cruella prefers to use the Yankees baseball team name format followed by the current year, Yankees2015.
If you are now trying to reproduce this at home, then you can download a small, "C" , which implements the DCC hashing algorithm, and compile it. , by the way, added support for DCC, so you can use it too. Let's assume that an insider doesn't want to mess with learning John the Ripper and likes to run "gcc" on legacy C code.
Playing the role of an insider, I ran several different combinations and was eventually able to discover that Cruella's password was "Yankees2019" (see below). Mission Complete!
A bit of social engineering, a little divination, and a pinch of Maltego and you're well on your way to cracking the DCC hash.
I propose to end here. We will return to this issue in other publications and look at even more slow and stealthy attack methods, while continuing to build on the excellent set of tools from Impacket.
Source: habr.com