Nmap Development mailing list archives
Re: Thoughts on SMB cracking
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 24 Jun 2010 09:26:28 -0500
Just my take on things, but when I run an on-line password cracking tool, I don't always want to attempt every user. I can think of times when I would have been surprised and disappointed in a tool that expanded its scope beyond what was specified in the invocation. If such a feature is added, it should probably be as an explicit option default off. It could even be a general option, like "attempt to enumerate users," that will take effect on services like SMB and SMTP that have user enumeration capability (perhaps lifted directly from the NSE scripts).
Another consideration is that not every tool has to be point-and-shoot. If I know enough to use a password cracker on an SMB service, I probably discovered that service with a tool like nmap, which just happens to already have SMB user enumeration capability. Ron's idea of exporting the user lists from nmap in a consumable format could work great for this. Even better integration could be achieved if/when the Nmap XML DTD is extended for script output. I'm not looking to engineer a solution, but if Ncrack knew to look in the Nmap XML for a <username> element under a <port protocol="tcp" portid="445"> element, then the problem of passing that information would pretty much be solved.
Dan On 06/24/2010 09:01 AM, Ron wrote:
I do indeed have a few comments! First, I don't think you should even try user1 user2 and user4. If you can, with a high level of confidence, get a proper user list, there isn't much point in trying known-bad usernames. But that raises the questions: o On services *other* than SMB, should you still enumerate users through SMB? o When you find a valid SMB account, should you attempt to use it to enumerate *all* accounts, then start over? o Can you enumerate users on other services (for example, I noticed this morning that Nessus got me a great list of users from SNMP)? o If you're attacking multiple services, should you give priority to the services that can confirm/deny the existence of users, then give priority to those particular users when attacking other services? For that last point, here's an example. You're doing a bruteforce against FTP, SMB, and Telnet. SMB has the capability of enumerating users, and also, occasionally, of validating accounts. So, you feed your list of accounts through SMB, and it finds 3 valid ones. So those accounts are prioritized on all services. Then, during the bruteforce, it finds a valid SMB credential. It uses that SMB credential to get a proper list of accounts. At that point: o You can throw away the rest of the accounts for SMB o You can prioritize the newly discovered accounts for other services, but still try everything That's getting rather complex, though, and I'm not sure if ncrack is set up to do any of that. I'm just throwing out ideas/scenarios. An additional thought, while we're talking about this: is there any way, in the future, we can leverage Nmap scripts for Ncrack? Even as simple as Nmap outputting user accounts, services, etc into an ncrack-readable file would be really helpful. There are multiple Nmap scripts that can enumerate accounts. If those accounts are all put into a common nmap.registry variable, and that variable can be output for ncrack, that would simplify a lot of things. That actually brings up yet another thought, which isn't at all related to Ncrack so I won't dwell on it. Nessus and Appscan and other tools have 'result plugins' that run after everything is done, and will take results that other scripts save (mac address, user accounts, etc) and combine/output them. I wonder if we should consider that for Nmap? Ron On Thu, 24 Jun 2010 15:57:31 +0300 ithilgore <ithilgore.ryu.l () gmail com> wrote:Hello nmap-dev. As of late, I am experimenting with the SMB protocol with the purpose of creating a high-speed SMB module for Ncrack. After studying Ron's smb scripts and relevant documentation/papers, I considered using a technique similar to smb-enum to get users from a SMB service if possible. Then Ncrack can add those users to its username lists and try them first. One question that arises from this, is which would be the most efficient way of trying them? Normally Ncrack, tries all the passwords from the passlist for each of the usernames. If Ncrack, adds those newly found usernames, it should probably try this new group for all the most common passwords and then try the less "intelligent bruteforcing". For example, say you have: username list: --------------- user1 user2 user3 password list: --------------- 123456 test password1 Normally Ncrack tries them like this: user1 123456 user2 123456 user3 123456 user1 test ... Of course, you can activate the --passwords-first option, so that Ncrack will try and crack them in the opposite way: user1 123456 user1 test user1 password1 user2 123456 ... Now, if Ncrack finds that usernames "Bob" and "Alice" exist for an SMB service (using an enumeration technique like SAMR or LSA bruteforcing), then it should instead try to crack them in this order: New username list: ------------------ Bob Alice user1 user2 user3 Cracking: --------- Bob 123456 Alice 123456 Bob test Alice test Bob password1 Alice password1 user1 123456 user2 123456 user4 123456 user1 test which essentially means that you virtually split the username list into two groups, the user-enumerated one and the normal username list (coming from a file or the command-line), and you try to authenticate the former group first. Probably, there should be an option however to override this functionality in case the user just wants to crack a specific username/password list of his own choosing first. In addition, he could also probably be able to disable the enum-phase in this case (to save the extra time needed for it). So what are your thoughts on it? I am expecting Ron or other SMB experts to have a strong say on this. Regards, ithilgore -- http://sock-raw.org http://twitter.com/ithilgore _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Thoughts on SMB cracking ithilgore (Jun 24)
- Re: Thoughts on SMB cracking Ron (Jun 24)
- Re: Thoughts on SMB cracking Daniel Miller (Jun 24)
- Re: Thoughts on SMB cracking Fyodor (Jun 28)
- Re: Thoughts on SMB cracking Ron (Jun 24)