This GPO-based “ransomware without ransomware” technique is pretty cool: abuse trusted Group Policy to deliver the impact, without ever dropping an encryptor on Windows endpoints. But there is something slightly amusing about framing “traditional ransomware detection wouldn’t catch this” as the big defensive challenge. By the time an attacker has domain-admin-equivalent privileges, can create and link GPOs at the domain root, turn off the firewall domain-wide, and exfiltrate data, there have likely been plenty of opportunities to detect them before the ransom wallpaper appears. Not detecting the ransomware binary isn't the same as not detecting the attack. 🙂 securelist.com/tr/payload-ra…

MacSync's iCloud Calendar trick is pretty cool. One MacSync downloader analyzed by Securelist contains a URL such as: https://caldav.icloud[.]com/published/... It retrieves a public .ics calendar, creates an anonymous pipe, launches zsh -s, sets the pipe as stdin, and feeds the calendar into it line by line. Most of the iCalendar content is obviously not valid shell syntax, so zsh simply produces errors as it works through it. Eventually, however, it reaches attacker-controlled shell commands embedded after the DESCRIPTION: field, and executes them. Those commands then download the next stage, again from iCloud. So, effectively, a public iCloud Calendar is being used as a trusted-hosted shell-script carrier. icloud[.]com is already listed by the Living Off Trusted Sites (LOTS) Project for malicious downloads and exfiltration, but not, as far as I can see, for this particular technique. Definitely something to watch for. Source: securelist.com/macsync-new-v…

As mentioned in yesterday’s post, several users downloaded a malicious installer that ultimately executed ChainScript. Part of the Hands-On Recon chain involved taking screenshots using PowerShell. The screenshot below shows the relevant code. This becomes particularly interesting from a detection perspective when PowerShell logging is enabled, and the resulting events are collected centrally. As is often the case, Elastic already has a detection rule covering this technique. It looks for PowerShell content containing: CopyFromScreen AND ("System.Drawing.Bitmap" OR "Drawing.Bitmap") A nice example of how relatively simple PowerShell Script Block Logging can expose attacker collection activity. Source: github.com/elastic/detection…

Recently, we responded to a single-host infection that our SOC handed over to us. The user downloaded a malicious "Remote Desktop Connection Manager" - well, actually, a legitimate tool developed by Microsoft- but attackers were now misusing the brand. See the first screenshot, where the user followed a classical malvertising, landing on the site in the second screenshot. After downloading and running the installer (leading to an infection), the attackers had full access to the infected device (and leveraged that access to take screenshots via PowerShell (more on that on another tweet) and use SSH to pivot to the internal network). The RAT was ChainScript, as nicely depicted here. [1] As soon as we took over this case, we began hunting inside the network for traces of lateral movement and/or similar techniques (TTPs, IOCs). Additionally, we found 3 additional infected computers with the same malware, with infections occurring in a short time span.. which was like.. what happened here? It turns out the devices belonged to employees on the same team, and the employee who had the first infection pasted the malicious link in a Teams Chat, encouraging the rest of the team to install the same software from the same malicious site (d'oh). So the saying could not be truer: Trust, but verify. Always download trusted software from legitimate sites; as this example shows, an infection (infections!) can happen within minutes. [1] blackpointcyber.com/blog/cha…

For the love of the (macOS) game. My new blog post covers a macOS DFIR blind spot: zsh startup files such as .zshrc, .zprofile, and .zshenv can have compiled .zwc counterparts. If the compiled file is newer, zsh may use it instead of the plaintext version, meaning investigators could inspect a benign-looking .zshrc while missing the code that was actually executed. .zwc files are not encrypted, and much of their logic, strings, commands, and control flow can still be recovered. The post demonstrates practical triage with zcompile -t and strings, introduces a static zwc-decompile parser for reconstructing compiled shell logic without executing it, and notes that several common macOS forensic tools do not explicitly collect these compiled startup files. The full blog post here: dfir.ch/posts/compiled_zsh/

What I learned today: auto_prepend_file auto_prepend_file is a standard PHP configuration directive. It names a file that PHP parses automatically before the script that was actually requested. Point it at a payload, and that payload executes on every single PHP request to the site. .user.ini is how that directive gets set without server access. When PHP runs as FastCGI or PHP-FPM, which is the normal configuration on modern shared and cPanel hosting, PHP reads a per-directory .user.ini file that any account with file-write access can create. No root, no control-panel login, and no server configuration change is required. Write access to the web directory is enough, which is precisely what we encountered on a recent Incident Response engagement. But a .user.ini file does not automatically mean your server is compromised. In our case, we identified several such files in different directories. However, when you find a .user.ini with the content "auto_prepend_file = hpzgadna.php" (spot the random filename?), then you might want to have a closer look. More information here: wpserverguard.com/guides/use…

On a recent Incident response case, we encountered VMkatz. "It extracts Windows secrets - NTLM hashes, DPAPI master keys, Kerberos tickets, cached domain credentials, LSA secrets, NTDS.dit, BitLocker keys - directly from VM memory snapshots and virtual disks, on the NAS, the hypervisor, wherever the VM files are." [1] Defender detected it with the following signature: VirTool:Win64/Vekesz.A The out-of-the-box release from the GitHub page is also heavily flagged, but one could compile (and obfuscate) the code to stay under the radar. In our case, the attacker just disabled real-time monitoring and added an exclusion: Set-MpPreference -DisableRealtimeMonitoring $true Add-MpPreference -ExclusionPath "C:\" And then pointing it to a directory, "and let it find everything", as pointed out in the documentation. ./vmkatz.exe C:\ClusterStorage\CSV01\node-002\ I think monitoring for AV alerts (and exclusions!) could go a long way. The basics make the difference. ☝️ [1] github.com/nikaiw/VMkatz

Very cool research from my team colleague Evgen Blohm 💪 He uncovered an espionage campaign dubbed Iranopasmigirim, active in June 2026 and targeting Iranian dissidents and activists. The attackers impersonated the “Rise Iran” campaign associated with Reza Pahlavi, using politically themed PDFs and other decoys to convince victims to execute malicious LNK files. Hunting across GitHub, VirusTotal, and related infrastructure revealed multiple earlier lures and development artifacts, including ISO, XLSM, and DOCM files. Part 2 follows mid-October 💙 labs.infoguard.ch/posts/iran…

Nice. Notepad++ 8.9.8 introduced a useful security hardening feature around session restoration and UNC paths. If a Notepad++ session contains a path such as "\server\share\file.ps1", either in the automatically restored "session.xml" or in a manually loaded session file, Notepad++ no longer silently accesses that path during session loading. Instead, it warns that opening the file may cause Windows to authenticate to the remote server automatically. This is because accessing a UNC path can invoke the Windows SMB client. Depending on the environment and authentication policy, Windows may be useful for offline password cracking or, where the target environment still permits relayable NTLM authentication, NTLM relay attacks. This does not expose the plaintext password or NT hash directly, but the captured authentication material may be useful for offline password cracking or, in suitable environments, NTLM relay attacks. The new dialog allows users to skip or load the network path once, or configure Notepad++ to always skip or always load network paths referenced by sessions. Source: github.com/notepad-plus-plus…

New blog post: Living Inside the Shell: zsh Modules on macOS zsh is much more than a command interpreter. Through its module system, the shell can perform operations that defenders often associate with separate binaries: establish TCP connections, manipulate files, access extended attributes, and more. That creates an interesting detection problem. If your logic mainly looks for tools such as curl, wget, nc, xattr, or rm, or relies heavily on child-process creation, you may only detect one implementation of the behavior. In the post, I look at zsh/net/tcp, zsh/mapfile, and zsh/attr, including a second-stage script executed directly from a socket without first being written to disk. From a DFIR perspective, the interesting part is what still remains visible. Using Apple Endpoint Security telemetry, I show that avoiding the usual utility does not necessarily hide the underlying action. dfir.ch/posts/zsh_modules/

Microsoft recommends the following mitigations to reduce the impact of this threat: Block web pages from automatically running Flash plugins. 😂 Source: microsoft.com/en-us/security…

My new "field note" shows how a seemingly generic Microsoft Defender alert can lead to a much more useful forensic finding when correlated with filesystem artifacts. Defender detected Behavior:Win32/RegDump.SA, attributed to svchost.exe running as SYSTEM. Looking at the MFT around the alert timestamp revealed a suspicious temporary file (see image). Its "regf" header identified it as a Windows Registry hive, and loading it confirmed that it contained a partial SAM hive. Impacket’s RemoteOperations implementation creates temporary hive files using eight random ASCII characters followed by .tmp. This makes the artifact highly consistent with an Impacket-style secretsdump workflow. Correlating the alert timestamp with MFT activity can expose the underlying attacker technique, or at least hint you in the right direction. Full article here: dfir.ch/posts/field_notes_av…

In a recent incident, we stumbled upon two suspicious drivers created during the compromise window and installed as services. ☝️ One thing I always check during an investigation: newly created services. The System event log, Event ID 7045, is your friend here. Looking at the files, it was immediately obvious that they had Alternate Data Streams (ADS) attached, as shown in the screenshot. Luckily, thanks to our colleagues at Check Point Research, we didn’t have to do all the heavy lifting ourselves. The ADS contained an encrypted binary structure that the driver used as configuration input. The driver itself can be abused to remove defensive technologies from the affected host. The research behind this technique is super interesting. If you have some time over the weekend, give it a read: research.checkpoint.com/2026…

Someone at BSides Frankfurt asked me this week if I could share the slides from my talk. Of course - and not just those. 🙂 All my conference presentations are available here: github.com/malmoeb/presentat…

If you're at @bsidesTLL, come join our anti-forensics workshop. I'm offering a 4-hour hands-on training session packed with lessons from years of incident-response work. Techniques you can apply directly in your own investigations.

After a fantastic first session at BruCON Spring Training earlier this year, we’re very happy to teach our Anti-Forensics course again - this time at DeepSec in Vienna. It’s been a busy year with plenty of interesting cases, and many of the lessons learned have been incorporated into new slides and practical examples. We’ve also significantly expanded the macOS anti-forensics section. Really looking forward to teaching this one again - and to a full classroom! :) More information here: deepsec.net/schedule.html

After a bit of tinkering, I was able to replicate the Google Docs attack vector described in the Huntress blog post [1] Attackers can use Google’s “App Scripts” feature (in Docs) to create a clever pretext. Essentially, the attack works as follows: The attacker sent the victim a legitimate Google Docs link that appeared to be a partially encrypted conference/planning document. Embedded in the document was a Google Apps Script that displayed its own HTML sidebar (DecryptPanel.html). This sidebar mimicked a “Document Decryption” feature and awaited an “Access Key” sent separately by the attacker. The decryption was designed to fail intentionally. After entering the supposedly correct key, the Apps Script interface displayed a fake error message and then offered repair/update steps (your classic Click Fix steps). What’s particularly interesting about this vector is that the victim remains entirely on docs.google.com throughout the process. This makes the process appear significantly more trustworthy than a classic phishing page on a third-party domain. Definitely something to look out for. [1] huntress.com/blog/defcon-phi…

And here is the second part of the Cleartext Password Series: dfir.ch/posts/fantastic_pass…

In a recent ISC SANS Diary, @xme 🇧🇪 discussed a malicious ZIP archive that led to Remcos, a pretty common RAT. As Xavier noted, "Most of the files used in this infection path remain undetected by most AVs." [1] PowerShell, AppData, Dynamic DNS, and Run Key as a persistence mechanism. Four of the eight areas I covered in my first blog post, N-IOCs to Rule Them All [2]. The information presented remains relevant, and finding such infections is not as hard as it sounds, even if they might bypass AV rules and signatures. [1] isc.sans.edu/diary/From+a+VH… [2] dfir.ch/posts/n-iocs/