DarkAegis
Development Update

1. The DarkAegis Fleet Dashboard Is Running

One of our biggest milestones is the first working implementation of the DarkAegis Fleet Dashboard.

We now have three Linux development systems — Debian, Arch Linux, and Ubuntu — connected to a centralized dashboard through authenticated, encrypted connections.

The dashboard provides an operational view of monitored infrastructure, including agent connectivity, enabled security collectors, system health, and security alerts.

Administrators can review alerts across connected hosts, filter by severity, and investigate suspicious activity without manually examining each machine.

The dashboard also introduces dedicated host-health views, showing available resource metrics, telemetry collection status, and reported gaps in monitoring coverage.

Crucially, the dashboard remains optional.

DarkAegis continues to monitor, detect, and generate alerts locally even when the dashboard is disconnected or unavailable.

This separation is fundamental to our approach: centralized management should enhance security operations, not become a dependency for basic protection.

2. Investigations That Tell a Story

Detecting suspicious activity is only part of the problem. Understanding exactly what happened is equally important.

We've made substantial progress on how DarkAegis presents and correlates security evidence.

The dashboard now includes dedicated process investigations that combine process ancestry, filesystem changes, network activity, privilege transitions, memory-related observations, and alert evidence.

For example, during controlled security testing, DarkAegis successfully detected a sequence involving a downloaded executable being written to disk and subsequently launched.

The resulting investigation preserved the relationship between the downloader, network connection, filesystem modification, execution, and process exit.

We've also validated detection of web-server processes spawning shells, including a critical-severity rule for selected root-UID execution scenarios.

These are controlled test cases rather than evidence of real-world attacks, but they demonstrate how DarkAegis can connect events into an understandable sequence.

The investigation interface now explains what each observation means, why it matters, and what the available evidence cannot establish.

The goal isn't simply to generate alerts. It's to give administrators enough context to make informed decisions.

3. Introducing DarkAegis Hunt

We've also introduced Hunt, a fleet-wide investigation and search capability.

Hunt allows operators to search retained security evidence across connected systems using IP addresses, executable paths, command names, or exact process identities.

Results can be grouped by host and process, with direct links into detailed investigations.

Network analysis has also improved. DarkAegis can summarize observed inbound and outbound connections, identify frequently observed remote endpoints, and display linked TCP connection durations and kernel-reported transfer counters where available.

These capabilities are designed to make questions like "Which processes communicated with this address?" or "Where was this executable observed?" much easier to investigate.

4. A New Terminal Interface for Linux Administrators

We haven't forgotten the administrators who prefer working directly in a terminal.

The dactl console interface has undergone a substantial redesign, introducing an interactive, dashboard-style terminal experience.

It now provides dedicated Overview, Alerts, Processes, and Health views, with layouts that adapt to different terminal sizes.

Operators can navigate alerts, inspect process relationships, review supporting evidence, and examine local agent status without opening a browser.

This interface communicates directly with the local DarkAegis agent.

No hosted service, dashboard subscription, or external network connection is required for its core functionality.

For Linux administrators managing servers through SSH, we believe this local-first workflow is especially important.

5. The First Steps Toward Malware Prevention

Until now, much of our engineering effort has focused on observing system activity and producing explainable detections.

We're now exploring the next major capability: preventing selected unwanted executables from running in the first place.

Our early implementation uses Linux fanotify permission mechanisms and locally evaluated executable fingerprints to make decisions before execution.

The experimental system supports three operating modes:

Off: Execution prevention is disabled.

Audit: Matching execution attempts are recorded without blocking them.

Enforce: A matching, locally blocked executable can be denied execution before it starts.

Controlled testing on an isolated Debian filesystem has successfully demonstrated audit behavior, execution denial, and permission for nonmatching executables.

We've also validated narrowly authorized mode changes through both the local terminal console and the authenticated dashboard.

This is early engineering work, not a production-ready antivirus or general malware-prevention claim. Broader filesystem coverage, failure recovery, safety, and performance still require extensive validation.

Nevertheless, it represents an important step toward expanding DarkAegis from detection into controlled prevention.

6. Privacy and Local Control Remain Core Principles

As our capabilities expand, our underlying philosophy remains unchanged.

DarkAegis is designed to give organizations meaningful control over what security information is collected and what leaves their infrastructure.

The current dashboard pilot explicitly excludes command-line arguments, file contents, packet payloads, and machine-learning research data from remote telemetry export.

Local collection does not automatically authorize remote transmission, and the standalone agent remains operational without a centralized dashboard.

We've also chosen to defer machine-learning-assisted alert prioritization from the initial evaluation product until it can demonstrate a meaningful improvement over simpler, explainable detection methods.

We're prioritizing useful security capabilities over adding AI for its own sake.

What's Next?

Our immediate development priorities are completing the evaluation workflows, improving operator usability, validating reliability and resource usage, and continuing controlled execution-prevention research.

We're also preparing the groundwork for organizations interested in evaluating DarkAegis across multiple Linux systems.

DarkAegis remains in pre-alpha development. Although the underlying systems are functioning in our development environment, there is not yet an accepted public alpha release.

We're focused on making the first evaluation version genuinely useful, rather than rushing out a release simply to reach a milestone.

Help Shape DarkAegis

If you administer Linux servers, work in cybersecurity, operate infrastructure, or manage Linux systems for clients, we'd be interested in hearing which security problems matter most to you.

Which investigation features would save you time? What information is missing from your existing security tools? And what would make a Linux-focused EDR solution worth deploying in your environment?

To discuss the project, share feedback or express interest using our contact form.

Thanks for following the development of DarkAegis.