My teammate @mgreen27 put together a new Velociraptor artifact to "inventory PHP installations on Windows, Linux and macOS for remediation scoping. Collect package versions, common binary/module paths and running PHP processes." docs.velociraptor.app/exchan… This might come in handy in the upcoming days 🙈

Python 3.15 (the final release is currently scheduled for October 9, 2026) introduces .start files as a structured replacement for executable import lines in .pth files. A .start file in site-packages references a package.module:callable. Python imports the module and invokes the callable during interpreter startup, before the user-supplied Python code runs. From a DFIR perspective, this creates another startup artifact worth checking when investigating unexpected Python execution or persistence. A wrote a short blog post about it, with an example showcasing the technique: dfir.ch/posts/today_i_learne…

“Crucially, this service is configured with Before=sysinit[].target, ensuring the rootkit executes on every system boot prior to the initialization of any security tooling.” [1] This is an interesting approach, but it may be worded too generically. With DefaultDependencies=no and Before=sysinit[.]target, the malicious systemd unit is deliberately moved into very early userspace initialization. That can matter from a detection perspective: if an EDR only attaches its eBPF programs, kprobes, tracepoints, or other telemetry after its userspace service starts, the rootkit may already have loaded and established its hooks by then. But "before any security tooling" is too absolute IMO. In the analyzed unit (see blog post from TALOS), the rootkit is explicitly stating "After=systemd-modules-load.service", so kernel modules loaded through the normal early boot path may already be resident. The rootkit is using insmod to load the malicious module, and the module itself resides on disk. Plus, after loading, you face various rootkit detection techniques. Loading it before any EDR / security tooling might be the easier part of the whole "stealth" journey. [1] blog.talosintelligence.com/u…

I published a short field note about TrickDump, and how we encountered this technique in a recent engagement: dfir.ch/posts/field_notes_tr…

My colleague @mgreen27 published velociraptor-skills, a set of reusable AI skills for DFIR with Velociraptor. These skills guide artifact selection, collection, hunting, analysis, and context management. They use a shared Python harness, vraptor, through a command-line interface rather than an MCP server or individual AI tools. The goal of using a separate harness is to optimize token use, control performance, and standardize the format of generated analysis notes. Read the full blog post here: labs.infoguard.ch/posts/ai_a…

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…