← All talks

07 - From Shell Commands to ATT&CK: Building Genos, an Open Source Command Intelligence Engine

BSides Toronto16:3897 viewsPublished 2026-10Watch on YouTube ↗
About this talk
Presented by Ahmed Khan at BSides Toronto 2026 on October 3rd. Command-line activity is one of the clearest places where attacker behavior shows up, but interpreting it correctly is not always simple. A single command can be obviously malicious, completely benign, or only suspicious depending on context. This talk goes over the design and development of Genos, an open-source command intelligence engine that classifies shell commands as benign, malicious, or context-dependent, while also mapping malicious behavior to MITRE ATT&CK techniques. We will look at why command-line detection is difficult, how attackers use obfuscation and living-off-the-land binaries, and how Genos combines de-obfuscation, machine learning, and rule-based security logic to make real-time decisions. The talk will also cover lessons learned from building the system, including dataset problems, false positives, technique-mapping challenges, and the gap between a research prototype and something defenders can actually use. This talk will walk through the process of building Genos, an open-source security research project focused on real-time command-line classification and MITRE ATT&CK mapping. The motivation behind Genos is simple: many attacks eventually touch the command line. Whether it is PowerShell, Bash, curl, wget, certutil, rundll32, mshta, encoded payloads, reverse shells, persistence commands, credential dumping, or defense evasion, the command line often contains strong behavioral clues. However, building a system that can classify these commands reliably is much harder than just matching keywords. The talk will cover the technical design of Genos, including a two-stage classification pipeline. The first stage acts as a gatekeeper, deciding whether a command is benign, malicious, or context-dependent. The second stage focuses on mapping malicious behavior to likely MITRE ATT&CK techniques. The system also includes a preprocessing layer that attempts to decode common forms of obfuscation such as Base64, hex strings, encoded PowerShell, and nested payloads. We will discuss where machine learning helps, where it struggles, and why pure ML is not enough for security detection. The talk will also explain how rule-based security knowledge can be used alongside model predictions to improve practical results, especially for commands involving LOLBins, encoded payloads, suspicious download-and-execute patterns, persistence mechanisms, and privilege-related behavior. This is not a vendor pitch or a “AI solves security” talk. It is a practical breakdown of what worked, what failed, and what had to be redesigned while building a usable command intelligence system. Topics include dataset construction, labeling commands with ATT&CK techniques, dealing with ambiguous commands, measuring false positives, handling context-dependent behavior, and testing the system against both benign administrative commands and attacker-style commands. A live or recorded demo will show how Genos analyzes commands, returns a verdict, assigns confidence, maps behavior to ATT&CK techniques, and explains why a command was classified a certain way.
Show transcript [en]

Hi guys, my name's Ahmed. And today I'm going to be showing my final project for my masters in cyber security. So what I decided to do is, you know, DIY like EDR plus command intelligence. You know, demystifying the black box like that that are known as EDRs. So I started as a sysadmin. Then I went on to be a security analyst and now I'm a threat researcher. I just finished my masters in cyber security. I did my first talk at Def Con this year in January. I'd say sorry, Def Con Vancouver. And I'm a first author of two IEEE papers. Today we're going to talk about, you know, the this is the agenda, project motivation primer, how to detect an

attack. And then, yeah. So those of you who have used like fail to ban, you know, I wanted to stop an SSH attack, but one day I saw this log. So this guy didn't like that I was using keys instead of passwords. Um Yeah, I think he was angry. So then I decided, this is before like I use any EDR, CrowdStrike, or what have you. I wanted to build my own like Microsoft. And I basically like made a sensor within Linux and then have like a web app. And then with all this data like, you know, IP, type of threat, port, country, and provider. So yeah. I went on to think about how to do a kernel-less EDR.

Um those of you that remember 2 years ago CrowdStrike had a huge outage. It was about I think eight 8.5 million PCs. Basically EDR it detects and responds to alerts and events. And why we need it instead of like regular antivirus is because, you know, we've shifted away from regular antivirus to fileless malware. Such an example is like, you know, admin admin, as you can see here. These are the like industry benchmarks for EDR solutions. The These aren't comprehensive, but I'm sorry if you're a vendor from another company but So, they detect known and unknown zero days. All right. Now, we're going to touch on like EDRs and like briefly how they work. All right. To start with, they need data

sources. They need networks, you know, file file files, processes, registry operations. And usually they're going to get them from user space and OS as in the kernel. So, EDRs like they use cur- the kernel because they have the ground truth. They can intercept system calls. They have, you know, They can stop things um threats before they impact process creation, file read and write execute, as well as memory allocation. So, although it has a much like, you know, higher visibility, higher control of what goes on in the computer, it, you know, it's hard to bypass. It can't stop ransomware and like, you know, user mode applications. All right. To make an EDR, you need telemetry and you need admin actions.

And this is for like a kernel-less EDR. So, to detect, I use, you know, dotnet system.collections and in Python, you can use pywin32. To respond, you can use any like OS command, shut down the host, lock it lock it up, or, you know, block the IP. So, for remote desktop brute forcing, you know, the attack is 4625. Like when it comes to Windows Event Viewer, and this has, you know, the collection of all the events that have taken place thus far. Um So, first I thought I was going to run a loop every like 60 seconds to find like the latest attack, but I thought that was computationally inefficient. So, I decided to make a what's called a

subscription. Where as soon as you start the program, you can uh square you can subscribe to you know future future logs. And this 30 lines of code is basically all you need in .NET to find 4625. It's not super super complicated. This in essence is a very very small prototype of a uh sensor. 4625 on line 10 and then the next you know five lines are are the like is the event data itself. Right? So, the algorithm to block the remote desktop brute force is you know you set a counter or like a buffer, right? And then you increase that buffer by one every time you detect a 4625 4625 event from one IP. Right?

This is really really inefficient because you would have to make rules for every attack. It won't scale up. You're going to you're going to get alert fatigue. You're going to get a lot of stress like this gentleman here said. Um 100 detections like they stay narrow and then if they're narrow that means that attackers can bypass it very easily. So, of course we're going to use AI. Um who doesn't? So, this was in November I had two options. Uh use an API or make an LLM ourselves. You know, we said it's everyone's doing it so it must be easy. The risk with the frontier models is that that it's indeterministic in that you know you won't you will not

get the same output twice even if you get the exact same input. Then you need guardrails. Then you need to then there's a whole security engineering problem like for the LLM system ourselves. So, this was a very very small LLM. We got about .063 on the accuracy after first cycle of training. Um this wasn't efficient because I had my thesis due in six weeks. And this was going to be very time consuming. So, I asked I literally asked ChatGPT like, you know, what do I do? Um He said to use like a debugger model, which is like a text classifier. So, I I don't know about you guys, but 58.9 is a lot better than 0.063. So, this is a

good direction. Yeah. And then our lab results were great, you know, 0.99. That That's like 99%. Here we can start see false positives. On top you see credential dumping attack. And on the bottom you see a completely benign attack. You're just calling cmd.exe. And our classifier thinks that it's an attack. So, to fix this we expanded the training set to cover like, you know, benign cases. We're getting like very good results here. Right. This is an obfuscation technique where if you change the file name, you can get the confidence to drop by a good 17%. It's the exact same data, exact same, you know, bits and bytes. Another obfuscation technique is, you know, by changing the cases of the command

itself. So, to normalize this before we send any command to classifier, we can do a dot lower case. And then yeah. Uh by the end of it, we got, you know, really good malicious and benign detection. This is, you know, fuzzing just to find like edge cases. So basically um over here we saw that One sec. Yeah. These were like fixed fixed test fixed like um They didn't cover edge cases. So, what this does is dynamically generates cases to find out which one is going to fail and then maybe add to those like in the training set, the new training set. Okay. So, now that we've successfully done, you know, two labels, now we're going to do four labels,

privilege escalation and parent defenses, and then setting changes, which had a huge impact on our accuracy. So, in terms of like, you know, computation power, I rented this H100 from DigitalOcean, uh $3.39 per hour. Uh it cost a lot of money, used a ton of VRAM, and used almost like 500 watts. Uh we got nothing out of it. So, RTX With the RTX 4000, it was a lot better, you know, we got two label uh classified classification working. Uh still an overkill, like too much VRAM. The next thing for our EDR, we wanted to do an attack chain. And over here is CrowdStrike's implementation. Uh right in the middle, I don't know if you guys can see, is the attack itself,

or where it where I'm where it's going to focus on the attack. All the other events like leading up to it, the gray ones are normal. Right, to make an attack chain, you need the thread itself. You need to query the query the one at the bottom. And then what you do, right, is see where it says parent ID? That's going to get your, you know, parent parent ID for that process. Then you keep going up until, you know, parent ID is zero, as you as you can see on the top. Right, we've done three attacks, all scripted, you know, all manual, but now we want something more dynamic, something more future-proof. So, we need more data and

a new model. We went to the Atomic Red Team library. What this is is a collection of attacks mapped to the MITRE matrix, and we've gone from Windows to Windows and Linux. So, we have a a huge like suite of, you know attacks. This is one sample attack from the ART library. The attack technique is on the top and the actual attack itself is at the bottom, lines 14-17. Another thing we noticed is that one attack does not always mean it's going to always going to be one like minor code. It can overlap with many.

So before we train Roberta on natural language right? You know, like English or Latin, right? We decided to go to code BERT because that's been trained on code itself. Uh as shell commands are closer to the code than natural language. Right, this essentially is like our first classifier. Accuracy was bad. Uh we trained it it we trained it on the ART library. Um and here's how we fixed it. So at first it was a binary classifier, right? And then second we split split it off to, you know, two models, the gatekeeper and the specialist. What the gatekeeper does is first it finds the bad command or the bad and good command. If it's good command, it rejects it. It says it's

benign and says, you know, you're good to go. If it's bad, it sends it to the second tier, which is the specialist, and that gives back the minor code. We added another class, um which which was suspicious. So instead of like just suspicious and malicious, it was now suspicious and malicious. Okay, and so far all of it has been running on a 4060. So we don't have to, you know, use LLMs or frontier LLMs. Um these are you know, how how we like parse commands and break them down. First, we identify the binary and then the argument and/or flags. And yeah, this is the end product. Uh, on the left you can see cat Etsy

password, you're enumerating, you know, the system like users on Linux. And then on the right you get the complete dissection. So, basically you can get this output from an LLM, you know, 100% but you won't get the same output uh every time. So, it's decided to, you know, call it suspicious and then you see see the flags. Like the binary's executable is cat, that's a Linux. And the arguments, you know, is the directory itself. And then the threat mapping's all the way on the right with the minor codes. So, in the real world context is huge. What we've just done is single alert. And you'd find these, you know, within a kill chain. That would be like one attack. Another

attack, it might be multiple kill chains by the same threat actor or, you know, APT what have you. And it might just be one alert out of like, you know, three kill chains.

Okay. So, takeaways from this, uh built a tiny EDR without kernel drivers, went from three scripted attacks to 141 dynamic attacks. And the research got validated. It got presented I had two two papers presented at the IEEE World Congress. So, that was the, you know, manual sensor on the left and then paper two was the dynamic, you know, 141 attacks. These are my sources and yeah, any questions?

>> Thank you. We are a small company working a fortune on endpoint detection and response and the extended services that go with that. I I would be really interested to to explore something like this, but just to play the two sides of the equation. If I talk to to the other guys at work, let's build something like this or let's buy something like this. The first question is going to be what about threat intelligence? What we get with a commercial product like CrowdStrike, Sentinel One, or similar is that the vendor is telling you but you're getting threat intelligence real time from you know a thousand different sources. Is that really a benefit or is that really a gap in this approach?

>> So, it's originally it wasn't supposed to be like a competitor. It was supposed to be like a a layer on top of like a seam or EDR. And um yeah. So, one of CrowdStrike's APIs is VirusTotal and their API is extremely expensive. It's like starting is like few thousand dollars. And yeah. Um So, that that wasn't the goal. We were not trying to compete with CrowdStrike at all. It's just It's just a school project. But uh yeah, it's just a proof of concept. >> Ahmed, thank you very much for your presentation. It was really cool. Um question for you is this is in user space, right? So, what about deflection, what about response, and preventing the

attack because you can't really do that completely from user space. Is that a known limitation? >> That's a limitation, yeah. We'd have to write kernel drivers, so

>> Uh one more question. Uh why didn't you consider just using existing base LLM and fine-tune it with your data set or examples or alternatively a reinforcement learning approach? >> Uh we did that with the IBM's like small model. It was a I'll go back to it one second.

Yeah, that one. So, it's a very small LLM, Granite 904. 350 million parameters. It's supposed to run on small GPU, not 80 GB of VRAM. >> Uh but then why this one specifically? >> Uh at the time it was the smallest and I wanted like edge IoT as well to be like in the you know, coverage. Not to be like heavy computational-wise. Yeah. >> Understandable, thank you. >> Thank you.

>> Thank you, Ahmed. >> Thank you. >> I might >> [applause]

[ feedback ]