lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jul 2013 22:27:53 +0100
From: some one <s3cret.squirell@...il.com>
To: Gregory Boddin <gregory@...hine.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Abusing Windows 7 Recovery Process

On Jul 10, 2013 9:16 PM, "some one" <s3cret.squirell@...il.com> wrote:
>
>
> On Jul 10, 2013 1:51 PM, "Gregory Boddin" <gregory@...hine.net> wrote:
> >
> > It won't.
> >
> > The whole point is to have full local access to hard-drives (from a
locked workstation for eg), to modify/read things in it.
> >
> > The loaded environment IS a live environment. I would say: almost a
copy of the install CD loaded from the hard-drive.
> >
> > What you can do is : take the SAM, modify somewhere else (not a windows
expert tough), re-inject and gain local access. (which is kind of useless
since local data are already available once the recovery is booted, unless
there's software you would like to run in that workstation once the
password is reset).
>
Oops, pressed send... Try again...

Hmm, not sure about this...

Haven't tried but lets say recovery console is running as system which can
read the SAM and it lets us copy it off the box to a share or usb or
whatever, if we can get it off i'm guessing we can rip out the hashes for
the users and attempt to crack them, spray them about or whatever...

But changing one so we know the password and then putting it back, doubt
this will work will it, as essentially we are changing the SAM file anyway
aren't we when we create a new legit user through net commands and it
discards this change when we reboot, or are there 2 SAM files? One in live
environment which dissapears and the real one...

Pass, i will try it out again when i get 10mins..:-)
>
> >
> > On 9 July 2013 20:39, some one <s3cret.squirell@...il.com> wrote:
> >>
> >> My initial thoughts after adding the user and rebooting was that it
was only valid in the recovery console session or something as once i
rebooted it was gone...
> >>
> >> Tried it again today in a different place and same deal. Reboot no new
user...
> >>
> >> Anyone have this working after reboot?
> >>
> >> Once you've inserted your payload with admin-or-better rights, it can
be
> >> anything from a rootkit that GP can't touch to a patched GP subsys that
> >> doesn't apply AD policies. This isn't really a caveat.
> >>
> >>
> >> On 2013-07-08 12:39:18 (+0200), Fabien DUCHENE wrote:
> >> > There may be an Active Directory domain policy which only allows a
> >> > configured set of groups/users to be admin of your workstation.
> >> > Keep in mind domain policies are applied at startup and periodically.
> >>
> >> _______________________________________________
> >> Full-Disclosure - We believe in it.
> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> >> Hosted and sponsored by Secunia - http://secunia.com/
> >>
> >> _______________________________________________
> >> Full-Disclosure - We believe in it.
> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> >> Hosted and sponsored by Secunia - http://secunia.com/
> >
> >

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ