CHAPTER 15
PowerShell Exploitation
The majority of corporate systems are still Windows based, so it’s important that we have a good grasp of the available tools in Windows systems. One of the most powerful of these tools is PowerShell. In this chapter, you learn about what makes PowerShell such a powerful tool, and we look at some ways to use it as part of our exploitation toolkit.
In this chapter, we cover the following topics:
• Why PowerShell
• Loading PowerShell scripts
• Creating shells with PowerShell
• PowerShell post exploitation
Why PowerShell
Although the PowerShell language has been a blessing for Windows systems automation, it also gives hackers leverage. PowerShell gives us access to almost all of the Windows features in a programmatic way, and it’s extendable and can be used to administrate Active Directory, e-mail systems, SharePoint, workstations, and more. PowerShell also gives us access to .NET libraries from a scripting standpoint, making it one of the most flexible tools you can use in a Windows environment.
Living Off the Land
When we talk about “living off the land,” we mean using the tools already present on systems to further our exploitation. This is valuable because whenever we add things to a system, we increase the possibility of detection. Not only that, when we leave tools behind, it helps disclose our tactics, techniques, and procedures (TTPs) so that it is easier to find our activity across other systems. When we live off the land, we can leave fewer artifacts behind and limit the tooling we have to move from system to system.
PowerShell is useful as an already existing tool on a system because it gives us the ability to easily script and also includes .NET integration, so almost anything we can write in .NET we can write in PowerShell. This means we can go beyond basic scripting and actually interact with kernel functions and more, which gives us additional flexibility that would normally require the use of separate programs.
One of the main benefits of PowerShell is that it can use the Internet Explorer options, so things like proxy support are built into PowerShell. As a result, we can use the built-in web libraries to load code remotely, meaning we don’t have to download any code to the target system. Therefore, when someone looks at the file-system timeline, these pulls from websites won’t show up, which allows us to be even stealthier.
PowerShell Logging
In earlier versions of PowerShell (pre v4.0), only a handful of logging options were available. This allowed us to operate without creating a lot of log alerts when we loaded PowerShell, and also made it very difficult for forensics folks to figure out what we had been doing. The only logging that was really shown was the fact that PowerShell loaded. With newer versions of PowerShell, however, additional options are available to increase PowerShell logging. Because of this, targeting the latest Windows version may give away more about what you are doing than the older versions.
NOTE We cover just a few of the logging aspects of PowerShell that might impact your hacking detection. For more information, we have added a reference from FireEye that lays out the different options in more depth and explains how to enable them.1
Module Logging
Module Logging enables a number of features concerning how scripts are loaded and the basics of what was executed. This includes what modules and variables were loaded, and even some script information. This logging greatly increases the verbosity when PowerShell scripts are run, and it may be overwhelming to an administrator. Module Logging has been available since PowerShell v3.0 and is not enabled by default, so you need to enable a Group Policy Object (GPO) on systems to get this logging.
Although this type of logging increases the visibility into what was run, much of the time it doesn’t provide the actual code that was run. Therefore, for a forensics investigation, this level of logging is still insufficient. It will, however, tip off investigators to the types of things you have been doing, although the specifics will likely not be logged.
Script Block Logging
Script block logging is used to record when scripting blocks are executed, which allows one to get a lot more in depth into what is being executed. Starting with PowerShell v5.0, script block logging provides a lot of data about potentially suspicious events to give the forensics folks something to go on.
Items that are logged include scripts started with the encodedcommand option as well as any basic obfuscation performed. Therefore, when script block logging is enabled, defenders will likely have some additional insight into what you were doing. This is a better solution for defenders than module logging because it highlights things you would likely care about from a forensics standpoint, while not creating as much of a log-parsing burden.
PowerShell Portability
One of the nice aspects of PowerShell is that the modules are very portable and can be loaded in a variety of different ways. This give us the ability to load both system install modules and modules in other locations. We also have the ability to load modules from Server Message Block (SMB) shares as well as the Web.
Why is being able to load from these remote locations so valuable? We want to leave as few traces as possible, and we want to have to duplicate as little work as possible. This means we can leave items we will use frequently on an SMB share, or even a website, and then reference them from there. Because a script is just text, we don’t have to worry about blocks for binary or similar file types. We can also obfuscate the code and then decode it on the fly, which potentially makes bypassing antivirus (AV) easier.
Because a script is just text, we can include it almost anywhere. Frequently, code sites such as GitHub are handy for this type of activity, as such sites have many business-related purposes. We can include our scripts in a repository or as basic gist commands that we load from inside our PowerShell environment to bootstrap other activities. PowerShell can even use a user’s proxy settings, so this is a great way to establish persistence in an environment.
Loading PowerShell Scripts
Before we can do any exploitation with PowerShell, you need to know how to execute scripts. In most environments, unsigned PowerShell scripts aren’t allowed by default. We’re going to take a look at this behavior so you can identify it, and then we’ll look at how to bypass it you so can bootstrap any code you want to run.
Lab 15-1: The Failure Condition
Before we look at how to get around security, we should take a look at how the security works when in action. To do this, we’re going to build a very simple script on our Windows 10 box that we set up in Chapter 10, and then we’ll try to execute this script. For our script, we’re just going to create a directory listing of the root of C:\. First, we need to open up a command prompt as Administrator and then run the following the code:
You can see here that the execution of our test.ps1 script was blocked because running scripts on the system has been disabled. Let’s take a look at what the current execution policy is:
This shows that the current execution policy is “Restricted.” Table 15-1 provides a breakdown of what each of the possible execution policies does.
Table 15-1 PowerShell Execution Policies
Let’s try changing the execution policy to Unrestricted and then run our test.ps1 script again:
As you can see, once we change the policy to Unrestricted, our script runs just fine. Based on Table 15-1, it looks like RemoteSigned should also work. Let’s try it:
The RemoteSigned policy works as well. In theory, we could just reset the execution policy to one of these two values. Unfortunately, in many environments, this value is enforced by Group Policies. In such a situation, it’s not that easy to change the policy. Therefore, let’s set the value back to Restricted, as shown here, and we’ll just proceed through the rest of the chapter with the strictest controls enabled:
Lab 15-2: Passing Commands on the Command Line
In Lab 15-1, we executed a number of PowerShell commands from the command line. In this lab, we’re going to look at how to execute more complex commands. In the previous examples, you saw that the -command option can be used to pass a command on the command line; however, many of the PowerShell options can be shortened. In this case, we can just use -com, as shown here, and save ourselves some typing:
Here, we were able to issue a simple WMI query with PowerShell, and without any additional quotation marks around our query. For basic queries this will work fine; however, for more complex queries, we may run into a problem. Let’s see what happens when we try to get additional information about the user who owns the system:
You can see here that we couldn’t use the pipe character to pass data from one method to another because it is interpreted by the operating system. The easiest way to get around this is through the use of double quotes, like so:
This time, the pipe character wasn’t interpreted by the operating system, so we could get just the username information from the output of the WMI query. For simple commands, this works well, and if we’re just doing a few of these commands, it’s easy enough to add them into a batch script and run them from there.
Lab 15-3: Encoded Commands
When we have a more complex task, not having to worry about formatting is nice. PowerShell has a handy mode that allows us to pass in a Base64-encoded string as a script to run—as long as the script is not very long. The total length for a Windows command-line command is about 8,000 characters, so that’s your limit.
We have to make a few changes to create an encoded command. First of all, the encodedcommand option of PowerShell takes a Base64-encoded Unicode string, so we need to convert our text to Unicode first and then encode it as Base64. To do this, we need an easy way to convert to Base64 encoding. Although we could use the tools already on Kali to do this, we’re going to use one of my favorite toolkits, Ruby BlackBag by Eric Monti. This Ruby gem contains lots of encoding and decoding tools to help with both malware analysis and hacking. First, we need to install it before we can use it:
Once this toolkit is installed, it not only adds Ruby functionality but also creates some helper scripts—one of which is called b64, a Base64 conversion tool. Next, we’ll take the same command we used in the last lab and convert it to a PowerShell-compatible Base64 string:
Here, we are using echo with the -n option to print out our PowerShell command without incorporating a newline. Next, we pass that into iconv, a character set converter, which will convert our ASCII text into UTF-16LE, the Windows Unicode format. Finally, we pass all of that into b64, as shown next. The string that it outputs is the string we’re going to use with PowerShell.
You can see here that when we pass our string with the -enc option, we get the expected output. Now we can build more complex scripts and pass an entire script on the command line so that we don’t have to worry about script execution prevention.
Lab 15-4: Bootstrapping via the Web
For complex scripts, encoding them may not always be our best bet. One of our other options is to put them on a website, load the scripts, and then bootstrap them into our code. Two functions in PowerShell help us do this: Invoke-Expression and Invoke-WebRequest.
Invoke-WebRequest will go out and fetch a web page and then return the contents of the page. This allows us to throw a page on the Internet with our code in it and then fetch it from within PowerShell. This function uses the IE engine by default, which our Windows 10 box doesn’t have, so we’re going to have to use a workaround to make sure it can fetch our web pages. We can use the -UseBasicParsing option to tell the function not to try to parse the results, but instead to just return them to us.
The Invoke-Expression function evaluates the code passed to it. We could load the code from a file and then pass it via stdin or another option. One of the most common methods attackers use, though, is to pass Invoke-Expression the output from a web request so that they can bootstrap in larger programs without having to worry about script blocking.
To begin, let’s copy our command to a file in our web root and then make sure that Apache is running:
Our file is named t.ps1 because we want to type the least amount possible. With our web server running on Kali (192.168.1.92, in this example) and our code in t.ps1, we can execute the code through our PowerShell command line in Windows without having to worry about using the encodedcommand option:
Here, we have chained our two commands together to pull in the file from our Kali box and execute it. This gives us the same output as running locally, and we didn’t get any of the error messages we saw before when we were trying to execute scripts.
We can do this same thing with Universal Naming Convention (UNC) paths. For this part of the lab, we’re going to set up Samba so that our web directory is accessible. But first, let’s make sure Samba is set up in Kali:
Once Samba is installed, add the following to /etc/samba/smbd.conf:
Finally, we can start our Samba service:
Once our service is started, we create a share listing using smbclient to verify that our share was successfully added. With the shares set up, now we can reference the same script via a UNC path. Instead of using the command line, let’s launch the PowerShell executable without any command-line options and try this out:
Here we have used the same basic approach with our UNC path instead of a URL. This gives us a few different ways to execute code on boxes without having to change policies for PowerShell.
Exploitation and Post-Exploitation with PowerSploit
PowerSploit is a collection of tools designed to help pen testers establish a foothold and escalate in an environment. The tools have been included in other frameworks such as PowerShell Empire and the Social Engineering Toolkit (SET). These tools help us establish shells, inject code into processes, detect and mitigate AV, and more. Once we’ve established access on a box, these tools can help us escalate and dump critical system information.
Understanding how these tools work together with the rest of our toolset will help us get and maintain access to boxes as well as to propagate throughout a domain. In this section, we’re going to look at a handful of the useful tools in the PowerSploit suite and use them to create a foothold without having to drop any additional tools on the system.
Lab 15-5: Setting Up PowerSploit
Earlier in the chapter we looked at different ways to run scripts within PowerShell. In this section of the chapter, we need to get PowerSploit set up so we can access it easily. Because we’ve already mapped an SMB share to our web root, we only need to download PowerSploit from GitHub and set it up.
To begin with, we’ll clone the repository for PowerSploit. To do this, we need to make sure git is installed:
In the example, git should already be present, but if it’s not, install it now. Next, we’re going to go into our web root and download PowerSploit:
WARNING Some tutorials online will have you access the files in PowerSploit and other exploit code directly from GitHub using the raw.githubusercontent.com site. This is incredibly dangerous because you don’t always know the state of that code, and if you haven’t tested it, you could be running something destructive on your target. Always clone the repository and test the scripts you are going to run on a VM before you run them on a target system so that you, your client, and your lawyers aren’t surprised.
Typing out long URLs isn’t a ton of fun, so we’ve gone into our web root and cloned the PowerSploit repository into a directory called “ps.” It’s called ps instead of a longer name because we want our URLs to be as small as possible to make them easier to type correctly when we are on our target system. We could go through all the different subdirectories and rename each script, but that’s not practical.
When we “cd” into the ps directory, we see a number of files and a directory structure. Let’s take a high-level look at what we can find in each directory:
The AntiVirusBypass subdirectory contains scripts to help us determine where in a binary the antivirus (AV) may be identifying a file as malware. The scripts in here help split a binary into pieces, and then those pieces are run through AV. Then, when you narrow the scope down as far as it will go, you can identify the bytes in the binary that need to be changed in order to bypass an AV signature.
The CodeExecution subdirectory contains different utilities to get shellcode into memory. Some of these techniques include DLL injection, shellcode injection into a process, reflective injection, and remote host injection using Windows Management Instrumentation (WMI). We’ll take a look at some of these techniques later in the chapter as a way to get Metasploit shellcode injected into a system without using files.
When you want to get information from a system, you’d look in the Exfiltration folder. This folder has tools to help you copy locked files, get data from Mimikatz, and more. Some of the other highlights include keyloggers, screenshot tools, memory dumpers, and tools to help with Volume Shadow Services (VSS). These tools don’t help you get the data off the system, but they’re great for generating data that is worth exfiltrating.
If you want to follow a scorched earth policy, the Mayhem folder is for you. The scripts in this directory will overwrite the Master Boot Record (MBR) of a system with a message of your choosing. This requires the system be restored from backup in many cases, so if your target contains something you like, stay away from this directory.
The Persistence directory contains tools that help you maintain access to a system. A variety of persistence mechanisms are available, including the registry, WMI, and scheduled tasks. These tools help you create both elevated and user-level persistence; that way, regardless of what level of access you need, you can easily maintain persistence on target systems.
The PrivEsc directory contains tools to help you get elevated access. They range from utilities that help you identify weak permissions that can be exploited, to tools that actually do some of the work for you. We’ll take a look at how to use some of these tools later in the chapter.
Although it doesn’t help in exploiting the system in any way, the Recon directory contains tools that can help you better understand the environment in which you’re working. These tools are handy for gathering basic information, port scanning, and getting information about domains, servers, and workstations. They can help you identify what you want to target, as well as help you build profiles for what exists in an environment.
Lab 15-6: Running Mimikatz Through PowerShell
One of the amazing features of PowerSploit is the ability to invoke Mimikatz through PowerShell. To do this, we have to call the Invoke-Mimikatz.ps1 script out of the Privesc folder. Let’s give it a shot:
No error messages pop up when we run it, but a few seconds later, we see a Windows Defender pop-up indicating that the script has been flagged as malicious. When we try to run Invoke-Mimikatz after we’ve loaded the script, it’s not defined. Therefore, we have to do some work to make this function. We’re going to use some of the work done by Black Hills Security to bypass AV and make the script load.2 Let’s start with deleting some spaces and comments from our web root (/var/www/html/ps/Exfiltration) in Kali:
Now we can go back to our Windows box and try it again:
We got a bit further this time, but we still see that the script was blocked. We’re going to have to make some additional changes to make it work. In Kali, let’s change the function names around to see if we can fool the security controls that way:
Here, we’ve renamed the main command as well as one of the subcommands. This should let us get around the AV that’s flagging the script as malicious based on function names. Let’s try again:
Our script loaded, and we were able to run Invoke-Mimidogz, but the default execution didn’t get us anything. The default is to try to pull credentials from memory, which Windows 10 blocks. However, we can get information from Local Security Authority Subsystem Service (LSASS). We’re going to have to run Invoke-Mimidogz with the -command flag to tell it to dump the lsadump::sam:
We see here that our privileges weren’t high enough to get to the LSASS-owned file, so we’re going to have to escalate. Fortunately, PowerSploit has a tool to allow us to do that as well. We’ll use the Get-System.ps1 tool in Privesc to get a SYSTEM token so that we can access the SAM file:
Here we load our Get-System.ps1 file from the Privesc directory of PowerSploit. Then, when we run Get-System, it gets a token for the SYSTEM user. The SYSTEM user has the ability to access the SAM file through LSA. This time, when we run the Invoke-Mimidogz script and ask for our lsadump::sam, it’s successful. We can see the NTLM hash for User. We can copy that and then take it over to our Kali box and crack it with John the Ripper:
When we run John against our creds.txt file, we see that the password for User is Password1. We have successfully changed Invoke-Mimikatz so that it won’t be blocked by AV, and we ran Get-System to get a SYSTEM token so that we could use Mimikatz to dump credentials out of the LSASS process. We were able to do all these tasks using just PowerShell, so no additional binaries were left on the system.
Lab 15-7: Creating a Persistent Meterpreter Using PowerSploit
During a penetration test, one of the things you might need to do is create a persistent backdoor. For this lab, we’re going to look at how to load shellcode with PowerSploit and then how to use PowerSploit to make our access persistent across reboots. The first step in the process is making sure you understand how to load Meterpreter using PowerSploit.
We will be using the Invoke-Shellcode module as part of the CodeExecution directory. We’re also going to set up our Meterpreter callback using Metasploit. Let’s do the groundwork for the process by setting up our Meterpreter callback handler. We are going to use a reverse_https payload. This payload is most likely to avoid detection by AV and other security controls because it uses a common protocol and it calls back to us from inside the target’s network.
Now that our callback is set up, let’s generate the shellcode to go with it. The PowerSploit module takes shellcode in the format 0x00 (instead of the \x00 convention of most languages). We’re going to create some shellcode and then perform some conversions. We use msfvenom to generate our payload and then do some additional scripting to clean it up:
When we generate our payload, we specify that the C format should be used. Because the output won’t look right for us, we’re going to use tr to delete new lines, double quotes, and semicolons from the output. Next, we take every occurrence of \x and change it to ,0x so that we can have our delimiter and the 0x that’s required before each hex character. Finally, we’ll have the variable declaration and an extra comma in our output, so we’re going to cut the output on that first command and take everything after it. We’ll copy this shellcode and then go over to our Windows box, load up PowerShell as a regular user instead of as Administrator, and load our Invoke-Shellcode.ps1 file from the web server:
We start up PowerShell and load our Invoke-Shellcode script. Once it’s loaded, we call Invoke-Shellcode with the shellcode we copied from the previous step. When we paste it after the -Shellcode option, we are asked if we want to carry out our evil plan. Answer Y for yes and then press ENTER. In the Kali window, we should see a connect back and an open Meterpreter session:
Our session was successfully started and we got our callback, so we now have a way to launch Metasploit shellcode with PowerShell to get interactive shells. This is great, but we’ll frequently need persistence. Therefore, we need to come up with a good way of causing the code to execute reliably. To do this, we’re going to create a single command that can run and will execute our shellcode. To make this easier, we’ll start out by creating a bootstrap file that contains the core commands we need to inject our shellcode. Save the following content to /var/www/html/bs.ps1:
We put the shellcode from Metasploit in the <shellcode> section and then save the file. Note that we added the -Force option to Invoke-Shellcode so that it doesn’t ask if we’re sure we want to execute the payload. Next, we’re going to go to our Windows box and use one of the helper functions in PowerSploit to create our persistence. Inside PowerShell, we need to create a script block based on our bootstrap file:
With the script block created, now we have to create our persistence. To do this, we use the Add-Persistence function from PowerSploit. First, we need to load the code from PowerSploit:
Creating persistence requires a few steps. To begin with, we need to decide how we want our persistence to work. For this example, we use WMI so that files aren’t left on disk. Ideally, we’d have the command run as SYSTEM so that we have as much access as possible. We also want it to run at startup so whenever the system reboots, we immediately get a callback. With our script block created, we can start assembling our persistence options:
We have set our elevated persistence so that it uses WMI and loads at startup. Next, we have to specify user behavior for when we want callbacks. Ideally, we don’t want to tip our hand, so we’ve set a new persistence option for creating a new session when the user becomes idle. Finally, we combine all these together with our Add-Persistence function.
Finally, we have to run our persistence script. To do this, we can’t use iwr because the file is local. Instead, we’re going to use the Get-Content applet to get the data and use iex to execute it:
Now, to test and make sure the script worked, we must reboot our Windows box. We obviously wouldn’t want to do this in production, but this is a good test in our virtual environment to see how the tools work. We should see a shell when the system comes up in the Metasploit console. We have requested that two types of persistence be created here, and each is unique to the user context. When the script runs as Administrator, it will use WMI, and when it runs as a user, it will run a scheduled task. This is because regular users don’t have the ability to create the WMI subscriptions.
NOTE If you don’t see a shell when you reboot, it could be that you no longer have elevated permissions from the previous exercises. Either you can regain system-level permissions so that you can write to the WMI subscriptions, or you can wait for your “User” user to become idle and a new shell to be triggered through scheduled tasks.
Using PowerShell Empire for C2
Being able to run individual scripts is nice, but having a comprehensive framework for interacting with PowerShell remotely works better for real-world engagements. This is where Empire comes into play. Empire gives us the capabilities of PowerSploit in a framework with modules. It also follows a beaconing approach that’s customizable, so you can better hide your interactions with the Command and Control (C2). In this section, we’re going to set up a basic C2, escalate privileges, and add persistence in Empire.
Lab 15-8: Setting Up Empire
Our first step is to clone Empire from the GitHub repository, as shown here. We’re going to do this in our home directory because these files don’t need to be accessible from the Web.
Now that we are in our Empire directory, the next step is to make sure we have all the prerequisites. Let’s run the setup script for Empire to install all the prerequisites:
Once everything is set up, we can run Empire by just typing .\empire. But first, we need to turn off Apache so that we can use port 80 for our communication. Once Empire is loaded, we can explore the framework. Typing help will give you an overview of the potential commands.
Lab 15-9: Staging an Empire C2
With Empire set up, we need to create a listener and then a stager. The stager enables us to bootstrap execution of our C2 on the target system. The listener receives communications from the compromised systems. We set up specific listeners for specific protocols of communication. For our example, we’re going to use an HTTP-based listener so that when a C2 connects back to us, it looks like web traffic.
The first step is to set up our listener. To do this, we go into the listeners menu and choose the HTTP listener. Then we enable some basic settings and execute our listener, like so:
Now that our listener is started, our next step is to create our bootstrap file. To do this, we go back out to the main menu and choose a stager, as shown here:
We select the windows/launcher_bat module for our stager. This will give us a PowerShell command that we can copy and paste on the target system to launch our C2. We specify the listener we want it to connect back to, and finally we generate the file.
Lab 15-10: Using Empire to Own the System
In this lab, we deploy our agent and then work toward escalation and full compromise of the system. Our /tmp/launcher.bat file has three lines, and we want the second one (our PowerShell command). Let’s copy that line and then execute it on our Windows host:
This will launch our PowerShell payload. In this example, the encoded command is truncated (yours will be much longer). Once the command is launched, though, we should see activity in our Empire console:
Once our agent is active, our next step is to interact with that agent, as shown next. Note that agents are specified by name (in our case 5CXZ94HP).
Now that we are interacting with our agent, we need to bypass the User Account Control (UAC) environment so that we can get an escalated shell. To do this, we run the bypassuac command, which will spawn a new elevated shell for us to work with:
We now have a new agent that should have elevated privileges. On the Windows box, you might see a prompt to allow administrative access to a program. Whether you do completely depends on how UAC is configured on the target system. We can verify that we have an elevated shell by typing in agents and looking for an asterisk (*) by the user, which indicates elevated privileges:
The next step is to use those elevated privileges to become the SYSTEM user. We’re going to execute the getsystem module to do this:
Now that we’re running as SYSTEM, we can gather credentials from the box. We’re going to use mimikatz to do this, similar to how we did in the PowerSploit section. We’ll execute the mimikatz/sam module under the credentials section to get our SAM dump, just as we did with PowerSploit:
We now have an NTLM hash that we can work on cracking. The next step is to add persistence so that we can get our connection back over reboots. This is much simpler in Empire than it was in PowerSploit. We just have to use our persistence module and execute it:
We now have startup persistence set through WMI, so we should be able to reboot our Windows box and get a shell back.
Summary
PowerShell is one of the most powerful tools on a Windows system. In this chapter, we looked at the different security constraints around running PowerShell scripts. We also looked at how to bypass these constraints using a variety of different techniques.
Once you bypass these restrictions, the door is open for you to use other frameworks such as PowerSploit and PowerShell Empire. These tools allow you to get additional access on systems, maintain persistence, and exfiltrate data.
By using these techniques, you can “live off the land,” meaning that you only use what’s already on your target system. No additional binaries are required. Because some of your pages may be caught by network AV, we also looked at how to work around signatures to get code execution. In the end, you’ll have agents that maintain persistence across reboots, as well as a number of tools to maintain access to your target systems while gathering and exfiltrating data.
For Further Reading
PowerShell Empire home page www.powershellempire.com/
PowerSploit documentation http://powersploit.readthedocs.io/en/latest/
References
1. Matthew Dunwoody, “Greater Visibility Through PowerShell Logging,” FireEye, February 11, 2016, https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html.
2. Carrie Roberts, “How to Bypass Anti-Virus to Run Mimikatz,” Black Hills Information Security, January 5, 2017, https://www.blackhillsinfosec.com/bypass-anti-virus-run-mimikatz/.