Re: cached login credentials



Commercials? Are you suggesting that I engaged in--*gasp*--marketing??? :)

Glad to see you're considering passphrases for admins. Why not go all the way and do it for everyone?

For what it's worth, "wipe and reload" is my preferred method, too. For two reasons: time and certainty. In most cases (warning: opinion masquerading as fact), it takes longer to investigate an attack and clean up after it than it does simply to nuke-and-pave, flatten-and-rebuild, whatever. And you can never be certain that a "cleaned" computer is in fact clean.

If you're willing to share, I'd like to see your guide as you put it together.

Steve Riley
steve.riley@xxxxxxxxxxxxx
http://blogs.technet.com/steriley


"msb-2007@xxxxxxxxxxxxx" <msb2007nospamnospam@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:3242E4E2-B5E4-4651-943C-0860741E4C38@xxxxxxxxxxxxxxxx
Thanks for the answer(s). And the commercial(s). ;)

That's a bummer. I was hoping I could just mitigate this (arguably large,
arguably small) residual risk by using a change to our administrative
procedures. I guess not completely. Yes, the larger password for the domain
administrator accounts is a good mitigation.

For what its worth, my working hypothesis is that I have compromised hosts
in my network (egads! what candor). Surprisingly many large networks have
this problem (the prevalence of botnets within corporate intranets is scary),
though most corporate IT shops are in denial. Worse, most just practice
"patch and release" instead of "wipe and reload" as part of their "incident
response". As a result, the intruder's entrenchment remains high.

As a result, I'm attempting to pull together a incident response best
practices guide that allows shops to actually recover from an entrenched
attack over time. It is naive to think that you'll find and fix every
effected host in the initial response activities. So you must start with
securing a "beachead" that over time allows you to be confident in your
server infrastructure, then over time through precision monitoring of network
traffic and host event logs along with solid desktop configuration/patch
management you can keep peeling back the onion to ensure the network is
eventually "intruder free".

You'll note that the original question was laptop based, but if you assume
that desktops in your network will be compromised, you need to be sure that
you have a way to limit exposure to this sort of expanded attack originating
from them too.

Regards,

-Matt







"Steve Riley [MSFT]" wrote:

Oops! Right, I missed that bit.

In answer to your original question, it depends on which kind of logon you
use. Anything that does an interactive logon will store cached credentials,
so yes, the GUI RunAs will do this. The command-line RunAs will also, unless
you include the /netonly switch.

Sure, rainbow tables are growing in popularity. They're effective in
pass-the-hash attacks, and this is why I've become an ardent fan of long
simple passphrases rather than short complex passwords. Pass phrases are
easier to remember, you can type them quicker, and they thwart rainbow
tables. Consider a simple 20-character passphrase: you're looking at many
tens, maybe low hundreds, of years to generate. And I can't find a handy
formula now, but I suspect that finding sufficient hard drive space to store
the output will be a bit problematic. For the same reasons, rainbow tables
become ineffective against password verifiers: remember these are salted
with user IDs, which require significantly larger tables--again, there's the
time and space issues to contend with.

Interesting corollary you've thought of, and I'm sure there's a lot of smart
discussion that could take place around it. I would consider it this way:
the only true defense we have against physical access is time. If we can
implement measures that seriously increase the time it would take to launch
an attack, then the stolen asset becomes less interesting (and indeed
probably encourages the attacker to move on to someone not as smart as you).
I like to think of encryption as the thing that buys us time. If the
available measures increase the time cushion to millions of years, then I'm
cool with that--to me, it's good enough. Long simple passphrases and
BitLocker (with TPM and PIN, please) are satisfactory mitigations to
Immutable Law #3.

Steve Riley
steve.riley@xxxxxxxxxxxxx
http://blogs.technet.com/steriley


"msb-2007@xxxxxxxxxxxxx" <msb2007nospamnospam@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:9D3A212E-4702-417D-AFC5-8C397B0D6DC2@xxxxxxxxxxxxxxxx
> Thanks for the quick response. And while I agree with each of your > points
> (I
> was attempting to acknowledge that in my original post), you didn't
> actually
> answer my question...
>
>
> If a user logs into a domain machine using "normal" domain user access
> credentials, and uses runas to do priviledged operations (assume they > use
> domain admin account credentials), is a credential cached anywhere for > the
> domain admin account?
>
>
> As to your point, rainbow tables are starting to become available to > more
> "ordinary" users, and so the "theoretical" is becoming more and more
> "practical" every day. Underground, distributed, collaborative rainbow
> table
> cracking networks do exist...
>
> My concern is that I'm trying to determine if Corallary 1 to Immutable > Law
> #3 is true or not... -- "If a bad guy has unrestricted physical access > to
> any
> computer in your network, even if its disconnected from your network, > it's
> not your network anymore" That would be bad....
>
> Thanks....
>
> -Matt
>
>
>
> "Steve Riley [MSFT]" wrote:
>
>> As Jesper and I describe in our book
>> (http://www.protectyourwindowsnetwork.com), cached credentials:
>>
>> * Are stored not in LSA but in the security hive, a better place for
>> storing
>> secrets
>> * Are _not_ your ID/password or the hash of your password, but instead >> a
>> hash of the hash, salted with your user name (in practicality, this >> makes
>> them nearly impervious to ordinary password cracking tools)
>> * Require running attack tools in SYSTEM context: meaning the bad guy
>> already has complete control of your computer anyway, so who cares?
>>
>> There's way too much fretting and worrying over this. Without cached
>> credentials, laptop computers become completely useless when not
>> connected
>> to the domain--and this, then, destroys the very reason that laptops
>> exist.
>>
>> If you're really worried about cracking passwords, then set password
>> policies that require certain complexity or--better--a minimum length >> of
>> at
>> least 15 characters (then you can ignore complexity). Now you can
>> eliminate
>> password cracking attacks from your list of worries, because the time
>> required to crack them stretches into the hundreds of millions of >> years.
>>
>> (Actually, password cracking attacks really aren't even that >> interesting.
>> "Pass-the-hash" attacks, where the bad guy already has hashes of
>> passwords,
>> _are_ interesting: see the "Should I be concerned about password
>> cracking?"
>> section in Jesper's article at
>> http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx.)
>>
>> In your note, you quote Immutable Law #3
>> (http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx).
>> Not to sound flippant, but the best way to thwart this attack is to >> make
>> sure you don't get your laptop stolen. There is, of course, a >> mitigation
>> for
>> this, too: BitLocker Drive Encryption in Windows Vista Business (if >> you
>> have
>> Software Assurance), Enterprise, and Ultimate editions.
>>
>> One other point that might matter: here at Microsoft, we don't disable >> or
>> tweak the settings. We leave the number of cached credentials set to >> the
>> default (10), and we require strong passwords. Soon we'll be moving to
>> corp-wide smartcard logon and finally getting rid of passwords.
>>
>> Steve Riley
>> steve.riley@xxxxxxxxxxxxx
>> http://blogs.technet.com/steriley
>>
>>
>> "msb-2007@xxxxxxxxxxxxx" >> <msb2007nospamnospam@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> wrote in message
>> news:7E81A5D6-B936-4A55-BEA4-FFC85650B6D4@xxxxxxxxxxxxxxxx
>> >I know this is a topic that has been argued about in security circles
>> >for
>> > some time...
>> >
>> > However, I haven't been able to find an answer to this particular
>> > question:
>> >
>> > If a user logs into a domain machine using "normal" domain user >> > access
>> > credentials, and uses runas to do priviledged operations (assume >> > they
>> > use
>> > domain admin account credentials), is a credential cached anywhere >> > for
>> > the
>> > domain admin account?
>> >
>> > Background: if I login to a machine directly with a domain admin
>> > account,
>> > the domain admin credentials will be cached locally. While these
>> > credentials
>> > are somewhat protected through Microsoft's approach with encrypted
>> > "verifiers", they are not completely secure from a determined >> > attacker.
>> > Lots
>> > of argument about how difficult it would be, but I'm confident there >> > is
>> > an
>> > attack vector there. The old adage "if I have physical access to >> > your
>> > machine, there is no telling what I can do" applies.
>> >
>> > I understand that there is a registry key (CachedLogonsCount=0) that
>> > can
>> > be
>> > set to disallow the caching of credentials, but that doesn't really
>> > work
>> > well
>> > when the computer is a laptop that needs to be useable when
>> > disconnected
>> > from
>> > the domain. My ultimate goal is to ensure that our security >> > practices
>> > for
>> > domain adminstrators don't expose the corporate network to >> > additional
>> > risk
>> > when a laptop is stolen.
>> >
>> >
>> > Regards!
>> >
>> > -Matt
>> >
>> >
>> >
>> >
.



Relevant Pages

  • Re: cached login credentials
    ... it takes longer to investigate an attack and clean up after it than ... in my network (egads! ... credentials, and uses runas to do priviledged operations (assume they ... domain admin account credentials), is a credential cached anywhere for ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... administrator accounts is a good mitigation. ... then over time through precision monitoring of network ... you have a way to limit exposure to this sort of expanded attack originating ... Anything that does an interactive logon will store cached credentials, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... domain admin account credentials), is a credential cached anywhere for the ... but the best way to thwart this attack is to make ... sure you don't get your laptop stolen. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... Require running attack tools in SYSTEM context: meaning the bad guy already has complete control of your computer anyway, ... Without cached credentials, laptop computers become completely useless when not connected to the domain--and this, then, destroys the very reason that laptops exist. ... domain admin account credentials), is a credential cached anywhere for the ...
    (microsoft.public.windowsxp.security_admin)
  • Re: cached login credentials
    ... Remember that a "rainbow table attack" against a cached domain ... then over time through precision monitoring of network ... Anything that does an interactive logon will store cached credentials, ... domain admin account credentials), is a credential cached anywhere for the ...
    (microsoft.public.windowsxp.security_admin)