Continuous Persistence Hunting
Inspects authorized keys, cron jobs, systemd units, sudoers, setuid binaries, and listening sockets continuously across every host.
Home / AuraCore
Secures your servers from the inside. Before an alert ever fires.
AuraCore Cluster and Workload Manager.
Attackers don't break in to trigger an alarm; they plant quiet persistence that survives a reboot. AuraCore maps your bare-metal servers, virtual machines, Kubernetes, and Docker in one hardware-attested mesh and removes threats via signed commands.
TPM 2.0 + mTLSCryptographic node attestation at boot
Linux & FreeBSDBare metal, virtual machines, Kubernetes, Docker
Zero Open ShellClosed command set with cryptographic signatures
Dry-Run PatchingVerified vulnerability updates before live rollout
AuraCore maps your sites and the links between them. On the right, Aura answers questions about your fleet.
Hardware-Attested Mesh
A node joins AuraCore only after verifying its boot chain via SecureBoot, TPM 2.0, and mutual TLS.
Signed Remediation & Patching
Matches installed packages against live vulnerability data and applies signed updates after an automated dry run.
AuraCore/Cluster
Hardware-attested cluster nodes
prd-k8s-ctrl-01Linux 6.6 · Kubernetes Control PlaneTPM 2.0 + mTLS · Attestedprd-db-eu-04Linux 6.6 · Bare-Metal DatabaseDrift: /etc/cron.d · Containedbsd-edge-gw-02FreeBSD 14 · ZFS Storage GatewayTPM 2.0 + mTLS · Attestedvm-erp-core-01Linux 6.6 · Virtual MachineTPM 2.0 + mTLS · AttestedContinuous persistence inspection across all nodes · Active signed remediation or strict read-only SIEM/SOC feed
Aura
Target node in Aura focusprd-db-eu-04
Signed remediation record · zero open shell
Command
REVOKE_CRON_PERSISTENCEAudit scope
authorized_keys · systemd · cron.d · sudoers · setuid · socketsDry run
Passed (0 package or service conflicts)Shell access
Architecturally disabled (Closed allowlist)Signature
ed25519:4c18...7b09 · SIEM record committedSecureBoot + TPM 2.0 · mTLS · 0 Shell
Server monitoring that finds what attackers leave behind
Standard EDR and log tools wait for noisy execution. AuraCore by Identiqa continuously inspects Linux and FreeBSD bare-metal servers, virtual machines, Kubernetes clusters, and Docker containers for persistence mechanisms. When a vulnerability or unauthorised artifact is detected, AuraCore isolates the workload or applies a cryptographically signed patch after a dry run.
Boot attestation, persistence artifacts, and dry-run patching
Every node proves its integrity at boot via SecureBoot and TPM 2.0 before establishing a mutually authenticated TLS channel (mTLS) into the AuraCore mesh. Unverified hosts can't join the cluster or pull workload secrets.
Instead of waiting for noisy malware execution, AuraCore continuously compares live host state against known-good baselines across authorized SSH keys, cron schedules, systemd units, sudoers rules, setuid binaries, and listening sockets.
Neither an external operator nor an AI model ever receives an open shell. Every remediation step or vulnerability patch is a cryptographically signed command from a closed command set, verified in an automated dry run before touching production, or operated in strict read-only mode feeding your SIEM and SOC.
In your rack. On the cloud contract you already have.
We size Identiqa to your infrastructure and sites. Buy directly through Identiqa or on your existing agreement with Amazon Web Services, Google Cloud, or Microsoft Azure.
See how AuraLink with ProtectionGrid worksCommon questions
How do you detect hidden attacker persistence across Linux, FreeBSD, VMs, and Kubernetes?
Adversaries survive reboots by hiding in authorized SSH keys, cron jobs, systemd units, sudoers rules, setuid binaries, and listening network sockets rather than running noisy malware. Identiqa AuraCore audits those exact persistence vectors continuously across bare metal, VMs, and containers.
Can existing Linux, VM, and Kubernetes workloads be enrolled into hardware boot attestation without new servers?
Yes. Identiqa AuraCore enrolls the Linux, FreeBSD, virtual machine, Kubernetes, and Docker workloads you already operate, verifying each node at boot via SecureBoot, TPM 2.0, and mutual TLS (mTLS).
How do you automate server containment and patching without granting external tools an open root shell?
By restricting every automated action to a closed, cryptographically signed command set. Identiqa AuraCore never uses an open shell, validates every update in an automated dry run before production rollout, and can also run in read-only mode so it only observes and reports to your SIEM or SOC.