blue tangle

  Following on from reading an unSafe.sh post about recent Lockbit ransomware gang activity, aka the new "Lockbit Black", I decided to look into a file that was posted along with the analysis, "123.bat".   You can view or grab a gist of the batch file below: We're going to run this batch file on a test VM and have a look at the resulting logs for some detection ideas, I'll be giving examples in Splunk SPL but I am certain with a little SIEM magic you can adapt the content to elastic, Sentinel or Defender Advanced Hunting queries instead. Lets get to it. The first questions we have to ask though, are around log availability and log visibility.  Are you ingesting Windows EventID 4688 and command line parameters along with that? How about logs from Powershell? If you are still running an older version of Powershell in your estate and finding motivation to update to 5+ is tough then here's your driver, better security and better logs that you can bung i

  In part one of these blog entries on command line obfuscation in Windows ( which you can find here , if you haven't read it), we covered some real basic SPL for detecting the usage of double quotes to potentially circumvent SIEM detections. One of the things I forgot to mention then is that counting specific characters in fields has a lot of potential uses within Splunk searches if you are prepared to think outside the box a little. For instance let's say you were looking at Apache web logs and you were wanting to find instances of directory (or path) traversal, someone appending something like "../../../../../../../../../../../../etc/passwd%00" to a url to try to get at your valuable files, you could modify the SPL as follows:   index=apache sourcetype=access_combined | eval traversalCount=mvcount(split( uri,"."))-1 | where traversalCount >=4 | stats values(uri) BY traversalCount clientip status   This would give you any instances of uris containing

  If you want inspiration for a slidedeck on the history of ransomware look no further. Where I wanted to nail down specific dates I looked for when ransomware strains or incidents made the mainstream news and used that as my base timeline. The slides cover the first incident of data held for ransom that I could find (in 1981) through to Karakurt as what I see as the future of ransomware, touching on targeted ransomware attacks and the advent of Big Game Hunting in between. The talk is made to be delivered in about 25 - 30 minutes, though I was cutting it rather close with that timing. Feel free to use and alter this PowerPoint as you wish.  

The only thing I find more fascinating than digital anti-forensics, obfuscation and defence evasion is coming up with ways to thwart those techniques as they are employed by adversaries in the wild. This will be a few posts about ways to detect Windows command line obfuscation using Splunk, but I'm sure that the SPL I'm going to include here could be adapted to create detections for other SIEM tools like elastic or Sentinel with relative ease. Think of this as a chance to look up a magician's sleeve for a little peek at the concealed dove. Before we look at detections though we need to define the problem itself, what is command line obfuscation (or “DOSfuscation”) and why is it a problem for defenders? I would urge anyone who is interested in learning more about this topic in depth to check out Wietze Beukema’s excellent SANS DFIR talk:   If you are following along with ATT&CK I think this technique is best mapped to T1027, Obfuscated Files or Information. One of t

  I'll be presenting at BSides Dundee on August 6th, discussing the entire history of ransomware in only 25 minutes. I've learned a lot doing the research for the talk. So much of what we understand about the history of hacking seems to be the same somewhat random selection of events written up with mistakes and incorrect assumptions then copied and pasted across dozens and dozens of blogs, news articles and academic papers forever, without anyone revisiting the actual primary sources for the events from the time that they happened. What was the first webshell to be written? Who was the victim of the first DDoS? What was the first computer virus discovered in the wild? Look any of this up online and you'll either find wildly conflicting answers or no information at all, we are not good at documenting our own history. Anyway, that's my rant over, look forward to giving this talk and hope to see some of you in attendance!

  There is never necessarily a good time for Windows updates, but if you are running Windows and care about security, you're going to have to do it eventually, right? Some Threat Actors would prefer that those updates remain uninstalled though, this blog and the research that went into it is inspired by this Scadafence paper entitled " Anatomy of a Targeted Ransomware Attack " which includes this list, pay particular attention to 2. "Disabling Windows updates", this got me thinking. I had a look through ATT&CK to try to map this TTP but to no avail, asking in the ATT&CK Slack I think "Impair Defenses: Disable or Modify Tools" (T1562.001) or "Service Stop" (T1489) seem most appropriate, but I'll leave it up to you as it could fit under a few techniques. I couldn't find any detections for this, so I decided to make my own and share them. Why would a threat actor want to stop Windows updates or even roll them back? I think TAs, e

  After the last two blog entries about winPEAS.bat related detections I figured we'd take a look at the pre-compiled binary version. Oh and we get this last pea related punny blog title, for now. First of all we have winPEAS retrieving local Wi-Fi profile details, potentially a pre-cursor to retrieving network security keys. We can hunt for this behaviour: index=winlogs EventCode=4688 (Process_Command_Line=*powershell.exe* OR Process_Command_Line="*wlan show profiles*") | stats min(_time) AS earliest max(_time) AS latest count(Process_Command_Line) AS Count values(Process_Command_Line) AS Process_Command_Line BY Creator_Process_Name | convert ctime(earliest) ctime(latest) | where Count > 1 | table earliest latest Count Creator_Process_Name Process_Command_Line     This is what it looks like in Splunk:      Other reconnaissance tools and legitimate user behaviour may introduce false positives here, though checking for Wi-Fi profiles on say a Windows server or des

  Last post we looked at winPEAS traces left in logs using Splunk and Windows security event logging and guess what we are doing this time? More of the same, these are potential security alerts or a jumping off point for some threat hunting.    What prompted me looking at PEAS-ng, Watson and dazzleUP is that they are all featured in one of the rounds of Conti ransomware gang leaks.    I'll be trying to cover all three red team tools in some depth, with some SPL. If you are using a different SIEM you can use what I have here to inspire your own detections, just go with your heart. winPEAS performs extensive reconnaissance on Windows endpoints to provide some guidance on potential privilege escalation paths for adversaries, as before we are looking at the batchfile implementation of winPEAS, though it also comes in pre-compiled binaries and there is a Powershell version floating around as well.   Part of this discovery/recon process involves using Windows native tool findstr.exe t

  Been a while since I've updated this, figured I might as well post some of my findings looking at logs generated by Windows privilege escalation discovery frameworks, in this case winPEAS (Windows Privilege Escalation Awesome Script). So far I've only looked at the resulting logs generated by running the .bat file implementation, I'll chuck up another couple of blogs as I work my way through the pre-compiled executable version, then dazzleUP and Watson. winPEAS is really comprehensive, it provides a lot of information about the host it is run on, patching and security updates, potential avenues for exploitation, existing services, file and directory permissions, etc. As a result of this though, it is very noisy in logs. To retrieve service information winPEAS makes use of the windows executable sc.exe with the " qc " command. A full run of winPEAS.bat resulted in around 250 sc qc queries on my test VM, we can hunt for this: Obviously replace the index

For those following along with ATT&CK this entry is about  Server Software Component: Web Shell  which is now a sub-technique of T1505, specifically it is T1505.003. We can also look at T1090, which is the Command & Control technique Proxy . Today we're taking a look at the traces that ReGeorg leaves in web server access logs. ReGeorg is a "thick client" webshell that enables an adversary to create a SOCKS proxy via a .php, .aspx or .jsp script running on the compromised webserver, this can be used to pivot to internal networks. Pictured above is the client side, it establishes the connection to the shell on a compromised server. After this connection is established an adversary can use something like proxychains to SOCKSify tools on their local machine that they want to use to access networks connected to the webserver but inaccessible from the net. Above you can see nmap run via proxychains through ReGeorg, on the left ReGeorg reports on connections, in the r

For those following along with ATT&CK this entry is about Server Software Component: Web Shell which is now a sub-technique of  T1505, specifically it is  T1505.003.   If I can avoid combing through web access logs to find stuff like webshells I'll happily dodge it, having looked at the log artefacts left by a number of popular public domain webshells I've found a couple of easy detections based around Windows Event Log (WinEventLog). We're looking at webshells like "Con7ext", variants of "WSO" and "Alfa Shell": Specifically we are looking at the parts of the webshell that provide basic reconnaissance as to server components and functionality: How is the webshell checking if perl, python or wget are installed? In a rather noisy way that we can definitely hunt for: For IIS and a PHP shell the Splunk SPL to search for this looks something like: index=win10 sourcetype="WinEventLog:Security" EventCode=4688 Account_Name=IUSR Creator_P

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