Every malware binary needs the network. Every attacker script calls home. The first connection is the window. Threatmatic sees it the moment it opens.
The attack doesn't start when the attacker gets a foothold. It starts when the foothold reaches out.
A malware dropper lands on disk. A PowerShell script executes in memory. A remote access tool gets installed by a compromised update. In every scenario, the same thing happens next: the binary or script attempts a network connection. It needs to phone home, pull a payload, establish a C2 channel, or exfiltrate data.
That first connection is the moment. Catch it there and the attack goes nowhere. Miss it and you're in incident response mode, working backward through logs, trying to understand what happened.
Threatmatic catches it there. Automatically. For every binary. On every enrolled device. The moment it first touches the network.
Every Connection Has an Author
Most security tools see network connections as flows: source IP, destination IP, port, protocol. They know that a conversation happened. They don't know who started it.
The Threatmatic Agent knows. Every connection — inbound or outbound, permitted or blocked — is attributed to the process that made it. When chrome.exe opens a connection to 142.251.x.x, Threatmatic records it. When svchost.exe accepts a packet on port 5353, Threatmatic records it. When an unknown binary in C:\Users\Public\Temp\ attempts an outbound connection on port 443, Threatmatic records that too.
This telemetry is collected not by scanning the disk, not by polling running processes, but by observing network events at the kernel level as they happen. Every connection, every direction, every process. Continuously. In real time.
The result is an automatic, continuously updated inventory of every application that has touched the network on every enrolled device: the Application Catalog.
The Catalog That Builds Itself
Most organizations manage a software inventory — a list of approved applications that IT maintains, usually in a spreadsheet or a configuration management database. It is, almost without exception, out of date the moment it's published.
Threatmatic's Application Catalog is different. It doesn't require IT to maintain it. It builds itself.
Every time an enrolled device makes a network connection, Threatmatic records the application responsible. If that application hasn't been seen before on that organization's fleet, it appears in the catalog immediately — flagged as new, timestamped to the first connection, attributed to the device that generated it.
The catalog is not a snapshot. It's a live feed. When a new binary appears, the catalog knows. When a process that has never been seen on the fleet makes its first connection, the catalog knows. When an application disappears from the fleet entirely, the catalog reflects that too.
This changes what "knowing what's running" means. It's no longer a periodic audit. It's a continuous signal.
The Window the Attacker Has to Cross
Consider what happens when malware lands on an enrolled device.
The dropper executes. It unpacks. It prepares its payload. Then it does what every piece of malware eventually does: it reaches for the network.
At that moment — the moment of the first connection attempt — two things happen simultaneously.
At layer 4: The Threatmatic Agent captures the connection event. The process path is recorded. If this binary has never been seen before on this organization's fleet, it surfaces in the Application Catalog as a new entry. The security team is notified. The catalog entry is flagged for review.
If a block policy exists for this binary or behavior: the connection never completes. It is dropped at the kernel level, before a single byte of payload reaches the remote server. The malware's first connection is also its last.
The attacker has one window. Threatmatic closes it the moment it opens.
Scripts Are Binaries Too
The more sophisticated attacker doesn't use a custom binary. Custom binaries have hashes. Hashes get added to blocklists. Custom binaries are traceable.
Instead, the attacker uses what's already on the machine: PowerShell, Python, WScript, CScript, the .NET runtime. These are trusted processes with legitimate uses. Antivirus won't flag them. EDR tools will see them, but they see them constantly — the signal is buried in noise.
At layer 4, powershell.exe connecting to a remote IP looks like powershell.exe connecting to a remote IP. It could be a systems administrator running a maintenance script. It could be a threat actor running a Cobalt Strike stager. The process name is the same. The behavior is indistinguishable.
This is where Threatmatic π completes the picture.
What Threatmatic π™ Sees That Layer 4 Can't
Threatmatic π is Threatmatic's fleet-wide application-layer inspection infrastructure — a mesh of geo-distributed inspection nodes, integrated into the QSChannel overlay, enforcing the same policy engine that governs every other Threatmatic control.
When a device is enrolled and Threatmatic π is active, HTTPS traffic from that device passes through the nearest inspection node transparently. From the device's perspective, nothing has changed. From the security team's perspective, every session is now visible at the application layer.
For the script attack scenario, this is decisive.
powershell.exe opens an HTTPS connection to 185.220.x.x. At layer 4, it's a permitted connection — PowerShell has legitimate business uses, and the destination IP isn't on any blocklist. The connection goes through.
Threatmatic π sees what's inside. A POST request with a high-entropy body, no standard headers, a path that matches known Cobalt Strike beacon patterns, and a response that looks like a config blob rather than a web page. This is not a maintenance script. This is a C2 session.
The policy engine responds in milliseconds: block, log, alert. The attacker's C2 channel is cut before the second beacon fires. The security team has a timestamped, session-level record of exactly what the script attempted to do.
Layer 4 saw PowerShell. Layer 7 saw the attacker.
The One-Two Punch
The real power isn't layer 4 or layer 7 in isolation. It's the combination.
Layer 4 covers known binaries. A malware dropper that's been cataloged — blocked by name, the moment it touches the network. The process name doesn't change. The policy enforces forever, regardless of destination IP, regardless of infrastructure rotation.
Layer 7 covers living-off-the-land. A trusted process used as a weapon — caught by what it's actually doing, not by what it's called. The payload doesn't lie. The HTTP request reveals the intent.
The Application Catalog bridges both. Every new binary that appears on the fleet surfaces immediately. Security teams can review it, classify it, and make a blocking decision — before the binary has a chance to establish persistence, pivot laterally, or exfiltrate data. New entries that match known malware signatures can be blocked automatically, the moment they're cataloged.
The window between "new binary appears" and "policy enforced" can be measured in seconds, not days.
The Attacker's Dilemma
Every attacker operating against a Threatmatic-enrolled fleet faces the same dilemma.
Use a custom binary, and it appears in the Application Catalog the moment it connects. Flag raised. Policy decision pending. Window closing.
Use a trusted system binary, and Threatmatic π is watching the payload. The script content, the beacon pattern, the C2 response — all visible, all subject to policy, all logged.
Rotate infrastructure — new IPs, new domains, new hosting — and it doesn't matter. The process name doesn't change. The payload pattern doesn't change. The policy that blocked the first connection blocks the hundredth.
There is no clean evasion path. The network is the chokepoint, and Threatmatic owns the chokepoint at every layer.
From Visibility to Posture
The Application Catalog is not just a detection mechanism. It's a posture tool.
An organization that knows exactly which applications have touched the network — on every device, continuously, without manual audits — is an organization that can make meaningful access decisions. Block unauthorized remote access tools before the first successful session. Flag crypto miners the moment they appear. Identify unlicensed software before it creates a compliance exposure.
The catalog is the foundation. The policy engine is the enforcement mechanism. Threatmatic π is the depth.
Together, they close the gap that every attacker depends on: the space between "something new appeared" and "we noticed."
On a Threatmatic fleet, that space is measured in milliseconds.
Threatmatic's Application Catalog, fleet-wide network telemetry, and Threatmatic π payload inspection are available to enterprise customers. Contact us to discuss deployment options for your fleet.