I have tracked this proposal through two previous cycles, its withdrawal after public opposition in late 2025 and the shift toward normalized scanning I flagged in December. The pattern I described then, temporary derogations quietly becoming permanent baseline, has now played out almost exactly as predicted, just with an unexpected twist on encrypted messaging.

In brief

• Chat Control 1.0, the voluntary CSAM-scanning derogation from the ePrivacy Directive, expired on April 3, 2026 after Parliament rejected its extension in March by 311 votes to 228.
• The Council adopted a first-reading position on July 2 reinstating the derogation unchanged through April 2028.
• Parliament voted on July 9 under emergency procedure; a rejection motion got more no votes (314) than yes votes (276) but missed the 361-vote absolute majority required in second reading, so the extension stands.
• An amendment adopted the same day excludes communications protected by end-to-end encryption from the scope of voluntary scanning, meaning WhatsApp, Signal, and Telegram are formally out of Chat Control 1.0’s reach.
• This exclusion applies only to the voluntary derogation track. The permanent CSA Regulation (Chat Control 2.0), still in trilogue, remains the venue where client-side scanning obligations could still be imposed on encrypted services.
• The Council now has three months to accept Parliament’s amendments; disagreement triggers a conciliation committee, while CSAR negotiations resume in September.

The procedural mechanic nobody explains clearly

Second-reading procedure under the ordinary legislative procedure (Article 294 TFEU) is where this vote’s outcome actually lives. When the Council adopts a position at first reading, Parliament can approve it, amend it, or reject it outright. Rejecting a Council position outright at second reading requires an absolute majority of Parliament’s component members, currently 361 votes out of 720, not a simple majority of votes cast in the chamber that day.

This is structurally different from a first-reading vote, where a simple majority of votes cast decides the outcome. It means abstentions and absences function, in practice, as votes in favor of whatever the Council already adopted. The rejection motion on July 9 secured 314 votes, comfortably more than the 276 in favor, and still failed by 47 votes against the threshold. MEPs fail to prevent Chat Control snoopfest revival put it plainly:

“Chat Control expired on April 3, 2026, after first being introduced in August 2021. Today, however, MEPs did not reach the required threshold to reject it.”

Anyone assessing the political durability of Chat Control needs to internalize this asymmetry. A proposal that cannot secure a straightforward parliamentary majority in its favor can still survive indefinitely as long as opposition cannot clear the higher bar required to kill a Council position outright. This is precisely the “zombie proposal” dynamic that outlets covering the file since 2022 have repeatedly noted, and the July 9 vote is the clearest procedural demonstration of it to date.

The end-to-end encryption carve-out and its limitations

The same session that failed to reject the Council’s text adopted an amendment explicitly excluding end-to-end encrypted communications from the scope of the voluntary scanning regime. As Euronews reported:

“A law allowing scanning of online communications to detect child sexual abuse material was amended by MEPs to protect users’ privacy.”

Practically, this means providers operating under E2E protocols, WhatsApp’s Signal Protocol implementation, Signal itself, Telegram’s Secret Chats, are outside the scope of the derogation Parliament just extended. That is a genuine, specific boundary, and it directly addresses the architectural concern I raised in December about client-side scanning turning “the user’s phone into a checkpoint.” If a service cannot access plaintext content to begin with, the voluntary scanning regime cannot compel it to scan.

But the boundary is narrower than the headlines suggest, for two reasons that matter to anyone doing compliance or threat-modeling work around this file:

• The exclusion applies to Chat Control 1.0 only. It is an amendment to the ePrivacy derogation, a voluntary, time-limited legal basis for providers who already scan certain content categories (typically metadata and non-E2E services like some cloud storage and unencrypted chat platforms). It does not touch the CSA Regulation still in trilogue.
• CSAR (Chat Control 2.0) is where detection orders live. The permanent regulation under negotiation would introduce mandatory detection orders that courts or authorities could issue against specific services, including, in earlier drafts, an obligation for E2E providers to implement client-side scanning to comply. That mechanism has not been foreclosed by this week’s vote. The trilogue resumes in September, and the encryption carve-out achieved in the derogation vote creates political pressure but no legal precedent binding the CSAR negotiators.

The distinction between these two tracks is the single most consequential technical detail in the entire file, and it is the one most general-audience coverage collapses into a single “Chat Control” narrative. Anyone advising a messaging provider, a CISO at a company running an E2E product, or a policy team tracking exposure needs to treat Chat Control 1.0’s encryption exclusion as a favorable signal, not as closure.

Where the CSAR negotiation actually stands

The permanent regulation has followed its own separate, slower track throughout 2026. Trilogue negotiations between Parliament, Council, and Commission resumed on June 29, running in parallel with the derogation fight that dominated headlines. Double threat to privacy: Chat Control 1.0 and 2.0 are back captured the structural risk of treating these as one fight:

“In March, the European Parliament rejected the extension of the so-called Chat Control 1.0 regulation, which expired in April 2026…”

The risk for observers, and for organizations building compliance timelines, is conflating the derogation’s fate with CSAR’s. A win on one track changes nothing about the substantive obligations still being negotiated on the other. The current CSAR compromise text under discussion reportedly narrows mandatory detection orders to known CSAM hash-matching rather than open-ended AI classification of new content, a meaningful technical distinction from earlier 2022-2023 drafts that proposed broader machine-learning based detection. Whether that narrowing survives the next round of trilogue, expected to conclude discussions by late autumn, is the actual decision point that will determine whether client-side scanning becomes a legal requirement for E2E services operating in the EU.

What happens next

The Council has three months from the July 9 vote to formally respond to Parliament’s amendments, including the encryption exclusion. Two outcomes are procedurally available:

1. The Council accepts Parliament’s amended text as-is, in which case the derogation, encryption exclusion included, enters into force through April 2028 without further negotiation.
2. The Council rejects or modifies the amendments, triggering a conciliation committee under Article 294(10) TFEU, composed of equal numbers of MEPs and Council representatives, tasked with reaching a joint text within six weeks, extendable by two.

Given that several member states have historically pushed for broader scanning mandates than Parliament has been willing to accept, a conciliation committee is a realistic scenario, not a formality. Meanwhile, CSAR trilogue continues independently, with the next substantive session expected in September. Any organization building a compliance roadmap around this file should treat Q4 2026 as the actual decision window for the regulation that matters most, not this month’s derogation vote, however dramatic its procedural mechanics turned out to be.

FAQ

What is the difference between Chat Control 1.0 and Chat Control 2.0? Chat Control 1.0 is the temporary ePrivacy derogation that lets providers voluntarily scan communications for CSAM, now extended to 2028, while Chat Control 2.0 refers to the permanent CSA Regulation still in trilogue, which would mandate detection orders and potentially client-side scanning as a legal obligation rather than a voluntary derogation.

Does excluding end-to-end encrypted messages from Chat Control 1.0 mean WhatsApp and Signal are now safe? Only from the voluntary scanning regime just extended. The permanent CSAR still under negotiation could reintroduce detection obligations covering encrypted services through client-side scanning, so the exclusion is a tactical win in one legislative track, not a resolution of the underlying architecture debate.

Why did Chat Control pass despite more MEPs voting against it than for it? Under the second-reading procedure, a motion to reject a Council position needs an absolute majority of all Parliament seats (361 votes), not just a simple majority of votes cast; the rejection motion got 314 votes against 276, more no votes than yes votes, but fell short of the 361 threshold, so the Council’s text stood.

The Master File Table, the USN Journal, and the $LogFile each capture a different dimension of file system activity, at a different granularity and with different retention characteristics. When an analyst knows how to correlate all three, the story they tell is significantly harder to fully suppress than anything a single log or a timestamp suggests.

This article walks through that structure in practical terms: what each artefact contains, how to extract it, and where the intersections between them are most useful for investigations.

In brief

• NTFS stores file metadata in at least two independent locations per file: $STANDARD_INFORMATION and $FILE_NAME inside the MFT. Attackers can modify one but not both through standard APIs.
• The USN Journal logs every file system change event sequentially, survives file deletion, and typically retains approximately 20 days of activity on an active volume.
• The $LogFile is a low-level transaction log that records redo/undo operations on NTFS metadata, providing independent evidence of when attributes were last written.
• dfir_ntfs and MFTECmd are complementary tools: one gives you programmatic access to raw NTFS structures; the other gives you analyst-ready CSV output for timeline correlation.
• File carving remains useful when MFT metadata is corrupted or missing, but it is best treated as a last resort.
• Correlating all three artefact layers produces a more robust timeline than any single source can provide.

The structure underneath the filesystem

Before getting into tooling, it helps to have a clear model of what NTFS actually stores about a file, because the forensic value of these artefacts only becomes obvious once you understand the redundancy involved.

Every file on an NTFS volume has at least one entry in the Master File Table, or $MFT (earlier overview). Each MFT entry is 1024 bytes and contains, among other things, two distinct sets of timestamps. The first set lives in the $STANDARD_INFORMATION attribute: the four MACB timestamps (Modified, Accessed, Created, $MFT entry modified) that most tools and the Windows Explorer interface expose. The second set lives in the $FILE_NAME attribute, which the NTFS kernel driver writes when the file is created and updates under a narrower set of circumstances. The critical forensic implication is that $FILE_NAME timestamps are written by the kernel and cannot be modified through standard Win32 APIs like SetFileTime. Most timestomping tools only reach $STANDARD_INFORMATION.

That asymmetry is the most reliable single indicator of timestamp manipulation available in NTFS forensics. A file where $STANDARD_INFORMATION Born is earlier than $FILE_NAME Born is, under normal filesystem operation, an impossibility. The kernel copies $SI values from $FN at creation time; any later backdating of $SI will diverge from the kernel-written $FN values. When you see that divergence, you are reading a contradiction in the metadata record, not making an inference.

The MFT also stores the file’s logical size, physical allocation, attribute list, and, for small files (typically under around 700 bytes), the file content itself as a resident attribute inside the MFT entry. This matters for carving: deleting a resident file does not free any cluster, it just marks the MFT entry as available for reuse. The content survives until the entry is overwritten.

USN Journal: the filesystem’s event stream

The USN Journal (\$Extend\$UsnJrnl) is an NTFS feature that has been available since Windows 2000 (dedicated post) and is enabled by default on modern Windows systems. Its primary stream, $J, records a sequential log of every file system change on the volume: file creates, renames, deletes, attribute changes, security descriptor updates, and more. Each record contains a 64-bit USN identifier, the filename, a parent MFT reference, a reason code bitmask (for example, USN_REASON_FILE_CREATE, USN_REASON_RENAME_OLD_NAME, USN_REASON_BASIC_INFO_CHANGE), and a timestamp.

The $MAX alternate data stream stores metadata about the journal itself, including the configured maximum size, which controls how far back the journal extends. On an active volume, this typically covers approximately 20 days of activity, though heavily active systems may retain significantly less. You can inspect this on a live system: fsutil usn queryjournal C:

For DFIR purposes, the USN Journal is valuable because it tracks changes rather than static file states. A file that has been deleted, timestomped, or renamed still leaves records behind. Consider the case of a tool deployed by an attacker that was later cleaned up with SDelete or a similar secure deletion utility. SDelete’s characteristic behaviour is to rename the target file multiple times before deleting it (AAA.AAA, BBB.BBB, and so on), then issue the delete. Each rename operation generates a RENAME_OLD_NAME and RENAME_NEW_NAME record in the USN Journal, producing a distinctive signature that survives the deletion itself.

The timestomping detection case is equally clean. A USN_REASON_BASIC_INFO_CHANGE record at a specific timestamp, correlated with the $SI/$FN discrepancy in the MFT, gives you two independent sources converging on the same event. Adding a Prefetch file for the timestomping binary, if it executed, gives you a third.

To extract the $J stream from a forensic image, you need to bypass the filesystem layer, since Windows will not give you direct access to NTFS metadata files through normal file operations. Two approaches work well in practice.

Using MFTECmd (Eric Zimmerman’s tool): MFTECmd.exe -f “E:\Evidence$J” –csv C:\output\ –csvf usn.csv

The resulting CSV includes UpdateTimestamp, Name, FileAttributes, UpdateReasons, ParentEntryNumber, and ParentSequenceNumber. To reconstruct full paths, you need to parse the $MFT alongside it and join on the parent MFT entry number: MFTECmd.exe -f “E:\Evidence$MFT” –csv C:\output\ –csvf mft.csv

Load both in Timeline Explorer and join on ParentEntryNumber. From there, filtering on USN_REASON_FILE_DELETE within your incident window, or looking for FILE_CREATE followed by FILE_DELETE within 60 seconds, covers a large fraction of malicious tool deployment and cleanup patterns.

dfir_ntfs: going below the surface

dfir_ntfs, the Python library developed by Maxim Suhanov (original post), targets a different use case than MFTECmd. Where MFTECmd is optimised for analyst-facing CSV output, dfir_ntfs is a programmatic interface to raw NTFS internals. It parses $MFT, $UsnJrnl:$J, and $LogFile directly, can work against volume images and volume shadow copies, and exposes the underlying structures in Python objects rather than spreadsheet rows.

Installation is straightforward:

pip3 install https://github.com/msuhanov/dfir_ntfs/archive/1.1.19.tar.gz

A minimal MFT parsing session:

import dfir_ntfs.MFT as MFT

with open('$MFT', 'rb') as mft_file:
    mft = MFT.MasterFileTableParser(mft_file)
    for file_record in mft.file_records(True):
        if not file_record.is_in_use():
            continue
        si = file_record.get_standard_information()
        fn = file_record.get_file_name()
        if si and fn:
            si_created = si.get_created_time()
            fn_created = fn.get_created_time()
            if si_created and fn_created:
                if si_created < fn_created:
                    print(f"[TIMESTOMP] {fn.get_file_name()} SI:{si_created} FN:{fn_created}")

That pattern, scanning for MFT entries where $SI Born is earlier than $FN Born, is one of the fastest automated timestomping detection passes you can run on a raw image. The NTFS driver cannot produce that condition under normal operation, so false positives are rare and usually traceable to known edge cases (volume cloning, VSS interactions) rather than attacker activity.

The library also provides access to volume shadow copies, which is where many investigations recover artefacts that an attacker deleted after gaining access but before VSS snapshots were removed. From a shadow copy, you can extract a $MFT state from an earlier point in time and compare it against the live MFT to identify entries that have been deleted or modified in between.

The third layer: $LogFile and what it tells you

The $LogFile is the NTFS transaction journal, a structure designed primarily to ensure filesystem consistency across crashes. It is also an independent source of metadata write events that most analysts overlook entirely.

$LogFile records redo and undo operations for NTFS metadata updates, including attribute changes, in terms of Log Sequence Numbers (LSNs). Each MFT entry carries the LSN of the most recent transaction that modified it. When you find a suspicious timestamp in $STANDARD_INFORMATION and want to independently confirm when it was last written, the corresponding $LogFile entry for that LSN gives you an out-of-band timestamp for the transaction itself.

Practical extraction is straightforward with NTFS Log Tracker (available at ForensicNote) or through dfir_ntfs’ LogFile.py module. In Timeline Explorer, loading both the MFT CSV and the $LogFile CSV and cross-referencing by LSN gives you a three-source timeline per file:

1. $FILE_NAME Born: kernel-written, reliable, rarely tampered with.
2. $STANDARD_INFORMATION timestamps: the attacker-facing values, modified by timestomping tools.
3. $LogFile LSN timestamp: when the NTFS driver last wrote the $SI attribute, independent of the value it wrote.

When all three converge, you have a solid story. When $LogFile shows a write to $STANDARD_INFORMATION at a time inconsistent with the $SI value itself, you have direct evidence of manipulation, not just an anomaly.

File carving: a fallback with limitations

Once you have exhausted MFT, USN Journal, and $LogFile analysis, file carving is what you turn to when filesystem metadata is genuinely gone, either because the attacker went after NTFS structures directly (as modern wipers like HermeticWiper and CaddyWiper do), or because the MFT entry was reallocated before the investigation started.

I covered carving techniques in more detail in Some thoughts about file carving. Basic carving works on header and footer signatures (magic numbers): %PDF / %EOF for PDF files, 0xFFD8 / 0xFFD9 for JPEG, CA FE BA BE for Java class files, and so on. The Gary Kessler signature list remains the reference here. Basic carving assumes the file is not fragmented and the beginning of the file is not overwritten.

Advanced carving handles fragmented files, where fragments may be non-sequential or have gaps. It relies on content analysis rather than just header/footer matching, which is computationally expensive but necessary for email archives, database files, or anything that grows over time.

The practical limitation is that carving produces no provenance. A recovered file has no MFT entry, no USN Journal record, no chain of custody in the filesystem sense. It exists as bytes. What it tells you about when something happened, or who performed an action, depends entirely on internal file metadata (EXIF data, document properties, embedded timestamps) rather than filesystem artefacts. For court purposes, and for timeline reconstruction, that is a meaningful limitation.

When the MFT entry survives but the file is marked as deleted, you can frequently recover both the file and its metadata. The MFT entry still contains the file’s timestamps, size, and allocation. In that case, you are accessing a deleted but intact record rather than carving from raw fragments, and the forensic value is substantially higher.

Putting it together: a practical investigation workflow

The standard starting point is always the $MFT, because it is the index to everything else. Extract it first, parse it with MFTECmd, and load the output in Timeline Explorer. At that stage you have a complete list of files the filesystem knows about, including deleted entries whose MFT records have not yet been reused.

From there, the sequence depends on what you find. If the incident window is clear, filter the $MFT timeline to that window and identify the files of interest. For each suspicious file, pull the USN Journal records for the corresponding MFT entry number and check whether the timestamps are consistent. Any USN_REASON_BASIC_INFO_CHANGE event at a time that does not match the $SI timestamps is an immediate red flag.

For files where you suspect timestomping specifically, compare $SI and $FN timestamps directly. A divergence greater than a few seconds, or a $SI Born earlier than $FN Born, warrants $LogFile analysis to confirm when the $SI attribute was last written.

If you are working with dfir_ntfs in a scripted pipeline, the library gives you the tools to automate all of this across an entire image: iterate MFT records, flag $SI/$FN discrepancies, cross-reference against USN Journal records for the same entry number, and export findings to a structured format for timeline import. For large-scale triage across multiple machines, that scripted approach scales better than loading individual CSVs in a GUI tool.

Volume shadow copies are worth checking before you conclude that deleted artefacts are unrecoverable. dfir_ntfs handles VSS parsing natively, and comparing the MFT state across shadow copy snapshots can surface files that were present at a known point in time and subsequently removed.

The NTFS artefact layer is not indestructible. As the evolution of disk wipers shows, modern destructive malware increasingly attacks NTFS metadata structures directly, and a sufficiently thorough wiper can corrupt or destroy the $MFT, $UsnJrnl, and $LogFile before a response team arrives. In those cases, carving is genuinely what remains. But that scenario is the exception rather than the rule. In most investigations, the NTFS layer is intact, the attacker assumed that deleting files and clearing event logs was sufficient, and the three-source correlation described here recovers considerably more than the attacker intended to leave behind.

FAQ

What is the USN Journal and why does it matter in DFIR?

The USN Journal is an NTFS change-log that records every file system event, including creations, renames, deletions, and metadata changes. It persists even after files are deleted, making it essential for timeline reconstruction and detection of anti-forensic techniques like timestomping.

How do you detect timestomping using NTFS artefacts?

By comparing the $STANDARD_INFORMATION and $FILE_NAME timestamp attributes in the MFT. If $STANDARD_INFORMATION timestamps predate $FILE_NAME timestamps for the same file, the kernel-written timestamps have been tampered with. The USN Journal and $LogFile provide independent corroboration of when the manipulation actually occurred.

What is dfir_ntfs and how does it differ from MFTECmd?

dfir_ntfs is a Python library by Maxim Suhanov that parses $MFT, $UsnJrnl, $LogFile, volume images, and shadow copies, exposing raw NTFS internals programmatically. MFTECmd is a Windows GUI/CLI tool that produces analyst-ready CSV output for Timeline Explorer. They are complementary rather than competing tools.

I have been in enough rooms, and enough organisations, to notice that this story has a loose relationship with how organisations actually function. The companies that do not implode, that pay their invoices on time, that do not require emergency all-hands meetings because a key person walked out, are sustained by ordinary people doing ordinary things, reliably, across thousands of working days — not by exceptional people doing exceptional things.

This is not a consolation prize but a more accurate description of reality than most management consultants are paid to provide.

In brief

• The performance obsession in modern workplaces is a cultural artifact rather than a management best practice.
• Most organisations run on distributed, competent mediocrity instead of the output of exceptional individuals.
• Knowing your limits is a form of professional maturity rather than a confession of inadequacy.
• A person who is average at their job may be genuinely excellent at chess, parenting, or running a ten-kilometre race. That does not make them less valuable at work.
• Chasing excellence across every dimension of life is a recipe for exhaustion rather than achievement.

The mythology of the superstar

The idea that organisations are defined by their exceptional individuals is not entirely false. Some roles genuinely require rare capability. A small number of people in any field operate at a level that is qualitatively different from their peers, and pretending otherwise would be its own kind of dishonesty. But the mythology that has grown up around this observation has become almost entirely detached from its origin.

The modern performance cult treats exceptionalism as a universal aspiration and, implicitly, a moral obligation, rather than as a statistical rarity. You are not merely expected to do your job well. You are expected to disrupt, to go above and beyond, to bring your whole self to work, to have a personal brand, to treat every quarterly review as an opportunity to demonstrate that you are on a trajectory toward something. The language of Silicon Valley talent management has colonised organisations that have no more need for “10x engineers” than a municipal waterworks has for a visionary chief evangelism officer.

What this mythology produces, in practice, is a workforce in which everyone is performing, in the theatrical sense of the word, rather than being actual high performers: staging visible indicators of exceptional output while the actual work gets done in the margins. The meetings run long. The Slack messages arrive at eleven at night. The slide deck has a growth chart. The infrastructure quietly breaks because nobody had time to maintain it.

The quiet arithmetic of ordinary people

Here is a question that is almost never asked in management literature: what is the organisational contribution of a person who is reliably present, competent, calm under pressure, and completely unspectacular?

The answer, if you work through it honestly, is enormous. It comes from what that person makes possible for everyone around them, not from any individual output alone. They do not create work for others by requiring management of their ego, their volatility, or their inexplicable decision to refactor a critical system two days before a product launch. They do not disappear into extended performance-coaching processes. Their name does not appear in tense email threads. They are, in the most underappreciated sense of the term, load-bearing.

Research on team dynamics in software engineering and related fields has consistently shown that team-level reliability depends less on the ceiling of individual performance than on the floor. A team with one exceptional engineer and three chaotic ones will lose, systematically, to a team of four solid, unremarkable engineers who communicate clearly and do not introduce surprises. The exceptional individual is real. The exceptional individual as a unit of organisational strategy is a marketing story.

The manufacturing world learned this a long time ago. Toyota’s production system, arguably the most influential management framework of the past sixty years, is built entirely on the premise that sustainable quality comes from ordinary people following well-designed processes consistently, not from heroic individuals compensating for broken systems. The Toyota insight is that a system depending on individual heroism is fragile by design — not that people do not matter.

The right size of ambition

There is a version of the argument against performance culture that I am not making. The more defensible position is that excellence is context-dependent, and the demand for it should be proportional to what is actually required.

A person who writes clear incident reports, responds to tickets in a reasonable time, does not introduce regressions, and leaves good documentation is, in a meaningful sense, excellent at their job. That person does not need to be a thought leader. They do not need to give conference talks. They do not need a “personal development plan” that involves becoming something they currently are not. They need to be left alone to continue doing what they are doing, with fair compensation and occasional acknowledgement.

More interestingly: that same person may be genuinely exceptional at something that has nothing to do with work. They might be a highly rated chess player, or an unusually good amateur musician, or a dedicated marathon runner, or the kind of parent who has the patience to actually be present. The performance cult, which evaluates the entire human through the narrow aperture of professional output, treats this as irrelevant. I think it is one of the most important facts about that person, because it tells you that human capability is a profile rather than a single variable. And profiles have peaks and troughs that have no particular obligation to align with job descriptions.

The person who is average at their job may be living a richer life than the person who has optimised their existence entirely around professional performance. This is allowed without being a failure condition.

What organisations actually need to understand

None of this is an argument for complacency, for turning up unprepared, for half-hearted effort, or for the particularly corrosive behaviour of someone who has quietly decided that they have checked out but has not bothered to tell anyone. There is a difference between competent mediocrity and careless indifference. The distinction matters.

What I am describing is the recovery of a realistic norm: that the standard professional expectation is doing your job well, without requiring extraordinary commitment beyond its scope. That this is valuable. That this is sufficient. That an organisation that cannot function unless its people are continuously operating beyond sustainable limits has a process problem rather than a talent problem.

The security awareness training parallel is instructive here. The same organisational psychology that has made annual checkbox training a substitute for actual security has made the performance review cycle a substitute for actual management. Both produce documentation. Neither produces the thing the documentation claims to measure. A culture in which every employee is being evaluated against an implicit standard of exceptional performance produces a lot of performance anxiety and a lot of visible busyness, and it tends to suppress the honest admission that something is broken until the cost of the broken thing exceeds the cost of pretending it is not.

The organisations that deal well with incidents, whether a ransomware case or a difficult quarter, are those with clear processes, good communication habits, and enough people who are sufficiently competent and sufficiently sane to execute under pressure — not the ones that had the most exceptional individual contributors. Resilience is a collective property of ordinary people in a well-structured system. It is not the shadow cast by an exceptional few.

This connects to something I noticed in thinking about DFIR team sustainability: the teams that hold together over time, that do not crater under operational pressure, are staffed by people who found a workable equilibrium between what the work demands and what a human life can sustain — not by people who gave everything and had nothing left. That equilibrium is, almost by definition, average. It is the most important thing a team can have.

If you are the person in your organisation who shows up, does the work, does not create drama, and goes home to something you actually care about: that is a reasonable life, well-lived — not a failure. The machine keeps running. The invoices get paid. Someone, somewhere, should probably say thank you.

FAQ

Is mediocrity in the workplace actually a good thing?

Mediocrity here means consistent, reliable, middle-of-the-distribution performance, not carelessness or incompetence. That kind of output sustains most organisations far more than the occasional superstar hire.

Why do companies over-invest in finding exceptional talent?

Because exceptional talent is visible, narratable, and easy to put in a slide deck. The distributed competence of a solid team is invisible until it disappears.

How does the performance obsession damage individuals?

By creating a permanent background pressure to demonstrate exceptional output across every dimension of life, which is neither realistic nor healthy. Knowing your limits is a form of self-knowledge, not failure.

According to a detailed forensic investigation by the Citizen Lab, Russian authorities used Cellebrite’s UFED (Universal Forensic Extraction Device) to break into his iPhone 12 on or around June 17, 2021, while the device was in official custody and Pivovarov was awaiting trial on politically motivated charges. The company had publicly cancelled its Russian contracts three months earlier.

In brief

• The Citizen Lab forensically confirmed that Cellebrite’s UFED was used to extract data from Pivovarov’s iPhone 12 on June 17, 2021, during official custody.
• Russia’s own MVD forensic report explicitly names Cellebrite’s UFED Physical Analyzer and UFED 4PC as the tools used in the extraction.
• Russian authorities searched the device for political contacts including Mikhail Khodorkovsky and human rights lawyer Anastasiya Burakova, suggesting the extraction may have seeded further targeting campaigns.
• Cellebrite cancelled its Russian contracts in March 2021, but the hardware continued to operate in offline mode, effectively nullifying the cancellation.
• Pivovarov’s MacBook, protected by full-disk encryption, was not successfully accessed — a concrete demonstration of why encryption matters.
• Cellebrite’s pattern across multiple countries remains reactive: it cancels contracts only after third-party exposure, and its technical architecture has historically made those cancellations easy to circumvent.

Who is Andrey Pivovarov

Pivovarov served as director of Open Russia, a non-profit organization the Russian government designated as “undesirable” in 2017, a classification the European Court of Human Rights later found incompatible with the European Convention on Human Rights. Sensing the escalating legal risk, Pivovarov dissolved the Russian branch of Open Russia on May 27, 2021. Four days later, he was arrested.

In July 2022, he was sentenced to four years in prison for “carrying out the activities of an undesirable organization” — charges that are, by any reasonable reading of international human rights law, politically motivated. He was released in August 2024 as part of a prisoner exchange. After his release, he made contact with Citizen Lab researchers at the World Liberty Congress in Berlin, and agreed to have his devices forensically examined. What they found was not a surprise, exactly, but it was documented for the first time with forensic precision.

The forensic evidence

The Citizen Lab’s analysis focused on MobileLockdown records from Pivovarov’s iPhone, specifically USB connection logs that include a Host ID, a unique identifier assigned to a Cellebrite device. The Host ID found on Pivovarov’s phone (9016926980658937761372207) was one the Citizen Lab had previously attributed to Cellebrite’s forensic hardware.

That alone would be strong evidence. But what makes this case unusual is the corroboration from an unexpected source: the Russian authorities themselves. The MVD Forensic Expert Report No. 1269-17, produced by Russia’s Forensic Expert Center of the Ministry of the Interior and provided to Pivovarov during his prosecution, explicitly confirms the use of Cellebrite’s UFED Physical Analyzer and UFED 4PC toolkit. The investigators documented extracting data from WhatsApp, Telegram, and Viber, and then searching the device contents for political terms: “Open Russia Civic Movement,” the name of opposition figure Mikhail Khodorkovsky, human rights lawyer Anastasiya Burakova, and Open Russia coordinator Tatiana Usmanova.

This is a useful reminder of how forensic tools actually get used in repressive contexts: to map political networks rather than to investigate crimes. As I’ve discussed before in the context of Android pattern-of-life forensics, the real power of device extraction lies in the reconstruction of relationships, habits, and associations, not in any single message or photo. In the hands of a state prosecutor pursuing political dissidents, that capability is a tool of repression rather than a law enforcement tool.

The MacBook that held

There is, in this story, one piece of genuinely good news. When Russian authorities seized Pivovarov’s Apple MacBook along with his iPhone, they could not get in. The MVD report itself documents the failure: the MacBook’s full-disk encryption made it impossible to extract the file system. The document includes screenshots of the login screen and macOS recovery functionality, the digital equivalent of a photo of someone staring at a locked door.

The forensic analysis found what appear to be failed login attempts on June 17, 2021. There was one apparent “successful” login in the records, but the Citizen Lab assessed this was actually a backdated timestamp: the MacBook’s battery had drained during its years in official custody, causing the system clock to reset to 1970-01-01 on first boot. When the device was eventually reconnected to Wi-Fi after being returned to Pivovarov in 2024, the clock corrected itself, jumping forward more than three years. The “successful” login of June 17, 2021 was in fact a login in November 2024. The Russian authorities got nothing from that machine.

The contrast with the iPhone outcome is instructive, and it connects to a topic I covered in some detail when examining iOS Lockdown Mode and its forensic implications: the security posture of a device at the moment of seizure determines what an investigator, or an adversary with forensic tools, can actually recover. Full-disk encryption on the MacBook worked. The iPhone’s protections, apparently, did not hold against Cellebrite’s extraction capabilities in 2021.

Cellebrite’s architecture of selective accountability

Cellebrite cancelled its Russian and Belarusian contracts in March 2021, following a legal petition filed the previous year by Israeli lawyer Eitay Mack alleging the company’s tools had been used by Russia’s Investigative Committee, the same body responsible for prosecuting Alexei Navalny, Pussy Riot, and others, for political repression.

The problem is structural. Cellebrite’s UFED systems have historically featured an offline mode, meaning they continue to function without phoning home for license validation. The Citizen Lab notes that the “historic architecture” of Cellebrite’s systems means that core functionality persists long after updates and support cease. In practice, a contract cancellation with a customer like the Russian Investigative Committee is less a hard cutoff than a gradual degradation. The hardware keeps working. It just stops receiving updates for new device compatibility.

This is not the first time this pattern has been documented. The Citizen Lab has forensically confirmed Cellebrite abuses in Serbia, Jordan, Kenya, and now Russia. In each case, Cellebrite’s response has been reactive: contracts cancelled after third-party exposure, with limited transparency about how the company evaluates customers or investigates reported abuses.

There is also a broader concern worth flagging. The MVD report shows Russian authorities using Cellebrite to search for Anastasiya Burakova, a human rights lawyer. In 2024, the Citizen Lab documented a global hacking campaign by COLDRIVER, a group linked to the Russian FSB, that targeted Burakova and other individuals in Pivovarov’s social network. The Citizen Lab notes the correlation: data extracted from Pivovarov’s phone under the color of legal prosecution may have contributed to identifying targets for subsequent FSB surveillance operations abroad.

Cellebrite markets its AI-enhanced analysis tools as capable of developing exactly the kind of pattern-of-life and social graph mapping that would be useful to a state looking to dismantle opposition networks. The increasing integration of AI into forensic platforms, something I’ve written about in the context of both mobile forensics and Apple Watch acquisition, raises the stakes considerably. LLMs can also introduce errors, creating false positives in pattern matching that could implicate innocent parties. In a system where the legal process itself is weaponized, those false positives have real consequences.

What you can actually do

The Citizen Lab’s recommendations are practical and worth reiterating, because they translate directly into personal security hygiene regardless of whether you face state-level adversaries.

• Keep your device’s operating system up to date. Cellebrite’s extraction capabilities depend in part on known vulnerabilities in older OS versions.
• Use a strong, preferably alphanumeric passcode. PIN codes are significantly more susceptible to brute force.
• Enable Lockdown Mode on iPhone if you are at elevated risk. As I explored in detail in my analysis of iOS Lockdown Mode, it substantially reduces the attack surface available to forensic extraction tools.
• Enable Full Disk Encryption on computers. Pivovarov’s MacBook is proof that this works, even against a state adversary with physical access and time.
• Enable Advanced Data Protection on iCloud (or Android’s equivalent). Data in transit and at rest should be encrypted with keys the provider cannot hand over.
• Power off your device completely before any situation where seizure is possible. A device at rest, never unlocked since last boot, is significantly harder to extract data from than one that has been recently unlocked.
• Use a password manager and ensure every account has a unique credential. If a device is extracted, changing passwords for accounts that were accessible from that device should be your first step.

If your device is returned to you after seizure, do not factory reset it before having it examined by a qualified forensic professional. The forensic traces that allowed the Citizen Lab to identify Cellebrite’s involvement in Pivovarov’s case came from the device itself. Deleting that evidence before analysis eliminates any possibility of understanding or documenting what was done.

The Pivovarov case is a clean, forensically solid example of something that happens far more broadly and with far less documentation. Forensic tools sold to law enforcement do not check, at the moment of use, whether the criminal prosecution they are supporting is politically motivated or compatible with international human rights law. That responsibility falls entirely on the vendor — and Cellebrite’s track record suggests it would rather cancel contracts when the press coverage becomes uncomfortable than prevent the abuse in the first place.

FAQ

How did Russian authorities access Andrey Pivovarov’s iPhone?

Forensic analysis by the Citizen Lab found traces of Cellebrite’s UFED on Pivovarov’s iPhone 12, confirmed by an official Russian MVD forensic report that explicitly named Cellebrite’s UFED Physical Analyzer and UFED 4PC toolkit as the instruments used in the extraction.

Did Cellebrite authorize the use of its tools in Russia after 2021?

No. Cellebrite cancelled its contracts with Russian and Belarusian customers in March 2021. However, the hardware continued to function in offline mode, and the Citizen Lab’s investigation confirms Russian authorities continued leveraging it for political prosecutions after the cancellation.

What practical steps can activists take to protect their devices from forensic extraction?

Key measures include keeping device software up to date, using a strong alphanumeric passcode, enabling Lockdown Mode on iPhone, enabling Full Disk Encryption on computers, and powering devices off completely before any situation involving risk of seizure.

If you have been following the Detection as Code methodology described in a previous post, you already know why this is a problem. This article is about the specific plumbing that fixes it: a CI/CD pipeline built around Sigma, the vendor-neutral detection rule format, with automated validation, test fixtures, and controlled deployment to your SIEM.

In brief

• A Sigma CI/CD pipeline has four stages: validate, translate, test, deploy. Skipping any of them defeats the purpose.
• sigma-cli handles validation and conversion in CI without external services or paid tooling.
• Every rule needs a positive test fixture (event it must match) and a negative one (event it must not match). Rules without both should fail CI.
• New rules should enter shadow mode for at least seven days before producing analyst alerts.
• CERT-EU’s droid is the most complete open-source tool for the full pipeline, from Atomic Red Team simulation to multi-SIEM deployment.

Repository structure before anything else

Before writing a single workflow file, get the repository structure right. The layout determines how maintainable the pipeline is at 200 rules. A structure that works in practice looks like this:

detection-rules/
├── sigma/
│ ├── windows/
│ ├── linux/
│ ├── cloud/
│ └── network/
├── tests/
│ └── fixtures/
│ ├── windows/
│ └── cloud/
├── platform-translations/
│ ├── sentinel-kql/
│ ├── splunk-spl/
│ └── elastic-lucene/
├── scripts/
│ ├── validate_metadata.py
│ └── coverage_report.py
└── .github/workflows/
├── ci.yml
└── deploy.yml

The sigma/ directory is the only source-controlled detection content. Everything under platform-translations/ is a build artifact, generated by CI, never edited by hand. If a Sentinel KQL query needs changing, you change the Sigma source and let the pipeline regenerate the translation. Editing the translated file directly is the same failure mode as editing production code on the server.

The tests/fixtures/ directory holds synthetic log events, one subdirectory per platform, named after the technique or rule they are testing. The convention matters: a fixture named t1059_001_positive.json next to t1059_001_negative.json is self-documenting in a way that a flat list of numbered files is not.

Rule validation

The first CI job runs on every pull request and every push to any branch. It does one thing: confirm that every .yml file in sigma/ is a valid Sigma rule.

sigma-cli is the primary tool here. It wraps the pySigma library and exposes a command-line interface for validation, listing, and conversion:

pip install sigma-cli
sigma check ./sigma/

sigma check validates syntax, required fields, and logical consistency. A rule with a malformed detection condition, a missing logsource block, or an invalid condition syntax fails with a non-zero exit code, which causes the CI job to fail and blocks the merge.

For JSON Schema validation, SigmaHQ’s sigma-rules-validator GitHub Action was originally developed and donated to the community by the Grafana Labs SecOps team. It validates rules against the official JSON Schema maintained in the Sigma specification repository, and accepts a paths input to target specific subdirectories:

steps:
  - uses: actions/checkout@v4
  - uses: SigmaHQ/sigma-rules-validator@v1
    with:
      paths: |-
        ./sigma/windows
        ./sigma/cloud

You can also pass a custom schema file or a schema URL, which is useful when your organization maintains a stricter internal variant of the Sigma specification.

A second validation job should enforce metadata completeness. Rules without MITRE ATT&CK technique IDs, an author field, a status, and a date are operationally useless at scale. A thirty-line Python script in CI that reads each rule file and exits non-zero if any of those keys are absent costs nothing to maintain and prevents the repository from accumulating orphaned detections:

import sys, pathlib, yaml

required = {"title", "status", "date", "author", "logsource", "detection"}

failed = []
for path in pathlib.Path("sigma").rglob("*.yml"):
    with open(path) as f:
        rule = yaml.safe_load(f)
    missing = required - rule.keys()
    if missing:
        failed.append(f"{path}: missing {missing}")
    if not rule.get("tags"):
        failed.append(f"{path}: no ATT&CK tags")

if failed:
    for msg in failed: print(msg)
    sys.exit(1)

Query translation

After validation, the pipeline generates platform-specific queries from the Sigma sources. sigma convert handles this with backends installed as pySigma plugins:

# Install backends for your targets
pip install pySigma-backend-splunk pySigma-backend-microsoft365defender

# Generate Splunk SPL
sigma convert -t splunk -p splunk_windows ./sigma/windows/ \
  -o ./platform-translations/splunk-spl/

# Generate Sentinel KQL
sigma convert -t microsoft365defender \
  -p microsoft365defender ./sigma/windows/ \
  -o ./platform-translations/sentinel-kql/

The -p flag applies a pipeline, which handles field name mapping between Sigma’s generic field names and the target platform’s schema. This is where most portability failures originate: rules that use CommandLine in the Sigma detection block translate cleanly to Sentinel’s ProcessCommandLine, but only if the correct pipeline is applied. A pipeline mismatch produces a syntactically valid query that matches nothing, and that failure is silent unless you have tests in the next stage.

Grafana Labs built a similar approach for teams using Grafana Loki via the pySigma-backend-loki project, which compiles Sigma rules to LogQL queries. The pattern is identical regardless of backend: the CI job installs the plugin, runs sigma convert, and checks the output for errors.

The translated outputs are committed to the repository only in the deploy workflow, not in CI. During CI they are written to a temporary directory and inspected. You do not want half-translated rule sets committed on feature branches.

Automated testing

Validation confirms the rule is syntactically correct. Translation confirms it compiles to the target language. Neither of those things confirms it actually detects what it is supposed to detect.

The minimum viable test is two fixtures per rule: one event the rule must match (true positive) and one event it must not match (false negative catch). Fixtures are stored as JSON files representing log events in the format your SIEM ingests:

{
  "EventID": 4688,
  "Image": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
  "CommandLine": "powershell.exe -EncodedCommand SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0AA==",
  "User": "DOMAIN\\attacker"
}

A pytest runner loads the compiled SIEM query, executes it against both fixtures, and asserts that the positive matches and the negative does not. This is the test-driven detection engineering pattern from BIPI, applied with a lightweight query evaluation library.

For teams that want higher-fidelity testing, droid is worth examining. Built and open-sourced by CERT-EU under the EUPL license, droid is a pySigma wrapper that integrates Atomic Red Team directly into the pipeline. Instead of synthetic JSON fixtures, it runs actual ATT&CK technique simulations in a sandbox, captures the resulting telemetry, and then verifies that the corresponding Sigma rule fires on that telemetry. The workflow is driven by a single TOML configuration file that maps rules to their ATT&CK test IDs and target platforms. For multi-SIEM environments, this approach eliminates the category of “the fixture was wrong, not the rule” failures that plague manually crafted test data.

A CI job that enforces test coverage at the pull request level:

name: Detection CI
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: SigmaHQ/sigma-rules-validator@v1
        with:
          paths: ./sigma

  metadata-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install pyyaml && python scripts/validate_metadata.py

  translate:
    needs: [validate, metadata-check]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          pip install sigma-cli pySigma-backend-microsoft365defender
          sigma convert -t microsoft365defender -p microsoft365defender \
            ./sigma/windows/ -o /tmp/sentinel-kql/

  test:
    needs: translate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install pytest pyyaml
      - run: pytest tests/ -v

Merge to main is blocked until all four jobs pass. The pipeline is the gatekeeper, not the analyst who happens to review the pull request.

Deployment and shadow mode

The deploy workflow runs only on merge to main, not on pull requests. The critical detail is shadow mode: new rules should never go directly to production alerting.

Shadow mode means the rule is active in the SIEM, matches events, and writes those matches to a dedicated index, but it does not create analyst alerts. After a defined observation window (typically seven days), a human reviews the match volume and event samples, then makes an explicit decision to promote, tune, or kill the rule.

This discipline is the difference between detection automation and accelerating failure: the same pipeline that deploys a well-tested rule deploys a poorly-tested one just as fast. Shadow mode is the structural safety rail.

Different SIEM platforms handle shadow mode differently:

• Microsoft Sentinel: deploy rules with enabled: false and suppress alerts via automation rules on a staging watchlist
• Splunk: deploy the search without attaching it to a notables policy
• Elastic: new rules start in enabled: false state; match results land in a dedicated index for review

The mechanism varies. The pattern is the same.

Pre-commit hooks for local validation

The pipeline should not be the first place a rule author learns their YAML is malformed. Pre-commit hooks run locally before a commit is created, catching the cheapest errors at the cheapest moment:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/adrienverge/yamllint
    rev: v1.35.0
    hooks:
      - id: yamllint
        args: [--strict]
  - repo: local
    hooks:
      - id: sigma-lint
        name: Sigma syntax check
        entry: sigma check
        language: python
        files: \.yml$
        pass_filenames: false
        args: [./sigma/]
      - id: metadata-check
        name: Sigma metadata check
        entry: python scripts/validate_metadata.py
        language: python
        files: \.yml$

Install with pip install pre-commit && pre-commit install. The YAML linter catches indentation errors and trailing whitespace. The sigma check hook catches detection logic errors. The metadata check catches missing ATT&CK tags. None of these should require a CI round-trip to discover.

ATT&CK coverage as a pipeline output

Once rules carry MITRE ATT&CK technique IDs in their tags field (in the format attack.t1059.001), a script in the pipeline can generate an ATT&CK Navigator layer file on every merge to main:

import pathlib, yaml, json

techniques = {}
for path in pathlib.Path("sigma").rglob("*.yml"):
    rule = yaml.safe_load(open(path))
    for tag in rule.get("tags", []):
        if tag.startswith("attack.t"):
            tid = tag.replace("attack.", "").upper()
            techniques[tid] = techniques.get(tid, 0) + 1

layer = {
    "name": "Detection Coverage",
    "versions": {"attack": "14", "navigator": "4.9", "layer": "4.5"},
    "domain": "enterprise-attack",
    "techniques": [
        {"techniqueID": tid, "score": count}
        for tid, count in techniques.items()
    ]
}
json.dump(layer, open("coverage-layer.json", "w"), indent=2)

The output is a JSON file loadable directly into ATT&CK Navigator. It updates automatically on every deploy, with no spreadsheet to maintain. The pipeline produces the coverage artifact as a side effect of doing the work, which is the only kind of documentation that stays current.

This is the same principle I described in my post on 24/7 security monitoring for small teams: build a system where discipline is enforced structurally, not through willpower or process documents. A CI pipeline that blocks merges without tests, enforces metadata, and generates coverage reports is a system with structural discipline. A SOC that relies on analysts to remember to update the coverage spreadsheet is one that runs on hope.

FAQ

What tools do I need to build a CI/CD pipeline for Sigma rules? The minimum stack is sigma-cli for validation and conversion, a Git host with CI support such as GitHub Actions or GitLab CI, and test fixtures in JSON or EVTX format. For advanced testing, droid by CERT-EU integrates Atomic Red Team to simulate real attack telemetry against your rules. Nothing in this pipeline requires paid tooling.

How do I prevent Sigma rules from breaking portability? Avoid vendor-specific field names in the detection block. Use a field normalization layer (ECS, OCSF, or a custom mapping) and validate every translation target in CI. A rule that compiles but silently matches nothing because the target SIEM uses a different field name is worse than a rule that fails loudly in the pipeline.

What is shadow mode and why does it matter? Shadow mode means a rule runs in your SIEM and logs its matches but never creates an analyst alert. A new rule should stay in shadow mode for at least seven days before promotion to production, giving you time to measure match volume and tune for false positives before anyone gets paged. It is the safety rail between fast deployment and fast failure.

In brief

• iCloud Private Relay is part of the iCloud+ subscription and is available on iOS 15, iPadOS 15, and macOS Monterey (12.0.1) and later.
• It routes Safari traffic and DNS queries through two separate hops operated by different entities, so no single party sees both the user’s IP address and their browsing destination.
• The transport uses QUIC over UDP/443 with TLS 1.3, which is opaque to most traditional inspection tools.
• DNS queries are protected via Oblivious DNS over HTTPS (ODoH), eliminating the DNS log as a reliable artifact for Safari traffic.
• Enterprises and MDM-managed devices can block or disable the service; unmanaged personal Apple devices on corporate networks cannot be forced to disable it.
• DFIR teams need to recalibrate: the IP address and DNS log are no longer sufficient anchors for investigations involving Apple devices.

How the architecture actually works

The design is deliberately adversarial toward any single observer, including Apple itself. When a user with an active iCloud+ subscription enables Private Relay, all Safari traffic and DNS queries stop going directly to the destination.

Instead, the device connects to an ingress proxy operated by Apple. This first hop sees the user’s real IP address and network provider, but the requested hostname is encrypted and hidden from it. The ingress proxy passes the request, along with a coarse geohash derived from the user’s real IP, to an egress proxy operated by a third-party content delivery network (Akamai, Cloudflare, Fastly, and others are among Apple’s partners). This second hop decrypts the destination hostname and makes the outbound connection, but it only receives geolocation data at roughly city or country level, never the original IP address. The iCloud Private Relay Overview whitepaper Apple published in December 2021 remains the most complete technical reference for this architecture.

DNS is handled separately through Oblivious DNS over HTTPS (ODoH). Queries are padded and encrypted using Hybrid Public Key Encryption (HPKE) before leaving the device, so the DNS resolver cannot identify the user and the ingress proxy cannot read the queried domain. The Apple Platform Security guide confirms that this coverage extends to all DNS resolution requests from the device, not just those initiated by Safari, making the classic DNS log artifact largely useless for Safari-originated activity.

Transport-wise, the relay uses QUIC (RFC 9000) with TLS 1.3, connecting to mask.icloud.com and mask-h2.icloud.com on UDP/443. In networks where QUIC is blocked, the client falls back to HTTP/2 CONNECT with the same TLS 1.3 requirement. As SANS Internet Storm Center’s Johannes Ullrich noted in his first hands-on analysis, the TLS client hello for the relay is negotiated with only three cipher suites (AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305) and the ALPN is HTTP/3 only, which makes the relay traffic identifiable at a metadata level even if the content is opaque.

The DFIR implications, layer by layer

The immediate reaction from network defenders when Private Relay appeared was that it was a VPN users did not ask for. The comparison misses architectural differences that change the DFIR calculus.

A traditional VPN tunnels all traffic through a single endpoint and typically routes everything, including non-browser traffic, through the same pipe. Private Relay is scoped: it protects Safari, unencrypted HTTP app traffic, and DNS. The Ookla Speedtest app, streaming applications with their own transport, and any app using HTTPS with its own certificate pinning all make direct connections with the device’s real IP address. The scope is meaningful, but it is not total.

For DFIR, the impact breaks down across several layers:

IP attribution. The egress IP presented to a web server or to a network perimeter monitoring tool is no longer the user’s IP. Apple publishes the full list of egress ranges at the official feed mask-api.icloud.com/egress-ip-ranges.csv, and most geo-IP databases now annotate these with the Organization field set to “iCloud Private Relay” and additional boolean fields such as is_relay or privacy_proxy. An analyst correlating a suspicious IP to a specific user device will find an Apple relay IP instead. The Apple developer guidance for network operators notes that relay IPs may be shared among multiple users in the same region, making per-user IP attribution from network logs unreliable.

DNS logs. ODoH means that on a network where Private Relay is active and not blocked, DNS queries from Safari do not appear in the local resolver’s logs. If your threat hunting workflow depends on flagging DNS lookups for known-malicious domains as an early detection signal, Private Relay creates a blind spot for any Safari-initiated activity. The REN-ISAC advisory on iCloud Private Relay flagged this directly: “Web traffic, DNS queries, and potentially other traffic are tunneled via QUIC over port 443 with TLS 1.3. This traffic will typically be opaque to network monitoring.”

Proxy and VPN anomaly detection. Detection rules that alert on connections from anonymous proxy or hosting ranges will catch Private Relay traffic, generating false positives in Apple-heavy environments. Tuning these rules requires knowing Apple’s egress IP space and treating it as a distinct category rather than a generic anonymization service. The Cloudflare writeup on iCloud Private Relay is useful here: it explains how Cloudflare itself had to update its IP categorization to avoid treating Private Relay users as suspicious.

Session correlation. Relay IP addresses rotate between sessions. They remain stable during a single browsing session, which Apple designed deliberately to allow anti-fraud mechanisms on the server side to function. Across sessions, the same user will appear with different IPs from the Apple egress pool. Any investigation that attempts to reconstruct a user’s browsing history by correlating IP addresses across time will fail unless the analyst controls the endpoint directly.

What breaks in the security stack

For teams that have built detection around network telemetry, the impact of Private Relay is uneven across tool categories. Zeek will still see the QUIC UDP/443 connection to mask.icloud.com, but the connection log is a black box with no SNI, no DNS context, and an Apple-annotated source IP. The conn.log and ssl.log outputs are useful for traffic-volume baselining and connection-count anomaly detection, but useless for destination correlation. Suricata rules that match on HTTP hostname or TLS SNI will not fire against relay traffic. Rules that match on the egress IP space can still detect that someone is using Private Relay, but that is a metadata signal, not a useful detection. NetworkMiner and similar pcap parsers will produce a host entry for mask.icloud.com with no children, and analysts expecting to see child connections to the actual destination will be disappointed. Arkime and ntopng will index the same opaque sessions with similar limitations. None of these tools are broken, but all of them have lost a layer of context that detection engineers often relied on implicitly.

The pragmatic response is to shift detection logic away from “what destination did this IP talk to” and toward “what client is talking to Apple’s relay from inside our network, and at what volume.” A simple conn.log query that counts relay sessions per source IP per hour will catch misuse, exfiltration patterns, and policy violations, even if every individual session is opaque.

A condensed view of what is and is not visible to the analyst after Private Relay:

The key insight is that the relay moves the opacity boundary from the destination to the network. Server-side and endpoint-side evidence is largely unaffected, and the practical DFIR shift is to anchor investigations there rather than at the IP-and-DNS layer where Private Relay lives.

Where the relay still leaks

Private Relay obscures a great deal, but the architecture leaks more than people often assume. A DFIR practitioner who knows where to look still has signals to work with.

The destination server still sees the full unencrypted request once the egress proxy forwards it. Server-side logs, application-layer data, and the actual user agent, cookies, and authentication headers remain untouched by the relay. For a web application that logs user actions, Private Relay changes nothing about the forensic value of those logs. The same applies to any TLS 1.3 session resumption cache the destination maintains, which is a far more reliable identifier of a returning user than the IP address ever was.

On the network side, the TLS handshake still carries a fingerprint. While the relay obscures the destination hostname, JA3 and JA4 fingerprinting can still distinguish a Private Relay connection from a direct connection in some configurations, and the relay client itself has a consistent fingerprint across Apple devices that simplifies traffic identification. The geolocation leak at the egress proxy level also means an investigator with access to logs from both the ingress and egress proxies (which neither party normally has) can correlate sessions. The two-proxy design prevents this in normal operation, but it is a structural property, not a cryptographic guarantee.

Timing and packet size analysis remain feasible for an observer who can see both sides of a connection. A relay adds latency in the 30-80 ms range, and QUIC packet sizes cluster around characteristic values depending on the request type. For most investigations this is too noisy to act on, but for targeted cases it can corroborate other evidence.

Encrypted Client Hello (ECH) deserves a mention in this broader context. Apple deployed ECH support for its own domains around the time macOS Sonoma shipped, and Private Relay’s design is compatible with ECH. As ECH adoption grows, the relay’s role in hiding the destination hostname from the ingress proxy becomes less special: the network sees a connection to a Cloudflare or Akamai front door, and the real destination is hidden inside. Private Relay in a post-ECH world remains useful for IP rotation and geohash separation, but the DNS and SNI hiding are no longer unique to Apple.

A related clarification: Private Relay is operationally separate from Private Cloud Compute, the architecture Apple introduced for Apple Intelligence. Private Cloud Compute routes specific on-device AI computation requests through hardened Apple server nodes with cryptographic attestation and stateless processing. The two services share a privacy brand but are independent. A user enabling Private Relay does not opt into Private Cloud Compute, and vice versa. The DFIR implications are also distinct: Private Cloud Compute is a server-side compute architecture and does not affect network telemetry for the user’s other traffic. Enterprise policy documents sometimes bundle the two together, and the confusion is worth flagging because the operational mitigations are completely different.

What enterprises and MDM can still do

Apple was not oblivious to the operational needs of managed environments. The iCloud Private Relay Overview whitepaper is explicit: enterprises with supervised devices can disable Private Relay entirely via a Mobile Device Management (MDM) configuration profile. A VPN profile installed on the device takes precedence over Private Relay, and the same applies to a Global HTTP Proxy configuration. Any traffic routed through the enterprise VPN or proxy will bypass Private Relay entirely.

For network-level control without MDM, the documented method is DNS-based: configure the local resolver to return NXDOMAIN (or a “no error no answer” response) for mask.icloud.com and mask-h2.icloud.com. Users will see a system notification that Private Relay is unavailable on the current network and will be prompted to either disable it or switch networks. Apple explicitly discourages silent drops or DNS timeouts, because these cause noticeable latency on client devices and, frankly, make your network look broken rather than intentionally restrictive.

For unmanaged personal devices on a corporate network, the options are limited to network-level DNS blocking. This is a reasonable posture for regulated environments, and it is worth noting that blocking these two hostnames is a fairly contained intervention. The whitepaper also lists several categories of traffic that Private Relay never touches regardless of settings: cellular carrier services (MMS, XCAP, Visual Voicemail), local network traffic (private IP ranges, mDNS), and any app or protocol that uses its own transport layer rather than Safari’s networking stack.

Rethinking the evidence model

A large part of the DFIR community has built its evidence model on the assumption that network telemetry, specifically IP addresses and DNS logs, was a reliable proxy for user identity and intent. Network telemetry was never fully reliable to begin with. NAT, shared Wi-Fi, Tor, and carrier-grade NAT have been degrading the IP-to-user mapping for years. Private Relay brought the erosion into the consumer mainstream, and at a scale the rest of the industry could not ignore.

For investigations involving Apple devices, the practical reorientation is toward endpoint artifacts. Safari’s browsing history, WebKit cache, and download records persist locally and survive Private Relay completely. On macOS, unified logs and FSEvents capture application behavior independent of network routing. Mobile forensics workflows that extract Safari’s local databases (the BrowserState.db and History.db files within Safari’s application container) remain fully valid, and the same extraction paths used in modern iOS evidence acquisition apply regardless of how the device routed its traffic. On managed devices, MDM can provide application inventory, compliance status, and, in some configurations, granular activity logs that are unaffected by network routing choices.

For network-side detection and threat hunting, the shift is toward application-layer signals rather than IP-and-DNS correlation. HTTP/S request patterns visible to a proxy that sits between the egress relay and the destination, anomalies in certificate transparency logs, and behavioral signals from endpoint EDR agents all bypass the opacity introduced by Private Relay. The same shift in mindset applies to threat hunting with YARA-X: the artifacts worth scanning have always been on disk and in memory, and the network layer was a shortcut, not a substitute.

Private Relay leaves endpoint forensics untouched. What it does break is the lazy workflow that treated network telemetry as ground truth. The shift is overdue, regardless of where one stands on Apple’s privacy stance. And for context, this is just one piece of a broader pattern: iOS Lockdown Mode and forensic analysis, Secure by Design: iOS 18’s privacy evolution and its impact on the DFIR, and the steady erosion of unencrypted-by-default services have all been pushing DFIR in the same direction for years. Private Relay just made it impossible to ignore.

FAQ

What traffic does iCloud Private Relay actually protect? Private Relay protects Safari web browsing and all DNS name resolution requests. It also covers unencrypted HTTP traffic from apps. Other app traffic that uses its own transport (e.g. streaming apps, VoIP) is not routed through the relay.

Can an enterprise block iCloud Private Relay on its network? Yes. The recommended method is to return an NXDOMAIN or “no error no answer” response from the local DNS resolver for the hostnames mask.icloud.com and mask-h2.icloud.com. Silent packet drops are discouraged by Apple as they cause delays on client devices.

Does iCloud Private Relay prevent all network-based forensic investigation? No. It reduces the value of IP-based and DNS-based telemetry, but it does not affect endpoint artifacts, MDM logs, application-layer data, or traffic outside Safari and unencrypted HTTP. DFIR shifts toward endpoint and application-layer sources, but the discipline does not disappear.

Detection as Code is a methodology, not a tool, a vendor category, or a buzzword. It is the answer to that problem.

In brief

• Detection rules are software artifacts: they deserve version control, peer review, automated testing, and a deployment pipeline.
• Sigma is the closest thing the industry has to a vendor-neutral detection language, compiling to Splunk SPL, Sentinel KQL, Elastic EQL, and more.
• A CI/CD pipeline for detections catches logic errors before they reach production, and provides a full audit trail when something goes wrong.
• Detection as Code fails without clean telemetry: version-controlling garbage rules is still garbage, just with a better commit history.
• Starting small works: a handful of high-value rules in Git with basic tests already eliminates the most damaging failure modes.

The gap that detection engineering refuses to acknowledge

Compare how your development team ships code with how your detection team ships rules. Developers branch, test, review, and deploy. If something breaks, they revert in seconds. If someone asks what changed, the answer is in the commit history. Your detection team, in all likelihood, clicks a rule into the SIEM console, saves it, and hopes for the best.

The process gap here is not cosmetic. It maps exactly to the same set of problems that software engineering solved decades ago. No version control means no history and no rollback. No tests mean the rule fires on legitimate traffic at 3 AM and nobody knows why. No peer review means a logic error survives because the author was the only person who read the query. No deployment pipeline means “staging” and “production” are indistinguishable concepts. Rapid7 summarized this gap into a blunt comparison: software engineering teams operate from Git with automated validation; detection engineering teams operate from a wiki and a Save button. One of these models scales. The other one collapses under its own weight.

The reason this persists is cultural rather than technical. Detection rules have traditionally been treated as configuration, not code. Configuration lives in a UI. You tune it by feel. You delete it when it gets annoying. The implicit assumption is that detection is an operational task, not an engineering one. Detection as Code challenges that assumption directly, and the discomfort that sometimes follows says everything about how embedded the old model is.

What Detection as Code actually means

The core idea is simple: every detection rule lives in a version control system (Git, overwhelmingly), is reviewed before deployment, is validated by automated tests, and is deployed through a pipeline rather than directly from a console. The rule is an artifact. Its history is preserved. Its ownership is explicit. Its behavior is testable.

This sounds obvious in the abstract. In practice it means several things change simultaneously.

Rules need metadata to be manageable at scale: author, creation date, last review date, MITRE ATT&CK technique IDs, target data source, expected false positive rate. Without metadata, a repository of 500 rules becomes a mystery archive that nobody wants to touch. With it, a simple script can emit a live coverage heatmap keyed by ATT&CK technique ID, updated on every commit, with no manual spreadsheet to go stale.

Rules need tests. A detection without a test is a hope, not a control. The minimum viable test is two fixtures: a malicious event the rule must match, and a benign event it must not match. Pull requests that lack both test cases should be rejected by CI, the same way you would reject application code without unit tests. This pattern sounds aggressive until you consider the alternative, which is finding out that your detection fires on legitimate admin activity during an actual incident.

Rules need deployment discipline. New rules should enter shadow mode for at least seven days: the rule runs and writes matches to a separate index, but creates no analyst alert. After a week you read the hit volume, sample a dozen events, and either tune, promote, or kill the rule. Detections that never leave shadow mode are still better than detections that page an analyst every twelve minutes with garbage. This is a lesson that applies equally to large enterprise SOCs and to the small teams I described in my post on 24/7 security monitoring: the goal is fewer alerts with better context, not more coverage with more noise.

How Sigma makes detection logic portable

The portability problem in detection engineering is real. Most organizations run more than one security platform. Rules written natively for Splunk are useless in Sentinel. Rules written for Elastic require a rewrite for Chronicle. Multiply this by every SIEM migration you will ever conduct, and the cost of vendor-native rule formats becomes visible.

Sigma is the closest thing the industry has to a solution. Released by Florian Roth in 2017, it defines detection logic in YAML: a logsource block that describes the data source, a detection block that describes what to look for, and a condition that ties them together. Tools like sigma-cli and pySigma compile that YAML into Splunk SPL, Microsoft Sentinel KQL, Elastic EQL, IBM QRadar, Chronicle YARA-L, Wazuh rules, and a growing list of other targets. A single Sigma file is the source of truth; the platform-specific query is a build artifact.

The SigmaHQ community repository on GitHub contains thousands of maintained rules covering techniques across the MITRE ATT&CK matrix, from credential dumping to living-off-the-land execution. The practical value is that you do not start a Detection as Code program from zero: you fork a curated baseline, map it to your environment, add tests, and own the result.

A minimal Sigma rule for detecting PowerShell encoded command execution looks like this in plain terms: logsource is Windows process creation; detection requires Image ending in powershell.exe and CommandLine containing -enc or -EncodedCommand; condition is selection. That single YAML file compiles to a working KQL query targeting DeviceProcessEvents in Sentinel and a working YARA-L rule targeting udm.principal.process in Chronicle. The portability is not theoretical. It is the reason Sigma has become, as the documentation now explicitly states, the de facto standard for SIEM-agnostic detection.

One important failure mode worth naming: Sigma rules that use vendor-specific field names in the detection block break portability silently. The rule compiles, the translation succeeds, and the query fires on nothing because the field name does not exist in the target SIEM’s schema. Field name normalization, whether through the OCSF schema, ECS, or your own data model, is not optional if you want portability to work in practice.

YARA and YARA-X for content-based detection

Sigma handles log-based detection. YARA handles file and memory-based detection: matching binary patterns, strings, and structural characteristics of files rather than log events. The two are complementary, and a mature Detection as Code program uses both.

I covered the YARA-X transition in detail earlier this year: the complete Rust rewrite addresses the performance ceiling that classic YARA’s C codebase had hit, particularly on rules with complex regular expressions and nested loops. For Detection as Code specifically, YARA-X brings two important improvements. First, the yr compile command works cleanly as a CI validation step, catching syntax errors before a rule is deployed to production scanning. Second, the JSON and YAML output formats make integration with automated pipelines practical without fragile text parsing.

YARA rules, like Sigma rules, need metadata and ownership. A rule without a description, author, and reference field is a detection waiting to become orphaned. For malware hunting workflows, the threat_name, malware_family, and MITRE technique tags are the difference between a rule library and a pile of patterns. YARA-X also fits naturally into threat hunting pipelines alongside Volatility3 and other DFIR tools, where the same rule corpus used in CI can be applied to memory dumps or disk images during incident response.

Where Detection as Code breaks down

The discipline only works on top of a functioning foundation. Git does not cure bad telemetry. Version-controlling rules that fire on unstructured logs, or that target fields that your parser does not reliably populate, produces a neat repository of rules that detect nothing. Before imposing engineering discipline on detection logic, it is worth confirming that your log sources are complete, that parsing is consistent, and that the fields your rules reference actually exist in your SIEM’s schema.

Ownership is the second failure mode. Detection as Code creates an audit trail for who wrote a rule and who approved it, but it does not automatically create a pager assignment. Rules without a named owner accumulate. They fire. Nobody investigates. After six months the SOC has learned to ignore the alert, and the detection is functionally dead while appearing alive in the repository. Every rule should carry an explicit owner and an explicit escalation path, and that information should be part of the metadata that CI validates, not an afterthought in a comment.

The third failure mode is scope creep in automation. The appeal of CI/CD for detections is real, but the same automation that deploys a well-tested rule can deploy a poorly-tested one just as fast. The solution is not less automation but better gates: require positive and negative test fixtures, enforce review by at least one person who did not write the rule, and run shadow mode for any rule touching high-volume data sources. Teams building 24/7 monitoring capability know the pattern well: the safe automation ladder applies here too. Enrich and validate automatically; promote to production only after human confirmation.

The cultural challenge is perhaps the most stubborn. Analysts who have spent years clicking rules into a console often experience Detection as Code as friction rather than discipline. The fix is demonstrating the value through a concrete incident: show the team the pull request that changed the rule three weeks before it started misfiring. That commit history, that diff, that author name is the argument that no process document can make as effectively.

A practical starting point

The good news is that you do not need to boil the ocean to start. A working Detection as Code program can begin with five rules and a single Git repository.

Pick your five highest-value detections, the ones covering your most credible risks and the ones your team actually investigates when they fire. Write each one as a Sigma rule. Add metadata: ATT&CK technique ID, data source, author, last reviewed date. Add a positive test fixture and a negative test fixture. Set up a basic CI pipeline that runs sigma-cli against every pull request and rejects merges without test coverage. That is version one. It is not impressive. It is sufficient.

From there, the program grows naturally: add YARA rules for your malware detection library, introduce shadow mode tooling for new rules before they go live, connect the rule metadata to an ATT&CK Navigator layer for coverage tracking, and eventually integrate deployment automation that pushes approved rules to your SIEM rather than requiring a manual copy-paste. Each step has compound returns: the coverage map improves, the audit trail extends, the on-call analyst gets better context at 3 AM.

Rapid7’s Terraform provider for InsightIDR demonstrates what the mature end of this looks like: detection rules expressed as Terraform resources with inline test cases, deployed through the same IaC pipeline your infrastructure team already uses. Governance happens as a natural side effect of the pull request workflow, not as a separate compliance exercise. Whether or not Terraform fits your environment, the model is instructive: detection logic as a first-class infrastructure artifact, subject to the same rigor as everything else you run in production.

Teams that have followed this path consistently report a 40 to 60 percent reduction in alert volume after six months, faster analyst onboarding because new team members can read the rule history to understand intent, and dramatically smoother SIEM migrations because the detection library is portable rather than locked into a vendor console. The coverage map becomes a credible artifact rather than a fiction. Most importantly, the team stops being afraid to delete bad rules, because the history is preserved and the test fixtures remain.

FAQ

What is Detection as Code? Detection as Code is a methodology that treats threat detection rules as software artifacts, managed through version control, peer review, automated testing, and CI/CD pipelines rather than ad-hoc console changes. The goal is a detection library that is auditable, portable, and maintainable rather than dependent on individual tribal knowledge.

What is Sigma and why does it matter for Detection as Code? Sigma is an open, vendor-neutral rule format that lets you write detection logic once and compile it to Splunk SPL, Microsoft Sentinel KQL, Elastic EQL, or other SIEM-specific languages. It is the most practical foundation for a portable, versionable detection library, and the SigmaHQ community repository provides a large baseline of maintained rules to start from.

Do I need a large team to implement Detection as Code? No. Even a small security team benefits from Detection as Code. Starting with a handful of high-value rules in a Git repository with basic CI validation already eliminates the most damaging failure modes like rules without ownership, no rollback path, and no audit trail. The overhead is low; the returns are immediate and compound over time.

That transition, from artifact to accountable human being, has no rigorous standard. It gets handled differently depending on the examiner, the organization, the jurisdiction, and occasionally the mood of whoever is writing the report. That gap is exactly what the FACT Attribution Framework (v1.1, published December 2025 on Zenodo) is designed to close.

In brief

• FACT stands for Forensic Compliance, Analyze Evidence, Correlate & Sequence, Testify & Transfer Findings, four stages that make up the full attribution lifecycle.
• The framework draws a hard, explicit line between identification (device, account, action) and attribution (person, accountability), and treats conflating the two as an error, not a shortcut.
• It wraps existing DFIR lifecycles in legal bookends: authority and compliance at the start, reporting and testimony-ready reasoning at the end.
• FACT defines who is authorized to make each type of claim in an investigation, keeping examiner roles clean and conclusions defensible.
• Version 1.1, the current release, reflects review by practitioners, attorneys, analysts, and instructors, and provides the legal and logical architecture that current DFIR processes generate evidence for, without replacing any of them.

The problem FACT is solving

There is a specific failure mode in digital investigations that almost nobody talks about openly, probably because it is embarrassing. An examiner recovers an artifact, ties it to an account, ties the account to a name, and writes that name into the final report next to the word “perpetrator.” The chain of reasoning in between usually gets summarized as “forensic analysis confirmed.” This works fine until the report reaches a courtroom, an HR panel, or a regulator. At that point, someone asks a simple question: how do you know a specific human being performed that action? And the answer, more often than it should be, is “…because the artifact was on their device.”

Brett Shavers, the framework’s author, is direct about this: “DF/IR doesn’t usually fail on the technical work. It fails at the exact moment someone gets impatient and confuses activity with identity, and then confuses identity with attribution.” FACT draws a hard line between identification (this device, this account, this action, at this time) and attribution (this specific person bears responsibility for that action). Those are not the same claim and they do not require the same evidence standard. Every examiner knows this intuitively. Very few frameworks force them to work it explicitly.

The distinction matters more today than it did ten years ago. Shared accounts, cloud-synced credentials, VMs, roaming profiles, and multi-user endpoints have made the device-to-person equation genuinely ambiguous in a large percentage of real investigations. The old mental shortcut, “the file was on their laptop, QED,” is increasingly a liability, both legally and professionally.

A typical insider-leak case makes the gap visible. An employee is accused of exfiltrating a sensitive document. The examiner recovers the file from the workstation, finds a matching copy in a cloud account tied to the corporate credentials, and reconstructs a network connection at 2 AM. The draft report names the employee. The case reaches arbitration, and defense counsel shows that the workstation was shared across a hot-desking rotation, that the corporate SSO cached the credentials on every machine in the pool, and that the cloud account was a team resource. The attribution collapses, and the organization is left with no defensible finding on a genuine incident.

The four stages of FACT

The framework is built around the acronym that gives it its name. Each letter represents a stage in the attribution lifecycle, and the stages are designed to be sequential and mutually reinforcing.

Forensic Compliance is the opening stage, and it sets the legal and procedural boundaries for everything that follows. Before a single artifact is examined, FACT requires that the investigator establish the authority under which the investigation is being conducted, validate that evidence acquisition meets applicable legal and jurisdictional requirements, and document the chain of custody from the start. This is not a box-ticking exercise: the stage explicitly determines who is authorized to conduct the investigation and what conclusions they are permitted to reach. An examiner working under a corporate HR mandate has a different authorization envelope than one operating under a court order, and FACT makes that boundary visible.

Analyze Evidence is the stage most DFIR practitioners are already comfortable with. It is where artifacts are examined, validated, and characterized: file metadata, registry keys, log entries, network telemetry, volatile memory contents. FACT does not prescribe specific tools here. You can use Volatility, YARA-X, or any combination of forensic tools appropriate to the case. What FACT adds is a requirement that findings at this stage stay at the identification level, with attribution deferred to the later stages. “This artifact was present on this device at this timestamp” is an identification. “This person created this artifact” is not, yet.

Correlate & Sequence is where the framework earns its complexity. This stage requires investigators to build the explicit logical bridge between the artifact evidence and the identity claim. Correlation might involve account linkage, biometric authentication records, physical access logs, behavioral patterns, communications metadata, or geolocation data. Sequencing imposes temporal coherence: the claimed attributable actions must fit into a consistent, evidence-supported timeline. For mobile evidence in particular, this is where most attribution claims either solidify or collapse, a challenge anyone who has worked on Android pattern-of-life analysis will recognize immediately. FACT does not tell you what correlation evidence is sufficient; it forces you to state what you have, what it supports, and what its limitations are.

Testify & Transfer Findings closes the cycle. This is the stage where conclusions must be articulated in a form that can survive scrutiny: legal proceedings, administrative hearings, regulatory reviews, or organizational governance processes. FACT distinguishes between the examiner role (who can state what the evidence shows) and the attribution role (who has the authority and the full evidentiary basis to say who is responsible). Keeping those roles clean is not procedural pedantry. It is what prevents examiners from being cross-examined into corners because they overclaimed their conclusions in the report.

Legal grounding and role separation

What makes FACT structurally different from most existing frameworks is its explicit treatment of authority and role separation throughout the lifecycle. Most DFIR models describe what to do. FACT also describes who is permitted to do what, and what each role is allowed to conclude.

This matters in practice because attribution claims carry legal weight that identification claims do not. An examiner can testify to artifact characteristics without exposing themselves to challenge on the question of intent or identity. An investigator or decision-maker with broader contextual authority can make the attribution claim, provided the underlying examination record supports it. FACT creates a documented handoff between those layers rather than letting them blur together in a single report signed by someone who was only authorized to do the technical work.

The framework also handles the AI-era complications that are starting to appear in DFIR work. When autonomous agents act on behalf of users, or when LLMs generate outputs that get confused with user-generated content, the device-to-person attribution chain becomes even less reliable. A scenario discussed in recent DFIR circles illustrates the problem: an enterprise chatbot with broad system access is manipulated through a long prompt chain to copy a customer database to an external location. The artifacts on disk include a system service account, a scheduled task, and a network connection. The naive reading is that the user whose credentials were in the logs did it. The actual actor was an agent acting on a prompt, and the user is at most negligent about their own prompt hygiene. FACT’s insistence on explicit, documented logical steps from artifact to person makes it a more future-proof methodology than frameworks that assume a simpler attribution environment.

Adoption and practical fit

FACT v1.0 was released in December 2025 after pre-release review by 36 practitioners spanning law enforcement, corporate DFIR, consulting, academia, and the legal sector. The feedback, according to Shavers, was consistent: existing frameworks do not provide a structured, defensible approach to person-level attribution, and FACT fills that gap without replacing anything already in use. Version 1.1 followed shortly after, incorporating multidisciplinary expert feedback and formalizing the attribution pathway. The full specification is published on Zenodo under a DOI-registered citation, the same record linked in the introduction.

For practitioners, the immediate question is where FACT fits relative to existing process. The answer is: at the edges. FACT does not replace your acquisition workflow, your tool stack, or your incident response playbook. It provides the legal and logical architecture that those processes generate evidence for. Think of it as the framework that answers the question your current lifecycle doesn’t ask: can you defend not just what you found, but who you said did it, and on what authority?

Concretely, FACT is designed to sit alongside the established DFIR and evidence-handling guidance that most organizations already follow. NIST SP 800-86 covers integrating forensic techniques into the incident response lifecycle. ISO/IEC 27037 prescribes identification, collection, acquisition, and preservation of digital evidence. The older RFC 3227 guidelines on evidence collection and archiving still show up in many IR playbooks. What those documents do not prescribe, and what FACT adds, is the explicit attribution layer and the role separation needed to defend person-level conclusions downstream of the technical work.

For teams that want to adopt FACT, the on-ramp is intentionally low. A practical first step is to map your current investigative workflow against the four stages: identify where authority is established, where identification claims stop, where correlation begins, and where conclusions are documented for handoff. Then define, in writing, who in your organization is authorized to make each type of claim. Most teams complete this exercise in a single working session and immediately surface gaps that previously lived as informal practice.

In environments subject to DORA, NIS2, or sector-specific compliance requirements, the attribution question has stopped being optional. Regulators are starting to ask for more than technical findings. They want to know who was responsible, how that determination was made, and whether the chain of reasoning is defensible. FACT provides exactly that structure. Being free, openly licensed, and DOI-registered on Zenodo also removes the usual barriers to adoption.

It is worth being explicit about what FACT does not do. It does not produce evidence on its own, and it does not substitute for sound forensic acquisition or sound investigative judgment. Where authority structures are unclear, where roles overlap, or where the organization is unwilling to keep identification and attribution separate in the final report, FACT will document those weaknesses rather than resolve them. The framework’s value scales with the rigor of the process around it.

FAQ

What is the FACT Attribution Framework?

FACT (Forensic Compliance, Analyze Evidence, Correlate & Sequence, Testify & Transfer Findings) is a legally grounded investigative model designed to bridge technical digital evidence and defensible human attribution in DFIR and incident response contexts.

How does FACT differ from existing DFIR frameworks?

Existing frameworks focus on documenting activity. FACT adds a structured, legally accountable pathway from artifact to person, drawing a hard line between identification and attribution and defining who is authorized to make each type of claim.

Who should use the FACT Attribution Framework?

FACT is relevant for digital forensics examiners, incident responders, corporate investigators, law enforcement analysts, and attorneys involved in cases where person-level attribution must be established and defended under scrutiny.

With macOS Tahoe 26, Unit 42 researchers at Palo Alto Networks have identified a new artifact that begins to close that gap. It is called App.MenuItem, and it is a previously undocumented Biome stream that logs the exact menu selections a user makes across the entire operating system.

In brief

• macOS Tahoe 26 introduced a new Biome stream, App.MenuItem, located at ~/Library/Biome/streams/restricted/App.MenuItem/local.
• The stream records the text of every menu item a user selects, along with a precise timestamp.
• Data is stored in SEGB-encapsulated protobuf format, requiring specific tooling to parse, and the open-source ccl-segb is currently the practical option.
• Most commercially available DFIR tools do not yet parse this artifact automatically.
• When combined with file system logs, App.MenuItem provides a narrative layer of user intent that raw technical artifacts cannot supply on their own.
• The artifact was likely introduced by Apple to support user suggestions or adaptive interface behavior, but its forensic value is substantial.

What Apple Biome is and why it matters

The Apple Biome framework is not new. It has been quietly accumulating forensic significance across macOS and iOS releases, tracking application usage, media consumption, device activity, and behavioral patterns in a structured, timestamped format. If you have spent any time doing macOS forensics, you have almost certainly encountered Biome streams already, even if only in passing.

Each Biome stream represents a specific data category. The framework stores entries in SEGB (Segment-Based) file format, which wraps protobuf-encoded records with metadata and integrity structures. This is not the most examiner-friendly format in the world, but it is consistent and well-structured once you know how to approach it. The forensic community has been building tooling around it for a while, and the OSX forensics tool ecosystem has matured considerably over the past few years.

What Apple appears to have added in Tahoe 26 is a stream specifically dedicated to recording UI-level user interactions, specifically, the menu items a user selects. The likely intended purpose is adaptive UI, autofill suggestions, or behavioral learning. The forensic side effect is an extremely granular log of what the user chose to do, expressed in plain language, with timestamps.

Where to find App.MenuItem and how to parse it

The artifact lives at: ~/Library/Biome/streams/restricted/App.MenuItem/local

The restricted path designation is significant. It signals that this stream is not user-accessible under normal conditions and requires elevated acquisition privileges to export. On a live macOS system acquisition, this means you will need appropriate access before collection. On a disk image, the path is accessible through standard forensic workflows.

Because the file uses SEGB-encapsulated protobuf, most current commercial tools will not parse it automatically. Unit 42 confirmed that none of the major commercially available DFIR platforms they tested processed this specific stream at the time of publication. The practical solution is the open-source Python tool ccl-segb, developed by CCL Group, which handles the SEGB format and exposes the underlying protobuf records.

The parsing workflow is straightforward:

1. Export the file from ~/Library/Biome/streams/restricted/App.MenuItem/local.
2. Run the ccl-segb CLI against it: python ccl_segb_cli.py <exportedfilename> > outputfilename.txt
3. Convert the text output to CSV for easier filtering and timeline correlation using a Python script.

The resulting output will contain timestamped menu item strings in plain text, human-readable action labels like “File > Save…”, “Compress ‘stolendata’”, or “Empty Trash”. Each entry carries a precise UTC timestamp.

Reconstructing user intent from the timeline

The investigative value of App.MenuItem becomes clearest when you look at what a sequence of entries actually communicates. Unit 42 shared a sample analysis timeline that illustrates this well:

• 18:32:37 User navigates via Go > Go to Folder… in Finder
• 18:36:59 In TextEdit, user selects File > Save…, types “u42validation”
• 18:37:54 User highlights a folder named “stolendata” and selects Compress “stolendata”
• 18:38:19 User selects Move to Trash
• 18:38:41 User interacts with the Dock to select Empty Trash

In eleven minutes, that sequence tells a story: navigate to a directory, create or edit a file, compress a folder for likely exfiltration, and then cover the tracks. The folder name appearing verbatim in the Compress entry is particularly useful. It provides direct evidence of the target of the action, not inferred from file system metadata.

This is the difference between a file system artifact telling you “a .zip file was created at 18:37:54 and a folder entry disappeared” and an artifact telling you “the user deliberately right-clicked a folder named ‘stolendata’ and selected Compress.” The semantic content is radically different, even when the underlying event is identical. Combined with the approaches discussed in forensic timeline creation, App.MenuItem can fill in the human layer that purely technical logs leave blank.

The artifact also captures Copy, Paste, and other UI interactions that leave minimal traces elsewhere. For investigations involving potential anti-forensic activity (where a user may have deliberately minimized their footprint), the menu item log may capture the very actions taken to clean up.

App.MenuItem is not omniscient, however. If a menu action does not include a specific filename in its label (a generic “Open” rather than “Open ‘evidence.pdf’”), you will see the action but not the target. This limitation is real, and the artifact works best as a corroborating source alongside file system events, unified logs, and other macOS behavioral artifacts, rather than as a standalone case-builder.

Implications for DFIR workflows on macOS

Every macOS release adds new artifacts, deprecates old paths, and occasionally restructures something you were quietly relying on. The transition from Sequoia to Tahoe is no exception. This mirrors a broader pattern: Apple keeps tightening privacy controls for users while simultaneously generating richer behavioral telemetry for its own purposes, telemetry that forensic investigators can, when acquisition conditions allow, turn into evidence.

The immediate practical implication is that examiners working with Tahoe 26 images should verify whether App.MenuItem is present and, if it is, incorporate it into their standard triage workflow. The parsing step is not complex once ccl-segb is set up, and the potential payoff (a timestamped record of deliberate user actions in plain language) justifies the extra step. It is also worth watching whether Volatility 3 and tools like mac_apt add support for this stream in the near term, as macOS memory and disk forensics tooling tends to respond fairly quickly to documented new artifact types.

For investigators who work across both macOS and Windows, the parallel with the recently discovered Windows 11 PCA artifact is worth noting: both represent OS-level logging that was likely designed for user experience optimization and has turned out to carry significant forensic value. The lesson in both cases is the same: keep checking what the OS is recording about itself.

FAQ

What is the App.MenuItem artifact in macOS Tahoe 26?

App.MenuItem is a new Biome stream introduced in macOS Tahoe 26 that logs the specific menu items a user selects across the operating system, along with timestamps. It is stored at ~/Library/Biome/streams/restricted/App.MenuItem/local.

How do I parse the App.MenuItem Biome stream?

The file uses SEGB-encapsulated protobuf format. You can extract it using the open-source ccl-segb tool with the command python ccl_segb_cli.py <exportedfilename> > outputfilename.txt, then convert the output to CSV for analysis.

What forensic value does App.MenuItem provide compared to standard file system logs?

Where file system logs record that a file was deleted, App.MenuItem shows the deliberate sequence of actions, selecting “Move to Trash” then “Empty Trash”, providing the human context and intent behind technical events.

This is the scenario that firmware implants and UEFI bootkits are built for: persistence so deep that the normal DFIR playbook of acquiring the disk, imaging the memory, analyzing, remediating, and reimaging simply does not reach it. It is not a new problem. The first UEFI rootkit documented in the wild appeared in 2018. What has changed is that the technique has moved from nation-state novelty to something approaching a tradecraft standard, and the forensic community’s response has not quite kept up.

In brief

• UEFI bootkits and firmware implants persist below the operating system, in EFI System Partition boot components or in SPI flash memory on the motherboard itself.
• Known implants include BlackLotus (EFI bootkit, bypasses Secure Boot on patched Windows 11), CosmicStrand and MosaicRegressor (firmware-resident, survives disk replacement), and FinSpy bootkit (commercial spyware with pre-OS component).
• Standard DFIR tools (Volatility, disk imaging, EDR agents) are structurally blind to firmware-layer persistence.
• Detection requires a different toolkit: CHIPSEC for SPI flash analysis, UEFITool for EFI binary inspection, boot log analysis, and PCR value attestation via TPM.
• Remediation is non-trivial: EFI-resident implants may require ESP cleaning and Secure Boot re-enrollment; firmware implants may require a full BIOS reflash or, in extreme cases, hardware replacement.
• Forensic readiness for this threat class requires pre-incident baselines of firmware hashes and PCR values, artifacts you cannot reconstruct after the fact.

The firmware layer and why it matters

Before cataloging what is exploitable, it helps to be precise about the architecture. UEFI (Unified Extensible Firmware Interface) replaced legacy BIOS on mainstream hardware from around 2010 onward. It is a complete pre-OS environment with its own networking stack, drivers, a file system (the EFI System Partition, or ESP), and a shell. It runs before any operating system component loads, which means anything it executes inherits an environment where no EDR agent, no AV engine, and no kernel patch guard exist yet.

The boot sequence on a modern UEFI system proceeds roughly like this: UEFI firmware (stored in SPI flash on the motherboard) initializes hardware, reads the ESP on the boot disk, loads the boot manager (\EFI\Microsoft\Boot\bootmgfw.efi on Windows), which in turn loads the OS loader, which loads the kernel. A bootkit can insert itself at any stage of this chain. The two most relevant levels for practical forensics are:

• ESP-resident: the implant lives on the EFI System Partition as a modified or additional EFI binary. It persists across OS reinstalls if the ESP is not explicitly wiped, and it can survive drive imaging if the ESP is not included in the acquisition scope.
• Firmware-resident: the implant is written directly to SPI flash on the motherboard. It persists across disk replacement, OS reinstall, and every other remediation step short of physically reflashing the chip.

The distinction matters for both detection and remediation. What these two classes have in common is that they are structurally invisible to anything that runs after the firmware has already executed, which includes every tool in a conventional DFIR toolkit.

ESP and firmware implants at a glance

Known implants in the wild

The forensic understanding of UEFI-level threats is not theoretical. Several real-world implants have been analyzed in enough detail to guide forensic work.

BlackLotus is the most significant recent case, first publicly documented by ESET in March 2023. It is a UEFI bootkit sold as a crimeware product (not exclusively nation-state) that can bypass Secure Boot on fully patched Windows 11 systems by exploiting a vulnerability in the Windows Boot Manager (CVE-2022-21894, also known as Baton Drop). BlackLotus installs a malicious EFI binary to the ESP, disables kernel protections including HVCI and Windows Defender, and deploys a kernel driver and a user-mode HTTP downloader. Even after Microsoft patched the underlying boot manager vulnerability, systems with a valid but vulnerable bootloader version still installed in their Secure Boot database remained exploitable, because the Secure Boot revocation list (the UEFI Forbidden Signature Database, or DBX) was not automatically updated.

The forensic artifacts of a BlackLotus infection on the ESP are reasonably concrete:

\EFI\Microsoft\Boot
├── bootmgfw.efi   # legitimate, but may be replaced
├── grubx64.efi    # BlackLotus drops this as its loader
├── winload.efi    # may be patched
└── system32\drivers
  └── [randomized].sys   # kernel driver

ESET documented the directory \EFI\Microsoft\Boot\system32\ as a BlackLotus artifact on the ESP, a path that has no legitimate reason to exist in a standard Windows installation.

CosmicStrand is an order of magnitude more serious. Kaspersky’s analysis published in 2022 describes a UEFI firmware rootkit attributed to a Chinese-speaking threat actor, found embedded in the firmware images of consumer-grade ASUS and Gigabyte motherboards. CosmicStrand hooks the CSMCORE DXE driver (a UEFI component) to intercept the Windows boot process, injects a shellcode kernel patch, and ultimately deploys a user-mode agent, all before Windows has loaded a single driver. From the OS’s perspective, the system looks clean. The implant is in the SPI flash chip soldered to the motherboard.

MosaicRegressor (attributed to APT41, documented by Kaspersky in 2020) used a modified version of the leaked Hacking Team UEFI implant source code, embedded in the UEFI firmware of victim laptops. It was found on systems used by organizations connected to North Korea-focused research. The infection vector involved physical access or supply-chain compromise. The implant drops a downloader component during the boot process.

MoonBounce (Kaspersky, 2022), attributed to APT41, went further than any of its predecessors by targeting the CORE_DXE component of the firmware, a component that is mapped into virtual memory when the OS starts, and injecting shellcode there. The injection is clean enough that the surrounding legitimate code still functions normally. MoonBounce left no files on disk; the entire attack chain ran from firmware through injected code in the kernel’s own memory.

FinSpy, the commercial spyware sold by FinFisher, was found in 2021 to include a UEFI bootkit component. Its ESET analysis documented infection of the Windows Boot Manager with a component that loaded the FinSpy trojan before the OS kernel initialized. This was significant because it confirmed that commercial surveillance vendors, beyond nation-state operators, had incorporated firmware-level persistence.

The forensic toolkit below Volatility

Volatility does not analyze UEFI firmware. Memory forensics tools analyze RAM, which is populated after the firmware has already handed off execution. By the time Volatility sees anything, a firmware implant has long since done its work.

If you are planning a workflow that mixes memory and firmware analysis, this boundary is worth revisiting alongside my notes on Volatility migration pitfalls and how Windows memory structures shape forensic visibility.

The toolkit for this threat class is different.

CHIPSEC (github.com/chipsec/chipsec) is the primary open-source framework for UEFI security analysis, maintained by Intel. It can read SPI flash contents, check write-protection status, verify firmware integrity against known-good baselines, and detect a range of UEFI vulnerability classes. On a live Windows system:

# Install and run CHIPSEC from PowerShell (requires admin)
python chipsec_main.py -m common.bios_wp
# Checks whether SPI flash write protection is enabled
# A disabled write protection is a prerequisite for most firmware implants

python chipsec_main.py -m common.uefi.access_uefispec
# Checks for UEFI variables with suspicious permissions

# Dump the full SPI flash to a file for offline analysis
python chipsec_util.py spi dump firmware.bin

The firmware.bin dump can then be analyzed offline. A meaningful analysis requires a known-good baseline of the same motherboard model and firmware version, something you need to have collected before the incident. This is one of the fundamental constraints of firmware forensics: unlike memory where you can reason about anomalies without a baseline, firmware analysis almost always requires a reference image to compare against.

UEFITool (github.com/LongSoft/UEFITool) parses UEFI firmware images and EFI binaries into DXE modules, PE images, and volumes. It can extract individual modules from a firmware dump for further analysis. Combined with a disassembler or Ghidra, it becomes the primary path for analyzing suspected firmware modifications:

# Extract all PE32 images from a firmware dump using UEFIExtract (CLI companion)
./UEFIExtract firmware.bin all

# The output directory structure mirrors the firmware layout
# Each extracted PE can be hashed and compared against vendor baselines
# or submitted to static analysis

For ESP-level analysis, the tools are closer to conventional DFIR work. The ESP is a FAT32 partition that is straightforward to image with standard tools. What requires attention is ensuring it is actually included in the acquisition:

# On Linux, identify the ESP and image it specifically
lsblk -o NAME,PARTTYPE,MOUNTPOINT
# Look for partition type EFI System (UUID c12a7328-f81f-11d2-ba4b-00a0c93ec93b)

# Image the ESP directly
dd if=/dev/sda1 of=esp.img bs=4M status=progress

# Mount read-only for examination
mkdir /mnt/esp
mount -o ro,loop esp.img /mnt/esp
ls -la /mnt/esp/EFI/

Once mounted, unexpected directories or EFI binaries can be identified. The expected contents of a clean Windows ESP are well-documented. Anything in \EFI\Microsoft\Boot\ that is not in the standard Windows boot file list warrants examination. File timestamps on the ESP can be informative, though they can also be manipulated.

Authenticode analysis of EFI binaries on the ESP can reveal unsigned or unusually-signed components:

# Using pefile to check EFI binary signatures
import pefile
import hashlib

efi_path = "/mnt/esp/EFI/Microsoft/Boot/grubx64.efi"
pe = pefile.PE(efi_path)

# Check for SECURITY_DIRECTORY (Authenticode signature)
if hasattr(pe, 'DIRECTORY_ENTRY_SECURITY'):
    print("Signed binary")
    # Extract and verify the certificate chain
else:
    print("UNSIGNED - flag for review")

# Hash for comparison against known-good databases
with open(efi_path, 'rb') as f:
    sha256 = hashlib.sha256(f.read()).hexdigest()
print(f"SHA256: {sha256}")

TPM PCR values are the most powerful forensic signal for detecting pre-OS tampering when they are collected in advance. The TPM’s Platform Configuration Registers record measurements of every component in the boot chain: firmware, boot manager, OS loader. If an implant modified any of these components, the PCR values change. Comparing current PCR values against a trusted baseline from initial enrollment is definitive evidence of boot chain tampering.

On Windows, BitLocker stores a PCR profile at enrollment time. On Linux, tpm2-tools provides access:

# Read current PCR values
tpm2_pcrread sha256

# PCR 0: UEFI firmware
# PCR 2: UEFI firmware data
# PCR 4: Boot manager (MBR or UEFI boot application)
# PCR 7: Secure Boot policy
# PCR 8-9: GRUB measurements (if applicable)

# Any deviation from a known-good baseline in PCR 0, 4, or 7
# is a strong indicator of boot chain interference

The forensic limitation: if you do not have a pre-incident PCR baseline, the current values still tell you the state of the boot chain today, but you cannot say definitively when tampering occurred or what the original values were.

Secure Boot limits and caveats

Secure Boot is the primary defense against ESP-resident bootkits. When properly configured, it requires every EFI binary in the boot chain to be signed by a certificate in the UEFI Signature Database (DB). A bootkit binary that is not signed, or whose signing certificate is not trusted, will fail to load.

BlackLotus broke this model not by defeating the cryptographic verification, but by exploiting the fact that the Secure Boot revocation process is slow and optional. The Windows Boot Manager binary it exploited (CVE-2022-21894) was patched, but the vulnerable version remained in the DB as trusted. Booting from a vulnerable but signed bootloader allowed the bootkit to load before Windows could enforce any of its own integrity checks.

The forensic implication is that Secure Boot status is necessary but not sufficient evidence of a clean boot chain:

# Check Secure Boot status on Windows
Confirm-SecureBootUEFI

# Check which certificates are enrolled in DB, DBX, KEK, PK
# Using PowerShell with Get-SecureBootPolicy or native UEFI variable access
[System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI db).bytes
) | Select-String "Microsoft"

# Also check DBX (revocation list) - an outdated DBX is a vulnerability
# Microsoft periodically publishes updated DBX through Windows Update
# Compare the current DBX hash against Microsoft's published values:
# https://uefi.org/revocationlistfile

An outdated DBX combined with a Secure Boot status of “Enabled” gives a false sense of security. This is exactly the configuration that BlackLotus exploits in the wild.

What remediation actually requires

Once a firmware-level implant is confirmed, the remediation path depends on where exactly the implant lives.

For ESP-resident implants (BlackLotus class), the steps are:

1. Image the ESP before any remediation, for evidentiary preservation
2. Boot from external trusted media (not the compromised disk)
3. Wipe and reformat the ESP
4. Reinstall Windows Boot Manager using bootrec /fixboot or a Windows recovery environment
5. Update the DBX to the latest Microsoft-published version
6. Re-enroll Secure Boot certificates from a known-good state

For firmware-resident implants (CosmicStrand/MosaicRegressor class), the options narrow considerably:

1. Obtain the latest clean firmware image from the motherboard vendor for the exact board revision
2. Flash using a hardware SPI programmer if the board is unbootable, or via vendor tools (ASUS EZ Flash, Gigabyte Q-Flash) from a trusted USB drive
3. Verify the flashed image hash against the vendor’s published checksum
4. In cases of confirmed nation-state-grade implants in production systems, hardware replacement is often the operationally cleaner choice because reflashing cannot guarantee the absence of implants in components beyond the main UEFI flash (Embedded Controller firmware, NIC firmware, drive firmware)

The article on wiper disk evolution noted that each generation of destructive malware removes a recovery option. The same logic applies in reverse here: each layer of firmware the attacker reaches is a layer where the defender’s standard tools provide no visibility.

Common false positives in firmware triage

Firmware triage has a high false-positive rate when baseline discipline is weak. The most common cases are:

• Legitimate firmware updates that alter DXE modules and hashes without any malicious activity.
• Normal OEM variance across board revisions that causes mismatches when analysts compare against the wrong reference image.
• Secure Boot key rotation and DBX updates that legitimately change boot measurements and PCR values.
• Dual-boot or recovery tooling that introduces additional EFI binaries in the ESP.

The practical mitigation is procedural: tie every finding to the exact hardware revision, exact firmware version, and a trusted baseline captured for that specific asset class. Without that context, firmware anomalies are easy to overstate.

The first 60 minutes of firmware-aware triage

When firmware persistence is plausible, the initial response window is decisive. A practical workflow for the first hour is:

1. Isolate the host from the network and preserve power state decisions in the case log.
2. Capture volatile context that may disappear after reboot, including current boot configuration, Secure Boot state, and event logs tied to boot integrity.
3. Acquire the full disk with explicit ESP inclusion, then acquire a dedicated ESP image for fast triage.
4. Hash all EFI binaries in \EFI\Microsoft\Boot\ and compare against known-good baselines for that OS build.
5. Validate Secure Boot material, including DB and DBX currency, and record the exact firmware version and motherboard revision.
6. Run CHIPSEC checks focused on SPI write protections and UEFI variable access controls.
7. If suspicion remains high, schedule an SPI flash dump and offline module comparison against a clean firmware reference.

This sequence does not replace deep analysis. It reduces the chance of losing decisive evidence while the case is still fluid.

Forensic readiness for a threat most teams are not ready for

The operational reality of firmware forensics is that it is almost entirely reactive to decisions made before the incident. The difference between a thorough firmware investigation and an investigation that produces a shrug depends almost entirely on whether someone collected firmware baselines, TPM PCR values, and ESP snapshots before the attack.

Most organizations have not done this. The threat intelligence community documented CosmicStrand in 2022, MoonBounce in 2022, BlackLotus in 2023, and still the vast majority of enterprise IR teams have no firmware baseline collection in their standard asset onboarding process. Part of this is tooling immaturity: CHIPSEC is powerful but not a polished enterprise product. Part of it is a threat model problem: firmware implants have historically been associated with nation-state APTs targeting high-value individuals, not broad-based ransomware campaigns. That association is eroding. BlackLotus was sold on criminal forums.

The operational gap mirrors a broader readiness problem discussed in DFIR always on: teams often optimize for speed during incidents, but underinvest in baseline collection that makes deep investigations possible.

A minimal firmware forensic readiness posture looks like this:

• At asset enrollment: run chipsec_util.py spi dump on each new system and store the resulting firmware image with the asset record. Hash it. Note the motherboard model and firmware version.
• Continuously: monitor DBX update status as part of patch management. An outdated DBX is a concrete, measurable risk.
• On critical systems: enable measured boot and record TPM PCR baselines in a trusted attestation store. Remote attestation via TPM 2.0 allows continuous monitoring of boot chain integrity without manual forensic intervention.
• On incident: always include the ESP in forensic acquisition scope. “Full disk image” must mean the full disk, including the FAT32 partition that your imaging tool might skip if not explicitly configured.

The field of firmware forensics has been niche by necessity: the tools are harder to use, the hardware is less forgiving than RAM or disk, and the evidence is often only interpretable against a baseline that was never collected. As bootkits move down-market and the gap between nation-state TTPs and criminal tooling continues to shrink, treating the firmware layer as out-of-scope in DFIR work stops being pragmatism and becomes a genuine operational gap.

FAQ

What is a UEFI bootkit and how does it differ from a traditional rootkit? A UEFI bootkit persists in firmware or EFI System Partition components below the operating system, surviving OS reinstallation, hard drive replacement, and conventional antivirus scans. Traditional rootkits operate within the OS kernel or userspace and are removed by reinstalling the system.

Can a UEFI bootkit survive a full disk wipe or OS reinstallation? Yes. Firmware-resident implants like CosmicStrand or MosaicRegressor are stored in SPI flash memory on the motherboard and survive disk replacement entirely. EFI System Partition bootkits like BlackLotus can survive OS reinstallation if the ESP is not wiped and Secure Boot is bypassed.

What tools can detect UEFI firmware tampering during incident response? CHIPSEC is the primary open-source tool for firmware integrity analysis, capable of detecting write-protection bypass and unauthorized firmware modifications. For EFI binaries, tools like UEFITool, efifs, and Binwalk support parsing and extraction. Volatility 3 does not analyze firmware directly.