Skip to content

v0.15.28

Choose a tag to compare

View all tags
@github-actions github-actions released this 26 Jun 23:40
· 8 commits to main since this release
v0.15.28
b3a9bd5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

InnerWarden 0.15.28

Fixed

Cloud-platform false-positive sweep from a 7-day decision-log audit of an Azure VM (the same method as the clean Oracle audit). A cloud VM's own platform agents and the platform control plane tripped the generic detectors, including a wrong auto-block of the Azure WireServer management IP. Every fix is keyed on a NON-IP signal (no platform IP is hardcoded in the product, by operator policy: "IPs change"); each ships with anti-evasion tests; the detector count is unchanged (82).

  • fileless:systemd flooded Critical on every unit start (Azure: 1206 Critical/week, all comm=systemd). systemd v254+ copies systemd-executor into a sealed memfd and fexecves it via /proc/self/fd/N at the start of every unit, which the fileless detector read as in-memory malware execution. The exec event carries no exe_path, so the fix resolves the launching process's parent via /proc/<ppid>/exe (the kernel symlink, which prctl(PR_SET_NAME)/argv[0] cannot forge) and suppresses only the self-fd fexecve form launched by a systemd manager. Anti-evasion preserved: /memfd:, /dev/fd/, (deleted), /proc/<other-pid>/fd/, and any non-systemd parent (a shell/dropper running exec /proc/self/fd/N) still fire; an unresolvable parent fails safe to firing; the memfd payload is still caught at creation by kernel_promote.
  • Cloud guest agents tripped C2 / flood / IMDS-SSRF detectors, auto-blocking the platform control plane. A cloud VM's management agents (Azure WALinuxAgent, AWS SSM agent / cloud-init, GCP guest agent, OCI cloud agent) poll the platform control plane (WireServer, IMDS) often enough to look like C2 beaconing, connection floods, and IMDS access by an unexpected process. On Azure this fed a cross-layer correlation that auto-blocked the WireServer management IP 168.63.129.16 six times (a block that can sever the VM from its management plane), and produced 869 IMDS needs-review incidents. New crates/sensor/src/cloud_platform.rs (a crate-root helper, not a detector) recognises the platform's agents by non-forgeable process identity: the cloud is auto-detected from DMI/SMBIOS (firmware strings, not anything userspace can forge); a compiled agent is matched by its real /proc/<pid>/exe; an interpreter agent (python3 /usr/sbin/waagent, cloud-init) is trusted only when its script argument is a known agent path that exists on disk as a root-owned file under a trusted system directory; and extension-handler children (relative script path) are matched by walking up to four parent hops to the real agent. is_guest_agent(pid, uid) is gated on a recognised cloud VM AND uid 0, and is used downgrade-only in c2_callback, outbound_anomaly, and imds_ssrf (the interpreter case its exe-prefix list missed). Anti-evasion (tested): an argv that merely names a guest-agent path without the file being root-owned, a trusted interpreter running a /tmp script, an untrusted interpreter, a planted look-alike path, on-prem Hyper-V (not Azure), bare metal, a non-root process, and a webserver runtime hitting IMDS all still fire. The WireServer actor was the Azure guest agent (python3 -u /usr/sbin/waagent), not the co-located AI agent.
  • dns_tunneling flagged Azure platform service DNS as high-entropy tunneling (Azure: 667/667 false positives). The host resolving Azure Storage / SQL / Service Bus / Key Vault FQDNs (<resource>.blob.core.windows.net, <vault>.vault.azure.net) tripped the Shannon-entropy heuristic on the random-looking resource name. The existing DNS_ALLOWED_DOMAINS allowlist (already covering provider-controlled zones like oraclevcn.com, internal.cloudapp.net, azure.com, amazonaws.com, googleapis.com) was simply missing the Azure service zones; windows.net and azure.net are added. This is a domain allowlist, not an IP one: Microsoft controls these zones and does not delegate arbitrary subdomains, so a DNS tunnel cannot be built under them. Anti-evasion preserved: the dot-boundary match means evil-windows.net is not trusted, and tunneling through an attacker-controlled zone still fires.

Install / upgrade (Linux, toolchain-free, signed binaries)

curl -fsSL https://innerwarden.com/install | sudo bash
# already installed:  sudo innerwarden upgrade --yes

Every binary below is signed (Ed25519 + Sigstore bundle). Docs: https://github.com/InnerWarden/innerwarden/wiki · Site: https://www.innerwarden.com

What's Changed

  • fix(sensor): suppress fileless FP from systemd sealed-executor unit launch by @maiconburn in #1119
  • fix(sensor): cloud-platform guest-agent provenance (non-IP) for WireServer/IMDS FPs by @maiconburn in #1120
  • fix(sensor): allowlist Azure platform service DNS zones (windows.net, azure.net) by @maiconburn in #1121
  • release: 0.15.28 (Azure cloud-platform false-positive sweep) by @maiconburn in #1122

Full Changelog: v0.15.27...v0.15.28

Contributors

maiconburn
Assets 49
Loading