I've decided to develop an Antivirus of my own

I want to build an AV that can progressively detect real threats.

I want to document the process too, sharing what I learn and showing what really happens inside an AV.

I also want to hack my own AV every major feature implementation, to see if the AV can actually detect a real attacker trying to hack a real up-to-date laptop.

I'll rely on this loop of developing and hacking to improve the AV and maybe one day move toward a product that could actually be used to defend our computers.

I call it an antivirus mostly because that word is easier to understand and probably has better reach.

NewGen-AV gives people a simple mental model: a new generation antivirus.

But what I actually want to build is closer to a personal endpoint security tool with EDR-like features.

I want telemetry, detection logic, response, and the ability to understand what happened on the machine before deciding what to do.

The first MVP will still be very simple, but that is the direction.

Concept illustration of the intended NewGen-AV pipeline from endpoint telemetry through analysis and detection to response actions.
NewGen-AV is designed to collect endpoint telemetry. The engine analyzes and correlates the resulting events, then applies detection logic to trigger one or more responses when it detects a threat.

My Background as an Offensive Security Professional

Part of the reason I care about this is my background.

I come from the offensive side.

I worked as a Senior Penetration Tester at PwC, and most of my work has been around penetration testing, Red Team operations and adversary simulation.

So this project is not coming from a purely theoretical interest.

In the enterprise world, even during relatively simple penetration tests, you rarely attack a completely undefended machine.

In the best case, you run into an antivirus. In the more common and realistic case, into an EDR.

After spending time on offensive activities where bypassing endpoint security was part of the job, a simple antivirus on my own private machine does not give me much confidence.

That does not mean EDRs are magic, they can be bypassed too. But from experience, EDR evasion is not something everyone can do.

A good EDR adds a defensive layer that is meaningfully stronger than a normal private-user antivirus, free or paid.

That is the level of capability I want to move toward.

This will also give us a tool to inspect what happens under the hood of our machines, while forcing us to better understand malware behaviour, detection logic, and offensive tradecraft from the defender's side.

An important note is that this AV will not be for the corporate world. There are already solid solutions to defend enterprise workstations and servers and slow down attackers.

I want this to benefit our private sphere.

Too many of us rely on Windows. Yeah, I do understand that some devs and sysadmins have their Unix machines and they are very proud of them, and that some marketing guys have Macs.

Yet the number of high-profile individuals running Windows on their private laptops is extremely high.

Every software we install, every executable we run may potentially compromise our machine. Persistently.

Compromising our private computers may mean leaked photos of us and loved ones, leaked crypto wallets, leaked credentials and documents. For some people it could also cause a foothold into their company network.

So being able to protect our private assets is a crucial, yet overlooked, aspect of our cyber life.

An overview of the AV architecture

High-level Architecture

As a general guideline you can imagine the architecture of the AV as follows:

High-level NewGen-AV architecture diagram showing sensors, the core engine, detection logic, and response flow.
The architecture separates sensors, the engine, detection logic, and response so each part can evolve independently.

Sensors catch events happening on the machine (e.g. a new program is being run, a new file being saved on disk or a new network connection being established).

For this first stage, we will not have multiple sensors. We will solely rely on ETW. If you don't know what ETW is, bear with me, more on it in the next posts. For now just keep in mind that it is an event logging system provided by Windows.

Those events are gathered and sent to an engine, which has the job of detecting if something suspicious is happening.

Whenever suspicious behaviour is detected, an appropriate response must be fired. In our MVP we will kill the malicious process.

Everything else will be built on top of this MVP.

Projects Structure

As for the components, I divided the AV into three main projects:

  • the Launcher, which is the executable that starts the AV
  • the Core-User, which encapsulates the main logic of the AV and runs in user mode
  • the Core-Common, which contains structs, objects and functions shared across the other projects

If you take a look into the project itself you will find a folder structure like this:

📁 NewGen-AV
 ├── 📁 NewGen-AV-Launcher
 │    └── 📁 src
 ├── 📁 Core-User
 │    └── 📁 src
 │         ├── 📁 analyzers
 │         ├── 📁 core
 │         └── 📁 sensors
 └── 📁 Core-Common
      └── 📁 src

I will routinely hack the AV

The series will also include posts where I deliberately test and hack around my own AV.

This will give us a way to test the effectiveness of the AV itself.

The adversarial testing part should also be interesting, because defensive engineering without attacker thinking is only theatre.

As a first milestone, we will have a working executable for the AV.

Console output showing the NewGen-AV executable running during an early MVP test.
The early MVP starts as a small console launcher that initializes the engine and proves the execution path before adding heavier detection logic.

And a clear detection and response for known malware.

PowerShell and Mimikatz test output showing a malicious process being terminated by NewGen-AV.
The first response test uses Mimikatz as a visible malicious process and confirms that NewGen-AV can terminate it during an early MVP run.

As for the screenshot above, you can see that after running the infamous Mimikatz, or any other known malicious executable, we see it being terminated and the console being dropped from the Mimikatz console back to PowerShell.

The AV also prints out the logs of the detection.

NewGen-AV detection log output printed after identifying and responding to a malicious executable.
The detection log makes the response observable: the tool identifies the suspicious executable, records the event, and reports the action it took.

All tests shown in this series are performed for educational purposes, in controlled environments, and only on systems I own.

Where To Go From Here

The next posts will be technical and will dive into the code that makes this MVP work, from the ETW Sensor to the implementation of our first layer of detection and response.

The screenshots show the AV working, but it is far from being a reliable security tool.

This is exactly the point of this series.

We will build the first version, hack around it, understand where it fails, and then use those failures to draw our way forward and decide what to implement next.