{ "id": "e15f275d-4222-4887-bbc5-4eb41ed41649", "created_at": "2026-04-06T00:20:52.833117Z", "updated_at": "2026-04-10T03:24:24.688502Z", "deleted_at": null, "sha1_hash": "4c533039021c287f4268b2cc362ee354a21838f0", "title": "You Bet Your Lsass: Hunting LSASS Access | Splunk", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 6670857, "plain_text": "You Bet Your Lsass: Hunting LSASS Access | Splunk\r\nBy Splunk Threat Research Team\r\nPublished: 2022-04-07 · Archived: 2026-04-05 19:19:11 UTC\r\nOne of the most commonly used techniques is to dump credentials after gaining initial access. Adversaries will\r\nuse one of many ways, but most commonly Mimikatz is used. Whether it be with PowerShell Invoke-Mimikatz,\r\nCobalt Strike’s Mimikatz implementation, or a custom version. All of these methods have a commonality:\r\ntargeting LSASS. The Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows\r\noperating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to\r\na Windows computer or server, handles password changes, and creates access tokens (per Wikipedia).\r\nWith that, the Splunk Threat Research Team dug into how Mimikatz, and a few other tools found in Atomic Red\r\nTeam, access credentials via LSASS memory, T1003.001. Part of this process for the Splunk Threat Research\r\nTeam is to continuously update older analytics to ensure we are providing up to date coverage on latest techniques\r\nand behaviors.\r\nTo begin, we’ll look at our current analytics related to LSASS memory dumping. We will then simulate\r\nT1003.001, OS Credential Dumping: LSASS Memory, by using Mimikatz, Cobalt Strike, Atomic Red Team\r\nT1003.001, and Invoke-Mimikatz. Last, we will update our current analytics or create new ones.\r\nCurrent Content Review\r\nAccess LSASS Memory for Dump Creation\r\nOur first analytic identifies the image load dbgcore.dll or dbghelp.dll and a TargetImage of lsass.exe. Dbgcore.dll\r\nor dbghelp.dll are two core Windows debug DLLs that have minidump functions which provide a way for\r\napplications to produce crashdump files that contain a useful subset of the entire process context.\r\nThis analytic focuses on the CallTrace and identifies whether dbgcore.dll or dbghelp.dll are loaded to dump\r\ncredentials.\r\n`sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll*\r\n| stats count min(_time) as firstTime max(_time) as lastTime by Computer, TargetImage,TargetProcessId, SourceIm\r\n| rename Computer as dest\r\n| `security_content_ctime(firstTime)`\r\n| `security_content_ctime(lastTime)`\r\nWe found, as we’ll show in our simulation, that dbgcore.dll and dbghelp.dll are no longer utilized with the latest\r\nversion of Mimikatz or Cobalt Strike. However, it still does capture the more basic utilities that access LSASS\r\nmemory.\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 1 of 14\n\nDetect Credential Dumping through LSASS access\r\nThis analytic looks for GrantedAccess of 0x1010 or 0x1410 against lsass.exe. These are common access types and\r\nit's probably a good time to understand what they are and the common values.\r\n`sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410)\r\n| stats count min(_time) as firstTime max(_time) as lastTime by Computer, SourceImage, SourceProcessId, TargetIm\r\n| rename Computer as dest\r\n| `security_content_ctime(firstTime)`\r\n| `security_content_ctime(lastTime)`\r\nThis query is limited to two GrantedAcess rights that are familiar to older versions of Mimikatz, but does not\r\nstand the test of time in capturing the latest rights request.\r\nGrantedAccess is the requested permissions by the SourceImage into the TargetImage. Microsoft details out the\r\nprocess specific access rights here. The below list highlights the most common values. Note that these may be\r\ncombined to create, for example, 0x1400 (PROCESS_QUERY_LIMITED_INFORMATION and\r\nPROCESS_QUERY_INFORMATION). You may notice some other common values related to process command-line spoofing (PROCESS_SUSPEND_RESUME).\r\nNow that we have a basic understanding of how these two current analytics work, let's capture data and begin to\r\ntest them out further.\r\nCapture Data\r\nTo get started with capturing process access event data with Sysmon, we have provided a simple config that\r\nidentifies TargetImage of lsass.exe. For other EDR products, the name may be similar - Cross Process Open for\r\nCarbon Black, or CrowdStrike Falcon SuspiciousCredentialModuleLoad or LsassHandleFromUnsignedModule\r\n(reference Falcon Data Dictionary).\r\n\u003cSysmon schemaversion=\"4.81\"\u003e\r\n\u003c!-- Capture all hashes --\u003e\r\n\u003cHashAlgorithms\u003emd5\u003c/HashAlgorithms\u003e\r\n\u003cEventFiltering\u003e\r\n\u003c!-- Event ID 1 == Process Creation. --\u003e\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 2 of 14\n\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\nPage 3 of 14\n\nC:\\Windows\\system32\\lsass.exe The Sysmon Modular project by Olaf Hartong has some filtering that may be useful to enhance the configuration.\nIn our testing, we utilized an open Sysmon configuration and the latest version of Sysmon.\nNow we are ready to simulate.\nSimulate\nTo simulate LSASS Memory Access, we will start with Atomic Red Team and follow up with Mimikatz, Invoke-Mimikatz, and Cobalt Strike.\nAtomic Red Team\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\nPage 4 of 14\n\nFor T1003.001, LSASS Memory access, we can run individual tests or all. In this instance, we will download all\r\nthe prerequisites and then run them all. There are cases where the tests may not complete and may need to be fixed\r\nor run manually (this is all based on operating environment variables).\r\nTo download Invoke-Atomicredteam and the Atomic Tests, run the following\r\n[Net.ServicePointManager]::SecurityProtocol =\r\n[Net.SecurityProtocolType]::Tls12\r\nIEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1'\r\nInstall-AtomicRedTeam -getAtomics -force\r\nInstall prerequisites\r\nSome Atomic tests have prerequisites and it is very simple to get those. This may include binaries or scripts n\r\nInvoke-AtomicTest T1003.001 -GetPrereqs\r\nNow we will invoke T1003.001.\r\nInvoke-AtomicTest T1003.00\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 5 of 14\n\nBefore we hop into Splunk, let's run the other two simulations.\r\nInvoke-mimikatz\r\nFor invoke-Mimikatz, we utilized Atomic Red Team T1059.001 test number 1. This uses the 2019 version of\r\nMimikatz. Roberto Rodriguez called out the differences in his blog from 2017 as well, in that older versions\r\nrequest different permissions. Upon successful execution, it will invoke Mimikatz in memory and dump\r\ncredentials.\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 6 of 14\n\nMimikatz\r\nDownload the latest Mimikatz from GitHub. Ensure AV and other products are turned off to avoid any issues.\r\nWe will run the following variations\r\n.\\mimikatz.exe \"privilege::debug\" \"sekurlsa::logonpasswords\" exit\r\n.\\mimikatz.exe SEKURLSA::Krbtgt exit\r\nAlright, that finishes our easy tests for Mimikatz.\r\nMimikatz and Cobalt Strike\r\nSimilarly, run the same commands within a session using Cobalt Strike. The behavior we will look for here is\r\nsimilar to most Cobalt Strike behavior we've identified in the past, a spawned process, default of rundll32.exe,\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 7 of 14\n\nwith no command-line arguments, with a process access event targeting LSASS.exe.\r\nNotes on testing\r\nTypically, our process is to simulate 1 test at a time and validate coverage. Iterate over each test and modify our\r\nquery as needed. For brevity, the blog skips the thorough process and highlights a faster process.\r\nContinuous Improvement\r\nAccess LSASS Memory for Dump Creation\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 8 of 14\n\nFor our first analytic that focuses on CallTrace image load dbgcore.dll or dbghelp.dll, we found that over time\r\nMimikatz moved away from these two DLLs (dbgcore.dll or dbghelp.dll). The main DLL used by Mimikatz is\r\nnow ntdll.dll. Ntdll.dll is a native Windows binary that provides similar native API paths to perform credential\r\ndumping. For example in the sekurlsa module there are many ntdll exported api’s, but what stands out is\r\nRtlCopyMemory which is used to execute the module related to credential dumping.\r\nAfter simulating the behavior we needed, we get some results\r\n`sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll*\r\n| stats count min(_time) as firstTime max(_time) as lastTime by Computer, TargetImage,\r\nTargetProcessId, SourceImage, SourceProcessId\r\n| rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`\r\nIn our screenshot, we see some utilities that still use dbgcore.dll or dbghelp.dll when credential dumping occurs.\r\nHowever, we do not see Mimikatz.exe and a few other utilities using dbgcore.dll or dbghelp.dll. Based on\r\nCallTraces, we see a pattern of ntdll.dll being used by various credential dumping utilities. If we add ntdll.dll to\r\nour current query we get the following results:\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 9 of 14\n\nWe now have a list of processes (source) targeting lsass.exe. Sometimes legitimate applications will request access\r\nto lsass.exe for credential access, say to authenticate with AzureCLI or a software deployment application. What\r\nwill differentiate these? This will be environment dependent based on roles and access associates may have, based\r\non process hierarchy, or GrantedAccess. As we will dig into next, filtering may be much easier once we combine\r\nGrantedAccess with CallTrace.\r\nNow we add GrantedAccess to our query to identify any patterns\r\nWe can see the permissions being requested by the SourceImage and we will begin looking at what those values\r\nmean next.\r\nDetect Credential Dumping through LSASS access\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 10 of 14\n\nNow our second analytic is focused on GrantedAccess, which we explored earlier what the values are. Now that\r\nsimulation is complete we can begin digging in.\r\nThe base query looks like this with some simulated data\r\n`sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410)\r\n| stats count min(_time) as firstTime max(_time) as lastTime by Computer, SourceImage, SourceProcessId, TargetI\r\n| rename Computer as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`\r\nWith all the simulation it was easy to spot the patterns between CallTrace and GrantedAccess, so we created a\r\ntable to showcase these values:\r\nWith all this testing, our updated Sysmon query combines the two analytics we set out to enhance by focusing on\r\nspecific GrantedAccess rights and CallTrace DLLs. Will this catch everything? Probably not, but it will at least\r\ncatch the majority of tools used and allow us to filter out known good in environments and focus on the rare.\r\n`sysmon` EventCode=10 TargetImage=*lsass.exe GrantedAccess IN (\"0x01000\", \"0x1010\", \"0x1038\", \"0x40\", \"0x1400\",\r\nThis will require some filtering as common system processes will access lsass.exe with GrantedAccess of 0x1400\r\nand 0x1010.\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 11 of 14\n\nFor Mimikatz and the various items that come with it, whenever it does make contact with LSASS.exe the results\r\nare mostly the same.\r\nAs noted in our table of CallTrace and GrantedAccess, dependent upon what is being executed with the utility\r\n(MimiKatz for example) the access will be different. This was also noted by Roberto Rodriguez here and Carlos\r\nPerez here.\r\nDoes this catch every variation of Mimikatz out there? Most likely not. However, it will be a great start to identify\r\nuncommon GrantedAccess rights to Lsass.exe. This may be expanded upon or converted to other utilities to assist\r\nwith detecting suspicious LSASS access.\r\nAdditional Observations\r\nDuring our simulations we identified behaviors that may assist teams in identifying suspicious SourceUser\r\naccessing LSASS. Typically, we will see source NT AUTHORITY\\SYSTEM and TargetUser NT\r\nAUTHORITY\\SYSTEM for normal system process behavior. However, seeing source\r\nATTACKRANGE\\administrator and Target NT AUTHORITY\\SYSTEM is suspicious.\r\nWhat if an adversary is already elevated? SourceUser will not be a user account, but NT AUTHORITY\\SYSTEM.\r\nThis may be a bit more difficult to detect, but it’s worth a hunt.\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 12 of 14\n\nWith all this data we hope you found this informative and understand a bit of our continuous improvement for our\r\ncontent.\r\nNew Analytics\r\nWindows Hunting System Account Targeting Lsass\r\nThe following hunting analytic identifies all processes requesting access into Lsass.exe.\r\nWindows Non-System Account Targeting Lsass\r\nThe following analytic identifies non SYSTEM accounts requesting access to lsass.exe.\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 13 of 14\n\nSource: https://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nhttps://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html\r\nPage 14 of 14", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html" ], "report_names": [ "you-bet-your-lsass-hunting-lsass-access.html" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434852, "ts_updated_at": 1775791464, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4c533039021c287f4268b2cc362ee354a21838f0.pdf", "text": "https://archive.orkl.eu/4c533039021c287f4268b2cc362ee354a21838f0.txt", "img": "https://archive.orkl.eu/4c533039021c287f4268b2cc362ee354a21838f0.jpg" } }