Password-Protected ...
 
Notifications
Clear all

Password-Protected Windows 10

28 Posts
15 Users
1 Likes
5,568 Views
benfindlay
(@benfindlay)
Posts: 142
Estimable Member
 

<SNIP>

However, something which I don't think has been mentioned yet is that once the password has been changed (or bypassed) you will no longer have access to EFS encrypted data or other secrets protected by the Windows credential manager.

I would be interested to learn from other practitioners if this scenario has come up or is changing/bypassing the password sufficient in practice despite the limitation?

Jim,

Great point. EFS is indeed one of the specific scenarios in which bypass and reset are NOT equivalent. However, the question still remains what exactly is the end goal of the bypass/reset? If it is simply to gain access to the user account and files NOT protected by Windows' credential manager, then bypass & reset are for all intents and purposes equivalent.

Speaking from my own experience, in six and a half years I never once encountered EFS on a case I examined, nor am I aware of it being present on any cases my colleagues examined during this time period.

I do however recall reading a news article some years ago about a terrorism case in which EFS was enabled and the investigators had to devote significant time and resources in cracking it to gain access (apologies, I can't recall/find the specific article now).

Ben

 
Posted : 12/03/2018 11:48 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Yep ) , the whole point is the different level of "changes" made by this (or that) method and amount of difficulty/inconvenience.

The #1 either modify the password (that then is lost forever, no "way back") or needs the creation of a new user (which is OK in most cases BUT that is not exactly "forensically sound"), the very little on volume activity to make a copy of the two .exe's and renaming them is minimal but still exists.

The #2 DOES NOT modify the password BUT it creates anyway some files on the volume because of the SYSTEM account, and anyway the access is more limited AFAICR.

The #3 DOES NOT modify the password nor in practice changes anything on the volume different from a "normal" boot with the user credentials, the patched .dll can be binary restored, so it is the less intrusive of all.
KONBOOT AFAIK/AFAICR uses anyway, method #3, possibly even bettered, because the .dll is patched in memory, I believe.

The actual "right" method of dumping the SAM and decrypting/cracking the password (while having the advantage of actually making the original password known) has on volume/filesystem exactly the same impact of #3, but it is obviously much slower[1] and setting up Ophcrack or similar and creating (or accessing) Rainbow Tables is not exactly easy-peasy.

Evidently this latter approach (again the "right" one in theory) will provide access to EFS.

As I see it (and not so casually I was among the people creating PassPass, from an original idea dating back to Windows NT 4 or 2000 by Damian Bakowski) method #3- when possible - is fast, easy , (besdes being IMHO also "elegant") and since it doesn't modify *anything* it could be a "first step" not preventing in any way the later adoption - if needed - of the "right" method of decrypting the password.

As another single datapoint, NOT related to forensics, more related to "clueless people that manage to lock themselves out of the system and ask for help in recovery" which is more my field of experience/interest, I never found anyone using EFS.
Lots of senselessly (hidden or non-hidden) encrypted containers like Truecrypt and similar, and a few bitlockered drives, but never EFS.

@JimC
Just in case, yet another possible issue (Syskey) loosely related to EFS
https://www.forensicfocus.com/Forums/viewtopic/t=11839/

jaclaz

[1] I mean if "admin", "password" and "123456" don't work wink

 
Posted : 12/03/2018 12:08 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

One other related scenario springs to mind, although I accept it may not be that useful in practice

There is a difference between a locked workstation and one with no user logged in. If you have access to a system level command prompt or similar, it is relatively easy to unlock a locked workstation without the password. This could be useful if a workstation was seized that was locked or was hibernated whilst locked. In such a case, the workstation could be unlocked and fully accessed without the password.

Based on this, I could argue that if a live image was not possible the next best thing would be to hibernate (rather than shutdown) a live workstation before seizing it. This would preserve the OS state and leave further options for future examination. This would of course overwrite the existing hibernation file which may not be desirable…

Apologies if this is telling old hands how to suck eggs.

Jim

www.binarymarkup.com

 
Posted : 12/03/2018 12:22 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Based on this, I could argue that if a live image was not possible the next best thing would be to hibernate (rather than shutdown) a live workstation before seizing it. This would preserve the OS state and leave further options for future examination. This would of course overwrite the existing hibernation file which may not be desirable…

Well, I could argue that IF the system has never been hybernated before the effects of writing a new hyberfil.sys file may be detrimental to the amount of data that can be carved from allocated and given how (often) hybernate is mal- or non- functioning, it represents IMHO a risk.

I guess it needs to be decided if the possible trade-offs are worth it depending on the specific case *needs*, I mean if the scope is knowing if in the last few minutes/hours a given program has been run, then having a hyberfil.sys is very meaningful, if the scope is finding (say) deleted correspondence it would be safer to shut down the system.

…decisions, always decisions … wink

jaclaz

 
Posted : 12/03/2018 2:17 pm
(@armando0)
Posts: 1
New Member
 

Thank you @Jaclaz for the helpful summary of the different methods.

Methods (1) and (2) both provide a system-level command-prompt at the login screen. This can be used to reset an account password. Method (3) by-passes this and permits login with any password. The end result is the almost same and all 3 methods require file system access to an unencrypted OS volume.

However, something which I don't think has been mentioned yet is that once the password has been changed (or bypassed) you will no longer have access to EFS encrypted data or other secrets protected by the Windows credential manager.

I would be interested to learn from other practitioners if this scenario has come up or is changing/bypassing the password sufficient in practice despite the limitation?

Jim

www.binarymarkup.com

If you don't want to lose access to EFS encrypted files or stored network/browser passwords, you have no other way but to recover the old password. Besides using Ophcrack to crack the password using rainbow tables, you can also use the following softwares to recover your password with GPU hardware acceleration

RainbowCrack - http//project-rainbowcrack.com/
HashCat - https://hashcat.net/hashcat/
Password Recovery Bundle - https://www.top-password.com/guide/windows-password-recovery.html
Proactive System Password Recovery - https://www.elcomsoft.com/pspr.html

A high-end graphics card can boost the cracking speed a lot.

 
Posted : 22/06/2018 1:03 am
(@burgesinz)
Posts: 1
New Member
 

Thank you @Jaclaz for the helpful summary of the different methods.

Methods (1) and (2) both provide a system-level command-prompt at the login screen. This can be used to reset an account password. Method (3) by-passes this and permits login with any password. The end result is the almost same and all 3 methods require file system access to an unencrypted OS volume.

However, something which I don't think has been mentioned yet is that once the password has been changed (or bypassed) you will no longer have access to EFS encrypted data or other secrets protected by the Windows credential manager.

I would be interested to learn from other practitioners if this scenario has come up or is changing/bypassing the password sufficient in practice despite the limitation?

Jim

www.binarymarkup.com

If you don't want to lose access to EFS encrypted files or stored network/browser passwords, you have no other way but to recover the old password. Besides using Ophcrack to crack the password using rainbow tables, you can also use the following softwares to recover your password with GPU hardware acceleration

RainbowCrack - http//project-rainbowcrack.com/
HashCat - https://hashcat.net/hashcat/
Password Recovery Bundle - https://www.passmoz.com/bypass-windows-10-8-7-admin-password.html
Proactive System Password Recovery - https://www.elcomsoft.com/pspr.html

A high-end graphics card can boost the cracking speed a lot.

Elcomsoft is too expensive. There are many free options to reset Windows password. A few good ones are Ophcrack, Offline NT Password & Registry Editor and Ultimate Boot CD.

 
Posted : 17/07/2018 2:40 am
joakims
(@joakims)
Posts: 224
Estimable Member
 

One thing about the hibernation method suggested. I agree that it is of course disasterous for the purpose of finding data in unallocated on disk. But the level of disasterousness may actually be slightly lower than first anticipated. The reason is that even though Windows writes a hiberfil.sys at the size of RAM to disk, the actual hibernation data that overwrites is much less. This is because the data written is only the actively used memory pages that are anyway compressed before written to disk. For a 16 GB RAM situation, that would likely result in roughly 1 GB actual data. The last 15 GB of (previously unallocated) data is still recoverable, but now from within the slack part of hiberfil.sys. But in the end, lots of data is still overwritten, which may be unacceptable.

 
Posted : 19/07/2018 3:10 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

One thing about the hibernation method suggested. I agree that it is of course disasterous for the purpose of finding data in unallocated on disk. But the level of disasterousness may actually be slightly lower than first anticipated. The reason is that even though Windows writes a hiberfil.sys at the size of RAM to disk, the actual hibernation data that overwrites is much less. This is because the data written is only the actively used memory pages that are anyway compressed before written to disk. For a 16 GB RAM situation, that would likely result in roughly 1 GB actual data. The last 15 GB of (previously unallocated) data is still recoverable, but now from within the slack part of hiberfil.sys. But in the end, lots of data is still overwritten, which may be unacceptable.

I am not sure to understand. ?

There is in practice no risk of overwriting unallocated space, unless the machine was never hibernated before (which was the "edge" case proposed), but if the machine was previouslty hibernated, the *whatever* is after the first GB will be pointless/outdated.

Let's say that the SAME machine is used, with 16 GB RAM.
The hiberfil file is created (the first time hibernation is used/triggered) 16 GB in size.
The first (roughly) 1 GB of it is written with "active" pages, compressed.
The last (roughly) remaining 15 GB of it remain 00's (or *whatever* was in the "chunk" of until then unallocated space).
If (at next use of the hibernation feature) what is saved is still roughly 1 GB in size, after n cycles you will still have a 16 GB file where roughly the last 15 GB are still 00's (or the same *whatever* it was before).

So past the first 1 GB we should have a "snapshot" of an area that was once unallocated, but that was allocated by the hiberfil.sys file and that NEVER changed.

jaclaz

 
Posted : 19/07/2018 4:26 pm
joakims
(@joakims)
Posts: 224
Estimable Member
 

Yes you're right. I forgot to mention that it applies only for the edge case mentioned where system had not been hibernated previously. That said and given what I previously described, it is thus potentially possible to recover larger pieces of data (multiple GB) from the slack parts within hibernation file, which are parts of unallocated dating back to a point in time before hiberfil.sys existed. That point in time on the disk may be just 00 if there has only been 1 installation on the machine, or it could be non-zero data from unallocated originating from a previous installation if the system was upgraded/reinstalled. Anyways, that was a slight deviation from the topic here.

 
Posted : 19/07/2018 8:28 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Yes you're right. I forgot to mention that it applies only for the edge case mentioned where system had not been hibernated previously. That said and given what I previously described, it is thus potentially possible to recover larger pieces of data (multiple GB) from the slack parts within hibernation file, which are parts of unallocated dating back to a point in time before hiberfil.sys existed. That point in time on the disk may be just 00 if there has only been 1 installation on the machine, or it could be non-zero data from unallocated originating from a previous installation if the system was upgraded/reinstalled. Anyways, that was a slight deviation from the topic here.

As I see it it is a nice and useful consideration ) , and potentially very useful in some edge cases.

Hypothetical set of prerequisites
1) the OS is installed
2) it is used for whatever activity that may later become "interesting"
3) the relative files are deleted (not wiped)
4) the hibernation is invoked (for the first time)
5) by pure chance the hiberfil file is created comprising (partially) the area where files in #3 resided
6) the other "interesting" files are overwritten, possibly after a defrag command or similar by other new files generated by the OS or by the user in "normal" usage

Surely it would be not a "common" case, but if the prerequisites apply the thingy might well be a sort of "time machine capsule", a real treasure trove.

jaclaz

 
Posted : 21/07/2018 11:35 am
Page 2 / 3
Share: