Most corporate systems, whether end-user systems or core servers, are guarded by various malicious software protections. These usually present in the form of anti-virus (AV), data-loss protection (DLP), and host-based intrusion detection (HIDS). These protections are useful for the defenders as they help the systems to remain safe, secure, and free from malicious code. At the very least, the hard drive, or non-volatile memory, is typically kept safe.
This paradigm has created a more difficult environment for attackers – both white and black hats. A few years ago, when an attacker wanted to take over a system, the mission was to get malware onto the hard drive of the target system. As end-point defensive software has become both more ubiquitous and effective, the methods used in post-exploitation have had to evolve in kind. This means that as soon as defenders got better tools, attackers had to innovate new methods of gaining access.
Pillaging RAM for Loot
These new methods of attack came into the world in the form of direct-to-RAM attacks. One of the most used and effective pieces of software available is a tool called MimiKatz by Benjamin Delpy aka GentilKiwi. MimiKatz is an incredibly useful tool for assisting an attacker with privilege escalation and other post-exploit activities by scraping all of the data directly out of the target system’s RAM.
These attacks work quite effectively on Windows-based machines and can often directly pull usernames and passwords in plain text, or hashes of the passwords, for all users currently logged into that machine. Additionally, any encryption keys that are in use will also be stored in the volatile memory (read: RAM) in plain text.
The ability to see passwords and keys in plaintext is a major boon to attackers. However, there is still the issue of getting software that is well known in the security world, and therefore easily identifiable, onto a hard drive. Getting past all of the sentinels that guard these systems is now possible with complex and convoluted code masking, usually accomplished with tools like the Veil-Evasion Framework or Metasploit’s MSFVenom software.
For better or for worse (for admins and hackers alike), all windows systems since Windows 7 come with a very powerful tool for admins and hackers called PowerShell (PS) installed by default. PS allows admins, or attackers, to run commands in .NET and from a system level of privilege. The wonderful functionality that Microsoft has worked very hard to put into PS has also led to the perfect solution for attackers to use memory scraping techniques without ever touching the target’s non-volatile memory (read: HDD or SSD).
One group associated with PS is the PowerShell Mafia, which is not a shady group despite the mental images that may be conjured by its name. Instead, it is a small group of security researchers that have spent a significant amount of time figuring out how to use PowerShell to aid in penetration testing.
This group has released a plethora of tools that can be used by hackers within PS to do a multitude of hacking tasks to exploit systems that have PowerShell installed. The tool most relevant to this blog post’s topic is called PowerSploit and its Invoke-MimiKatz.ps1 tool. With this, an attacker can host a .NET version of MimiKatz on their system via a web server, and by sending a small PS command to the target system, an attacker can do the unthinkable.
Using this technique, attackers can run this tool and steal the information stored in RAM by simply running the MimiKatz code directly in the memory of the target system. This effectively bypasses all of the system’s resident guardians and allows the attacker to access highly sensitive information with almost no chance of discovery and with a very high chance of gaining useful information.
How Do I Mitigate This?
First, this is a “post exploitation” technique, which means that the attacker has already gained access through other means to at least one of your systems. So, the best practice would be to keep the bad actors out, which would effectively prevent them from using this vulnerability against you.
In reality, we do not live in such a cut and dry world, and there may be a vulnerability on many of your systems that no one, except some bad actors, knows about at all (zero-day). The other major change that should have already taken place long ago is that no user should have admin rights, and no admin should log in directly with their privileged account unless it is absolutely necessary.
Knowing your network, implementing good security practices, and extra precautions taken on privileged account governance are the best ways to avoid these attacks at the moment. Fortunately, all of these mitigations are important to the overall security of an organization, so they should either be in place already or be something the organization is working toward implementing.