MSSQL is still a thingTheDFIRReport recently posted an article regarding BlueSky ransomware being deployed following MSSQL being brute forced.
I'm always interested in things like this because it's possible that the author will provide clear observables so that folks can consider the information in light of their infrastructure, and write EDR detections, or create filter rules for DFIR work, etc.
LNK FilesTheDFIRSpot had an interesting write-up on using LNK files in your investigations, largely from the perspective of determining what a user or threat actor may have done or accessed while logged in via the Windows Explorer shell.
Lining up creation and last modification times of shortcuts/LNK files in the account's Recent folder can provide insight into what might have occurred.
Again, keep in mind that for this to work, for the LNK files to be present, access was obtained via the shell.
If that's the case, then you're likely going to also want to look at the automatic JumpLists, as they will provide similar information, and LNK files in the Recent folder, and the RecentDocs and shellbags keys for the account can provide a great deal of insight into, and validation of activity.
Understanding default constellations, as part of a base software load is imperative, as is having a process to build out that constellation based on additional installed software.
Something to keep in mind is that access via the shell has some advantages for the threat actor, one being that using GUI tools means that EDR is blind to most activity.
EDR tools are great at recording process creation events, for example, but when the process already exists, what happens via the process that does not involve cmd.
Exe, PowerShell, WSL, or WSA may not be visible to EDR. Yes, some EDR frameworks also monitor network connections, as well as Registry and file system modifications, but by necessity, those are often filtered.
When a GUI tool is opened, EDR based on process creation events is largely blind to activity that occurs via drop-down boxes, check boxes, text fields, and buttons being pushed.
We can assume that the 4-digit number listed in the minidump file path was the process ID, but the creation of that process was beyond the data retention window, so we weren't able to verify which process the threat actor targeted for the memory dump.
Malware Write-upsMalware and threat actor write-ups need to include clear observables so that analysts can implement them, whether they're doing DFIR work, threat hunting, or working on writing detections.
Exe commands meant to change the wallpaper to the ransom note, many of which are duplicates.
As Simone says, these are commands that the ransomware would execute...these commands are embedded in the executable itself; this is something we see with RaaS offerings, where commands for disabling services and the ability to recover the system are embedded within the EXE itself.
In 2020, a sample of the Sodinokibi ransomware contained 156 unique commands, just for shutting off various Windows services.
If your EDR tech allows for monitoring the Registry and disabling processes at the endpoint, this may be a good option to enable automated response rules.
Otherwise, detecting these processes can lead to isolating endpoints, or the values themselves can be used for threat hunting across the enterprise.
Something else that's interesting about the listing is that the first two entries are misspelled; since the key path doesn't exist by default, the command will fail.
This misspelling provides an opportunity for a high fidelity threat hunt across EDR telemetry.
This Cyber News was published on windowsir.blogspot.com. Publication date: Mon, 18 Dec 2023 14:28:05 +0000