blue tangle

  Raspberry Robin aka "QNAP Worm" is a suspected pay-per-install malware botnet linked to threat actor DEV-0856. Raspberry Robin spreads through infected USB, users click a .lnk file on the USB and from there msiexec.exe grabs a remotely hosted .msi file and quietly installs it, which is the next stage of the Raspberry Robin payload. One of the interesting things about Raspberry Robin is that it uses a very distinctive, low effort, form of command line obfuscation, mixed case (or "alternating caps"). You can see what that looks like below, from what looks like a Defender detection in the attached screenshot.     I wanted to come up with a way to detect mixed case obfuscation in Splunk, you can see what I came up with below:   index=winlogs EventCode=4688 Creator_Process_Name=*\\cmd. exe | rex field=Process_Command_Line max_match=0 "(?<upper>[A-Z])" | rex field=Process_Command_Line max_match=0 "(?<lower>[a-z])" | eval count_upper=m

    I'm very aware that in infosec we tend to be like magpies, distracted by new and shiny objects while sometimes underestimating the impact of the boring tried and true techniques that hackers use day in and day out because they just work. Having said that, I'm only human and when I see something I haven't seen before it piques my curiosity. That was the case with this tweet by Jazi , a Fortinet threat intel researcher, talking about a Darkbit payload. Before we get into the content of that tweet though let's have a quick look at Darkbit, as there are so many ransomware groups now, and the smaller ones can start to blur together as there are only so many adjectives that they seem to favour.   Darkbit are not a very active ransomware group, from what I can tell they have had one high profile victim, the Technion - Israel Institute of Technology. The group heavily implies that they are a disgruntled former tech worker, the further implication is that they may have work

    I wrote a Sigma rule for security/hacking tool Seatbelt, you can find it below.

  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

  Quick blog entry on detections for the Ghostpack discovery/reconnaissance tool Seatbelt . This entry will focus on looking at command line parameters that can be caught even if the executable itself is renamed, if I have time we can delve into other event log artefacts another time. From the Seatbelt github repo: Seatbelt is a C# project that performs a number of security oriented host-survey "safety checks" relevant from both offensive and defensive security perspectives. So essentially what the tool does is retrieve local system information that might have security or safety implications. In terms of commands that can be tacked on to Seatbelt there are a literal ton of options. But what we are going to focus on here are the command groups, which break the many, many available commands down into categories, so we have: All, User, System, Slack, Chromium, Remote, Misc. The groups above are invoked like this, if you wanted to run all checks: Seatbelt.exe -group=all And so

  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

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

    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