('binary' encoding is not supported, stored as-is) Mailer: SecurityFocus In-Reply-To: <F40AaNUqsGo9Fr6QCpz0000b3e8at_private> Ian, I'm not sure why this is the case, perhaps it has something to do with how LM passwords are handled...you know, the whole thing about splitting it in 7-byte segments, forcing the password to all caps, etc. Anyway, my experience with this on pen tests and vulnerability assessments has shown that against a single system, the "/u:domain_name" or "/u:computer_name" stuff really isn't an issue. And from the error you're seeing, it's clear that NAT is cleaning up it's connections so you don't have a conflict. In fact, the error message seems to point out that there's something wrong with either the username or password...perhaps a capitalization problem with either one. If you do any Perl scripting, I have something that might help you out. Go to: http://patriot.net/~carvdawg/perl.html Get 'null.pl'. This script uses Win32::Lanman, and attempts null session connections/enumeration. A couple of simple mods will turn some of the code into a brute force password cracker. If you look at the ConnectIPC() and Disconnect() functions, you'll see where this is possible. HTH, Carv >NET USE Z: xxx.xxx.xxx.xxx\c$ /user:administrator password > >to map the C$ to a local z: > >However every time I try that it gives me a > >System error 1326 has occurred. >Logon Failure: unknown user name or bad password. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 08:50:34 PST