{ "id": "ab9c7967-7544-47e1-a815-24718aacbb99", "created_at": "2026-04-06T00:18:26.542403Z", "updated_at": "2026-04-10T03:30:33.87203Z", "deleted_at": null, "sha1_hash": "2011d9d5436dfeb134721cdf6765fee764461144", "title": "Registry Analysis with CrowdResponse »", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 839244, "plain_text": "Registry Analysis with CrowdResponse »\r\nBy Chad Tilbury\r\nPublished: 2014-08-28 · Archived: 2026-04-05 16:37:13 UTC\r\nThe third release of the free CrowdResponse incident response collection tool is now available!  This time around\r\nwe include plugins that facilitate the collection of Windows registry data.  Our inspiration for this release was one\r\nof those vulnerabilities that just won’t die – Windows Sticky Keys. We’ll show how to identify this attack while\r\ndemonstrating the new additions.\r\nNew Plugins\r\n@RegDump [-ds] \u003creg key\u003e\r\nRegDump recursively extracts Windows registry key and value data.\r\n-d Nested output format\r\n -s Recursive dump\r\n \u003creg key\u003e Registry key to start dump from\r\nValid registry hive names are: HKLM, HKCU, HKCR, HKU, and HKAU (pseudo key representing all users)\r\n@RegFile [-scmh] \u003creg key\u003e\r\nRegFile searches for registry string values (REG_SZ and REG_EXPAND_SZ) and identifies file path data.  If the\r\nfile exists on disk, file information, hash, and digital signature details are recorded.\r\n-s Recursive dump\r\n -c Verify digital signature of discovered files\r\n -m Compute MD5 hashes\r\n -h Compute SHA256 hashes\r\n \u003creg key\u003e Registry key to start dump from\r\nThe Attack\r\nThe Sticky Keys attack is one of those vulnerabilities that is nearly too simple to believe.  With a high success rate\r\nin most Windows environments, it is not surprising that we still see even some of our more advanced adversaries\r\nputting it into play.  The original Sticky Keys attack involved replacing the C:\\Windows\\System32\\sethc.exe\r\nbinary with something that could provide access to the underlying OS, such as cmd.exe.  After the switch, all it\r\ntakes is five presses of the Shift-key from the logon screen and cmd.exe is executed.  Since sethc.exe is executed\r\npre-login, the attacker effectively gets a shell without needing to authenticate.  This reduces the logging footprint\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 1 of 7\n\n(no compromised account logon necessary!) and gives the added bonus of providing a shell running with\r\nLOCAL_SYSTEM privileges.\r\nAs new versions of Windows introduced slightly better protection mechanisms for the System32 folder, a new\r\nvariant emerged – setting cmd.exe as a debugger to the sethc.exe process.  One simple addition to the Windows\r\nregistry and the attack works just as before, except there is no longer a need to perform file replacement.\r\nREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\sethc.exe\" /t\r\nAnother common variant takes advantage of a different part of the accessibility suite, Utilman.  The attack is\r\nidentical to the sethc.exe registry debugger modification seen above, except the binary is now Utilman.exe and a\r\nsimple Windows key + U combination will present a LOCAL_SYSTEM privileged shell.\r\nREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\utilman.exe\"\r\nAn important detail about this vulnerability is the attacker must have prior access to the system.  That can be\r\neither via an administrator account (necessary to modify HKLM or write files to C:\\Windows\\System32) or via\r\nphysical access to the machine, with modifications done via a bootable USB.   Hence it is largely used post-compromise in conjunction with RDP as a convenient means for attackers to pivot through the network or to\r\nregain access after a password reset.  Finding evidence of a Sticky Keys attack may lead the responder to the\r\ninitial compromise of a system, but it will not be the first malicious activity to occur.\r\nFinding Sticky Key Attacks\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 2 of 7\n\nFile Replacement\r\nOne of the clever things that make the Sticky Keys attack difficult to identify is that the file replacement uses a\r\nlegitimate Windows binary (cmd.exe).  Thus, the resultant file will still nicely match your list of known good\r\nhashes.  The trick of course is to not only compare hashes, but to ensure you are matching the filename with the\r\ncorrect hash.  Using the CrowdResponse @DirList plugin, we can pull filenames, hashes, and digital signatures\r\nfor all files in the C:\\Windows\\System32 folder.\r\nFrom the CrowdResponse config file:\r\n@dirlist \"%windir%\\system32\" -h -m -r -s -t -p 2 -z 30 -i \"\\.(exe|dll|sys)$\"\r\nWith the output in hand (or in a backend database), a simple query for well-known sethc.exe or cmd.exe hashes\r\ncan be constructed to easily identify anomalies.  In this example we see cmd.exe and sethc.exe both having the\r\nsame (cmd.exe) hash.\r\nRegistry Analysis\r\nImagine a tool that dumps all of your favorite registry locations for inspection along with validating any binaries\r\nthat are referred to within those registry locations. This use case nicely covers the capabilities of\r\nCrowdResponse’s new @RegDump and @RegFile plugins.  Let’s see how they work when searching for Sticky\r\nKey modifications.\r\nFrom the CrowdResponse config file:\r\n@RegDump \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\" -s\r\n@RegFile “HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options” -s -c -h\r\n-m\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 3 of 7\n\nThe @RegDump output clearly shows utilman.exe as an outlier (it was the only one in the list with a “debugger”\r\nvalue) and @RegFile nicely identified the full path in that registry value and provided hash and digital signature\r\ninformation.   While this example shows us using the new registry plugins to identify Sticky Key modifications,\r\nthey are equally useful to collect known hotspots in the registry, such as the infamous “Run” keys and other\r\nregistry-based ASEPs.\r\nYARA\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 4 of 7\n\nYou may recall that one of the first features of CrowdResponse was the ability to scan memory and disk for\r\narbitrary YARA signatures.  YARA’s power lies in its simplicity, and there are some great signatures available to\r\nhelp you find all kinds of evil.  Florian Roth at BSK Consulting shared a clever YARA signature for detecting\r\nsethc.exe file replacement.  The signature looks for well-known strings within sethc.exe, and if they are not found,\r\nflags the binary for potential file replacement.  A slightly modified version can be used with CrowdResponse:\r\nCrowdResponse –o out.xml @yara –m sethc.yar –f sethc.exe –t %windir%\\System32\r\nContents of sethc.yar:\r\nRule Sethc_Replace\r\n{\r\nstrings:\r\n$s1=\"stickykeys\"fullword nocase\r\n$s2=\"stickykeys\"wide nocase\r\n$s3=\"Control_RunDLL access.cpl\"wide\r\n$s4=\"SETHC.EXE\"wide\r\n}\r\nThe command uses the CrowdResponse @YARA module to scan anything named sethc.exe in the\r\n\\Windows\\System32 folder, flagging the binary if specific strings are not present.\r\nScaling Your Efforts\r\nIt is increasingly necessary to collect and analyze incident response data at scale.  Scaling analysis to hundreds or\r\nthousands of systems requires a process that can collect the results of a tool like CrowdResponse and get the data\r\ninto a searchable repository.  Once accomplished, you can easily detect the Sticky Keys attack with a search\r\nsimilar to the one seen below.\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 5 of 7\n\nIn this example an analyst with knowledge of the Sticky Keys vulnerability created a simple query and identified\r\nthree new compromised systems.  Other possible searches include the presence of a “Debugger” value and hash\r\ncomparisons of sethc.exe and utilman.exe.\r\nRemediation\r\nWhat can be done about this attack once it is identified?  Like many Windows vulnerabilities, the most effective\r\nmitigation is to prevent adversaries from achieving administrative privileges.  Modifying the necessary keys or\r\nfiles in this attack requires administrative rights.  Beyond that, there are some things you can do to make the attack\r\nslightly more difficult and potentially easier to detect.\r\nUpgrade systems to at least Win7/Win2008R2.  This does not remove the vulnerability, but at least makes\r\nfile replacement slightly more difficult.\r\nTurn off sticky keys via the registry.  An obvious solution, but unfortunately an attacker with administrative\r\nrights can easily re-enable.\r\nEnforce Network Level Authentication for RDP connections.  Available starting with Windows 7 and\r\nServer 2008, NLA requires account authentication before a RDP session is established.  NLA could be an\r\nelegant fix, except that an adversary with administrative rights can easily disable it.\r\nRequire IPsec to pre-authenticate RDP sessions.  This solution mitigates any advantages Sticky Keys give\r\nto an attacker, but requires significant up-front work.\r\nSet real-time triggers looking for changes to file system or registry in your security tools.  Tune end-point\r\nmonitoring or HIPS to look for telltale signs of file replacement and registry modification.\r\nWant to try it yourself? Download the latest version of CrowdResponse here.   A big thank you to Robin Keir and\r\nDanny Lungstrom for their work on this release.\r\nThe CrowdStrike team is committed to developing and delivering free community tools like CrowdResponse,\r\nCrowdInspect, Tortilla, and the Heartbleed Scanner.  If you have any questions or would like additional\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 6 of 7\n\ninformation on our services, products, or intelligence offerings, please reach out to us via our contact page. For\r\nimmediate assistance with an Incident Response, the CrowdStrike Services team can be contacted at\r\n1.855.CROWDIR (276-9347).\r\nSource: https://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nhttps://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://web.archive.org/web/20200730053039/https://www.crowdstrike.com/blog/registry-analysis-with-crowdresponse/" ], "report_names": [ "registry-analysis-with-crowdresponse" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "8bd26575-9221-47d1-9d8b-5c18354dc1bd", "created_at": "2022-10-25T16:07:24.335Z", "updated_at": "2026-04-10T02:00:04.94173Z", "deleted_at": null, "main_name": "Tortilla", "aliases": [], "source_name": "ETDA:Tortilla", "tools": [ "Babuk", "Babuk Locker", "Babyk", "CHINACHOPPER", "China Chopper", "SinoChopper", "Vasa Locker" ], "source_id": "ETDA", "reports": null }, { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434706, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/2011d9d5436dfeb134721cdf6765fee764461144.pdf", "text": "https://archive.orkl.eu/2011d9d5436dfeb134721cdf6765fee764461144.txt", "img": "https://archive.orkl.eu/2011d9d5436dfeb134721cdf6765fee764461144.jpg" } }