These last months I've been familiarizing myself with Windows syscalls: how they work, their offensive usage and potential detections from the blue side. Although the theory was quite interesting, I had to get my hands on it.

I started with the basics: static syscalls for my version of Windows.

As I'm not a pentester - I'm a programmer - I found it too uncomfortable to have to define each syscall each time. That's why I made a list with all the syscall numbers and a template that mapped each syscall with each number in a global variable.

It was something like this:

syscall.asm:

EXTERN syscall_no:DWORD

.code

call_syscall PROC
    mov r10, rcx
    mov eax, syscall_no
    syscall
    ret
call_syscall ENDP

END

syscall.cpp:

extern "C" DWORD syscall_no = 0;
extern "C" void* call_syscall(...);

[...]

DWORD syscall_no = syscalls.find("NtReadVirtualMemory");
call_syscall(h_process, mem_addr, &buf, mem_size, nullptr);

Everything that involves Kerberos functionality is such a complex subject… since I’ve been abusing these attack chains a lot recently, I thought this post would be helpful to someone.

NOTE: Nothing explained here is new at all. If you understand how Delegations work you may be already aware of these vectors. Nonetheless it might not be as straight forward for everyone, hence I’m writing this.

If you are not familiar with Kerberos Delegation, you can find some links in the References section as I don’t feel necessary to explain what is already perfectly explained by others.

Introduction

Ok let’s asume we've compromised Web01.capsule.corp, a server with Kerberos Unconstrained Delegation enabled:

Hello H4x0rs! At this time you surely have heard about the new and dangerous Citrix vulnerability labeled as CVE-2019-19781, consisting in a Directory Traversal plus Remote Command Execution attack vector. During a real security engagement I had to face a peculiar situation related to this and I wanted to share it with you, hope you find it useful.

Just as a quick recap, CVE-2019-19781, also known as “Shitrix” takes advantage of how the Citrix Gateway appliance handles templates. You can create a template by making a call to the /vpn/../vpns/portal/scripts/newbm.pl endpoint and inserting some Perl template into an XML file. This one contains the payload, but it is not executed until a request is made to the /vpn/../vpns/portal/<xml_name>.xml endpoint, which is the action that triggers the command execution.

There are a few exploits available to the public that implements that process so that you only have to specify the target and press enter to get a shell. However none of these worked for me for a good reason that we are going to explore in the following lines.