blue tangle

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!

I've purchased the domain bluetangle.dev and renamed this blog. I really like the imagery of a blue fishing net undergoing constant repair, thinking about the blue team and how hard we struggle to stop things slipping by us. In terms of content, I'll still be poking around at red team and hacker tools and thinking about detections and threat hunts as I go. Here is some DALL-E art to commemorate the change. Back to regular updates soon.

    Time for part 2 of a few blogposts on threat actors disabling Windows updates. We covered why in the last post along with how, this time around we will be mostly focusing on detections.   We aren't just detecting disabled Windows updates though, we're detecting the steps required to actually delete and remove installed updates. First we look at usage of the Windows native binary takeown , which enables an administrator to recover access to files that was previously denied.   In this case we are looking at takeown grabbing access of folders relating to Windows updates Our Splunk search looks like this:   index=winlogs EventCode=4688  Process_Command_Line IN ("*\Windows 10 install\*", "*\Windows10Upgrade\*")  New_Process_Name="*\\takeown. exe" | 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 Account_Name ComputerName  | c

  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