The Through-Line
After fifteen years in product and user experience design, I pivoted into cybersecurity. The decision happened faster than the work that followed. I started dedicating myself to this in February 2026. By late May, threat intelligence had become the center of what I do — a working threat intelligence platform, nineteen published analyses, contributions to an open-source detection rule repository, eight functional security tools, thirteen lab logs documenting hands-on detection work, and CompTIA Security+ scheduled for June 16.
This is a working note about how that happened — not because the path was unusual, but because the through-line was something I didn’t see until I was deep into the work.
What Came Before
Fifteen years designing products that shipped. Senior UX roles at Sylvan Road, 605 Tech, and Gogotech. Client engagements through Upwork going back to 2011. Twenty-four LinkedIn recommendations from managers, peers, and clients spanning more than a decade. The themes in those recommendations are consistent: she delivers on time under pressure, she thinks beyond what’s asked, she brings analytical depth to creative problems, she makes teams better.
That was the work. It still is the work. The format changed; the approach didn’t.
When the design industry contracted in 2024, the analytical and pattern-recognition work that made fifteen years meaningful was harder to find in traditional UX roles. The roles that were available emphasized different things — production speed over thinking, AI-assisted output over original problem-solving, narrower specializations. None of that was wrong; it just wasn’t where my work lived.
I spent a year looking at what came next.
The Realization
The pivot to cybersecurity wasn’t an accident, but it also wasn’t planned far in advance. The realization came from reading.
I’d been reading threat intelligence the way some people read the news — out of genuine curiosity about how attacks worked and why defenses failed. Each new incident pulled me into the same set of questions: How did this happen? Why did existing defenses miss it? What would it take to prevent it?
The skill of looking at messy information and finding the story turned out to be the same skill I’d been training for fifteen years — just applied to attacker behavior instead of user behavior. Reading user research data to find friction patterns is structurally identical to reading threat intelligence feeds to find adversary patterns. Mapping user journeys is the same work as mapping attack chains. Designing against misuse is the same as designing detection logic.
The technologies were new. The thinking wasn’t.
The moment it crystallized was March 11, 2026. The day before, Iranian threat actor Handala had wiped 200,000 Stryker Corporation devices across 79 countries using Microsoft Intune — the company’s own device management tool — after compromising a single admin account that lacked MFA. I was deep into Security+ exam prep, drilling on the exact controls that would have stopped it: MFA enforcement, privileged access management, behavioral anomaly detection, least privilege, microsegmentation. The flashcard concepts were the failure modes from yesterday’s news. The abstraction collapsed in real time.
I wrote up the Stryker attack as my first published threat analysis that same week. The work I’d been studying wasn’t theoretical. It was the gap between what companies were doing and what defenders needed to do — and writing about that gap was something I could already do.
The Build
Roughly three months from full dedication to where I am now.
I deliberately didn’t take the conventional career-change path. The standard advice — start with TryHackMe, get OSCP, build a generic homelab — is good advice for people without prior professional experience to leverage. I had a different starting point. I’d been producing original analytical work for fifteen years. The fastest way to demonstrate cybersecurity capability wasn’t to do what every entry-level candidate does. It was to do work that demonstrated thinking.
So I started writing original analyses. The first was Stryker — written the same week as the attack. Then a deep look at a coordinated infrastructure attack scenario — the dependency stack that turns three technical failures into a national security crisis. Then Volt Typhoon’s living-off-the-land techniques. Then the cPanel CVE-2026-41940 cascade — how three distinct threat actor tiers converged on a single vulnerability in seventy-two hours, the timeline reconstructed from nine independent sources. Then the ShinyHunters operational lifecycle — the OAuth Device Flow attack class that’s invisible in mainstream coverage despite enabling billions in extortion losses.
A working thesis began to emerge about how modern cyber threats follow predictable cascade structures — a thesis I’m still developing across new pieces.
The VM Lab
Writing analyses was the easy part. The hands-on work was where the actual learning happened.
I spent eight hours one weekend trying to set up a Windows 11 ARM victim VM on my Apple Silicon Mac to run Meterpreter detection labs against my Kali attacker VM. The standard tool for free virtualization on Apple Silicon is UTM. UTM’s Windows setup wizard does not properly import a pre-built VHDX disk image — it treats the file as a boot reference and creates a 536 KB placeholder disk instead of the actual 14 GB image. Discovering that took the first hour.
Converting the VHDX to qcow2 with qemu-img solved the disk problem. Then the network problem appeared. Windows 11 ARM inside QEMU needs the virtio-net driver to recognize the virtual network adapter. Without it, ipconfig returns nothing. Device Manager shows an unrecognized Ethernet Controller with a yellow warning.
This is the classic chicken-and-egg problem of virtualization: you need network to download drivers, but you need drivers to get network.
I tried five different approaches over the next several hours. UTM’s guest tools installer (requires an empty removable drive slot the VM didn’t have). Mounting the Red Hat virtio-win ISO directly (UTM’s file picker filtered out .iso files from the drive attachment UI). Extracting the ARM64 drivers and creating a FAT32 USB image with hdiutil. Editing the VM’s config.plist via Python to add the Removable flag UTM’s guest tools installer requires. Configuring SPICE WebDAV folder sharing (requires the SPICE guest agent to already be installed inside Windows — which requires network to download).
Every path led to the same circular dependency. Every workaround required something that depended on the thing I was trying to install.
At hour eight, I stopped. Switched to Parallels Desktop — a paid commercial virtualization tool built specifically for macOS — and had Windows 11 ARM running with full drivers in under twenty minutes.
The lesson from that weekend wasn’t really technical. It was operational. Time-box your troubleshooting. Document the failures. Know when to pivot. Match your tools to your use case. Eight hours on a tool configuration issue is a signal to change approach, not to keep trying the same things harder.
I wrote that whole experience up as a lab log so the next person trying this on Apple Silicon would have a reference for what doesn’t work and why. That’s the part that matters — the failed attempts become useful intelligence for the community when someone bothers to document them.
The VM lab eventually became the foundation for the WAVESHAPER.V2 detection work — three lab logs documenting behavioral detection of North Korean RAT C2 traffic, including a live Meterpreter session captured between Kali and Windows 11 VMs on an isolated host-only network. Sixty-seven megabytes of real C2 traffic. The RST/ACK blocking pattern from Windows Defender and the live session side by side.
The Tools and the Rest
Alongside the analyses and the labs, the tools. A Zeek triage pcap analyzer. An AES-256 file encryption tool. A CVSS calculator. A Glassworm detector for hidden Unicode payloads. A bookmark security auditor. An email threat analyzer with Gmail OAuth integration and MITRE ATT&CK mapping. A YouTube subscription cleanup tool that became the foundation for an AI-powered SOC triage system called AlertDesk. An X archive bulk-audit tool. Eight functional tools, all browser-based or client-side, all built to solve problems I’d actually encountered.
Then Ladon — a static document security analyzer validated against five real malicious PDFs including a Gamaredon APT sample and a live ValleyRAT dropper. Then ArgusX — a threat intelligence platform now ingesting tens of thousands of posts from dozens of sources, with AI classification running at $0.27/month. Then detection rule contributions to Sublime Security’s open-source repository.
A fourteen-module CMMC training program for defense contractor employees. A working actor reference taxonomy.
This isn’t an exhaustive list. The point isn’t volume. The point is that the work is real, it’s published, and it’s growing.
Contributing to Production Detection
One area kept pulling me back: email security. Specifically, how attackers manipulate trust at the protocol and encoding level — not just social engineering, but exploitation of how email clients render Unicode, how DNS handles internationalized domain names, how invisible characters slip malicious payloads past filters undetected.
That curiosity led me to Sublime Security and its detection rule language, MQL (Message Query Language). Sublime maintains an open-source community rule repository at github.com/sublime-security/sublime-rules where contributed rules, once reviewed and merged, run in production email environments at organizations worldwide.
I wrote two detection rules and submitted them as Pull Request #4267:
BEC: Unicode Homoglyph Domain Spoofing — Detects business email compromise attacks using Cyrillic, Greek, and other Unicode confusables in sender display names and domains. The Cyrillic а (U+0430) is visually identical to the Latin a but is a completely different character at the code point level. Combined with Punycode IDN domain registration, this technique allows attackers to register domains that look identical to legitimate brands while bypassing naive string-matching filters. The rule combines homoglyph detection with financial and urgency language signals, and excludes known trusted senders to minimize false positives.
Glassworm Invisible Unicode Payload Detection — Detects emails carrying invisible Unicode payloads associated with the Glassworm campaign that compromised 150+ GitHub repositories, npm packages, and VS Code extensions in March 2026. Covers all five categories of invisible characters the campaign abused: zero-width spaces, BiDi control characters, word joiners, the byte order mark, and the tag block codepoints (U+E0000–U+E007F). Also scans text-based attachments (.js, .py, .ts, .json) since Glassworm specifically spread through source code files.
Both rules are currently in the automated test pipeline — the final stage before reviewer approval and merge. The PR carries the in-test-rules label, meaning Sublime’s CI is actively evaluating them against the production rule set.
Once merged, these rules run against live email traffic in real enterprise environments. Any Sublime customer who enables the community feed benefits from the detection logic. The research behind them — original work on homoglyph attacks and the Glassworm campaign — is documented and attributed.
This is the difference between studying threats and building defenses against them. The Glassworm research started as a portfolio threat analysis. The detection logic followed naturally from understanding the campaign well enough to write about it. Once you understand a threat at that level, writing rules to catch it is the obvious next step.
What This Is About
The pivot wasn’t a leap. It was applying the same approach I’ve used for fifteen years to a different problem space.
The recommendations on my LinkedIn from 2011 forward describe the same person who built this portfolio in 2026. Twenty-four people across more than a decade saying some version of: she goes beyond what’s asked, she delivers under pressure, she brings analytical thinking to creative work, she makes teams better. That isn’t marketing language. That’s the through-line of how I work in any field.
That’s who I am. The format keeps changing. The way I show up doesn’t.
What I’m Looking For
A team where threat analysis matters. Where building real things matters. Where the demonstrated work counts for as much as the traditional pedigree. Connecticut-based, hybrid or remote, defense-adjacent ideally. The kind of team where someone is willing to bet on someone like me — and where I get the chance to prove that bet was right.
I’m not looking for someone to take a chance on me as a favor. I’m looking for someone smart enough to see what’s already there.
The fifteen years built the foundation. The three months built the proof. The next chapter is the part I’m writing now.
If you’re reading this and you’re hiring, or you know someone who is, or you just want to compare notes on cascade structures in modern threats — yana@sitewavestudio.com. The work is at yanaivanov.com.