blue tangle

For those following along with ATT&CK this entry is about  Application Layer Protocol: DNS , Command And Control technique T1071 and PowerShell , Execution technique T1086. Having written a bit about DNSCat2 previously I wanted to check out PowerShell implementations like  dnscat2-powershell  an d see what I could turn up in logs. I tried running various commands through the shell from the server side and discovered the following: PowerShell calls nslookup.exe to communicate with the server side of DNScat2 and executes commands issued through that shell, we can hunt for this: index=win10 sourcetype="wineventlog:security" EventCode=4688 Creator_Process_Name=C:\\Windows\\*\\WindowsPowerShell\\*\\powershell.exe | stats count(New_Process_Name) AS Count values(New_Process_Name) AS Processes BY Account_Name Creator_Process_Name Our results will look like this: We can look specifically for calls to nslookup by PowerShell and count the events with this SPL: index=win10 sourcetype

Today we're looking at Network Sniffing , ATT&CK technique T1040. This is very much a signature based rule but if you are ingesting WinEventlog:Security (and of course you are, right?) and specifically EventCode 4697 ("A service was installed in the system") then you can take the barebones splunk SPL from below and make it work for you. So how are we going to detect network sniffing on Windows endpoints? The installation of the drivers for the various Pcap variants. index=win10 sourcetype="wineventlog:security" EventCode=4697 AND Service_File_Name IN ("*pcap*", "*npcap*", "*npf*", "*nm3*", "*ndiscap*", "*nmnt*", "*windivert*", "*USBPcap*", "*pktmon*") | table _time Account_Name Computer_Name Originating_Computer Service_Name Service_File_Name   The Service_File_Name list is derived from looking at the names of .sys files associated with the most popular packet capture o

For those following along with ATT&CK this entry is about  Network Service Scanning , Discovery technique T1046. Time to get to detecting! First lets talk about the SPL that you see floating around the web to detect portscanning. There are a few obvious ways of doing it, you can look for people hitting some arbitrary number of ports like > 500 or you can simply count and list all ports connected to by a certain src and sort by that count. I think if you are looking for an adversary to hit more than 500 or a 1,000 ports then you are looking for the noisiest of attackers, especially if you are looking at internal network traffic, there's a better way. We need to look at the tools attackers use and try to think about what would be the most efficient way for them to get the information they need without lighting up your SIEM like a christmas tree. Luckily nmap has a page dedicated to just this question, " What Are the Most Popular Ports? " and we can see that the top 2

For those following along with ATT&CK this entry is about Application Layer Protocol: DNS , Command And Control technique T1071. I've been looking at various DNS based red team tools and the traces they leave in Windows logs, tools like DNScat2, Iodine and DNSExfiltrator. Looking at DNScat2 I was interested in detecting activity on the endpoint to save picking through voluminous network logs. If we take a look at the structure of command line args shown on github we can see some potential detections already, even if the binary itself is renamed. So the cli args we are looking for are "--secret", "--dns", "port" and "host", as well as an FQDN or IP address for the server side. Throwing together a really rough detection we can say that if the DNScat2 process is executed from the cli in Windows then we are looking at a Creator Process Name of cmd.exe and we can use urltoolbox in place of an unwieldy huge regex to find our server address in