{
	"id": "195449bd-60f8-41d0-b443-2f3cc6824d8e",
	"created_at": "2026-04-06T00:12:00.220768Z",
	"updated_at": "2026-04-10T03:21:55.978115Z",
	"deleted_at": null,
	"sha1_hash": "8dc1e02115e8d387a2f34fe0a31a6d28e70ae176",
	"title": "Gifting User Passwords to Adversaries With NPPSPY | Huntress",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4222534,
	"plain_text": "Gifting User Passwords to Adversaries With NPPSPY | Huntress\r\nArchived: 2026-04-05 17:18:14 UTC\r\nWhile investigating an intrusion, Huntress stumbled on something rather fascinating to do with adversarial\r\ncredential gathering.\r\nThreat actors are often retrospectively gathering credentials by dumping what’s already on the system (like\r\nMimikatz). Some tools, like Responder, let the threat actor listen network-wide and pick up some hashes that are\r\nwhizzing around the Active Directory. \r\nBut it isn’t too common that we at Huntress see threat actors proactively manipulate a system not just to gather\r\ncredentials, but to gather cleartext passwords*. Normally, we only see this proactive effort via\r\nUseLogonCredential registry manipulation.\r\nAnd yet, while investigating a recent intrusion, we found an unusual technique to steal cleartext creds. \r\nA threat actor had gained access to a complex network, dwelled in dark corners of the environment, and then\r\ndeployed Grzegorz Tworek's NPPSPY technique to ‘man in the middle’ the user logon process, and squirrel\r\naway the user’s name and password in an unassuming file. \r\nIt seems that the community has documented this NPPSPY technique in theory, but so far it seems like no one has\r\ndocumented when they have encountered it maliciously deployed in the wild. \r\nIn this article, let’s have a look at when the Huntress team encountered this technique IRL. \r\nWhat Does NPPSPY Do?\r\nBefore we go into the details of this tradecraft, I recorded a short video of how this technique works. The TLDR\r\nhere: it’s possible to man-in-the-middle the login process and save a user’s password cleartext into a file on the\r\nfile system:\r\nI am simplifying the technique because I am a simpleton from Grzegorz’s notes [1, 2] and Microsoft\r\ndocumentation. Many have already written about this technique and incorporated it into security frameworks, like\r\nAtomic Red’s suite of tests, so I won’t dwell too much on the granularity of this explanation.\r\nWhen you sit down to sign onto your machine and type in your password to authenticate, a bunch of different\r\nthings are done on the back end with your credentials: hashing, checking, flying back and forth to a domain\r\ncontroller, etc.  \r\nThe conversation between Winlogon and Local Security Authority Subsystem Service (LSASS) is most relevant\r\nfor our instance. Winlogon is both the graphical user interface that we use to put our credentials in, as well as the\r\nconversational partner with LSASS for letting you sign in. \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 1 of 10\n\nIt’s more of a challenge to mess with LSASS to try and gather credentials, and so the NPPSPY technique takes the\r\npath of least resistance by focusing on Winlogon. \r\nWhen you give your password to Winlogon, it opens up an (RPC) channel to a mpnotify.exe and sends it over the\r\npassword. Mpnotify then goes and tells some DLLs what’s up with this credential. \r\nNPPSPY comes alive here. Mpnotify is maliciously told about a new adversarial network provider to consider.\r\nThis network provider is attacker-controlled and comes with a backdoored DLL the adversary has created. This\r\nslippery DLL simply listens for this clear text credential exchange from winlogon down to mpnotify and then\r\nsaves this clear text credential exchange. \r\nWhat Did We Find in the Wild?\r\nLet me take you back to the case.\r\nDuring this intrusion, the Godparents of DFIR, Jamie Levy and Harlan Carvey, used their forensic wizardry to\r\npoint the team to find and give some attention to a ‘C:\\Windows\\System32\\lsass.dll’. They had identified that\r\nthis had been associated with a compromised account and advised us to go and determine what it was. \r\nNow, we’re all good noodles on the ThreatOps team, and if a Big Boss gives an order, you bet we’ll go get it\r\nDONE. We got the DLL, dissected it, hypothesized it was NPPSPY and then deployed it in our local lab to verify\r\nthis theory. \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 2 of 10\n\nAfter having tested locally, we then looked at the compromised system. Very satisfyingly, we could account for\r\nthe exact techniques the threat actor had leveraged. \r\nThe network provider in this instance was named logincontroll (typo intentional)\r\nIt occupied HKLM\\SYSTEM\\CurrentControlSet\\Control\\NetworkProvider\\Order and created value\r\nlogincontrol\r\nAnd then pointed logincontroll with the path C:\\Windows\\System32\\lsass.dll at registry\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services\\logincontroll\\NetworkProvider\r\nBelow are screenshots from the compromised system:\r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 3 of 10\n\nIn our lab and then on the compromised host, we identified that C:\\Windows\\Temp\\tmpCQOF.tmp was the\r\nhardcoded file that the threat actor had designated to listen and record the credentials as Username -\u003e Password:\r\nNow I can’t show you what was in that file on the compromised system—only what was re-created in our testing\r\nenvironment. But trust me, seeing a tonne of cleartext usernames and passwords was WILD. \r\nOutstanding Oddities\r\nYou know, something always interesting with investigations is that even when you reach one conclusion, there is\r\nalways one thread out of place, waiting for you to pull, unravel and get further lost in the sauce.\r\nWe identified this tradecraft on a compromised Exchange server.\r\nRemember C:\\Windows\\Temp\\tmpCQOF.tmp, the file that kept a record of the cleartext creds? Evidence\r\nsuggested that email addresses and their corresponding clear text passwords made it into the dump. \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 4 of 10\n\nThis was me upon that realization. Now, keeping in mind that I am a mere mindless marmoset, I get easily\r\nconfused. How did backdooring the local login process end up rounding up the email addresses and passwords for\r\nusers authenticating to gather their emails, from this Exchange machine?\r\nTo try and wrap my head around what the evidence was showing, we sought counsel with Huntress’ Researcher\r\nTech Lead and Leader of the Council of the Wise, Dave Kleinatland 🧙. \r\nDave agreed it was odd, but suggested\r\nExchange-related authentications CAN be swept up in NPPSPY’s net for catching cleartext\r\ncredentials in transit… If you're capturing creds on an Exchange box, you're doing well.\r\nThis suggests that for NPPSPY, there are under-documented benefits to targeting specific servers in an Active\r\nDirectory. We saw the evidence firsthand that hitting an Exchange box also gathered the clear text creds for users\r\njust trying to access their emails.\r\nInvestigating and Defending\r\nA worry we had when putting this blog together is that by shining the spotlight on an interesting, lesser deployed\r\noffensive security technique, Huntress would be partially responsible for a spike in near future usage.\r\nAs such, we wanted to spend some time on how defenders can investigate and detect this. \r\nFor my red team colleagues, some places advise how to deploy NPPSPY. The default DLL that Grzegorz kindly\r\nprovides will get flagged by Defender, but Grzegorz’s kindness knows no bounds, and he provides the C code to\r\ncompile it yourself.\r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 5 of 10\n\nChecking Live Systems\r\nGrzegorz provides this script to look at the Network Providers and their associated DLL file paths.  \r\nFrom a registry point of view, it’s a ‘service’, but it is not really a service and thus cannot be detected as such. In\r\nthe screenshot below, you can see NPPSPY comparison to the other legitimate ones ‘logincontroll’ is relatively\r\nlight on signatures, version numbers, or descriptions. But it is considered trivial for threat actors to add many of\r\nthese, so don’t rely on the absence of these for detection. \r\nForensics\r\nLike a lot of things in infosec, Harlan seems to have already had all bases covered, no matter how novel the\r\ntechnique. \r\nBy leveraging the services plugin for RegRipper v3.0, we will see the very suspicious service name we have\r\nalready identified with our threat actor’s implementation of NPPSPY.  \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 6 of 10\n\nMonitoring and Detecting\r\nThe file name that records the cleartext credentials is hardcoded from the source, and therefore we do not have\r\ndetection opportunities here. \r\nAlthough the NPPSPY docs advise dropping the DLL in C:\\windows\\System32, you don’t have to. The example\r\nbelow demonstrates how an adversary can drop the required DLL in any directory, like C:\\windows\\temp.\r\nTherefore, we do not have detection opportunities here for any required directories. \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 7 of 10\n\nThis NPPSPY technique is noisy. And detecting this is possible with various security monitoring tools that\r\nmonitor the processes and commands being run on a machine. You could use Sysmon as a free option. At\r\nHuntress, we have our Process Insights listener that makes parent-child process lineage easy to follow.\r\nThere are several detection opportunities for NPPSPY, as adversaries have to\r\nBe a privileged user\r\nCreate and manipulate a number of registry entries \r\nBring a DLL on disk\r\nAnd then write clear text creds to a file somewhere\r\nElastic has a rule query for this kind of network provider manipulation. They assign it a severity medium...\r\npersonally, I’d assign this kind of activity to be a super nuclear critical... but that’s just me. \r\nIOCs and Behavior\r\nOS Credential Dumping - ATT\u0026CK T1003\r\nValues under HKLM\\SYSTEM\\CurrentControlSet\\Control\\NetworkProvider\\Order\r\nFor our case: logincontroll\r\nUnexplained entries in HKLM\\SYSTEM\\CurrentControlSet\\Services\\\u003chere\u003e\\NetworkProvider\r\nFor our case: logincontroll\r\nUnexplained DLLS in folders (very difficult to detect)\r\nFor our case: C:\\windows\\system32\\lsass.dll\r\nFiles being continually written too (essentially impossible to detect this IMO)\r\nFor our case: C:\\Windows\\Temp\\tmpCQOF.tmp\r\nRemediating\r\nTo remediate and eradicate this wickedness, we tested furiously with our virtual machine snapshots.\r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 8 of 10\n\nDeleting only C:\\windows\\system32\\\u003cattacker.dll\u003e stops the credential file being written to\r\nDeleting only the key HKLM:\\SYSTEM\\CurrentControlSet\\Services\\\u003cAttacker provider\r\nname\u003e\\NetworkProvider stops the credential file being written to\r\nTherefore deleting both the attacker-controlled DLL and the registry entry will stop the cleartext credential\r\ngathering activity for sure. \r\nBelow is an extract of the report the partner received from us, which allowed one-click automatic remediations to\r\nundo the ensnarement NPPSPY had placed the machine under.\r\nSo, the Bad Actors Won?\r\nSome may point the blame at security researchers in these instances. It’s easy to assume that because they create\r\ntechniques and share proofs of concept, that they are the root of evil in the cybercriminal ecosystem.\r\nThis couldn’t be further from the truth. The problem is not offensive security research. The problem is\r\ncybercriminals. \r\nWhile this technique was cooked up by a security researcher, the threat actor could have leveraged a whole\r\nplethora of other malicious techniques to achieve their goals—this was just one of them, albeit a spicy one. \r\nOffensive security research helps us defenders stay sharp, and motivate us to constantly improve our tradecraft.\r\nThose attackers got in somehow, and there are always lessons to learn about hardening defenses and imposing cost\r\non dipsh*t adversaries. \r\nTechniques like NPPSPY have probably been deployed in the wild before. From what we can tell, Huntress seems\r\nto be the first at sharing and documenting its IRL usage by threat actors. Offensive tools do not remain elusive and\r\nmysterious for long once the defensive community gives them some attention. \r\nWe hope this article is a small contribution that helps the community fight back and conjure better defenses!\r\n• • •\r\nAddendum: cleartext vs. plaintext\r\n*I consulted NIST docs to conclude what NPPSPY is. A rough overview is that cleartext means un-encrypted text,\r\nwhereas plaintext is the text involved in a more complicated cryptographic exchange. \r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 9 of 10\n\nOf course, if a password is about to be input into a cryptographic authentication like one does for a Windows\r\nlogin, wouldn’t that make it plaintext? Potentially. But NPPSPY seemingly takes place before cryptography really\r\ngets involved, and therefore it seems more appropriate to weigh in on the side of cleartext. \r\nIf anyone has any strong feelings otherwise, please @ me on Twitter.\r\nSource: https://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nhttps://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy"
	],
	"report_names": [
		"cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy"
	],
	"threat_actors": [],
	"ts_created_at": 1775434320,
	"ts_updated_at": 1775791315,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8dc1e02115e8d387a2f34fe0a31a6d28e70ae176.pdf",
		"text": "https://archive.orkl.eu/8dc1e02115e8d387a2f34fe0a31a6d28e70ae176.txt",
		"img": "https://archive.orkl.eu/8dc1e02115e8d387a2f34fe0a31a6d28e70ae176.jpg"
	}
}