Hello dear friends. Today we are going to explore some particular cases when targeting Sharepoint instances along your way in Pentests/Red Team exercises. When I faced this suite for the first time, I noticed that there is a lot of information that can help us, but it is spread among multiple sources, so I wanted to share my own compilation combined with my research work.

As you may know, Microsoft Sharepoint is a web-based collaborative platform that integrates with Microsoft Office. Primarily sold as a document management and storage system, the product is highly configurable and usage varies substantially among organizations. Focusing on what is of our interest, this is a web-driven suite usually accessed by authenticated corporate users and known to suffer from a myriad of CVE reported issues if not patched. These last ones lead to Remote Code Execution (RCE) and ultimately allow attackers to compromise the server instance. Sounds like a good target to compromise.

However, the complete exploitation process is not always straightforward and we may find some difficulties when trying to escalate privileges or set up some persistence implants. We are going into detail in the following sections.

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.