<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    >
<channel>
    <title>Comments on: Protecting Privileged Domain Accounts:  LM Hashes -- The Good, the Bad, and the Ugly</title>
    <atom:link href="http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/feed/" rel="self" type="application/rss+xml" />
    <link>http://computer-forensics.sans.org/blog</link>
    <description>SANS Computer Forensic Investigations and Incident Response Blog</description>
    <lastBuildDate>Thu, 23 May 2013 7:44:46 +0000</lastBuildDate>
    <language>en</language><item><title>By: Mike Pilkington</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-15407</link><dc:creator>Mike Pilkington</dc:creator><pubDate>Fri, 17 May 2013 19:35:06 +0000</pubDate><description><![CDATA[Hi Curious,That is true, pass-the-hash is extremely effective and once an attacker is in the environment and has the hashes, then they can mostly get where they want to with them.  There are some tools though that need the actual password.  For example, from the outside, a password is often all that is necessary to login to client VPN gateways or webmail.  Since the LM hash is so simple to reverse to get the password, a stolen LM hash becomes an issue not only from the inside (via pass-the-hash), but also the outside since it can effectively be turned into the password.All that said, it's really become a moot point with the discovery of passwords in memory by Benjamin Delpy, implemented in his tool mimikatz.  We can now dump the password just as easily as the LM hashes.  So at this point, I'd consider this information about LM hashes mostly an FYI regarding yet another way our credentials are exposed with an interactive logon.Thanks,Mike]]></description><content:encoded><![CDATA[Hi Curious,That is true, pass-the-hash is extremely effective and once an attacker is in the environment and has the hashes, then they can mostly get where they want to with them.  There are some tools though that need the actual password.  For example, from the outside, a password is often all that is necessary to login to client VPN gateways or webmail.  Since the LM hash is so simple to reverse to get the password, a stolen LM hash becomes an issue not only from the inside (via pass-the-hash), but also the outside since it can effectively be turned into the password.All that said, it's really become a moot point with the discovery of passwords in memory by Benjamin Delpy, implemented in his tool mimikatz.  We can now dump the password just as easily as the LM hashes.  So at this point, I'd consider this information about LM hashes mostly an FYI regarding yet another way our credentials are exposed with an interactive logon.Thanks,Mike]]></content:encoded></item><item><title>By: Curious</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-15392</link><dc:creator>Curious</dc:creator><pubDate>Wed, 15 May 2013 20:14:20 +0000</pubDate><description><![CDATA[Forgive my ignorance, but if the hash has been obtained, then couldn't the attacker just use a pass-the-hash attack to gain access?  Then it wouldn't matter if the hash was LM or NT, credentials have still been obtained.]]></description><content:encoded><![CDATA[Forgive my ignorance, but if the hash has been obtained, then couldn't the attacker just use a pass-the-hash attack to gain access?  Then it wouldn't matter if the hash was LM or NT, credentials have still been obtained.]]></content:encoded></item><item><title>By: Jason</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-15067</link><dc:creator>Jason</dc:creator><pubDate>Thu, 28 Feb 2013 14:33:16 +0000</pubDate><description><![CDATA[Good article.  Does having two factor authentication help defeat these kind of exploits?]]></description><content:encoded><![CDATA[Good article.  Does having two factor authentication help defeat these kind of exploits?]]></content:encoded></item><item><title>By: Mike Pilkington</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-14952</link><dc:creator>Mike Pilkington</dc:creator><pubDate>Tue, 12 Feb 2013 19:44:15 +0000</pubDate><description><![CDATA[I agree.  The next article in the series discusses exactly that via the mimikatz tool:  http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords.  However, I need to update that article.  At the time I wrote it, it was not yet known that the Kerberos SSP also stored the password in memory.  With that being the case, there's no way to realistically avoid the passwords in memory, other than avoiding interactive logons as I mentioned.]]></description><content:encoded><![CDATA[I agree.  The next article in the series discusses exactly that via the mimikatz tool:  http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords.  However, I need to update that article.  At the time I wrote it, it was not yet known that the Kerberos SSP also stored the password in memory.  With that being the case, there's no way to realistically avoid the passwords in memory, other than avoiding interactive logons as I mentioned.]]></content:encoded></item><item><title>By: Stas</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-14937</link><dc:creator>Stas</dc:creator><pubDate>Tue, 12 Feb 2013 10:59:36 +0000</pubDate><description><![CDATA[What is the point to extract LM hashes from live memory? Have a look at the following software, it extracts PLAINTEXT passwords using all known methods including biometric credentials, WCE-like, Win8 Vault ones, etc.:http://www.passcape.com/index.php?section=blog]]></description><content:encoded><![CDATA[What is the point to extract LM hashes from live memory? Have a look at the following software, it extracts PLAINTEXT passwords using all known methods including biometric credentials, WCE-like, Win8 Vault ones, etc.:http://www.passcape.com/index.php?section=blog]]></content:encoded></item><item><title>By: Mike Pilkington</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-13716</link><dc:creator>Mike Pilkington</dc:creator><pubDate>Fri, 30 Mar 2012 17:37:31 +0000</pubDate><description><![CDATA[Hi BigW,You bring up a great point.  I should have been more clear in the post that using 15 characters isn't the only way to break LM hashes.  I do think it's the best way though.  In my article on encrypted passwords in memory (http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords), a reader made a similar point and I gave the following response, which applies here as well:Hi Anders,You bring up a great point! You are very right, there are a lot of ALT characters which will also break the LM hash, and I should have mentioned that. Unfortunately though, there are also some issues with relying on ALT characters for this purpose. The following Microsoft TechNet article discusses the use of ALT characters to break the LM hash: http://technet.microsoft.com/en-us/library/dd277300.aspx#ECAAAfter first making the point that &amp;gt;14 character passwords will break the LM hash, it goes on to say the following: &quot;Second, if the password contains certain ALT characters, the system will also not be able to generate an LMHash. This latter point is tricky, because while some ALT characters significantly strengthen the password by removing the LMHash, others significantly weaken it since they are converted into a normal upper-case letter prior to storage.&quot;So it turns out that there are some ALT codes which could do the opposite of what we intend. That stinks! Table 1 in the article does list the ALT codes which will break the LM hash, which is nice. However, that's pretty difficult to keep track of and would be really hard to train English-speaking users to follow in a password policy. Though for non-English speaking users, it would probably be much easier, and in fact may not even be necessary since I would think most non-English speakers probably use Unicode in their passwords to begin with?As kind of a side note...In testing I've tried quite a few variations of passwords with ALT codes in Windows XP and haven't had a great deal of luck. For example, I was able to create a new password in XP with ALT-7 (bullet symbol), but thats not a Unicode character and thus it creates an LM hash (verified with WCE). On the other hand, I tried including ALT-0128 (euro symbol) in a new password, but I couldn't get XP to accept it as a password in the Change Password dialog box. On Windows 7, it worked just fine though. It also worked if I set the password on the domain controller and then logged into XP with the new password. So possibly it's user error, but from what I could tell, XP (at least my non-international version) does not have full support for changing passwords with ATL codes.To sum up, you make a great point and I was definitely too absolute in saying that the &quot;only&quot; way to break LM hashes is with &amp;gt;14 character passwords. On the other hand, ALT characters do not provide a straightforward and fail-proof method for disabling the LM hash, so I still recommend &amp;gt;14 character passwords for consistently breaking the LM hash.Hope that helps BigW, and thanks for rightly pointing out the non-ascii option to breaking LM hashes.Mike]]></description><content:encoded><![CDATA[Hi BigW,You bring up a great point.  I should have been more clear in the post that using 15 characters isn't the only way to break LM hashes.  I do think it's the best way though.  In my article on encrypted passwords in memory (http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords), a reader made a similar point and I gave the following response, which applies here as well:Hi Anders,You bring up a great point! You are very right, there are a lot of ALT characters which will also break the LM hash, and I should have mentioned that. Unfortunately though, there are also some issues with relying on ALT characters for this purpose. The following Microsoft TechNet article discusses the use of ALT characters to break the LM hash: http://technet.microsoft.com/en-us/library/dd277300.aspx#ECAAAfter first making the point that &amp;gt;14 character passwords will break the LM hash, it goes on to say the following: &quot;Second, if the password contains certain ALT characters, the system will also not be able to generate an LMHash. This latter point is tricky, because while some ALT characters significantly strengthen the password by removing the LMHash, others significantly weaken it since they are converted into a normal upper-case letter prior to storage.&quot;So it turns out that there are some ALT codes which could do the opposite of what we intend. That stinks! Table 1 in the article does list the ALT codes which will break the LM hash, which is nice. However, that's pretty difficult to keep track of and would be really hard to train English-speaking users to follow in a password policy. Though for non-English speaking users, it would probably be much easier, and in fact may not even be necessary since I would think most non-English speakers probably use Unicode in their passwords to begin with?As kind of a side note...In testing I've tried quite a few variations of passwords with ALT codes in Windows XP and haven't had a great deal of luck. For example, I was able to create a new password in XP with ALT-7 (bullet symbol), but thats not a Unicode character and thus it creates an LM hash (verified with WCE). On the other hand, I tried including ALT-0128 (euro symbol) in a new password, but I couldn't get XP to accept it as a password in the Change Password dialog box. On Windows 7, it worked just fine though. It also worked if I set the password on the domain controller and then logged into XP with the new password. So possibly it's user error, but from what I could tell, XP (at least my non-international version) does not have full support for changing passwords with ATL codes.To sum up, you make a great point and I was definitely too absolute in saying that the &quot;only&quot; way to break LM hashes is with &amp;gt;14 character passwords. On the other hand, ALT characters do not provide a straightforward and fail-proof method for disabling the LM hash, so I still recommend &amp;gt;14 character passwords for consistently breaking the LM hash.Hope that helps BigW, and thanks for rightly pointing out the non-ascii option to breaking LM hashes.Mike]]></content:encoded></item><item><title>By: BigW</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-13711</link><dc:creator>BigW</dc:creator><pubDate>Wed, 28 Mar 2012 23:19:11 +0000</pubDate><description><![CDATA[Hi Mike, worth noting that the use of non-ascii characters also prevents the creation of LM hashes.]]></description><content:encoded><![CDATA[Hi Mike, worth noting that the use of non-ascii characters also prevents the creation of LM hashes.]]></content:encoded></item><item><title>By: Mike Pilkington</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-13661</link><dc:creator>Mike Pilkington</dc:creator><pubDate>Sat, 10 Mar 2012 06:43:51 +0000</pubDate><description><![CDATA[Hi Will,I understand your point and I don't necessarily disagree with it.  My point is simply, why make it easier for the attacker?  What concerns me most about allowing the password to be obtained so easily (which is what we're doing by making LM hashes available) is that it often opens up many more systems for the attacker to infiltrate--systems that don't support the native Microsoft network authentication protocols.  This is particularly dangerous and often true of external services such as VPN and webmail.  Ideally, we'd simply have a Microsoft-provided mechanism to fully disable LM hashes, including in memory, and so it would be one less vulnerability to worry about.  So yes, I guess you could say one more &quot;layer&quot; of defense-in-depth.Thanks, Mike]]></description><content:encoded><![CDATA[Hi Will,I understand your point and I don't necessarily disagree with it.  My point is simply, why make it easier for the attacker?  What concerns me most about allowing the password to be obtained so easily (which is what we're doing by making LM hashes available) is that it often opens up many more systems for the attacker to infiltrate--systems that don't support the native Microsoft network authentication protocols.  This is particularly dangerous and often true of external services such as VPN and webmail.  Ideally, we'd simply have a Microsoft-provided mechanism to fully disable LM hashes, including in memory, and so it would be one less vulnerability to worry about.  So yes, I guess you could say one more &quot;layer&quot; of defense-in-depth.Thanks, Mike]]></content:encoded></item><item><title>By: Will</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-13626</link><dc:creator>Will</dc:creator><pubDate>Fri, 09 Mar 2012 20:38:21 +0000</pubDate><description><![CDATA[Just to play devil's advocate for a moment - what is the benefit of making passwords 15  characters when the NT hash is still written to disk and in memory?  The attacker needs admin privileges to pull the LM hash from memory, but if he's already got admin, he's got access to the unsalted NT hash. With the NT hash, the attacker doesn't need to know the user's password, the NT hash can be replayed via pass-the-hash.  I realize it's all a part of DiD, but I'm wondering if there is a more specific benefit.]]></description><content:encoded><![CDATA[Just to play devil's advocate for a moment - what is the benefit of making passwords 15  characters when the NT hash is still written to disk and in memory?  The attacker needs admin privileges to pull the LM hash from memory, but if he's already got admin, he's got access to the unsalted NT hash. With the NT hash, the attacker doesn't need to know the user's password, the NT hash can be replayed via pass-the-hash.  I realize it's all a part of DiD, but I'm wondering if there is a more specific benefit.]]></content:encoded></item><item><title>By: photo editor free download</title><link>http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly/comment-page-1/#comment-13601</link><dc:creator>photo editor free download</dc:creator><pubDate>Fri, 09 Mar 2012 14:59:52 +0000</pubDate><description><![CDATA[Wow. Nice article. I love your style. And its well structured. And informative, but not too much. I like it.]]></description><content:encoded><![CDATA[Wow. Nice article. I love your style. And its well structured. And informative, but not too much. I like it.]]></content:encoded></item></channel></rss>