Skip navigation
All Places > Metasploit > Blog > Authors thelightcosine

Metasploit

7 Posts authored by: thelightcosine Employee

The Server Message Block (SMB) protocol family is arguably one of the most important network protocols to be conversant in as a security professional. It carries the capability for File and Print Sharing, remote process execution, and an entire system of Named Pipes that serve as access points to any number of services running on a machine, such as Microsoft SQL Server. For users of Metasploit, they will know SMB as the protocol used for PSExec, a remote code execution module that can turn any Administrator credentials into a session on the box. It is also the protocol that has played host to several of the most high-profile vulnerabilities, such MS08-067 (the vulnerability used by the Conficker Worm), and MS03-039 (the vulnerability used by the Blaster Worm).

 

Additionally, the File and Print Sharing services mean that SMB is the default means of sharing files in a Windows environment. Whenever you create a “network share” in Windows, it is being served up over SMB. I can tell you, from personal experience, that network shares are a gold mine during a penetration test.

 

Now, armed with some understanding of why this protocol is so important, we must dive into how Metasploit handles SMB. Metasploit’s current “implementation” of SMB has been an ad hoc reverse-engineered effort that started small and was added to with each major SMB vulnerability we wrote modules to target, which turned out to be rather a lot. The implementation is extremely rough, and only supports SMB1. There are some very good reasons for why this is the case.

 

SMB is complex

SMB, by its very nature is complex. It is a binary protocol, opposed to a text protocol such as HTTP, and is only readable by computers that have been trained to do so. It also has a wide array of capabilities, some of which are interdependent upon each other.

 

Earlier I called SMB a protocol family, and that’s because it is not really just one protocol, nor is it a group of protocols operating at various layers as is the case with something like RDP. It is a Frankenstein’s Monster of efforts by different groups including IBM, Intel, 3COM, and Microsoft. The formative years of SMB were not governed by a single driving design, and it can be seen in the protocol. What’s worse, is that for a long time there was no available developer documentation for the protocol specification. Anecdotally I have heard the story that Microsoft themselves had lost any documentations on the spec, and had to reverse engineer the protocol to provide said documentation.

 

This left Metasploit developers and contributors in the position of only being able to look at packet captures to reproduce what they see going on.

 

The rise of SMB2 and SMB3 and the decline of Metasploit’s SMB

After years of dealing with SMB/CIFS Microsoft finally designed a new protocol, SMB2. They rolled this out for the first time in Windows Vista, and it has since become standard in every Windows OS. SMB2 is a more elegant and more streamlined version of the SMB protocol. Unfortunately, none of Metasploit’s existing code supported the new protocol. For a while this was fine as SMB1 was still enabled by default in the Windows OSes. Over the past few years it has become an increasingly common practice however, to disable SMB1 and only allow SMB2.

 

This change meant that Metasploit could no longer talk to those boxes. Modules from information gathering, to brute forcing, to exploits all suddenly became ineffective against these boxes. On top of this, Metasploit’s ad hoc implementation of SMB1/CIFS had become very recognizable due to its particular idiosyncrasies. IDS/IPS vendors began to differentiate between Metasploit’s SMB traffic and that of a legitimate SMB client. All of this culminated in our SMB support becoming less and less useful as time went on.

 

RubySMB to the rescue

We on the Metasploit team knew something had to be done about our aging SMB code. We weighed several options including trying to clean up the existing code. In the end, we decided to create a new library from scratch. This new library would support both SMB1/CIFS as well as SMB2, and be designed with an eye to coming back and adding the even newer SMB3.

 

We are pleased to announce that, not only have we been working on this new RubySMB gem, but that we have hit the first milestone in its development. The RubySMB Gem can do full client authentication to a remote server. It can communicate over SMB1 or SMB2, and does multi-protocol negotiation so that it can find the correct dialect to speak invisibly to the user.  It handles Extended Security mode for the old SMB1, and can handle security signing for both versions of the protocol.

 

The gem has also been integrated into Metasploit Framework for the first time. We recently added a new version of the SMB Bruteforce, auxiliary/scanner/smb/smb2_login. This version of the SMB LoginScanner module behaves essentially like the original, except that it seamlessly handles both versions of the protocol, and security signing all without any user configuration. It currently does not support the admin privilege check, which is why it has not replaced the original smb_login module.

 

This represents Metasploit’s first steps into future proofing our support for the SMB Protocol family.

 

The Future of RubySMB

We still have a lot of work to do on the RubySMB project, and a lot of important milestones to hit. In the short term, we are shooting for the following goals:

 

  • In the Gem:
    • Support for Listing, Reading, and Writing Files
    • Support for named pipes
    • Simple SMB File Share Server
  • In Framework:
    • Converting smb_version information gathering module to use the new gem
    • Converting PSExec to use the new gem
    • Building in support for the simple file server that will allow modules to define resources on the server and set callbacks for when something requests those resources, much like how the Rex HTTPServer works today.
    • Look at adding SMB Named Pipe transports for Meterpreter payloads

 

In the longer term we have several other goals we hope to accomplish with this project:

  • Adding Support for SMB3
  • Adding SMB3 protocol level encryption (potential IDS/IPS evasion capabilities)
  • Begin work on a similar project for DCERPC to integrate with this gem

 

Creating protocol libraries at this level is not a simple or easy task, but the results will be rewarding for all members of the Metasploit Community. We will be able to not only update compatibility for our existing SMB-based features, but begin expanding those capabilities. If you are interested in joining in on this effort, please check out our starting wiki page for the project.

 

- David “thelightcosine” Maloney

UPDATE: It has been pointed out that there is prior work worth noting. This blog post by Damon Cortesi talked about using Volume Shadow Copy to get the SAM file back in 2005. As with all things in our Industry, we stand on the shoulders of those who came before us. We would certainly not want to take away from anyone else's previous work and accomplishments.

 

Dumping the stored password hashes from a live Domain Controller can be tricky. There are a number of things to consider, and there have been several approaches over the years. Some of these approaches have had glaring problems with them. We’ve recently changed all that. Before we talk about our new approach, let’s take a look at the history there.

 

LSASS Injection

 

The original way Metasploit dumped any Windows password hashes was through LSASS injection. LSASS(Local Security Authority Subsystem Service) is the service responsible for handling authentication and security policies on a Windows system. Meterpreter would inject into the lsass.exe process and scrape the password hashes directly out of process memory. This was effective but very dangerous. Injecting into LSASS could make the process unstable and could potentially crash it. If LSASS goes down in Windows, the whole system ends up in a bad state and will have to be rebooted to fix it. If you do this on a live Domain Controller, you are not just taking out authentication on that Domain Controller but potentially for the whole domain itself.  Metasploit moved away from this approach for workstations a long time ago, abandoning it for a Registry based approach in the Hashdump post module. This remained the de facto method for getting Domain hashes however.

 

NTDS.dit

 

The NTDS.dit file is the database for Active Directory. It is an Extensible Storage Engine(ESE) Database. This is a poorly documented format that is based on the Jet Database Engine. While a Domain Controller is running, NTDS.dit is of course locked. We need a way to get a copy of the file that is not locked. Several years ago there was an article on safely dumping domain hashes. It was written by Tim Tomes about research that he and Mark Baggett had done. Their technique abuses Volume Shadow Copy Service(VSS) to make a copy of the NTDS.dit file. They then used other tools to then parse the raw file itself. Their work, and ours was based heavily on the research of Csaba Barta published in this white paper.

 

Running Extraction Tools on the Victim

 

Once we have a copy of NTDS.dit we need to parse it. The approach used by tools like ntdsxtract is to parse the file itself. If we were to run tools like this on the victim, they will suck the whole file up in memory. Parse out the user accounts, and then dump them back out somewhere. The problem with these tools is that they can greedily suck up memory and CPU cycles on the machine. You can still end up pegging the CPU on the live Domain Controller. As a PenTester your client will not be too happy if you grind their DC to a halt. If you are doing a true Red Team type exercise, this also greatly increases the chance that you’ll get caught. There are definitely some issues with this approach as well.

 

Downloading NTDS.dit

 

Another option that people use, is to download the copy of the NTDS.dit file, and the pieces of the Registry that they will need to decrypt the stored hashes. They can then feed those pieces into offline tools on their own box, and not worry about consuming target resources. The glaring problem with this approach arises in larger organizations. NTDS.dit can grow to be GB in size. Transferring a file that big will take time. It is likely to attract notice, and if your connection to the target is lost in the middle, you have nothing usable for your trouble. This is still not an ideal scenario.

 

Meterpreter to the rescue!

 

Remember when I told you that NTDS.dit is an ESE Database? ESE is based on the Jet Engine. The Domain controller must have some way of accessing NTDS.dit that does not involve reading it as a raw file right? Well, every Windows system comes with the JetAPI. We can use the JetAPI to have Windows handle all the database parsing for us. We create a Jet Engine Instance, and attach it to our copy of the NTDS database. We can then step through the database and find the specific records for valid user accounts. This allows us to do all our parsing on the target, but without loading the entire file into memory at once.

 

When Meterpreter attaches to the database, it creates a Channel back to the Metasploit client. This channel acts as a pipe directly to the parser. Our client is then able to perform read operations on this channel. Every time a read operation is triggered, the parser will pull out up to 20 user accounts and send them back over the wire. Batching the accounts this way serves multiple purposes. It keeps our memory usage low as we only have 20 accounts loaded into memory at a time. It keeps our request/response windows somewhat efficient, which is important for HTTP based session transport. Most importantly, it means that we are pulling accounts in real time. If our connectivity is lost, or the session dies, we have not lost all progress. We still end up with the accounts we managed to get to at that point.

 

 

The User Accounts

 

The NTDS user account objects we get back contain a lot of information about those accounts. Let’s take a look at what we get from each account:

 

  • The Account Name (samAccountname)
  • The account Description
  • The Date and Time of the last time the account logged in
  • The Date and Time of the last time the account’s password was changed
  • The Date of when the current account password expires
  • If the Account is Disabled
  • If the Account is locked out
  • If the Account’s password has expired
  • If the Account’s password is set to never expire
  • The current NT and LM hashes for the account
  • The saved history of previous NT and LM hashes (up to 20 depending on AD settings)

 

Make a special note of that last one. Not only are we dumping the current NTLM hashes for each account. We’re dumping all the password hashes going back up to 20 previous passwords.  If you crack all of these hashes, you’ll be able to even do trending data on the passwords. Does a particular user just use the same password with an incrementing number? Well you’ll know what his next password is. Do you see “changeme123” or “summer2015” in a lot of user’s histories? Then you probably have the IT helpdesk’s password reset scheme. There are a lot of ways this historical data can benefit of a PenTester, and we won’t take the time to go into all of them here. Just use your imagination.

 

The current and historical hashes will be saved as NTLMHash Credential objects in the database. From here you can crack those hashes with Metasploit’s John the Ripper integration, using auxiliary/analyze/jtr_crack_fast. If you don’t want to crack them you can always use them for pass the hash attacks using our Bruteforcers/Psexec mdoules. Metasploit Pro users will be able to immediately use those credentials in the Credential Reuse part of the app, or the Pass the Hash Metamodule.

 

 

No longer will you have to reach for another tool when you get a session on a Domain Controller. Just reach for the new post module at post/windows/gather/credentials/domain_hashdump. It will take care of all the rest for you. Happy pwning!

 

[ETA] If you'd like a video explainer of how to safely dump Active Directory password hashes with Meterpreter, we have one right here:

wbwactivedirectory.jpg

This post is the fourth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014.


This summer, the Metasploit team began the large undertaking of reworking credentials throughout the project. Metasploit, as you already know, began as a collection of traditional exploits. Over the years it has grown into much more than that. Credentials were first introduced into Metasploit in the form of Auxiliary Scanner modules meant for bruteforcing. The data model that was created to support this was designed with only this use case in mind. The result was that our concept of creds was as follows:

 

  • A Username
  • A Password
  • The Service it was valid on

 

This was an unfortunately limited and limiting approach. As Metasploit continued to grow and develop, Credentials kept cropping back up. We found new ways to find, validate, and exploit credentials. As we continued to grow we found ourselves chaffing under those constraints. There were a number of issues with this concept of creds:

 

  • You couldn’t have a Credential without knowing exactly what service it was for
  • The same username and password on a different service was a different credential. This means you couldn’t see all the services a given credential pair was valid on, easily.
  • Several forms of authentication required additional components to be valid. For example an AD Domain Name, a PostgreSQL Database Name, or an Oracle SID.
  • There was no way to store incomplete credentials. You couldn’t get a list of valid usernames from AD, then use those to try and bruteforce their specific passwords.
  • There was no good way to store Password hashes that were not replayable like SMB NTLM Hashes were. This made it difficult to properly store those hashes for offline cracking
  • There was no normalization of credential data in the database, making it extremely inefficient to store and retrieve data about Credentials from the Database.

 

These were just some of the problems we encountered. We had to find dirty hacks to try and make things fit every time we wanted to do something new with Credentials. On top of that, the code responsible for dealing with creds, reporting them, bruteforcing for them, etc was showing its age. The code was diversified, with several different implementations in place, hacks in some places holding it all together. It was time for a change

 

A Fresh Approach

We began the work of redoing Credentials from the ground up. We had to redefine what a Credential meant. We identified three basic parts of a Credential

 

Public: A Public is the part of a Credential that is publicly known; typically a username. Currently in Metasploit, there are two type of Public, a Username and a BlankUsername. The Metasploit::Credential::Username class holds a known username (duh?). There should only ever be one instance of BlankUsername at a time. It represents a case where the username is not really needed for the credential, such as the case with VNC.

 

Private: A Private is the part of a Credential that is secret. We currently have several types of Privates in Metasploit:

  • Password – a plaintext password
  • BlankPassword – a single instance object used whenever we say that the password is Blank or doesn’t matter
  • SSHKey – an SSH private key
  • NTLMHash – an NTLM hash is special because it is a password hash that can be replayed against SMB as a valid authentication mechanism. This is the basis of the “Pass the Hash” attack
  • NonreplayableHash – This is all the other kinds of password hash. These are not usable for things like bruteforce or exploits like tomcat_mgr_deploy, but can be used by our offline cracking modules to try and derive plaintext passwords.

 

Realm: Realm is one of the trickier, and more confusing parts of our new credential concept. We mentioned earlier that some scenarios require some additional context for authentication. Let’s take the example of an AD Domain. If you have a user  Administrator and one contosso\Administrator, those are NOT the same account. The first one is probably a local admin on a box, while the second one may be the Domain Admin. Chances are, hopefully, that they also will not have the same password. It is therefore important to clearly distinguish that these are not, in fact, the same creds.

 

Credential Core: We tie all of these components together into what we call a Credential Core. A credential core associates the components together to form a single credential, as the same individual components could belong to many different credentials

 

With those core pieces in place, it is time to extend the capabilities of the raw data model, beyond just recording that a Credential exists. The next step can be thought of as the Look Ahead and Look Behind operations of a Credential. That is to say “where did this Credential come from?” and “Where does this Credential work?”

 

Origin: A Credential Core will always have an Origin. The Origin represents how we first learned about this specific credential core in this workspace. There are currently several types of credential Origins

  • Service: A Service Origin means that the Credential Core was obtained through remote interaction with a network service. This will usually be from either an Auxiliary Module or an authenticated exploit that succeeded. The Origin will contain the full name of the module that was used, as well as an association to the service it was run against to get that credential.
  • Session: A Session Origin means we got the credential from post-exploitation methods on an open Session. It will contain the full name of the post module that was run, as well as an association to the Mdm::Session record, for the session it was obtained from.
  • CrackedPassword: A CrackedPassword origin indicates that the Credential Core was obtained by using Offline Cracking against either an NTLMHash or a NonreplayableHash Credential. It will contain an association back to the original credential Core that it was cracked from. Because the Original Core will also have an Origin, this means we preserve an entire chain of origin on the Credential. For example, if you have an NTLMHash that was obtained from a Meterpreter Session then crack it. The Plaintext version of the Core will have a CrackedPassword Origin pointing back to the Hashed version of the Core. The hashed version of the Core will have a Session Origin that will tell you it came from the hashdump module run against a given session. The Session object will tell you the details of how that session was opened. The entire history of how you got from running a given exploit to obtaining that plaintext credential is now recorded.
  • Import: An Import Origin indicates that the Credential Core was imported from an external file. Metasploit supports importing data from a number of different sources, and also has the ability to export Credentials in it’s own format and reimport them.  The Import Origin also contains the name of the file that was imported.
  • Manual: A Manual Origin indicates that a user manually entered that Credential in. In Metasploit Pro, Express, and Community the Manual Origin will also contain an association to the User who entered it.

 

Login: A Login is the association between a Credential Core and a Service it is believed to be valid on.  A Login will also contain two other useful pieces of metadata. It will tell you the last time it was attempted, and it will contain a status. There are several different accepted statuses for Logins currently:

  • DENIED_ACCESS: This status is set on the Login when the credential was valid but had insufficient permission to login or perform the requested action
  • DISABLED: this status is set when the credential was valid but the account has been disabled.
  • INCORRECT: this status is set when the credential was not actually valid for the service.
  • LOCKED_OUT: this status will currently only ever be set on SMB Logins as it is the only service that will give us this level of detail. It is set when the account is locked out.
  • NO_AUTH_REQUIRED: This status will be set when the service does not actually appear to require auth. Indicates that the Login was a false positive due to the service accepting any authentication.
  • SUCCESSFUL: pretty self-explanatory
  • UNABLE_TO_CONNECT: This status is set when the last attempt to use the credential against this service returned some sort of a connection error.
  • UNTRIED: This status is set when we think the Credential is valid on the service, but haven’t actually attempted it yet. This will occur when we get credentials from something like post exploitation where we know where the cred is supposed to be valid on.

 

This may all seem very complicated, but it is extremely powerful. On a conceptual level, Credentials are a very difficult thing to capture accurately. This is especially true because of the conflicting authentication standards between widely differing services. This approach gives us the best flexibility to handle various different scenarios. It also allows us to do some pretty cool things with the data. Let’s take a look at a visual example for a second.

 

creds_example1.png

 

 

In this example we compromise a machine with the ms08_067 exploit, and get a Meterpreter Session. That Session has an Mdm::session record saved to the database. That Session record includes what exploit was used to open it, and the datastore options that were selected for that particular run. Once we have the session we run the Hashdump post module and get some NTLM Hashes. We get one for the local Administrator account. We create the Public with the Username ‘Administrator’, we create an NTLMHash private as well, and then create a Credential Core tying them together. When we create the Core, we also create a session Origin that says this core came from running ‘post/windows/gather/hashdump’ against Mdm::Session 1. Now we run ‘auxiliary/analyze/jtr_crack_fast’ which feeds those NTLM hashes into John the Ripper and successfully cracks the Administrator hash. We create a new Password object(‘Password1’) and create Credential Core 2 which has that Password and uses the same Public object as Credential Core 1. Core 2 has a CrackedPaassword Origin which points back at Core1. We then take Core 2 and use it against an SMB Service on a Second host and successfully login, so we create Login1 which connects that service to Core 2 with a Successful status and a last_attempted_at timestamp of the exact time we successfully logged in.

 

Wheew, that was a mouthful. Let’s see what that means looking at it in reverse now. You’re getting ready to write up some findings, and you take a look at your data. You see that you have a successful Login on host2. It was a Login on the SMB Service, and you know exactly when it was that you Logged in. You see that you Logged in using Administrator:Password1. How did you get that credential? Well you cracked it from this NTLM Hash. Where did you get the NTLM Hash?  You got it by running Hashdump on the Meterpreter Session on Host1. You know exactly when you did that to because the Origins have timestamps. How did you get that session? Well you got it by running ms08_067 against that host, at this specific time, with these specific settings. See how powerful that is? You can show an entire chain of events, and analyze exactly what they mean for the environment you’re testing.

 

LoginScanner: Bruteforcing Evolved

With our Credential modeling now completely redone, bruteforcing needed to level up as well. The old Auxiliary Scanner modules for creds had become a tangled mess. There were different approaches in each one, and we need a sane way of rationalizing exactly how we do bruteforce. Additionally we wanted clean, performant code that was covered by automated tests. This is the crucible in which we formed the LoginScanner classes. I won’t bore you with as exhaustive a detailing of the inner workings of the LoginScanner classes. The important parts are that all LoginScanners derive from a common base which defines the standard behavior for a LoginScanner. This include things like Bruteforce Speed, Timeouts, the way it takes credentials etc. Each module then  instantiates the correct  LoginScanner class, passes in the correct datastore options, and then calls the scan! Method, and passing it a block. The scanners all take a block for each login attempt result, so that any module that uses them can decide what those results mean. This makes the LoginScanners reusable and extremely flexible.

 

You might ask what this means for you as a user. It means predominantly two things: The reliability of the LoginScanner modules is greatly increased. Each one should behave in the same general way. If you know how to use one, you know how to use all of them. The second is that the LoginScanners are now significantly faster and more efficient. In fact, it actually caused me some problems while making sure they were Timeout safe. I wrapped some scanners in a 1 second timeout just to make sure they cleaned up properly. To my surprise the Postgres LoginScanner completed before the timeout triggered. It turned out that the Postgres LoginScanner was now capable of making approximately 12 login requests in a one second period. Your mileage will vary based on network conditions and the protocol you are using, but there is no doubt that these new LoginScanners are capable of some serious speed compared to their predecessors.

 

Looking toward the New Year

This work is far from finished. This undertaking is the single largest rework Metasploit has seen since the conversion from Perl to Ruby. We bit off quite a chunk of work, and we are far from finished. There are still modules out there that use the old credentials. This will be one of our main focuses in the near future. We will also be looking at leveling up msfconsole’s capabilities in terms of looking at the creds you have saved. Things like offline cracking will probably get additional attention in the future as well. The fact is that Credential based attacks are one of the most prevalent breach vectors. You can patch every system in your environment. You can hook up IPS and AV at every art of your network One weak credential can still bring your entire Organization to its knees. Buffer overflows come and go, bad passwords are forever. Merry Haxmas!

Multiple modules inside the Metasploit Framework bear the title PSExec, which may be confusing to some users.

 

first.png

 

When someone simply refers to “the PSExec module”, they typically mean exploit/windows/smb/psexec, the original PSExec module. Other modules are more recent additions, and make use of the PSExec technique in other ways. Here’s a quick overview of what these modules are for:

 

Metasploit Module

Purpose

Comment

exploit/windows/smb/psexec

Evading anti-virus detection

Service EXE is now getting caught by most AV vendors. Use custom templates or MOF upload method to circumvent AV detection.

exploit/windows/local/current_user_psexec

Local exploit for local administrator machine with goal to obtain session on domain controller

Great starting point to take over an entire network. Attack is less likely to get noticed because it uses legitimate access methods.

auxiliary/admin/smb/psexec_command

Run arbitrary commands on the target without uploading payloads.

Unlikely to be detected by AV but limited because you can only send one command, not obtain a session.

auxiliary/scanner/smb/psexec_loggedin_users

Get list of currently logged in users

Run this module against all targets to get tons of information on your targets.

 

 

We’ll now look at each one in detail below. First, let’s talk about what PSExec is, and where the idea comes from.

The PSExec Utility

 

The name PSExec comes from a program by the same name. Mark Russinovich wrote this utility as part of his sysInternals suite in the late 90s to help Windows Administrators perform important tasks, for example to execute commands or run executables on remote systems.

 

The PSExec utility requires a few things on the remote system: the Server Message Block (SMB) service must be available and reachable (e.g. not blocked by firewall);  File and Print Sharing must be enabled; and Simple File Sharing must be disabled.

 

The Admin$ share must be available and accessible. It is a hidden SMB share that maps to the Windows directory is intended for software deployments. The credentials supplied to the PSExec utility must have permissions to access the Admin$ share.

 

PSExec has a Windows Service image inside of its executable. It takes this service and deploys it to the Admin$ share on the remote machine. It then uses the DCE/RPC interface over SMB to access the Windows Service Control Manager API. It turns on the PSExec service on the remote machine. The PSExec service then creates a named pipe that can be used to send commands to the system.

The PSExec Exploit (exploit/windows/smb/psexec)

 

The PSExec exploit modules in Metasploit runs on the same basic principle as the PSExec utility. It can behave in several ways, many of them unknown to most users.

 

The Service EXE

 

In this method, the exploit generates and embeds a payload into an executable, which is a Service image uploaded by the PSExec utility – similar to the PSExec service. The exploit then uploads the service executable to the Admin$ share using the supplied credentials, connects to the DCE/RPC interface, and calls into the Service Control Manager before telling SCM to start the service that we deployed to Admin$ earlier. When the service is started, it starts a new rundll32.exe process, allocates executable memory inside that process and copies the shellcode into it. It then calls the starting address of that memory location as if it were a function pointer, executing the stored shellcode.

 

The service EXE is generated using an executable template with a placeholder where the shellcode is inserted. The default executable templates in Metasploit Framework are flagged by major AV solutions because most anti-virus vendors have signatures for detecting these templates. No matter what payload you stick in this executable template, it will get flagged by AV.

 

AV Evasion

The PSExec exploit has several advanced options. The first is the options to supply alternative executable templates.

second.png

 

There are two separate options: One is to use set EXE::Path, which will tell Metasploit to look in a different directory for the executable templates. The other is set EXE::Template, which is the name of the executable template file to use. If you create an executable template and store it in a different directory, you will need to set both of these options. Writing a custom executable template is a good way to avoid AV detection. If you write your own EXE template for the PSExec exploit, it must be a Windows service image.

third.png                                                  

 

In addition to writing a custom executable template, you can write an entire executable on your own. This means that a Metasploit payload will not actually get inserted. You will code the entire behavior into the EXE itself. The psexec exploit module will then upload the EXE and try to start it via SCM.

 

Tip: If you would like to save time evading anti-virus, you can use the dynamic executable option in Metasploit Pro, which generates random executable files each time that are much less likely to be detected by anti-virus. (Watch my webcast Evading Anti-virus Detection with Metasploit for more info.)

 

The Management Object File (MOF) upload method

fourth.png

MOF files are a part of the Windows Management Instrumentation (WMI). They are Manage Object Files. They contain WMI information and instructions. MOF files must be compiled to work properly, however there is a way around that on Windows XP.  In Windows XP, if you drop an uncompiled MOF file in the system32\wbem\mof\ directory, Windows XP will compile the MOF for you and run it.  The PSExec exploit has a method for using this to our advantage. If you set MOF_UPLOAD_METHOD true, it will do a few things differently. Our payload EXE will be generated as a normal instead of a service EXE. It will then upload it via Admin$ as expected before generating a MOF file that will execute the EXE we uploaded. It will use Admin$ to deploy the MOF file to the MOF directory. Windows XP will then compile and run the MOF, causing our payload EXE to be executed.

 

The MOF method can be combined with the custom EXE or custom template methods described above to try and evade AV as well. The MOF Method currently only works on Windows XP as later versions require the MOF to already be compiled in order for them to run.

 

The PSExec Current User Local Exploit(exploit/windows/local/current_user_psexec)

 

The Current User PSExec module is a local exploit. This means it is an exploit run on an already established session. Let’s set up a scenario to explain how this works. In our scenario you do the following:

 

  1. Set up a browser exploit at some address
  2. Trick a local system administrator to visiting the site
  3. Get a reverse Meterpreter shell, inside the administrator’s browser process
  4. Run netstat to see if the administrator is connected to one of the Domain controllers

 

So now Meterpreter is running on a system administrator’s box under her user context. While there may not be something you’re interested in on her workstation, she has permission to access a domain controller (DC), which you would like to shell. You don’t have her credentials, and you cannot talk directly to the DC from your box.

 

This is where the current_user_psexec module comes in. This local exploit works the same way as the psexec exploit. However, it runs from the victim machine. You also do not supply any credentials. This exploit takes the authentication token from the user context, and passes that alone. This means you can get a shell on any box the user can connect to from that machine and has permissions on, without actually knowing what their credentials are.

 

This is an invaluable technique to have in your toolbox.  From that first machine you can compromise numerous other machines. You can do this without having set up any proxy or VPN pivots, and you will have done it using legitimate means of access.

 

The PSExec Command Execution Module (auxiliary/admin/smb/psexec_command)

 

Submitted by community contributor Royce @R3dy__ Davis, this module expands upon the usefulness of the PSExec behavior. It utilizes the same basic technique but does not upload any binaries. Instead it issues a single Windows command to the system. This command is then run by the remote system. This allows arbitrary commands to be executed on the remote system without sending any payloads that could be detected by AV. While it does not get you a shell, it will allow you to perform specific one off actions on the system that you may need.

 

The PSExec Logged In Users Module (auxiliary/scanner/smb/psexec_loggedin_users)

 

Also brought to you by Royce @R3dy__ Davis, this module is a specialized version of the command execution one. It uses the same technique to specifically query the registry on the remote machine and get a list of all currently logged on users. It is a scanner module which means it can also run against numerous hosts simultaneously, quickly getting the information from all the targeted hosts.

 

Summary

 

What we’ve seen here is that the PSExec technique is actually a relatively simple mechanism with immense benefit. We should all remember to thank Mark Russinovich for this wonderful gift he has given us. As time goes by, people will find many more uses for this same technique, and there is room for improvement on how these modules work and interact. The PSExec exploits are two of the most useful, and most reliable, techniques for getting shells in the entire Metasploit Framework.

 

[ETA] If you're looking for more information on PSExec, there's more information in this Whiteboard Wednesday video -- How PSExec and Remote Execution Work:

wbwpsexec.jpg

I hear a lot of questions concerning antivirus evasion with Metasploit, so I’d like to share some the information critical to understanding this problem. This blog post is not designed to give you surefire antivirus (AV) evasion techniques, but rather to help you understand the fundamentals of the issue.

 

A Quick Glossary

 

Before we begin, let’s define a few terms. This will be important for understanding some of the things we will discuss.

 

Payload: A payload is the actual code that is being delivered to a victim by an exploit.

 

Signature: In the antivirus world, signatures are the most basic form of detection. A signature is a set of rules or pattern match against code. Signatures are based on known examples of malicious code. For a real life analogy, think of those artists sketches the police put on the news when they are looking for a criminal. They are meant to convey enough detail so that people can easily recognize someone who is known to be dangerous.

 

Heuristics: Heuristics are the attempt to identify malicious code by matching specific behavior instead of exact patterns in that code. It watches the way the code runs, and determines dangerous behavior based on more complex sets of rules.

 

Sandbox: AV sandboxes are protected segments in the operating system, where code can be run safely. It prevents that code from harming important parts of the OS. AV can run malicious code in a sandbox while it uses heuristic detection to determine if it’s safe. Because these sandboxes could seriously slow down operation of the system, it usually only runs for a brief period then releases the code if nothing malicious is detected.

 

Payloads

 

The first thing we need to understand is how payloads work in Metasploit. When talking about payloads, there are two different kinds of payload we need to understand.

 

Singles: A single payload is a piece of standalone shellcode that is generated in one step and that performs a single discrete task, for example the Windows Add User Payload.

 

Staged: Staged payloads are componentized payloads, which are used to get larger more complex payloads to the target when there isn’t enough space in the exploit. Staged payloads are broken down into stages, hence the name.

 

  • Stage 1: Also know as ‘the stager’, is a relatively small bit of shellcode that opens a communication channel back to a payload handler running in Metasploit. The handler then sends the stager back the next stage of the payload, which is placed into memory and executed. Examples of stagers include: bind_tcp, reverse_tcp, reverse_http, and reverse_https among others.
  • Stage 2: Is what will actually be setting up our payload to run in memory. In the case of Meterpreter, this will load the basic Meterpreter skeleton into memory, which downloads the Meterpreter libraries and extensions from Metasploit.

 

Many times when people say that AV is catching Meterpreter, it is actually the stager that is getting flagged. These stagers are fairly recognizable, and are the easiest path for AV to try and block our payloads.

 

Executable Templates

 

In many scenarios, the exploit directly writes the stager into the memory of the application being exploited. However, in some cases Metasploit has to deliver payloads through vulnerabilities other than memory corruption. This is where executable templates come in handy. We cannot simply write a blob of shellcode to the machine and expect it to execute; we need a properly formatted executable file that will handle this for us.

 

An executable template is primarily responsible for one job: It grabs space in memory, writes stager shellcode (or a single payload) into that space, and executes it. These executable templates come in many flavors, but PECoff (executable file) and ELF binaries are the most common.

 

When an executable payload is generated in Metasploit as part of an exploit, or generated through something like MSFVenom, a set of default templates are used. Most of the AV vendors have added static signatures for these default templates. These signatures don’t even look for a payload; they just look for the executable template. Look what happens when we upload one of these empty templates to VirusTotal:

 

1.png

 

 

There is nothing actually malicious in that executable but 33 different AV products pick it up. This is a lazy but effective technique on the AV Vendors’ parts. Since they know a lot of Metasploit payloads will be wrapped in these specific binaries, they create some static signatures and then go on to other things.

 

How do we get around this issue? Well the most obvious answer is to use a different executable template. When using an exploit that leverages an executable payload, there are advanced options available for the use of custom templates. To see this, select the psexec module and hit ‘show advanced’. You’ll see these options under advanced options:

2.png

 

There are a lot of different considerations when selecting an executable template: You could try to use an existing executable that is known to be safe, and try to hide your payload there. Some of the advanced options above exactly do that. For more information on this approach, I also highly recommend Chris Gates’ blog post: Carnal0wnage; Attack Research Blog: Msfencode a Msfpayload Into An Existing Executable

 

You could also write and compile your own template, enabling you to do all sorts of complex and dirty tricks in your template. We’ll talk a little more on this later on when we discuss the dynamic executable option available in Metasploit Pro.

 

The Encoder Myth

 

Many users seem to be confused about what encoders are for: “AV keeps picking up my payload no matter what encoder I try.” Encoders are not meant to evade AV but handle bad characters. When dealing with memory corruption exploits some characters may break your exploit. In most cases, a null byte anywhere in the payload will cause it to fail. Depending on the protocol, other characters may cause unintended results. Common characters for this are space, tab, carriage return, and line feed, among others.

 

Encoders are designed to modify the payload so that it will work for a given exploit, avoiding a known set of bad characters and size limitation. There are many different ways we can go about this.

 

Newer, more advanced encoders actually use a rolling XOR encoding to create polymorphic code. The encoder uses a rolling XOR on the payload creating an encoded data stream. It then prepends a decoder stub to it. When the payload is delivered, the decoder stub triggers first, decoding the payload back into executable shell code in memory. The payload is unrecognizable until it runs. This has, in the past, created the unintended side effect of helping to evade antivirus, and is probably responsible for the creation of the Encoder Myth.

 

However, any decent heuristic detection inside AV will not be fooled by this simple obfuscation. Furthermore the decoder stub itself will tend to be fairly recognizable and could potentially be caught with signature-based detection.

 

Another way to evade AV is through the creation of new polymorphic encoders, obfuscating the code and creating currently unrecognized decoder stubs. This is a stopgap measure, as AV eventually creates signatures for the new decoder stubs, and is still not be particularly effective against heuristic detection.

 

Dynamic Executable Templates in Metasploit Pro

 

Starting with version 4.4, Metasploit Pro offers the option to dynamically generate executable templates when using the psexec module, which can be selected from Advanced Options when running the PSExec module, or Payload Settings in the Bruteforcer when selecting SMB.

3.png

The Dynamic EXE Option for PSExec

 

4.png

 

Dynamic EXE Option in the Bruteforcer

 

A dynamic EXE can also be generated manually using the exploits/pro/windows/dynamic_exe module. This will generate a dynamic exe on Metasploit Pro’s local file system. The payload can then be delivered by various out-of-band methods.

 

5.png

 

The purpose of the dynamic executable generator is to avoid AV detection. It generates the C code for the executable template, and includes the payload directly, instead of injecting it after the template has been generated. The C code is written in a random, on-the-fly fashion and compiled with Metasm. It uses several techniques to try and evade AV.

 

Dynamic Nature

The code is completely different every time it is generated, using randomized procedurally created C functions, which are then assembled into randomized call trees. This means that the code is different every time; the execution flow also doesn't fall into any predictable patterns either. Metasploit Pro initializes random variables and scrambles them with other, required variables so that the significant variables are never mapped into the same place in memory. The actual functions are different every time, the execution flow is different every time, and the memory layout is different every time. This makes it virtually impossible for AV vendors to create a static signature for detection of these payloads.

 

You could say we are exploiting the fundamental flaw with signature based detection. The amount of work to maintain signatures becomes overwhelming, and signatures are quickly outdated.

 

Appear harmless

The randomly generated C functions also fill the call tree with completely harmless, innocuous operations, which is especially important for sandboxing. As you already know, sandboxes run for a limited time and eventually release the payload. By performing only legitimate actions during that time, the sandbox will have no choice but to release our payload, at which point we can safely execute the actual payload.

 

Hide the payload

You are probably tired of seeing the word random, but here we go again: Metasploit Pro actually randomizes its payload in memory. The payload is read into memory completely scrambled. We then unscramble the payload only right before we execute it. This scramble is randomized each run, making it very hard to detect the payload sitting in memory.

 

Detect debuggers

Like with AV, the code can detect debuggers and stop any malicious activity, making reverse engineering of the payload much more difficult (though far from impossible).

 

Dynamic run-time linking

 

Antivirus solutions also often look at the imports table of the executable. Metasploit Pro evades detection through dynamic runtime linking of all required functions, keeping the imports table almost completely empty. It also makes it harder to recognize what functions the code is actually calling.

 

These methods make life difficult, though not impossible, for reverse engineers and antivirus solutions to analyze Metasploit payloads. In fact, Metasploit does get caught by some AV solutions, with detection rates varying from run to run.

 

Antivirus evasion is never done. We will never be satisfied with what we’ve achieved. Watch this space for updates on the arms race. We intend to work hard to stay a few steps ahead.

 

Further Reading

This has been a quick, high level, overview of some of the concepts. For more detailed work, check out some of these links:

 

Why Encoding Does not Matter and How Metasploit Generates EXEs; Thoughts on Security

Facts and myths about antivirus evasion with Metasploit

Pentest Geek; Using Metasm To Avoid Antivirus Detection (Ghost Writing ASM)

 

Late one night at Derbycon, Mubix and I were discussing various techniques of mass ownage. When Mubix told me about the WinRM service, I wondered: "Why don't we have any Metasploit modules for this yet?" After I got back , I began digging.

 

WinRM/WinRS

 

WinRM is a remote management service for Windows that is installed but not enabled by default in Windows XP and higher versions, but you can install it on older operating systems as well. WinRM's sister service is called Windows Remote Shell (WinRS). Both of these authenticated services are tied to an HTTP or HTTPS SOAP listener and support Kerberos and NTLM authentication by default. I started looking at NTLM authentication since it's already supported in Metasploit.

 

If you're setting up WinRM, please be aware that the default quickconfig setup will leave the service in an awkward, non-functional state. It will set AllowUnencrypted to false, meaning it will refuse to establish any sessions over HTTP without SSL. Unfortunately, the quickconfig setup will not configure the HTTPS listener. The user can now either set AllowUnecrypted to true or configure the HTTPS listener.

 

If the listener is HTTPS, some adjustments will need to be made to the module default options. Just set SSL to true, set SSLVersion to the correct SSL Version, and adjust RPORT appropriately. Default settings for the WinRM ports vary depending on whether they are encrypted and which version of WinRM is being used. In older versions of WinRM, it listens on 80 and 443 respectively. On newer versions, it listens on 5985 and 5986 respectively. Metasploit can connect to both HTTP and HTTPS ports; use the standard SSL options for HTTPS.

 

The listener has two back ends: The first one is WMI, which provides powerful querying of system information and remote management functionality. The second is a remote shell interface.

 

More information about WinRM can be found here.

 

Discovery (use auxiliary/scanner/winrm/winrm_auth_methods)

 

The first thing to build, was a basic discovery module that determines if a WinRM service is listening on a given HTTP(S) port. If it does, it also enumerates the supported authentication methods. The screenshot shows how the discovery module creates a service entry for WinRM with the authentication types included in the info.

winrm_discovery.png

 

Bruteforce (use auxiliary/scanner/winrm/winrm_login)

 

In this example, the service supports Negotiate (NTLM) authentication. However, we cannot do anything with WinRM without working credentials. The winrm_login module is a standard Metasploit login scanner to bruteforce passwords. After you supply a list of targets (HOSTS), the WinRM port (RPORT), and specify which credentials to try, it will attempt to find a working password for the service.

 

winrm_login.png

 

Running WMI Queries (use auxiliary/scanner/winrm_wql)

 

Once we have found valid credentials for the WinRM service, we can abuse the WMI functionality to execute arbitrary WQL queries against the target. The module will also save the query results as loot. In the example below, we run a WQL query to get the architecture of the remote system (32 or 64 bit).

 

winrm_wql.png

 

Running Commands (use auxiliary/scanner/winrm/winrm_cmd)

 

WinRM's conjoined twin sister, WinRS, allows the user to instantiate a shell on the remote box, send commands, and receive output streams. Metasploit can send any arbitrary Windows command, and receive both STDOUT and STDERR, essentially providing a stateless shell over HTTP/SOAP.

 

It is important to note that WinRS shells have a maximum time to live before the service will close them out. The service also has a configurable concurrent command limit, but these don't matter in this case as we are only executing a single command and cleaning up the shell. Here, we execute a simple ipconfig command as an example.

 

winrm_cmd.png

 

Getting Shells! (use exploit/windows/winrm/winrm_script_exec)

 

Now we're in a great position to get shells. For many years, the PSExec module has been the main way of using system credentials to obtain a shell. This has become less and less reliable as many of the Metasploit Framework payloads are detected by anti-virus solutions. Metasploit Pro users have the option of dynamically generating EXE payloads, but this is not foolproof.

 

The advantage of the WinRM Script Exec exploit module can obtain a shell without triggering an anti-virus solution, in certain cases. This module has two different payload delivery methods. Its primary delivery method is through the use of PowerShell 2.0. The module checks to see if PowerShell 2.0 is available on the system. It then tries to enable unrestricted script execution, an important step because PowerShell does not execute unsigned script files by default. If either of these checks fail, it will default to the VBS CmdStager payload method, otherwise it will use our Powershell 2.0 method.

 

PowerShell 2.0

 

When using the PowerShell 2.0 method, the module writes the payload into a script file using the Append-Content cmdlet and executes it. This is where other payload delivery methods tend to get caught. The VBS Cmdstager PSExec, and other similar modules write out an EXE on the filesystem and run it. These EXEs often get picked up by AV. With the PowerShell 2.0 method, we are only dropping pure PowerShell onto the file system. These scripts do not appear to be flagged by any known AV.

 

We're not quite done yet - there’s some more trickiness afoot. Remember that we said WinRS shells have a limited time to live. This means that any child processes spawned in that shell will also get killed inside 5 minutes, including our shell. The traditional migrate –f option is not an option. It creates the notepad.exe process, which is also a child of the shell, and therefore subject to the same limitation. We need an alternate migration method, to get out of that process tree. This is where the new smart_migrate Metasploit post-exploitation module comes in. SmartMigrate takes a snapshot of the process environment on the victim machine, grabbing the PIDs for winlogon.exe and any explorer.exe processes. It first attempts to migrate to Winlogon, a very stable system process for migration purposes and a highly desirable target. If we lack sufficient permissions, the module looks at the explorer.exe processes. If there is an explorer.exe process for our current user context it will try to migrate to that one first. If one does not exist within our current user context, it will go down the list trying each one.  This clear, automated process helps successfully migrate the shell before WinRS times out.

 

With the PowerShell 2.0 method, it is important that you select an x64 payload if you are targeting an x64 system, otherwise you won't be able to obtain a session. If there is a mismatch between the remote architecture and your payload when using PowerShell 2.0, the module will not launch the exploit and warn you of the error.

 

winrm_exploit.png

 

VBS CmdStager

 

If any of the initial checks failed, i.e PowerShell 2.0 installed, and an Unrestricted Execution Policy, we fall back to the VBS CmdStager. This method writes out two files to the filesystem. It writes out a base64 encoded copy of the actual payload, and a VBScript file. The VbScript file is then executed. It decodes the base64 files and writes out an exe. The VbScript then executes the EXE it has written out. This method is far less stealthy as it involves actually writing an EXE to the filesystem. It is a reasonable fallback position though, as VBS should be available on any system that does not support PowerShell. This method still requires the same migration as the Powershell 2.0 method.

 

Screen Shot 2012-11-06 at 12.32.24 PM.png

 

We hope you've had fun abusing the WinRM/WinRS service with Metasploit. What we have seen here is only the begining of what can be accomplished with WinRM in Metasploit. We expect to see more WinRM modules in the futures. Also, the discovery, bruteforce, and exploit modules will soon be integrated into  Metasploit Pro's automated features. Metasploit Pro users will be able to discover WinRM services, bruteforce WinRM services, and use the script_exec module to to gain a shell using credentials.

 

Happy Hacking!

 

-Thelightcosine

The Metasploit Framework continues to grow and expand with the support of the community.

There have been many new features added to the Metasploit Framework over the past month.

I am very excited to be able to share some of these new developments with you.

 

Mubix's Recon Modules

Mubix's post-exploitation modules form his Derbycon talk are now in the repository. The resolve_hostname module,

originally called 'Dig', will take a given hostname and resolve the IP address for that host from the windows victim.

The enum_termserv module will dump Windows RDP connections form the victim machine, to give you a

list of other potential  targets. The computer_browser_discovery module, formerly called netdiscovery, taps the victim

machine's Computer Browser Service via Railgun. This will return a list of all machines available on the same broadcast

domain as the victim machine. an addition to mubix's original module has been made to give users the options to create

host records in the Metasploit database for any hosts discovered this way.

 

[*] [2011.12.05-15:35:57] Found 4 systems.

.

...[*] [2011.12.05-15:36:02] Netdiscovery Results

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

TYPE     IP            COMPUTER NAME   VERSION  COMMENT

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

69635    192.168.2.35  WINXPTEST       5.1

69635    192.168.2.9   MELODIE         6.1

8556551  DMALONEY-VDSDA  5.2

 

 

Windows Wireless LAN

There are a new group of Windows Post modules under post/windows/wlan. These modules all use Railgun to hook the

windows WLANAPI. There are currently four modules in this group:

 

wlan_profile: This module will enumerate all of the wireless LAN interfaces on the machine. It will then enumerate all the

saved wireless profiles on each interface. If the meterpreter session has sufficient privileges it will also decrypt the wireless

key material. One caveat to this last part is that Windows XP does not actually store the WPA keyphrase. It instead stores

the derived key which was derived using the PBKDF2() function. since this is all windows stores, it is surely still usable in

this format but does not do you any good from a password reuse standpoint. On the TODO list is another module that will

make the victim machine connect to a specific network with the option of using one of the pre-saved profiles or passing it

your own profile.

 

msf  post(wlan_profile) > set SESSION 1

SESSION => 1

msf  post(wlan_profile) > exploit

 

 

[+] Wireless LAN Profile Information

GUID: {eb566b46-0140-4eca-800a-a5e01fae7251} Description: Intel(R) Centrino(R) Advanced-N 6230 State: The interface is connected to a network.

Profile Name: derbycon

<?xml version="1.0"?>

<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">

          <name>derbycon</name>

          <SSIDConfig>

                    <SSID>

                              <hex>6465726279636F6E</hex>

                              <name>derbycon</name>

                    </SSID>

          </SSIDConfig>

          <connectionType>ESS</connectionType>

          <connectionMode>auto</connectionMode>

          <MSM>

                    <security>

                              <authEncryption>

                                        <authentication>WPA2PSK</authentication>

                                        <encryption>AES</encryption>

                                        <useOneX>false</useOneX>

                              </authEncryption>

                              <sharedKey>

                                        <keyType>passPhrase</keyType>

                                        <protected>false</protected>

                                        <keyMaterial>derbycon</keyMaterial>

                              </sharedKey>

                    </security>

          </MSM>

</WLANProfile>

 

 

wlan_current_connection: This module will enumerate all of the wireless LAN interfaces on the victim machine,

and then get information about the current wireless connection on each one. This information includes the MAC address

of the access point, the SSID, the BSS type, the connection type, signal strength, RX/TX rates, security settings,

encryption and authentication algorithms used, and whether 802.1x authentication is used on the network.

 

msf  post(wlan_current_connection) > set SESSION 1

SESSION => 1

msf  post(wlan_current_connection) > exploit

 

 

[+] GUID: {eb566b46-0140-4eca-800a-a5e01fae7251}

Description: Intel(R) Centrino(R) Advanced-N 6230

State: The interface is connected to a network.

          Mode: connection initiated by wireless service automatically using a persistent profile.

          Profile: Skynet

          SSID: Skynet

          AP MAC: xx:xx:xx:xx:xx:xx

          BSS Type: Infrastructure

          Physical Type: Extended rate PHY type

          Signal Strength: 94

          RX Rate: 54000

          TX Rate: 54000

          Security Enabled: Yes

          oneX Enabled: No

          Authentication Algorithm: WPA-PSK

          Cipher Algorithm: TKIP

 

 

[*] WlanAPI Handle Closed Successfully

[*] Post module execution completed

 

 

wlan_bss_list: This module will enumerate all of the wireless LAN interfaces on the machine. It will then scan

with each interface for new wireless networks. It then records the information about all of the available wireless networks.

This information includes a lot of the same information pulled down by the current_connection module.

 

msf  post(wlan_bss_list) > set SESSION 1

SESSION => 1

msf  post(wlan_bss_list) > exploit

 

 

[*] {"GetLastError"=>0, "return"=>0, "ppWlanBssList"=>5282784}

[*] Number of Networks: 16

[+] SSID: horton

          BSSID: xx:xx:xx:xx:xx:xx 

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -90

          Signal: 16

 

 

[+] SSID: Skynet

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: 802.11n PHY type

          RSSI: -25

          Signal: 99

 

 

[+] SSID: WIN_930

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -89

          Signal: 18

 

 

[+] SSID: The Dragisic Network

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -86

          Signal: 23

 

 

[+] SSID: jacob1

          BSSID: xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -76

          Signal: 40

 

 

[+] SSID: WIN_BA74

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -78

          Signal: 36

 

 

[+] SSID: MonroeMFC

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -90

          Signal: 16

 

 

[+] SSID: starmonster

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -81

          Signal: 31

 

 

[+] SSID: Eric Home

          BSSID:  xx:xx:xx:xx:xx:xx  

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -87

          Signal: 21

 

 

[+] SSID: linksys

          BSSID:  xx:xx:xx:xx:xx:xx

          Type: Infrastructure

          PHY: High-rate DSSS (HRDSSS)

          RSSI: -74

          Signal: 43

 

 

[+] SSID: Tarheel_Country

          BSSID:  xx:xx:xx:xx:xx:xx 

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -72

          Signal: 46

 

 

[+] SSID: W32.Blaster.Worm

          BSSID:  xx:xx:xx:xx:xx:xx 

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -80

          Signal: 33

 

 

[+] SSID: Leidi

          BSSID:  xx:xx:xx:xx:xx:xx

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -88

          Signal: 20

 

 

[+] SSID: theriault

          BSSID:  xx:xx:xx:xx:xx:xx

          Type: Infrastructure

          PHY: 802.11n PHY type

          RSSI: -81

          Signal: 31

 

 

[+] SSID: EckerNet

          BSSID:  xx:xx:xx:xx:xx:xx 

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -75

          Signal: 41

 

 

[+] SSID: Belkin_G+MIMO_Wireless_E5A125

          BSSID:  xx:xx:xx:xx:xx:xx 

          Type: Infrastructure

          PHY: Extended rate PHY type

          RSSI: -87

          Signal: 21

 

 

[*] WlanAPI Handle Closed Successfully

[*] Post module execution completed

 

 

wlan_disconnect: This module takes an integer as an argument. that Integer is the index of the interface you want

to target. Most machines will likely only have 1 wireless interface, and so this option can be left on the default

value of 0. The module will disconnect the specified wireless interface from whatever network it is currently

connected to. This will be more useful when the module to connect the interface to a specified network is

done.

 

Database Hash dumping

There are some interesting new Auxiliary modules in the framework now too. These are hashdump modules for several

of the more popular database servers: MSSQL, MySQL, Postgres, and Oracle. The modules take supplied credentials

and log onto the databases on a given port across a supplied RHOSTS list. It will then attempt to dump all the

database user password hashes. If it succeeds, it will then store them in a csv as loot for further cracking.

These modules will also attempt to save all the database, table, and instance names from the database. It will

use these for wordlist building when attempting to crack the hashes.

 

 

msf  auxiliary(mssql_hashdump) > exploit

 

 

[*] Instance Name: "WINTEST2008"

[+] 192.168.2.13:1055 - Saving mssql05.hashes = sa:010051aa13a36f6efb5296ee8b804138173e0696d0892c52fcb6

[+] 192.168.2.13:1055 - Saving mssql05.hashes = ##MS_PolicyEventProcessingLogin##:010031b4ae8d43c66a1a17f5f5e7da86a1764dc48ddc6 babdd9e

[+] 192.168.2.13:1055 - Saving mssql05.hashes = ##MS_PolicyTsqlExecutionLogin##:010094044117b73bd4051b810dab0b7db5e3cbd8bb402c3 6ffe0

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user1:01006dcfe5ee776f7fa8210a33c5bf2aaaef2b5ee25f315a2890

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user2:0100acc65dd1643d5a43320af56bc37861e6ba4af7b9a0e866ee

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user3:0100e838d7b99cedfb902161be09e3e859f2aca099f5eb49684b

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user4:0100a9ec455822cb06dcb752390725649dbf669aa1994669a1ce

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user5:0100a5a9092099814984bbbf0aa851477b5edbd1a5406ba1bebb

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user6:01001d924e4d071f25849387181a2c1b0336b60baecf3e78b874

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user7:01001e0a03d8f99fb1355ae09ebde36686f1041c072e4111f999

[+] 192.168.2.13:1055 - Saving mssql05.hashes = user8:0100c506c9b67d8592f9f36982c82f8907ac38258b1fe358a84c

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

msf  auxiliary(mssql_hashdump) >

 

Linux unshadow

The auxiliary/analyze/jtr_unshadow module is another new addition. This module exists for scenarios where you can

pull arbitrary files off victim machines in less standard ways, such as directory traversal attacks. It will take

paths to locally stored passwd and shadow files. It will then unshadow the passwd file and store it as loot for

future cracking.

 

New Password Cracking Options

Building on the success of our first John the Ripper(JtR) cracking module, we now have a few more. There are John the

Ripper modules for cracking Microsoft SQL Server, MySql, Oracle, and Linux hashes. It will look for the database

hashes in the loot files created by the previously mentioned hashdump modules. All of these modules

will assemble a wordlist based on a number of things:

 

 

  1. The default wordlist we ship with
  2. All usernames and passwords currently stored in the creds table
  3. All hostnames in the hosts table
  4. Any passwords already cracked by JtR (in the .pot file)
  5. Any captured MSSQL instance names
  6. Any database and table names gathered by db hashdump modules
  7. An optional user supplied wordlist

 

All of these items are pulled together, and uniqued to create a wordlist for cracking. It will then

attempt limited password cracking using these wordlists and some fast and easy cracking rules.

These modules are not a thorough cracking attempt, but rather an attempt to crack the quick and

easy hashes. any hashes that are successfully cracked are then stored as creds in the database.

 

 

msf  auxiliary(mssql_hashdump) > use auxiliary/analyze/jtr_mssql_fast

msf  auxiliary(jtr_mssql_fast) > exploit

 

 

[*] Cracking MSSQL Hashes

[*] Cracking MSSQL05 Hashes

[*] HashList: /tmp/jtrtmp20111205-10995-2yklnu-0

[*] Trying Wordlist: /tmp/jtrtmp20111205-10995-1s8wt88-0

guesses: 5  time: 0:00:01:20 DONE (Mon Dec  5 15:13:41 2011)  c/s: 3436K  trying: �tude1900

Use the "--show" option to display all of the cracked passwords reliably

[*] Output: Loaded 11 password hashes with 11 different salts (MS-SQL05 [ms-sql05])

[*] Output: WINTEST2008      (user6)

[*] Output: password2        (user2)

[*] Output: password2        (user1)

[*] Output: user3            (user3)

[*] Output: password8        (user8)

[*] Trying Rule: All4...

Warning: mixed-case charset, but the current hash type is case-insensitive;

some candidate passwords may be unnecessarily tried more than once.

guesses: 0  time: 0:00:02:05 DONE (Mon Dec  5 15:15:47 2011)  c/s: 3947K  trying: |||}

[*] Output: Loaded 11 password hashes with 11 different salts (MS-SQL05 [ms-sql05])

[*] Output: Remaining 6 password hashes with 6 different salts

[*] Trying Rule: Digits5...

guesses: 0  time: 0:00:00:00 DONE (Mon Dec  5 15:15:47 2011)  c/s: 2898K  trying: 89092

[*] Output: Loaded 11 password hashes with 11 different salts (MS-SQL05 [ms-sql05])

[*] Output: Remaining 6 password hashes with 6 different salts

[*] user1:password2:192.168.2.13:1055

 

 

[*] user2:password2:192.168.2.13:1055

 

 

[*] user3:user3:192.168.2.13:1055

 

 

[*] user6:WINTEST2008:192.168.2.13:1055

 

 

[*] user8:password8:192.168.2.13:1055

 

 

[*]

 

 

[*] 5 password hashes cracked, 6 left

 

 

[*] 5 hashes were cracked!

[+] Host: 192.168.2.13 Port: 1055 User: user1 Pass: password2

[+] Host: 192.168.2.13 Port: 1055 User: user2 Pass: password2

[+] Host: 192.168.2.13 Port: 1055 User: user3 Pass: user3

[+] Host: 192.168.2.13 Port: 1055 User: user6 Pass: WINTEST2008

[+] Host: 192.168.2.13 Port: 1055 User: user8 Pass: password8

[*] Auxiliary module execution completed

msf  auxiliary(jtr_mssql_fast) >

 

 

One thing to note is that the jtr_linux module is not listed as fast mode. This is because this module

can be very slow depending on the type of Linux hashes it is trying to crack. If the hashes were created

using crypt(3) this module can be VERY slow.

 

There is also one other hash cracking module that does not use JtR. This is the postgres_md5_crack module.

JtR currently does not support Postgres md5 hashes. These hashes are create by taking the password and

appending the username before md5 hashing it. The postgres_md5_crack module generates a wordlist the same way

the JtR modules do. It then takes each word appends the username of the hash being tried, md5 hashes it and

compare against the hash. If it's a match it saves the discovered cred in the database. This module can actually

move surprisingly fast, but is not necessarily a thorough cracking method.

 

These are just some of the new features that have been added to the Metasploit Framework over the past month.

Stay tuned as there are sure to be even more great new features coming. If there is something that Metasploit

doesn't do, that you think it should, let us know. Better yet, try your hand at writing it yourself and send us

a Pull Request on Github! Cheers for now.

Filter Blog

By date: By tag: