('binary' encoding is not supported, stored as-is)
Mailer: SecurityFocus
In-Reply-To: <F40AaNUqsGo9Fr6QCpz0000b3e8_at_hotmail.com>
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/
Received on Nov 05 2001
Intro
