-
-
Our project logo!
-
Our admin dashboard showing blocked commands and their execution contexts
-
A malicious command being blocked before it could cause widespread damage
Inspiration
More and more commands run on our machines with no human watching. A 2026 honeypot study found 99.23% of logged-in SSH sessions were a script running a single command and disconnecting, with no human typing at all (Ghost Without Shell).
AI agents are quickly becoming vessels for autonomous attacks, executing multiple shell commands without a human noticing. This starts with unauthorized access escalating into a full system takeover. At the same time, local AI models are becoming better at making quick decisions that a human may not always be able to supervise. We developed Sid as the combination of these two ideas: a offline-only first line of defense against malicious commands, powered by specialzed decision models.
What it does
Sid judges every command that runs on a Linux machine before it can do damage. It looks at the command itself as well as the context surrounding the command, such as what its parent process is or what files it touches. When a command is run, before it executes we capture it and run it through a local decision model, specifically a fine-tuned Laya model. From doing so we give one of 3 verdicts:
- Allow: the command is allowed to execute
- Block: the command is clearly malicious and must be stopped to mitigate damage
- Warn: the command is diverted to a sandbox, where its behavior is monitored and passed off to a human for review.
A minimal web dashboard shows every decision with user and admin overrides, plus a detailed stats view for advanced users. Warnings and decisions made by are model are delivered within milliseconds of a user calling a command, allowing for seamless integration into already-running systems.
No part of this model requires access to the internet or expensive hardware. An average laptop is able to run the model that we created. This lets our solution be extremely well-posited for situations where cost-efficiency and data privacy are core tenets of the institutions we're protecting, such as a non-profit who still deserves a layer of protection to prevent their website from being forcefully taken down by bad actors.
How we built it
This entire process runs in multiple stages:
- We capture the command before it executes. This is done through multiple built-in Linux security libraries: eBPF on x86 and seccomp-notify on ARM, as well as fanotify for file activity. This capture happens at the kernel level, ensuring we capture every command being run above in the userspace.
- Unknown commands are decided upon via our fine-tuned Laya model. We trained this model on nearly 11,000 unique commands and contexts to be able to classify the severity of running unknown commands on Linux systems. This training data was supplied by numerous red-team datasets like Atomic Red Team and GTFOBins, as well as benign command datasets like NL2Bash.
- In cases where the model is unsure, we investigate by simulating the command being run. We utilize overlayfs to keep the user's filesystem protected. In cases where we are confident that a command is malicious, we prevent the command from running. We also assume the entire context that spawned the command is compromised in some way and must be shut down immediately. For example if a web app spawns a malicious command via a shell, we assume that not only is the shell compromised but the entire web app may be too (through an unknown RCE vector).
- We supply a web dashboard to admins of servers that Sid is deployed on. This dashboard is specifically designed to be as optimized as possible to communicate efficiently with the low-level software powering this solution and prevent a full system hang.
Challenges we ran into
One significant challenge we faced was deciding how to efficiently place our capture points. We conSidered the possibility of monitoring every individual syscall a program would make, and this would allow for greater insight into what it was that each command was doing as it was executing. However we discovered that in doing so we'd not only have a large number of unique syscalls to monitor, we'd have large quantities to monitor as well. If we incurred a few milliseconds of overhead per syscall, the entire system would slow to a halt.
Another challenge we encountered was deciding to drop very obvious attack signals. One such signal would be if multiple commands were executed in a short amount of time, which could be a clear indicator of a denial-of-service attack if they each held up system resources. We understood, though, that if we did this, we'd run into scenarios where an attacker with enough knowledge of our defense strategies could time their attacks to be just slower than our DoS threshold. To limit playing an everlasting cat-and-mouse game, we decided to exclude this from a command's context and focus on more deterministic features such as how that command was being called in the first place.
Accomplishments that we're proud of
Many of our accomplishments lie in the planning and execution of our capture system and the model we developed. Our fine-tuned Laya model is the very first of its kind, being able to choose how to respond to unknown commands, instead of just passively logging them. Since command history (and decision history) becomes part of the context fed back into the model on future calls, the model is able to improve its own output by understand what has and has not been allowed before. This separates us from existing EDR solutions like Tegra or Crowdstrike, who only sit idly or operate on hard-defined rules which are often broken by novel attack methods.
With human agency at stake in today's world, we are also proud of the fact that we still maintain a human in the loop. In cases where we are unsure, we let a human understand the threat that they may be facing and allow them to make a binary yes/no decision on it.
What we learned
Across the entire team this was the biggest low-level experience that any of us had. With a mix of host operating systems and architectures, we had to learn what made our individual solutions different, and how to combine those differences to deliver a comprehensive app that covered every use case. We also learned how much team dynamics greatly affected our success - we all took a team personality test before starting and laughed at the results, but found that as time went on the results were more and more accurate. Multiple team members were able to bounce ideas around and complement each others strengths (such as a strong focus in AI vs. a strong focus in security), as well as hold each other accountable and ensure we all met our deadlines and supported each other when we needed assistance in reaching them.
What's next for Sid (System Intrusion Detection)
With a capable model with cyber capabilities, we would like to test how our system fares against direct attacks that threaten it. One key assumption we made was that we'd only have to deal with userspace software, since if an attacker or piece of malware could get kernel level access then it would have the same amount of reach that we do. It would be interesting to see how we could evade being removed from the system at that stage, or at least how to prevent that from happening quickly.
We would also seek to have more data included in our model. We found that accuracy significantly improved the more unique data that we included when training our model. One area we can find more data is in Capture the Flag write-ups. Many of these write-ups contain exact commands that a determined attacker (the competitors) are running to achieve a certain goal, as well as what contexts they are running in. With enough write-ups we would have a clear understanding of how real human threat actors may behave in a wide variety of technological landscapes.
Log in or sign up for Devpost to join the conversation.