Closed GoogleCodeExporter closed 9 years ago
Hey mate:
Can you checkout the trunk version of secretsdump.py and check if the problem
is still there? I fixed some issues after 0.9.12.
Trunk version is located here.
https://code.google.com/p/impacket/source/browse/trunk/examples/secretsdump.py
let me know
Original comment by bet...@gmail.com
on 3 Sep 2014 at 3:12
Hi. I grabbed the latest secretsdump.py from trunk. Identical error message as
before.
Original comment by decke...@gmail.com
on 3 Sep 2014 at 7:46
Thanks for checking.. Please edit that file, find the instances of these two
lines:
#import traceback
#print traceback.print_exc()
and uncomment them (you will see two instances of these lines).
Please run it again and send me the output.
thanks
Original comment by bet...@gmail.com
on 3 Sep 2014 at 7:52
Two runs against two DC's with different errors with each but both utf16
encoding related. I tried on both Kali Linux and Ubuntu 12.04 with same result.
---------------------
[*] Dumping cached domain logon information
(uid:encryptedHash:longDomain:domain)
...
Traceback (most recent call last):
File "./secretsdump.py", line 1383, in dump
self.__LSASecrets.dumpCachedHashes()
File "./secretsdump.py", line 901, in dumpCachedHashes
domain = plainText[:record['DomainNameLength']].decode('utf-16le')
File "/usr/lib/python2.7/encodings/utf_16_le.py", line 16, in decode
return codecs.utf_16_le_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode bytes in position 2-3: illegal
encoding
None
[!] 'utf16' codec can't decode bytes in position 2-3: illegal encoding
[*] Cleaning up...
---------------------
[*] Dumping cached domain logon information
(uid:encryptedHash:longDomain:domain)
...
Traceback (most recent call last):
File "./secretsdump.py", line 1383, in dump
self.__LSASecrets.dumpCachedHashes()
File "./secretsdump.py", line 903, in dumpCachedHashes
domainLong = plainText[:self.__pad(record['FullDomainLength'])].decode('utf-16le')
File "/usr/lib/python2.7/encodings/utf_16_le.py", line 16, in decode
return codecs.utf_16_le_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode bytes in position 32-33: illegal
UTF-16 surrogate
None
[!] 'utf16' codec can't decode bytes in position 32-33: illegal UTF-16 surrogate
[*] Cleaning up...
---------------------
Original comment by decke...@gmail.com
on 3 Sep 2014 at 8:38
thanks for the data.
What OS/Service packs were those two DCs?
Original comment by bet...@gmail.com
on 3 Sep 2014 at 8:40
Windows Server 2008 Standard SP2 (32-bit)
Original comment by decke...@gmail.com
on 3 Sep 2014 at 9:01
Are these DCs test DCs?.. If so could you send me the SECURITY, SAM and SYSTEM
hives so I can debug?
First time I see this error.
SAM hashes are dumped correctly?
If you can send me data, run the attached version and send me output.
If you wanna skip the domain cached credentials part (which is the one that
seems to be failing), comment the line 1378:
#self.__LSASecrets.dumpCachedHashes()
cheers
beto
Original comment by bet...@gmail.com
on 4 Sep 2014 at 12:50
Attachments:
Thanks beto. Can't share the hives, but I'll try commenting out
dumpCachedHashes to see if it continues from there. Thanks
Original comment by decke...@gmail.com
on 4 Sep 2014 at 2:18
Hey mate:
Please let me know how it goes.. I'll try to get a similar OS installed trying
to reproduce this issue..
Anything else you think might be useful to know (particularities of that OS,
language, etc) about the DCs?
Have you tried it elsewhere successfully?
cheers!
beto
Original comment by bet...@gmail.com
on 4 Sep 2014 at 2:01
Hi beto. Haven't had a chance to try it anywhere else. The OS language is
English.
Original comment by decke...@gmail.com
on 5 Sep 2014 at 1:02
@Beto I was helping out this gentleman with this issue and we found out the
NTDS was located on another drive. It's pretty easy to locate via registry
value:
KEY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
VALUE: DSA Database file
Since you are already starting the RemoteRegistry service, it should be a snap
to pull this.
Back to the story at hand, the NTDS.dit was also found in the ADMIN$ share but
it was corrupt in some way. So there is a good chance that secretsdump.py is
finding this version and trying to dump it and getting errors. I do understand
the need to continue this for error handling though.
Original comment by jd.mu...@gmail.com
on 8 Sep 2014 at 5:44
@mubix thanks for jumping in and for the NTDS location data. I knew that can be
done but still didn't research where to find it so thanks for making my life
easier :)..
Now.. I'm a lil bit lost tho.. I thought the problem was with the cached
credentials part. That has nothing to do with the NTDS.dit.. @deckerxl what was
the result of running the script I sent you at #7?
There's definitely something weird of those systems I'd love to nail down. I
don't want to try: except those utf decoding because that will mask a bigger
problem (IMHO). What I think it's happening here is the decryption of the
cached credentials values (NL$1, NL$2, etc) is failing.. hence later we have a
decoding error.
Original comment by bet...@gmail.com
on 8 Sep 2014 at 2:03
So, looks like the problem was secretsdump was picking the wront NTDS.dit.
https://code.google.com/p/impacket/source/detail?r=1260 should solve this issue.
If problem still persists please reopen this ticket.
Original comment by bet...@gmail.com
on 30 Oct 2014 at 3:47
Original issue reported on code.google.com by
decke...@gmail.com
on 3 Sep 2014 at 3:08