Home on Clean Tech

Building a Threat Intel CLI Tool in Rust

Wed, 01 Apr 2026 00:00:00 +0000

Python is the default language for security tooling, but Rust offers compelling advantages for CLI tools that need to be fast, distributable as a single binary, and safe by default. Here’s how I built a threat intelligence lookup tool in Rust.

The goal

A single binary that:

Accepts an IP, domain, or hash as input
Queries VirusTotal, AbuseIPDB, and Shodan in parallel
Outputs a unified JSON report

Project setup

cargo init threat-lookup
cd threat-lookup
cargo add reqwest --features json,rustls-tls
cargo add tokio --features full
cargo add serde --features derive
cargo add serde_json
cargo add clap --features derive

CLI argument parsing with Clap

use clap::Parser;

#[derive(Parser, Debug)]
#[command(name = "threat-lookup")]
#[command(about = "Query threat intel APIs for IOCs")]
struct Args {
 /// The indicator to look up (IP, domain, or hash)
 indicator: String,

 /// Output format
 #[arg(short, long, default_value = "json")]
 format: String,

 /// Verbose output
 #[arg(short, long)]
 verbose: bool,
}

Parallel API queries with Tokio

The key advantage of Rust here is safe, zero-cost concurrency. All three API calls happen simultaneously:

Writing Effective YARA Rules for Cobalt Strike Beacon Detection

Sat, 28 Mar 2026 00:00:00 +0000

Cobalt Strike remains one of the most prevalent post-exploitation frameworks used by both red teams and threat actors. Detecting its beacons through YARA rules is a fundamental skill for any SOC analyst or threat hunter.

Understanding beacon artifacts

Cobalt Strike beacons leave identifiable patterns in both their staged and stageless payloads. The key areas to target are:

Configuration blocks — the beacon stores its config in a predictable structure
Sleep mask routines — the obfuscation applied during sleep cycles
Named pipe patterns — default pipe names are a common indicator

A basic detection rule

rule CobaltStrike_Beacon_Config
{
 meta:
 description = "Detects Cobalt Strike beacon configuration block"
 author = "SOC Team"
 date = "2026-03"
 severity = "high"

 strings:
 $config_header = { 00 01 00 01 00 02 ?? ?? 00 02 00 01 00 02 ?? ?? }
 $default_pipe = "\\\\.\\pipe\\msagent_" ascii wide
 $watermark = { 00 09 00 02 00 04 }

 condition:
 uint16(0) == 0x5A4D and
 filesize < 1MB and
 ($config_header or $default_pipe) and
 $watermark
}

Hunting in memory

For in-memory detection, you’ll want rules that match against the decrypted beacon configuration. Use a tool like pe-sieve or BeaconEye to dump process memory first, then scan:

Deploying Ollama on a Jetson Nano for Private LLM Inference

Sun, 15 Mar 2026 00:00:00 +0000

Running large language models locally is no longer reserved for beefy GPU rigs. With the right setup, a Jetson Nano can serve as a surprisingly capable inference endpoint for smaller models — completely air-gapped from the cloud.

Why edge inference matters

For security professionals, running models locally means:

No data exfiltration risk — queries never leave your network
Predictable latency — no API rate limits or outages
Full control — choose your model, quantization, and context length

Hardware requirements

Component	Specification
Board	NVIDIA Jetson Nano (4GB)
Storage	64GB+ microSD (A2 rated)
Power	5V 4A barrel jack (not USB)
Cooling	Active fan recommended

Installation

First, flash JetPack 4.6 and update the system:

Building a ZFS-Based NAS with TrueNAS Scale

Fri, 20 Feb 2026 00:00:00 +0000

After years of running a makeshift NAS on an old desktop, I finally built a proper TrueNAS Scale server. Here’s what I learned about ZFS pool design, hardware selection, and avoiding common pitfalls.

Hardware selection

Budget was a constraint, so I optimized for reliability over raw speed:

Motherboard: ASRock B550M with ECC support
CPU: Ryzen 5 5600G (low TDP, enough for transcoding)
RAM: 32GB ECC DDR4 (ZFS loves RAM for ARC cache)
Boot: 2x 120GB SSD in mirror (TrueNAS boot pool)
Data: 4x 8TB Seagate Exos in RAIDZ2

Why RAIDZ2

With 4 drives, RAIDZ2 gives you two-drive redundancy at the cost of usable space. The math:

Competitive List Building for 10th Edition 40K: A Data-Driven Approach

Sat, 10 Jan 2026 00:00:00 +0000

List building in competitive 40K is part art, part science. While gut feeling and local meta knowledge matter, tournament data gives you a statistical edge most players ignore.

Gathering the data

Sites like Stat Check and 40kstats aggregate tournament results. The key metrics to track:

Win rate by faction — overall faction strength in the current meta
Internal win rate by unit — which datasheets actually contribute to wins
Points efficiency — damage output or objective scoring per point invested

Building for objectives, not kills

The most common mistake in competitive list building is optimizing for damage output. 10th edition rewards board control and objective scoring heavily. A useful heuristic:

About

Mon, 01 Jan 0001 00:00:00 +0000

About this blog

This is a technical blog covering a broad range of IT topics — from cybersecurity and threat hunting to AI/ML experiments, homelab builds, and gaming strategy.

About me

I’m a cybersecurity professional based in France, working across SOC operations, threat detection, malware analysis, and infrastructure automation. Outside of work, I enjoy building homelab systems, tinkering with local AI models, learning Rust, and playing Warhammer 40K.

Contact

Feel free to reach out via email or find me on GitHub.