Skip to content
ZEROWARN
The full arsenal

From the request to the consequence. No gaps.

Six independent planes —the request, the code being run, the file, the process, the network and the account's behaviour— judge what they see and confirm each other, because a real attack leaves a trail in several at once, while an isolated false positive dies on its own. This is what SHIELD catches. None of it needs a prior signature, and all of it is built and verified today.

Webshells, however obfuscated

However many layers of obfuscation it carries, SHIELD sees the code already decoded — right where it hands the attacker's request to a command. And it sees the web process make its classic first move —opening a shell, downloading a tool— whatever happens next.

How does it do it?

It captures the code at the exact moment the interpreter compiles it, already free of obfuscation. Then it checks two things at once: that a real fragment of what the user sent reached the dangerous argument —not a chance match— and what intent that code has, using an engine embedded in the agent that scores by what the code does. The file at rest is handled by the content antivirus engine as soon as the webshell touches disk. And in parallel the web process itself is seen opening a system shell.

Code injection: RCE, inclusion and deserialisation

RCE, local and remote file inclusion, deserialisation, arbitrary writes. Everything you ask a WAF for, except that instead of guessing at the door and failing against evasion, SHIELD sees the real value arrive at the dangerous point. No signatures to maintain and no 0-day slipping through for want of a rule.

How does it do it?

The seven classes of dangerous operation —execute, include, deserialise, write file, SQL query, Redis commands and MongoDB queries— are observed at the point of use, with their value already resolved. The analysis is by value: a real fragment of the user's input must actually reach the dangerous argument, which is why obfuscating the request is useless. No class is left out: the design itself makes it impossible to add a dangerous point without deciding how it is judged.

SQL and NoSQL injection, even with the connection encrypted

SQL and NoSQL injection is caught in the query heading for the database engine, not in the HTTP request. Covers MySQL/MariaDB, PostgreSQL, SQL Server, MongoDB and Redis — and still sees it when the database connection travels encrypted, where any network inspection is blind.

How does it do it?

SHIELD reads the query inside the server, at the point where the application hands it to the data engine —before encryption wraps it— and recognises the protocol by its own shape, so it works just as well on non-standard ports and with libraries whose names are not visible. On that text it applies the same by-value analysis: it flags when the user's input breaks the structure of the query, which is what tells an injection apart from ordinary data. It also sees extraction: when, after a suspicious payload, the database starts dumping records outward.

Fileless attacks, rootkits and process injection

Code running only in memory, injection into other processes, a rootkit trying to slip into the kernel. The fileless attacks a file scanner, by definition, will never see, and which here are in plain sight.

How does it do it?

It observes the exact operations of a fileless attack: creating executable memory and launching it without touching disk, writing into another process's memory, asking for memory that is writable and executable at once (the shellcode signature), or loading a program into the system kernel itself. All of it from the web lineage, which should never do any of this.

Back doors and persistence

The exact moment the attacker tries to persist: a new remote-access key, a hidden scheduled task, a service that starts on reboot, a back door in the system configuration. SHIELD sees it being written, and knows a web process has no business touching those places.

How does it do it?

Every write is resolved to its real path —proof against symbolic links and detours through the directory tree— and compared against the known persistence locations: remote-access keys, scheduled tasks, boot services, system accounts and preload hooks. It only counts if it comes from the web process; the administrator's legitimate maintenance is exempt.

The whole campaign, not the isolated event

Download → stage → execute. Or webshell → command-and-control call. Or webshell → mass dump of data outward. SHIELD joins the steps over time and reconstructs the attacker's full story, not fragments that would look harmless on their own.

How does it do it?

It keeps each process's history and correlates within a bounded window: external download → file marked executable → its execution; webshell → outbound connection; webshell → database write; webshell → data exfiltration by volume; and the quietest case of all, the file the application itself writes and then executes, even if it tries to disguise the path. On top of that it builds the attacker's campaign in the industry's standard stages (access, execution, persistence, command and control, exfiltration), aggregating all their incidents under one actor even when they arrive through different requests.

Command-and-control, mining and data theft

Stops command-and-control and data exfiltration before they leave the server. Blocks the attacker coming in —even hiding behind network tags— and the one going out, with a reputation that learns from your whole fleet. And it knows the real IP behind the proxy.

How does it do it?

The outbound connection is denied on the spot if the account is quarantined or the IP is on the block list (a single table covering IPv4 and IPv6, where allow beats block). The inbound packet is dropped by its source IP at the earliest possible point, before it enters the network stack. The client's real IP is extracted from the protocol itself, even with a proxy in front, and attributed to the right request — not to the wrong process. And it flags the connections the application opens towards forbidden internal destinations, the classic pattern of cloud credential theft.

Anomalous behaviour, account by account

It learns what is normal for each account and detects the odd, even when the attacker moves slowly to avoid noise. The classic "low and slow" does not help: SHIELD measures the rarity of each step, not its frequency, so going slowly does not make anyone invisible.

How does it do it?

It learns, account by account, which chains of actions are normal, and scores the rarity of each step, not its frequency. The threshold self-calibrates after an observation period; the model updates itself, but it never learns as normal something it already flagged as anomalous, so an attacker cannot acclimatise it little by little.

Containment: kill the process, isolate the account, neutralise the file

Kills the process, isolates the account, neutralises the malicious file (reversibly, in case it was wrong) and cuts its network. All conservative by default: it only contains what carries certainty; a suspicion stays a warning, so it can never break a legitimate site.

How does it do it?

It kills the process anchored to its real identity, so it cannot reach another through identifier reuse. It isolates the account with a lock inside the kernel that cuts off its execution and network, without touching its neighbours. And it neutralises the file by moving it out of where it is served or making it unusable, always keeping how to undo it; if it cannot, it says so instead of pretending it contained. The golden rule ships from the factory: containment demands a certainty signal —a deterministic rule, or a file whose verdict is so high that the antivirus itself escalates to reversible containment—; whatever only a model or behaviour has an opinion about stays a warning, and can only reach containment if you enable it and two independent sources agree.

52 observation pointsinside the kernel, in real time
23 attack rules8 that block on the spot · 15 that correlate
It sees the encryptedreads the database query inside TLS
Anti-evasionwhat cannot be observed is denied
Multi-versionPHP 5.x–8.x side by side, each calibrated on its own

See it on your own data

Deploy the agent on three servers and leave it in observation mode. Within days you will have the figures for your own traffic: what it would have detected, what it would have contained and with how much noise. Turning on blocking is a later configuration change, and it is your call.