DRIFT Linux: where it comes from, why it exists, and where it wants to go
There is always something strange about releasing a first version.
On one side, there is excitement, because an idea that has lived for months or years in your head, in your tests, in your failed attempts, and in those late nights spent fixing tiny details, finally becomes something real. On the other side, there is inevitably a certain amount of concern, because the moment a project leaves its protected internal space, it stops belonging only to the person who built it and starts being seen, judged, and interpreted by others.
DRIFT Linux is no exception.
Even when there is already a significant background made of previous distributions, previous paths, and previous experiences, that feeling does not really go away. Every project has its own identity, its own weight, and its own story. And every time, no matter how used one may be to building, designing, or releasing things, the moment something starts walking on its own still feels special.
At the moment, DRIFT Linux is effectively carried forward by a single person. That is both a responsibility and a very honest statement about the project’s current stage. At the same time, there is also a very clear hope: that over time a real community may grow around it, made of curious people, analysts, contributors, professionals, and enthusiasts willing to help it evolve, improve, and become stronger.
A new project with a longer story behind it
To really understand DRIFT Linux, one thing should be made clear from the beginning: this is a new project, but it was not born in a vacuum.
Behind it there is a long path shaped by real-world work, practical needs, experience in digital forensics and incident response, and previous work on specialised distributions. In that path, one name had a particularly important role: DEFT.
The author was directly and substantially involved in the history of DEFT Linux, a distribution that for years represented an important reference point in the forensic field. That involvement was not secondary, but that of the primary technical and architectural driving force behind the project, alongside valuable teammates who each brought their own contribution and added value.
It was a major experience in the fullest sense of the word. Major because of the satisfaction, the growth, the quality of the work, and what it left behind both technically and personally. As often happens with projects that truly matter, however, there were also more difficult moments. In particular, the actual weight of the technical and design work was not always perceived or acknowledged in proportion to the contribution behind it, while other figures at times ended up receiving more visible public recognition and attribution. These dynamics can leave a mark, especially when one has contributed so deeply to the construction of a project.
That said, it would be wrong to reduce DEFT to those aspects alone. It remains an important, formative, and foundational chapter, one that concretely helped shape method, vision, and approach. And it is also from there that the conditions for later paths were born and in a way, DRIFT can be seen as the natural evolution of DEFT.
One of those paths is Tsurugi Linux, a project that is still active and of which I continue to be a part. This too is important to me: my path did not stop there, but continued to evolve while maintaining a concrete connection with projects that have shaped, and continue to shape, the DFIR landscape.
DRIFT and Tsurugi: two distinct paths, still connected
DRIFT Linux and Tsurugi Linux are two distinct projects, each with its own identity, its own vision, and its own path. That distinction, however, is not a form of distance. If anything, it is part of their value.
DRIFT was born within a positive human and technical context, built on solid collaboration, long-standing friendship, mutual respect, and the desire to create something further without overlapping with an existing path. From the beginning, the idea was to develop a space with greater implementation freedom, where specific technical choices and directions could be explored while maintaining an open, healthy, and collaborative relationship with the other project.
For this reason, DRIFT Linux and Tsurugi Linux remain parallel projects, but not disconnected ones. On the contrary, they share a real closeness, an active dialogue, and the possibility of influencing each other in a positive way, while still remaining clearly recognisable in their respective differences.
There is also one point that matters personally to me: I continue to be part of both projects. And that very dual involvement makes the idea of a collaborative, constructive, and non-competitive relationship even more natural. This is not about choosing between two opposing directions, but about carrying forward two different yet meaningful paths that can coexist, enrich each other, and grow side by side.
Why DRIFT Linux really exists
Beyond the personal and project history, DRIFT Linux was born from a very concrete technical need.
The idea was to have a portable, preservation-oriented DFIR lab, designed to cover a number of activities that repeatedly matter in practice:
- acquisition of device drives
- acquisition of Web and Cloud content
- first response activities
Written like this, it may look like a short list, but there is quite a lot inside it. It means thinking about a tool that is not just “convenient”, but one that is philosophically aligned with the environments in which it is used. It means building something that is designed to preserve before it tries to impress. It means creating an environment that does not need to be reinvented from scratch every time it is needed.
That is exactly the spirit in which DRIFT Linux was born.
A live ISO first, by design
From the very beginning, DRIFT was conceived first and foremost as a live ISO.
This was not an aesthetic choice, and it was not driven by nostalgia. It was a technical decision. In many forensic and incident response contexts, what is needed is a portable tool, quick to boot, as predictable as possible in its behaviour, and capable of reducing impact on the context being observed or acquired.
Also, not every scenario is a comfortable one, with perfectly cooperative hardware or a graphical environment ready to go. For that reason, DRIFT was also designed with situations in mind where a GUI may not be available, may not start properly, or may simply not be appropriate.
In those cases, it can still be used through a pure text-based environment, supported by a set of purpose-built TUIs created specifically to simplify technical workflows. This is not command-line folklore for its own sake. It is a practical choice, because in certain environments simplicity, control, and clarity matter a lot more than visual polish.
Further ahead, there are also plans for an installable box-like version with characteristics different from the live ISO, while still preserving the same underlying philosophy. The form may evolve, but the mindset will remain the same. Even in its future versions, DRIFT aims to stay a strongly preservation-oriented instrument.
The central point: preserving the context
This is probably where the technical heart of DRIFT Linux really lies.
The goal is not merely to have a bootable system with useful tools inside. That would only be the starting point. The real point is that DRIFT tries to shape system behaviour from the very earliest phases of kernel boot, specifically to increase as much as possible the guarantees around the preservation of connected evidence.
This attention led to work not only on controls involving drive buses such as SATA, USB, and other storage-related channels, but also on aspects of the underlying hardware that are often overlooked and yet can matter a great deal in certain contexts.
One of the most relevant examples is the system clock. It only seems like a secondary detail to those who have never had to think seriously about chain of custody, temporal coherence, timelines, and evidentiary reliability. In reality, it can be a very important element, and for that reason it deserves attention from the earliest stages of boot.
In other words, DRIFT tries to behave the way a DFIR-oriented tool should behave: not as a generically convenient system, but as an environment that aims to be respectful, cautious, and defensive toward whatever is placed in front of it.
Stealth by choice, not by accident
Another fundamental aspect is radio and wired isolation.
In some investigative or incident-related scenarios, simply powering on a machine and letting it behave “normally” may already be too much. An active Ethernet port, a Wi-Fi interface trying to communicate, Bluetooth announcing itself, an unintended connection attempt: all of these things can contaminate the picture, generate unwanted events, reveal the analyst’s presence, or alter an environment that should instead be approached with care.
For this reason, DRIFT was designed so that Ethernet, Wi-Fi, and Bluetooth are effectively neutralised from boot. The idea is for the system to remain as quiet and discreet as possible, while leaving the analyst in control of deciding whether, when, and how those interfaces should be re-enabled.
Again, this is not hardening for the sake of theatrics. It is about moving control away from default system behaviour and back into the hands of the operator. And when working in sensitive environments, that difference matters a lot.
To simplify this process, DRIFT includes dedicated interfaces built specifically to make the orchestration of these behaviours easier and more deliberate.
A project that does not pretend to be “finished” already
One of the worst mistakes a first release can make is pretending to be perfect, definitive, and complete. That would not be credible, and it would also be rather arrogant.
DRIFT Linux is not perfect, and it is not complete. Saying that openly is not a weakness.
What it aims to be, right now, is a solid starting point. A serious and useful DFIR tool, already shaped by specific technical precautions and by a recognisable philosophy. A project born with the ambition to be genuinely useful for analysts, while also being fully aware that it still needs to grow, mature, be tested, corrected, refined, and expanded.
That is usually how the tools that last are built: not by pretending to be omnipotent on day one, but by laying down sound foundations.
The next directions
The path of DRIFT Linux does not end with this first ISO.
Additional variants are already planned, including a micro version designed to be extremely minimalist, very lightweight, and especially useful in constrained environments or on limited hardware.
At the same time, there are also plans for versions specifically aimed at the cloud world, with variants for contexts such as Azure, AWS, Google Cloud, and similar environments. This is a natural evolution, because DFIR work today does not happen only on physical machines, local disks, and traditional acquisitions. More and more often, it moves across distributed environments, remote services, and hybrid infrastructures.
The idea, then, is to let DRIFT grow not as a single static object, but as a family of tools sharing the same underlying philosophy.
The name DRIFT
The name itself was not chosen casually.
DRIFT carries several meanings, all of which are coherent with the spirit of the project.
The first one is the most immediate: it evokes the urgency that comes with an incident, the moment when you need to react, start the engine, and move quickly. There is a metaphor of speed in it, of a sharp manoeuvre, of energetic response, but not in the sense of chaos or improvisation. Rather, it suggests fast movement while still maintaining grip, control, coherence, and safety.
Then there is a second layer, more playful but still perfectly aligned with the technical context: DRIFT can also be read as something that echoes DFIR T, meaning Digital Forensics & Incident Response Toolkits.
Finally, there is also a more personal, almost phonetic nuance that points back to the “former DEFT”. For the author, that name recalls an important part of a technical path, an architectural journey, and a broader experience in building live systems for forensics. It is not a nostalgic reference for nostalgia’s sake, but a technical and human memory that feels worth keeping.
Closing thoughts
DRIFT Linux comes from a story that already exists, but it does not merely inherit it passively.
It comes from real experience, technical work, mistakes, useful lessons, good collaborations, a few bitter moments, and above all from the desire to build something with a clear identity of its own.
It is a young project, but one with deep roots. It is a personal project, but one meant to grow. It is a technical project, but not a cold one. And above all, it is a project that does not want to sell an artificial image of perfection. It wants to try to be genuinely useful.
If this first release manages to convey even part of that intention, then it will already be a very good beginning.