Re: cached login credentials



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
    ... , it takes longer to investigate an attack and clean up after it than it does simply to nuke-and-pave, flatten-and-rebuild, whatever. ... 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)
  • 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)
  • 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)
  • RE: DoS/DDoS Attack
    ... Subject: DoS/DDoS Attack ... DDoS spoof the packet from the same network but just a different host ... > There are still many features that all the DDoS mitigation OEM have ...
    (Pen-Test)