Saturday, August 22, 2009

Learning more about meterpreter and ideas for future research

In the course of performing a penetration test, I've taken some time to get more familiar with the Metasploit meterpreter, which is something I've wanted to look into for some time. I saw Skape and spoonm present on meterp at Blackhat some years ago in their post-exploitation talk and I was impressed with the progress they made in providing tools for penetration testers. I was also surprised at just how easy it was to bypass various anti-virus applications by using msfencode and msfpayload to create a stand-alone meterpreter binary. In my day job I'm analyzing malware some of the time and I often see it bypass detections (at least, the signature type detections from and I'm sure that it's a tough job to attempt to provide good protection in any antivirus product. I applaud anti-malware firms who work to protect people from crimeware. It's a tough problem. Anyway, regarding meterpreter. Considering that reverse shell callbacks could come at unpredictable times (unless one can really set up a scenario that creates predictability - sorta like massaging the heap, but the social engineering equivalent) I first tried (in my test lab) to use PhishScrape.rb from Attack Research as my first test, but it didn't run properly for unknown reasons. I will be looking into this further as time allows, but in the meanwhile did some digging into other meterpreter scripts out there. Came across a technique to upload mdd.exe to perform a memory dump, which could be downloaded or kept on the host and the volatility memory dump analysis tool could be used to extract plain-text passwords from memory (LSA secrets, and the like; makes me think of a bug I found in PuTTY some years ago where even after disconnect, the password was not scrubbed from memory and could be viewed with a memdump tool, a known problem that some other guy made $300 with by selling to iDefense shortly before and unknown to me until after the fact). Considering the amount of RAM on most modern systems, a memdump could be rather large and trigger bandwidth alerting in a netflow or IDS log. If one is trying to be stealthy in a pentest, this would not be good. So I wondered if the target credentials might exist in a specific memoryspace and if just those areas could be dumped with something like skapes memgrep tool (or equivalent) that would seriously save on the bandwidth and disk space requirements involved not to mention shorten the engagement. This might be a worthwhile project, if I can ever get a large block of "free" time. This has likely been done already and I just don't know about it yet.

Anyhow, none of this will be news to people who are actively using meterpreter, but some of the meterpreter script sites I looked at tonight: (greets to CG + valsmith) (greetings to alexander sotirov, who I haven't yet met) (greets to mc)

and an interesting post about the process of a pentest from carnal0wnage

I guess I'm going to need to learn ruby somewhere along the line!


  1. Looks like some memory dumping by process tool was already available in meterpreter but I didn't learn about it until after I wrote this blog entry. I know that HDM has said that keeping the docs up to date has been challenging. Now that MSF is owned by Rapid7 maybe the docs will be kept up to date and more easily accessible. Thanks

  2. for more recent meterpreter magic, check colin ames' source boston 2010 talk - neurosurgery with meterpreter. clever stuff.