| table _time EventCode EventDescription Description Image PipeName process_name parent_process_name parent_process_id Index=main host="WIN-DC-483" source="xmlwineventlog:microsoft-windows-sysmon/operational" ProcessId=1076 EventCode!=7 Now I want to see if any named pipes were used, which can help me locate other hosts in my environment where there is similar behavior. In my previous blog, I was only concerned about parent/child processes and used the great PSTree app to help me sift through those quickly and accurately. This gives us some good information to begin our hunt. The dllhost.exe SourceProcessId is 1076 and was run at 11:47:10 on October 28, 2021. The search returned a single result on showing dllhost.exe accessing lsass.exe. After filtering for those events, we then look for only lsass.exe in the TargetImage field and then look for a few DLL’s in the CallTrace field. Blackhills Information Security provides a good article on the various Sysmon event codes here, just scroll down to Event Code 10 for more information. This search also uses Sysmon events, but now we are looking for EventCode 10 (Process Access) events. | `access_lsass_memory_for_dump_creation_filter` | stats count min(_time) as firstTime max(_time) as lastTime by Computer, TargetImage, TargetProcessId, SourceImage, SourceProcessId `sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll* OR CallTrace=*ntdll.dll* I ran the following search in my environment to detect Cobalt Strike Mimikatz activity (it actually picks up other malicious LSASS memory dumping activities as well, and comes from the Splunk Security Content repo): If you run other detections to pick up things like Mimikatz, you should have one or two threads to pull if something bad happens. What can we do to find this behavior when someone was not super lazy with their use of Cobalt Strike? Well, read on my friend, read on. Run Mimikatz on the 2016 Domain Controller.Īnd here’s the result from the same search I ran earlier.Show running processes on both Windows 2016 servers.Move laterally via PSExec in Cobalt Strike to both Windows 2016 servers.Run “net computers” to see what else is on the network.Compromise Windows 10 client with Cobalt Strike beacon.With new pipe names (we’ll find these later), I ran through these same steps again: I’ve now become quite the Fancy Lad having changed all of my pipe names to hopefully avoid the detection I ran earlier. Read up on these if you want further detail of how this works. This is done through Cobalt Strike’s Artifact Kit. On top of changing profiles, you also want to modify the default Cobalt Strike Beacon binary to avoid using the MSSE pipe names. How do you do this, well it’s a rather trivial process, and this post by ZeroSec gives a good run-through. A Bit of the Ol’ Switcherooīack to malleable profiles. Reading this one first would be like watching the great Liam Neeson in Taken 4 before you watched him in Taken 3. If you haven’t already read it, you need to go back and do so, as that’s where I cover things like pre-requisites and other interesting tidbits. I also mentioned how Cobalt Strike provides the ability to change pipe names via malleable profiles to try and avoid being detected. In part 1, we saw how our detections picked up Cobalt Strike named pipes when they were using their default, out of the box, values. Shannon Davis provided the first half of this blog on pipe hunting in part twenty-nine, and will now run through the second half! – Ryan Kovar T his blog post is part thirty of the " Hunting with Splunk: The Basics" series.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |