Join Us!

Syskey password on ...
 
Notifications
Clear all

Syskey password on startup  

Page 1 / 2
  RSS
RobinSage
(@robinsage)
Junior Member

Hi,
I have a question regarding handling a syskey password prompt at windows (vista, w7, w8.x) startup.

This question arose from a tech forum post where online scammers had set syskey startup whilst pretending to remotely "fix" a pc for $300. If you don't pay then… Fortunately the passwords are reasonably simple 123, 1234, 12345. I am expecting more challenging passwords as this problem evolves into malware.

In a controllable environment I would consider using a hardware keylogger to record the user typing password, but remote software negates that, so what is the "best" way to handle the situation? I know there is software from elcomsoft that will attempt dictionary / brute force attacks against an extracted syskey. Other options are from passcape or linux based tools that will turn off the syskey, but requires changing the users' passwords too and protected storage is fubar.

I had considered doing a memory dump from a live system and searching for a known key eg 123456789. So far I have been unsuccessful, and probably somewhat naive in that approach, like it's probably hashed.
Looked extensively on the 'net for info but "syskey" seems irrevocably tied to "windows password recovery" and not this situation. Any thoughts, prior work ?

thanks

Quote
Posted : 03/06/2014 3:34 pm
athulin
(@athulin)
Community Legend

This question arose from a tech forum post where online scammers had set syskey startup whilst pretending to remotely "fix" a pc for $300.

Thus preventing a boot… presumably they also forced a reboot or shutdown.

In a controllable environment I would consider using a hardware keylogger to record the user typing password, but remote software negates that, so what is the "best" way to handle the situation?

Logging the activities of a remote user at a micro-level? Third-party software, if it exists at all. The ordinary LocalSessionManager logs is at session-level only, as far as I recall. But that's an enterprise-level solution. For normal users, the best solution is not to let anyone else touch their systems.

Or were you referring to something else?

I had considered doing a memory dump from a live system and searching for a known key eg 123456789. So far I have been unsuccessful, and probably somewhat naive in that approach, like it's probably hashed.

Or not the known key you were looking for or lost since it was present or …

In general, it's bad engineering to allow an important password to be left hanging around in memory for too long. I'd expect it to have been erased from memory as soon as it was stored or used in an authentication attempt.

Looked extensively on the 'net for info but "syskey" seems irrevocably tied to "windows password recovery" and not this situation. Any thoughts, prior work ?

Have you googled for 'remove syskey password' ? I seem to find one or tweo apparently relevant links already on the first page, but as I said I'm a bit hazy on what you are really asking about.

ReplyQuote
Posted : 03/06/2014 10:11 pm
RobinSage
(@robinsage)
Junior Member

Hi,

Thanks for your comments.

yes there are many "how to remove syskey password" results. With the exception of the dictionary / bf attacks all of them appear require a user password reset as well. I am hoping to find a solution that does not require that.

If windows keeps passwords in memory, just in case they are needed then it may be possible to retrieve them in plain text. Like current user / session passwords recovered by mimikatz & windows credential editor.

One solution is to do a system restore to a point before syskey was applied. Unfortunately the bad guys and gals are starting to delete restore points too.

As for the poorly explained memory dump… I have set a syskey password on a test system and was attempting to find that password in memory after loggin in.

So, does dealing with syskey at startup occur in the forensics world?

ReplyQuote
Posted : 04/06/2014 1:37 am
Adam10541
(@adam10541)
Senior Member

I've never once encountered this syskey password, in fact to be honest I had to google it to see what it even was P

However from a forensic point of view this password doesn't stop us accessing any of the information on the hard drive as it only encrypts the SAM key, so I can't see an impact unless you are trying to conduct a live inspection.

This could prove challenging though as if you took the normal approach (image drive, restore to donor drive, boot system with donor drive) you are still going to come up against the password issue, and while you can reset the account password and thereby bypass the syskey lock, you are also going to alter the admin account and presumably lost potential evidence by way of desktop appearance, settings and some files as well…..

ReplyQuote
Posted : 04/06/2014 10:10 am
athulin
(@athulin)
Community Legend

However from a forensic point of view this password doesn't stop us accessing any of the information on the hard drive as it only encrypts the SAM key, so I can't see an impact unless you are trying to conduct a live inspection.

The syskey is also used to encrypt the EFS master key … so if you are using EFS to enctypt any of your disks, and use SYSKEY password, you're kind of stuck.

There are some tools that claim to break EFS encryption, but I have no idea of how good they are.

Never encountered any EFS disks with separately kept SYSKEYs myself.

ReplyQuote
Posted : 04/06/2014 8:52 pm
RobinSage
(@robinsage)
Junior Member

As with most password systems, people making a poor choice of password is usually the weak link. A good dictionary, a user targeted wordlist plus a strings grep of the drive and you're probably good to go with the EFS decryption tools.

Other protected storage items like email & wifi passwords also seem to get destroyed with a syskey reset.

I have seen EFS on several business class laptops, but only one instance of syskey startup on floppy back in the 2000 days.

ReplyQuote
Posted : 05/06/2014 12:15 am
jaclaz
(@jaclaz)
Community Legend

I am failing to understand what the problem is (final goal).

  1. Re-accessing data on a system where a third party (maliciously and without user knowing it) has setup Syskey encryption of the SAM?
  2. Re-accessing the actual system (i.e. booting to it)?
  3. Re-accessing the system without blanking all user's passwords?
  4. [/listo]

    There is a rather straightforward procedure to decrypt a syskey hash, see here
    http//epyxforensics.com/node/34

    that I believe works for other versions of the OS besides the 7 on which the article is based.

    But there are several different tools/methods, another example
    http//www.oxid.it/cain.html
    http//www.oxid.it/ca_um/topics/nt_hashes_dumper.htm
    http//www.oxid.it/ca_um/topics/syskey_decoder.htm

    The point worth of note IMHO is that if the "added" Syskey encryption (and I believe change of password) has been carried out "maliciously" by a malware of some kind, the system is compromised, i.e. you have no way to know "what else" the malware may have done.

    As such the system should NOT be trusted for *anything* (if not extracting the data that was not backed up prior to the infection/attack) and possibly not even booted at all.

    Can you try better explaining the scenario/case at hand?

    jaclaz

ReplyQuote
Posted : 05/06/2014 1:07 am
RobinSage
(@robinsage)
Junior Member

Excuse the tardy reply.

A user or in this case a "ms support" scammer can set a boot time syskey password that gives the following prompt before windows will progress to the user login screen.

Entering the incorrect password 3 times will force a reboot.

Extracting and decrypting the syskey hash for windows user login password recovery is, as you said, quite straight forward. However the above prompt requires the password, not the hash. This scenario is based on a standalone pc.

1. Accessing user data - cannot login
2. Re-access the system - boot the system without syskey startup or recover required key
3. Re-access the system without blanking the passwords

Items 2 & 3 combined with a view to preserving EFS is the preferred outcome of my research.

My results so far
1. Treat as non bootable system - slave drive or use a linux / PE boot disc. No EFS
2. Simple passwords recovered via dictionay / brute attack gives full access as a normal boot.
3. A damaged but bootable OS with access to EFS.

I totally agree with your point concerning 3rd party intrusion on any system will have compromised its integrity and rendered it "untrustworthy". In a corporate environment a new drive would be fitted and a clean OS installed. I would do the same with my pc. Unfortunately in the small business and private sector without any inhouse IT support many users are oblivious to, or choose to ignore, such latent problems.

alice

ReplyQuote
Posted : 07/06/2014 10:49 pm
jaclaz
(@jaclaz)
Community Legend

Extracting and decrypting the syskey hash for windows user login password recovery is, as you said, quite straight forward. However the above prompt requires the password, not the hash. This scenario is based on a standalone pc.

Now I see oops .
It is the Syskey Start Up Password! (not that you hadn't said exctly that, only that I somehow completely failed to realize it was that one you were describing)

You are describing more or less this case
http//triplescomputers.com/blog/casestudies/solution-this-is-microsoft-support-telephone-scam-computer-ransom-lockout/

I don't think there is a way to "crack" that (the advice to restore a copy of the Registry is good of course) without resetting all passwords (as a matter of fact the approach is to disable the Syskey tool offline and change an Admin password, but all the other passwords will become invalid).

Something I have never tried is to see is if the good ol' MSV_1.0.DLL trick (which lately - Holmes.Sherlock with some little help by me "ported" to grub4dos, see here http//reboot.pro/topic/18588-passpass-bypass-the-password/ http//www.sherlock.reboot.pro/passpass-bypass-the-password/ ) would allow to boot to the OS without providing a password, and then *what* can be done from the booted system.

jaclaz

ReplyQuote
Posted : 08/06/2014 1:02 am
RobinSage
(@robinsage)
Junior Member

Hi,

Yes, as per TrippleSComputers http//triplescomputers.com/blog/casestudies/solution-this-is-microsoft-support-telephone-scam-computer-ransom-lockout/. I know Steve via the Technibble forum.

Just checked my Process Monitor dump for syskey when setting / changing password (obviously after logging in) and msv1_0.dll isn't listed. It may well be used, but this is not my best area. Similarly tracing the prompt before user login is beyond my ability too (

As it happens I have devised solution #3, a clunky workaround that can preserve EFS but breaks some of the OS.

thanks for the info on PassPass. How did I not know about it sooner?! 😯 oops ?!

alice

ReplyQuote
Posted : 08/06/2014 2:49 am
jaclaz
(@jaclaz)
Community Legend

I checked a bit around, and it seems you found a new (please read as old wink ) interesting topic of research.

It seems to me like all the original work on Syskey protection has been made a looong time ago and nowadays, with the new info we have available there may be some possibilities.

The original work by Nicola Cuomo
https://web.archive.org/web/20060511000813/http//www.studenti.unina.it/~ncuomo/syskey/syskey.txt
Sets aside modes #1 and #2

The key used by Syskey to encrypt the password hashes (called bootkey
or system key) can be generated and stored in three ways. The method
to use is selected when running syskey.exe on the host.

1) Using a user supplied passphrase(actually the MD5 hash of it). The
system will prompt for the passphrase during startup.

2) Using a system generated key stored on a floppy. The system will
ask for the boot floppy during startup.

3) Using a system generated key stored on the "the local system using
a complex obfuscation algorithm" (citing Microsoft site[2]). This is
the default method used.

In the first two cases generally nothing can be done. If you cannot
get the passphrase or the boot floppy you are compelled to crack the
syskeyed hashes.

The last case is different.

and analyzes mode #3 only, but the paper is (and study/programs) are several years old, dating back at the time where MD5 (or a similar hashing algorithm) was considered "secure" or at least outperforming the capabilities of most computers.
Maybe today, with the increased computing power and thanks to a few new approaches it may be possible to "attack" modes #1 and #2.

Also the other "main" documentation, which is the analysis and tool by Peter Nordahl
http//pogostick.net/~pnh/ntpasswd/
though updated/bettered/what not, remains within the "limits" of the original research
http//pogostick.net/~pnh/ntpasswd/syskey.txt
a Syskeyed system can only be accessed through removing Syskey altogether (thus losing Users passwords and EFS keys).
Please note how the latter document numbers the modes according to the values in Registry (different from the previous doc)

However the value named 'SecureBoot' holds the mode of syskey
1 - Key in registry
2 - Enter passphrase
3 - Key on floppy

But removing this key (or setting it to 0) isn't enough to disable
syskey. There's more..

It seems to me ? like it should be *somehow* possible to brute-force (or dictionary) attack offline the Registry anyway, provided that a collision can be generated on the StartKey.key MD5 crypt hash
http//www.pearsonitcertification.com/articles/article.aspx?p=25090

However, now there is a problem how to protect the Syskey. This protection may be implemented in one of three ways

  • The Syskey is obfuscated and stored in the Registry. System can boot without administrative action.
  • The Syskey is obfuscated and placed on a floppy disk that must be present when the system reboots. The Syskey is not stored anywhere on the system. The key is stored in a file call STARTKEY.KEY. Do not store the key on an ERD. To do so would be to provide two items needed to attack your system in one location. Do make copies of the disk. Without it you cannot boot your Windows NT system.
  • A passphrase is entered and then used to create encrypt the Syskey. An MD5 cryptographic hash (digest) of the Syskey is stored in the Registry. The password must be entered during system boot to make the system usable.

In either the floppy disk choice or the password choice, the Syskey is not stored anywhere on the system. Therefore, these choices are more secure. If the floppy disk is lost or becomes corrupt, however, or if the password is forgotten, the system cannot be booted.

The known program SAMINSIDE has a "side tool" called PasswordToSyskey.exe that can seemingly generate a Startkey.key from a given password/passphrase, so the missing step is "connecting" the StartKey.key to it's Cryptographic MD5 hash in the SAM.

I believe that - one way or the other - this is the approach PSPR uses
http//elcomsoft.com/help/en/pspr/index.html
http//elcomsoft.com/help/en/pspr/recoveredhashes.html

Please note that usually the SAM database is encrypted with a locally stored system key, and PSPR automatically decrypts it, but the SYSKEY utility can be used to additionally secure it by moving the SAM database encryption key off the Windows-based computer. The SYSKEY utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the SAM database. If the local machine is configured this way, PSPR can try to recover this start-up password click on Find SYSKEY startup password link to open a new window where you can set brute-force and dictionary attack options. The same window is opened if you dump password hashes from external SAM and SYSTEM files (in Manual mode), or if the start-up password is known, you can enter it there (or if SYSKEY is stored on a floppy disk, provide PSPR with it in order to get password hashes decrypted for further attacks).

As it happens I have devised solution #3, a clunky workaround that can preserve EFS but breaks some of the OS.

Care to share some info on this? ?

jaclaz

ReplyQuote
Posted : 08/06/2014 2:44 pm
RobinSage
(@robinsage)
Junior Member

Care to share some info on this? ?
jaclaz

I was waiting for Jamie to review this thread. Last time I revealed wink a workaround for a program the software company demanded the thread be removed ( Lesson learned etc.

Anyhow, it's not rocket science, just joined up some dots. For EFS it's documented that if the password is changed offline, then access is lost. However, if you can restore the original password then it all works again.
So,
1. obtain user login password by asking in my scenario / cracking with usual tools if required.
2. remove syskey (and blank password)
3. reset user password as per #1
4. reboot & login
5. access EFS / Export keys

I used Passcape's Reset Windows Password tool http//www.passcape.com/reset_windows_password to reset the syskey. The free tool from Petter Hagen http//pogostick.net/~pnh/ntpasswd/ is next on the list.

Pascape warn that "After you reset the password, you may temporary lose access to your Web site passwords, file share credentials, Wireless connection passwords, EFS-encrypted files, e-mails encrypted with your private keys, other personal data encrypted with DPAPI"

As Dr.McCoy said " it's worse than that…"

Somethings are definitely broken in the windows crypto as highlighted with wifi security. WiFi can connect to open APs but WireShark shows no packets are transmitted when you attempt to join WEP / WPA / WPS networks. Normal LAN works fine but as this is in a VM or just a test then it doesn't matter if you can get the files. I have tried resetting perms on the Registry and Windows folder. I guess comparing before / after reg is a logical step.

Insecurety Research has a write up on SAMSRV.dll http//insecurety.net/?p=768

Well that's it. It works for me. Hopefully it may be of some use for you too.

alice

ReplyQuote
Posted : 08/06/2014 11:35 pm
jaclaz
(@jaclaz)
Community Legend

Insecurety Research has a write up on SAMSRV.dll http//insecurety.net/?p=768

Yep, that is more or less the idea, though I have - being picky - to underline how the F format may not be documented but it is "known", see as an example
http//sourcecodebrowser.com/samdump2/1.1.1/samdump2_8c.html

I have no idea if it is possible, mind you, but in the case of the "computer repair ransom", the "normal" login passwords are not changed (and the legitimate user already knows them).

So, you are in a "special" situation of the "passphrase to start up", where you actually know the passwords but you don't know the key used to encrypt them.

Maybe something *loosely similar* to a known plain text attack is possible. ?

jaclaz

ReplyQuote
Posted : 09/06/2014 1:03 am
RobinSage
(@robinsage)
Junior Member

A variation on the original scenario is that startup password has been set, but the system not shutdown yet. A temporary solution is to not shutdown / reboot the system, and just use hibernate as necessary. A system "resume" does not generate the "startup" prompt.

alice

ReplyQuote
Posted : 09/06/2014 5:04 am
jaclaz
(@jaclaz)
Community Legend

A variation on the original scenario is that startup password has been set, but the system not shutdown yet. A temporary solution is to not shutdown / reboot the system, and just use hibernate as necessary. A system "resume" does not generate the "startup" prompt.

alice

Yep, that shoudl be only for "cold boot".
But I presume the end user won't be aware that the Syskey settings have been changed untill he/she actually reboots, otherwise it would be simpler to just run again the Syskey tool and change back the settings (but to do that one would need to have the password cry ).
I cannot say if in that case (system up and running) one of the "dumping" tools can save/recover the password.
Maybe it would be needed a *somehow* "hacked" syskey that bypasses the verification of the "old" password. ? (allowing to change the settings without providing it).

jaclaz

ReplyQuote
Posted : 09/06/2014 2:58 pm
Page 1 / 2
Share: