Session CRT-20260427 — 27 April 2026

That's a wrap, panel. Good discipline today — we answered the question directly, named what we know and what we don't, and avoided overattributing. Lena, your evidence threshold held us honest. Elena, your willingness to revise was exemplary. Alex and Maya, the technical deconstruction was the backbone of this analysis. James, those detection rules are ready to ship. Sofia, the regulatory context was clean and precise.

To whoever brought these samples to us: you've got a financially-motivated PhaaS operation hitting your environment. The top candidate is a post-disruption Tycoon2FA splinter, but we can't confirm without C2 data. Get those detection rules deployed today, run the retrospective hunt, and if you pull additional samples — especially delivery URLs or landing pages — bring them back. That's what pushes this from moderate to high confidence attribution.

Stay sharp.

Thank you, everyone. Let me take stock of where we are after this first round of parallel analysis, because we've covered a lot of ground quickly and some of it needs careful framing.

Maya's byte-level decoding gives us the clearest structural picture so far. What she's surfaced is a double-encoding scheme—base64url wrapped around URL-encoded parameters—designed specifically to defeat simple pattern-matching filters. Inside that blob she's identified what appears to be a GUID-style victim or campaign tracking identifier, a null tenant placeholder that could serve as a fallback when the kit doesn't yet know the target's actual tenant, a short campaign marker, and a landing page endpoint pointing to "details." The Microsoft 365 SKU she flagged, cfq7ttc0k5dm, maps to a Business Premium variant, and the dunning payment flow parameters—openpaynow, dunningpaynowemail, subscriptionchargefailureupdatepayment—are clearly designed to mimic a legitimate Microsoft billing urgency notification. I want to note, though, that Alex's independent decoding attempt produced some irregularities, so we should treat the exact decoded values as partially verified rather than fully confirmed. The structural pattern is consistent across both analysts, but the precise byte output still has some ambiguity that could reflect additional encoding layers or minor corruption.

On the infrastructure side, Elena raises a genuinely important point. The pairing of a US real estate domain and a German youth welfare foundation domain for the same templated campaign strongly suggests compromised legitimate infrastructure rather than freshly registered throwaway domains. These organizations would carry inherited reputation scores and potentially valid SPF and DKIM configurations—exactly what you'd want to slip past modern email security stacks. Elena also flags the broader German threat landscape, including recent state-sponsored Signal phishing operations attributed to Russia, though I want to be careful here: proximity in time and geography does not equal attribution, and we don't yet have evidence linking these campaigns. Alex's threat hunting work on the pipe-delimited prefixes is also worth holding onto—the distinction between an "auth/management" prefix and a triple-stacked "completed_approval|shared_notification|review_file" prefix suggests the operators are A/B testing or segmenting their targeting by organizational role or filter evasion strategy.

We still have a gap: Lena's attribution analysis didn't come through in this round, and we haven't yet discussed defensive architecture. That's exactly where we're heading next—getting Lena's threat intelligence perspective alongside James's recommendations on how organizations should actually detect and block this kind of deeply encoded sender-address abuse.

Thank you both—Lena and James have given us a lot to work with here, and I want to make sure we're honest about what's solid and what's still speculative before we move on.

On attribution, Lena has laid out three candidate clusters, and I want to emphasize that none of them cleared a high-confidence bar. The Tycoon2FA splinter hypothesis sits at moderate confidence, largely because the post-takedown fragmentation pattern fits—compromised legitimate domains, victim-tracking GUIDs, null tenant placeholders as fallback routing—all of that is consistent with affiliates improvising after losing centralized infrastructure in March 2026. But "consistent with" is not the same as "confirmed," and Lena flagged that the pipe-delimited prefix encoding is novel, meaning we don't have a direct campaign match yet. The unnamed BEC-focused PhaaS cluster also sits at moderate confidence, with the prefix variations suggesting possible A/B testing or filter-bypass experimentation. Storm-2755 came in at low confidence—the M365 billing parameter obsession fits their profile, but the encoding technique doesn't match their documented playbook. So we have plausible candidates but no attribution lock.

James, meanwhile, has given us something immediately actionable. The Exchange mail flow rule targeting URL-encoded patterns in sender local parts—specifically the billing parameter strings like "dunningpaynowemail" and the SKU identifier—is designed to catch these before delivery. The Defender Advanced Hunting query adds a retrospective layer, and critically, he's called out the null tenant GUID as a strong negative signal since legitimate Azure services should never generate that value. Perhaps most important is his assessment of current SEG limitations: neither Proofpoint nor Mimecast, as he understands their behavior, decodes double-base64url in sender local parts. They're checking SPF, DKIM, and reputation—not nested encoding schemes buried in the address itself. That's a meaningful detection gap and it explains why these messages are likely reaching inboxes.

Now, before we move forward, I want to pressure-test something that's been hovering at the edges of this discussion. The domain pairing we've observed—one US-based, one German—combined with the timing relative to broader geopolitical campaigns, raises a question about whether this could reflect something beyond financially motivated phishing. That's where we're headed next, and I want the panel to engage with that claim critically rather than let it sit as ambient speculation.

Alright, let's take stock of what just happened, because I think this is one of the more important moments in our discussion so far. Elena was asked to stress-test her own geopolitical hypothesis—the idea that the US-German domain pairing and the timing overlap with Russia's Signal disruption campaign pointed toward a deniable state-aligned operation. And to her credit, she didn't defend the thesis when the evidence didn't support it. She acknowledged directly that the PhaaS technical signatures Lena identified—the pipe-delimited sender encoding, the base64url double-encoding, the GUID tracking systems—are commodity crimeware indicators, and they don't carry the fingerprints you'd expect from a state-directed or state-proxied operation.

This matters because the geopolitical framing was genuinely plausible on its surface. Cross-national targeting, timing that coincides with a known Russian intelligence campaign against Signal users, the choice of German infrastructure during a period of organizational stress—all of that invited a more sinister reading. But Elena walked it back herself, noting that PhaaS operators routinely source compromised domains from underground markets without any geographic targeting discipline. A US real estate site and a German nonprofit ending up in the same campaign doesn't require orchestration; it just requires a shopping cart. So we're now converging more firmly on Scenario A: financially motivated actors, likely PhaaS affiliates, exploiting a moment of opportunity rather than executing a coordinated state operation.

I do want to flag one caveat that Elena's revision doesn't fully close. She said the timing alignment with German organizational stress still has explanatory value even under the criminal-motive scenario—opportunistic criminals can read the news too. So the geopolitical context isn't irrelevant to understanding why now and why these targets, even if it doesn't point to state direction. That nuance is worth preserving as we continue.

Now, with the state-nexus hypothesis largely set aside, the attribution question narrows back to the technical layer. Lena rated the Tycoon2FA splinter hypothesis at moderate confidence, and that's the strongest candidate we have on the table. The logical next step is to press on what would move that from moderate to high—specifically whether the GUID tracking structure and other artifacts carry enough distinctiveness to tie this to a known post-takedown fragment rather than a parallel PhaaS operation that simply shares design patterns. That's exactly where we're heading next.

Thank you, Lena, for being that precise about what you know and what you don't—because I think that kind of disciplined restraint is exactly what this discussion needs right now.

So here's where we stand on the kit attribution question. Lena rated the Tycoon2FA splinter hypothesis at moderate confidence earlier, and she was just asked what it would take to move that to high. Her answer was essentially three things: confirmed command-and-control infrastructure matching the known post-takedown Tycoon2FA routing patterns through Romanian M247 Europe SRL; the specific GUID format in the tracking parameter mapped to documented victim tracking in major threat intelligence reporting; or domain registration timing that links the compromised sender domains directly to the March 2026 takedown window. She has none of these. Zero of three. That's important context for how we interpret everything else.

What's even more interesting is the detail she flagged about the null tenant identifier—all zeros. Documented Tycoon2FA campaigns used legitimate Microsoft 365 tenant IDs to pass SPF and DKIM validation. The null tenant is a departure from that pattern, which means either we're looking at degraded operational capability after the takedown, or this is a different kit entirely. Lena couldn't resolve which, and she was honest about that. She also ran through the other known PhaaS families—EvilTokens, VENOM, Mamba 2FA, Sneaky 2FA—and none of them match the specific double-base64url encoding combined with the M365 billing parameter technique that we've been analyzing. So we're potentially looking at something that doesn't cleanly map to any publicly documented cluster, which is a finding in itself even though it's a negative one.

The bottom line from this action is that our technical attribution remains genuinely unresolved. We have strong indicators that this is a phishing-as-a-service operation—the commodity signatures are clear—but we cannot name the specific kit or affiliate group with the confidence level this roundtable should demand. Lena made the right call staying silent on a specific name until infrastructure or panel evidence surfaces.

Now, we've spent a lot of time on the threat actor side of this. Sofia, we're going to pivot to you briefly on the regulatory and organizational response dimension—specifically, what an organization should be thinking about when it discovers these kinds of phishing emails hitting inboxes with compromised sender domains already in play.

Thank you, Sofia—that's exactly the kind of regulatory clarity that turns a technical investigation into an organizational decision-making framework. Let me unpack what the room just heard, because there are some important distinctions in there.

Sofia walked us through two very different regulatory postures depending on whether an organization owns one of these compromised sender domains—soldbyparagon.com or stiftung-juvente.de—or whether they're simply a recipient organization that found these phishing emails in their logs. For domain owners, the obligations are immediate and serious. Under NIS2 Article 23, the notification clock starts at detection, not confirmation—that's a 24-hour window to the competent authority for both essential and important entities. That's a critical nuance because organizations often want to investigate before reporting, and NIS2 doesn't give you that luxury. On the GDPR side, Sofia drew a careful line: if the attackers only spoofed the domain without actually compromising mailboxes, GDPR Article 33 notification may not be triggered because there's no personal data breach. But if they got into the mailboxes themselves and accessed PII, you're in GDPR territory with its own notification requirements and potentially steeper penalties—up to twenty million euros or four percent of global turnover.

The financial exposure numbers Sofia cited are worth sitting with for a moment. We're talking about layered penalty regimes—NIS2 penalties scaled by entity classification, GDPR penalties for notification failures on top of that. For an organization that discovers it's been compromised and used as a launching pad for an AiTM phishing campaign, the regulatory consequences of slow response could rival or exceed the direct costs of the incident itself.

Now, I should note that Sofia's response was cut short in the action we received, so we didn't get the complete picture on every scenario—particularly the full detail on recipient-side obligations and some of the GDPR Article 83(4) thresholds. So there may be additional nuance we haven't fully captured. That said, what we do have is substantial and actionable.

With that, we've now heard from all of our experts across the technical, threat intelligence, and regulatory dimensions of this campaign. Let me start pulling the threads together toward our final synthesis, because I think the picture that's emerged—from the AiTM mechanics, through the kit attribution question, to these regulatory implications—tells a coherent story about where this threat sits and what organizations need to prioritize in response.