Without additional info, it's hard to say for certain. Microsoft indicates that LM hashes will not be stored when the user changes passwords.
However, in a SANS article by Mike Pilkington, he applies the appropriate mitigation settings, yet still have instances where LM hashes can be found in memory.
[After dumping the SAM db] As expected, no LM hashes are available. The first 2 accounts are disabled by default and no password was ever set for them. For user account MIKE, only his NT hash is available. So far, so good!
[After dumping credentials in-memory] It turns out that Windows calculates and stores the LM hash in memory, assuming the password is less than 15 characters, regardless of what the host or domain settings are for LM hash storage and LM challenge-response!
A little deeper
After calculating the NT and LM hashes of the
Pa55w.rd, the value for NT is
377565F7D41787414481A2832C86696E and LM is
C321C0EE1F8388924A3B108F3FA6CB6D, neither of which match what you have above. So I'm wondering, perhaps you copied the wrong hash? Or, did you copy the password incorrectly?
On various pentests I've been on, I have noticed that legacy environments have a really tough time getting rid of LM hashes, even if they push out that GPO to not store LM hashes and disable LMv1/2 on the network. This could certainly be related to hashes still being calculated and stored in memory as the article indicated.