Paige Williams sits down with Dominic Jainy, an IT professional working at the intersection of AI, machine learning, and blockchain, who has been deeply embedded with SOC teams wrestling with real-world threats. Drawing on hands-on work operationalizing behavior-driven intelligence and tuning detection pipelines, Dominic explains why the gap hurting most SOCs isn’t tooling or headcount—it’s the absence of fresh, context-rich threat intelligence grounded in live malware behavior. Across this conversation, he unpacks how context trims alert fatigue, how TTP-based detections outlast signatures, how sandbox-linked artifacts accelerate triage, how community-sourced signals from over 15K SOC teams translate into high-quality IOCs, and how all of this turns into measurable improvements in MTTD and MTTR, audit readiness, and resilience across hybrid-cloud enterprises.
You say the real gap in SOCs is missing, fresh threat intelligence—not headline attacks. What moments proved that for you, what metrics shifted after you addressed it, and how did analyst workflows change day to day?
The turning point came on a week when the news cycle was screaming about one family of ransomware, yet our incident queue told a different story—commodity loaders and stealers were doing the most damage because we lacked current, behavior-driven context. Once we plugged in live indicators backed by sandbox sessions, analysts stopped guessing and started recognizing patterns tied to real campaigns. MTTD and MTTR trended in the right direction because decisions moved from hunches to evidence, and research time shrank as context sat right next to the alert. Day to day, workflows shifted from tab-hopping and ad hoc googling to a consistent triage routine grounded in TTPs, linked hashes, and session artifacts—less firefighting, more confident action.
When alert fatigue hits, how do you triage with context-rich indicators—what fields matter first, and can you share a before-and-after MTTD/false-positive story?
I start with reputation and recency—IP/domain associations seen in active campaigns, then pivot to malware family tagging and TTP notes pulled from the sandbox. If an indicator is tied to recent behavior—process injection, suspicious persistence writes, outbound beacons to fresh infrastructure—it moves to the top of the queue. Before we had this level of context, our triage relied on static blocklists and signatures, which inflated false positives and stretched investigations. After enrichment, the noise dropped because every alert carried a backstory—linked sessions, related hashes, and known techniques—so we could dismiss dead ends quickly and fast-track true positives without second-guessing.
You call out TTP-based detection over signatures. How do you translate recent TTPs into rules, what logs and fields do you prioritize, and which detections caught modified payloads you’d otherwise miss?
I translate fresh TTPs into behavioral rules by mapping technique notes from sandbox runs to fields we already ingest—process ancestry, command line parameters, registry write events, script interpreter activity, and outbound network patterns. Endpoint logs give me the process tree and command lines; DNS and proxy logs give me domain resolution and URI patterns; and identity telemetry highlights credential misuse. That combination catches payload variants that deliberately mutate signatures but repeat the same mechanics—like abusing a living-off-the-land binary with an obfuscated command line followed by a distinct C2 handshake. Those rules survived payload churn because they hinge on how the attacker moves, not what the binary looks like.
Walk us through a zero-day–like case you handled. What telemetry clues stood out, how did sandbox behavior guide next steps, and which playbook steps trimmed investigation time the most?
The clue was a clean file reputation coupled with an odd process lineage—an unexpected script host launching a LOLBin that reached out to newly registered infrastructure. In the sandbox, we saw staged credential harvesting, silent persistence via registry autoruns, and a second-stage download with evasive sleep timing. We leaned on the playbook steps that use session-linked artifacts: pull related hashes, block associated domains and IPs, and search for the same process tree across endpoints. The biggest time saver was jumping straight from the alert to the sandbox session, then to ready-to-execute containment actions—no prolonged hunting for breadcrumbs across disconnected tools.
You mention 15K SOC teams fueling ANY.RUN’s feeds. How does that community signal turn into high-quality IOCs, what validation steps cut noise, and what metrics prove the signal-to-noise ratio beats traditional feeds?
The community uploads and analyzes live samples, and the platform extracts indicators from real executions, not theoretical detections, which dramatically sharpens fidelity. We validate by cross-referencing behaviors within the session—process actions, network traces, and dropped files—so an IOC isn’t just a string; it’s anchored to observed TTPs. That grounding cuts noise compared to static or stale sources inflated by web-scraped artifacts. The proof shows up in fewer wild goose chases and quicker, more decisive responses—analysts trust the feed because each IOC points back to concrete behavior, not a vague label.
With live behavior-driven indicators, which behaviors do you weight most, how do you map them to ATT&CK, and what examples show early detection before infrastructure rotated?
I weight persistence changes, credential access attempts, and C2 patterns that include domain generation or fast-flux style pivots—those are the heartbeat of a campaign. Mapping to ATT&CK happens naturally: persistence via registry or scheduled tasks, credential access via LSASS-targeted actions or browser data theft, and command-and-control via beaconing intervals and protocol quirks. We’ve flagged campaigns early by correlating a new domain’s first beacon with known technique fingerprints from the sandbox session—even as the adversary rotated infrastructure. Because the behaviors stayed constant, we acted on day-one indicators instead of waiting for coverage to trickle into signatures.
Context links back to sandbox sessions. Which session artifacts do you review first, how do you pivot from them, and can you walk through a step-by-step pivot that led to quick containment?
I begin with the process tree to understand the attacker’s storyline, then network traces to see who the sample talks to, and finally the dropped files to map secondary payloads. From the parent process, I pivot to command lines and spawned children, then branch into domains and IPs pulled from the packet capture. A recent pivot went like this: alert fires on suspicious script host → open linked sandbox session → confirm LOLBin misuse plus outbound to a domain in the session → query SIEM for that domain across the enterprise → find two more endpoints resolving it → push an immediate block and isolate hosts via EDR. Start-to-finish, the session artifacts stitched the picture together so we could move from detection to containment without friction.
On integration, how do you wire the feeds into SIEM, SOAR, and EDR, what parsers or field mappings matter most, and which automation reduced MTTR without spiking false positives?
We ingest the feed into the SIEM with parsers that normalize indicators and their context—indicator type, confidence, first-seen timestamp, related families, and a direct link to the sandbox session. Field mapping is critical: aligning indicator fields to asset, user, process, and network schemas ensures joins work cleanly across EDR and identity logs. SOAR runs playbooks that enrich alerts with session context, execute scoped blocks on domains/IPs, and launch host quarantine when multiple corroborating signals line up. Automation stayed precise because each step required behavioral confirmation from the linked session—not just a blind match on a string—so MTTR fell without lighting up the on-call with false alarms.
Budget constraints are real. How do you show ROI from improved MTTD/MTTR, what cost buckets shrink first, and which dashboard convinced leadership to keep funding the program?
I tie ROI to reduced investigation hours and fewer escalations—shorter MTTD/MTTR means less time spent per case and fewer incidents spiraling into disruption. The first cost buckets to shrink are overtime, emergency contractor hours, and the soft costs of business interruptions. A dashboard that resonated showed cases resolved with sandbox-backed context versus those without; leadership could see analysts moving from hours of manual research to minutes of decisive action. Pair that with trend lines showing steadier operations during peak threat weeks, and funding became an easy decision.
For remote workforces and cloud migrations, which telemetry gaps hurt most, how do you enrich those with TI, and can you share a case where feed-driven detections covered a cloud blind spot?
Remote endpoints and cloud services often sit outside traditional perimeter visibility, so gaps appear in process lineage, DNS egress, and identity events that hop across providers. We enrich by correlating behavior-driven indicators with what we do see—proxy logs, endpoint events from managed devices, and identity signals from cloud IAM. One case hinged on a cloud-hosted workload making outbound calls to a domain seen in a fresh sandbox session; the feed gave us the missing context to prioritize the alert even though the binary looked innocuous. That enrichment bridged the blind spot long enough for us to block the path and investigate the workload safely.
You highlight ransomware, stealers, and loaders. Which families feel most active right now, what loader-to-payload chains are you seeing, and how did feed updates change your blocking and hunting playbooks?
Activity ebbs and flows, but loaders and stealers remain the workhorses because they set the stage for ransomware or data theft. We see chains where a loader drops a stealer to inventory credentials and browser data before staging the heavier payload. Feed updates refocused our blocking on early-stage infrastructure and shifted hunting toward the behaviors that enable the chain—persistence changes, credential access attempts, and the first C2 handshake. By leaning on live behavior, our playbooks stopped chasing names and started dismantling the steps that all those families share.
Tell us about a high-noise day in the SOC. How did you cut noise using campaign context, how did you tune rules without losing coverage, and what measurable outcomes stuck a month later?
We had a morning where alerts spiked across multiple geos due to a phishing wave. We calmed it by clustering alerts around campaign context from the feed—same domains, similar beacons, and shared process behaviors—so analysts could treat them as one outbreak, not dozens of isolated cases. We then tuned rules to require a combination of campaign-linked indicators and behavior—no single weak signal could trigger an urgent response. A month later, the improvements held: analysts reported fewer duplicate investigations and more time spent on real incidents, with coverage intact because behavior remained the core criterion.
How do you keep detection rules current as attacker tooling shifts, what review cadence do you use, and which change control process stopped rule decay while keeping on-call analysts in the loop?
We set a regular review cadence that tracks the latest TTPs from the feed and compares them to our existing rules—retire what’s stale, refine what still works, and add behaviors we see in fresh sessions. Change control runs through a lightweight approval flow: proposed rule changes reference the sandbox session, ATT&CK mapping, and expected outcomes, then get a controlled rollout with monitoring for unintended side effects. On-call analysts get concise change notes and an example alert screenshot, so they know what to expect at 2 a.m. This rhythm reduced rule decay because each change was anchored to observed behavior, not theoretical possibilities.
For compliance and audits, how do you evidence threat monitoring from these feeds, which artifacts do auditors value, and what metrics or timelines helped you pass a tough audit?
We package cases with the full lineage: feed indicator details, the sandbox session link, related hashes, domains, and the playbook actions taken. Auditors value concrete artifacts—hash lineage, IP and domain blocks, case notes timestamped from alert to containment, and the ATT&CK techniques observed. We walk them through timelines showing how context-enabled triage trimmed detection and response, and how consistent playbooks supported repeatable outcomes. Because everything ties back to verified behavior, our evidence reads like a narrative rather than a pile of disjointed logs, which satisfies both technical and governance scrutiny.
What is your forecast for threat intelligence–driven SOC operations?
I see behavior-first intelligence becoming the default, with community-sourced signals continuing to accelerate visibility, especially as more teams contribute live samples every day. SIEM, SOAR, and EDR will converge around context as the currency—rules will be born from TTPs mapped directly to sandbox observations, not retrofitted from signatures. As hybrid environments grow, the winners will be the SOCs that stitch together endpoint, identity, and network clues with live session artifacts to act before infrastructure rotates. The most resilient programs will put fresh, trustworthy data at the center—so analysts trade guesswork for clarity and consistently make the right move when it matters.