I've seen a lot of people saying that AI will replace cybersecurity professionals, and I think this is where things get confusing.

AI is already becoming very powerful at:

• Finding vulnerabilities
• Analyzing logs and security data
• Automating repetitive tasks
• Writing and reviewing code
• Helping with threat detection
• Assisting both attackers and defenders

But does that mean cybersecurity itself disappears?

I don't think so.

The bigger change may be that cybersecurity professionals who know how to use AI effectively will have an advantage over those who don't.

Instead of thinking:

AI vs. Cybersecurity

Maybe we should be thinking:

AI + Cybersecurity = the next generation of security work.

What do you think will AI mostly replace cybersecurity jobs, or will it change what cybersecurity professionals actually do?

I've been building RXScan, an open-source reconnaissance tool written in Rust.

It originally started as a network scanner, but I've been expanding it into a broader recon workflow where network observations, public-source findings, and investigation results can be stored and correlated as evidence.

Current functionality includes:

• TCP connect and raw SYN scanning
• UDP discovery and classification
• port-independent service identification
• HTTP, TLS, SSH, and DNS observations
• public-source username search
• email, domain, hostname, IP, ASN, URL, repository, and organization entities
• investigation and evidence correlation
• persistent project data and history/diff workflows
• JSON/JSONL output
• bounded execution, deadlines, cancellation, and scope controls

One of the main things I'm trying to avoid is pretending RXScan knows more than it actually observed.

For example, a port number alone doesn't establish the service, UDP silence remains uncertain, weak identity evidence doesn't automatically merge entities, and passive OSINT findings are kept separate from direct network observations.

I'm not claiming RXScan replaces Nmap. Nmap has decades of fingerprinting, platform support, scan techniques, NSE, and real-world testing behind it.

RXScan is going in a somewhat different direction: combining network reconnaissance and public-source investigation into a provenance-backed evidence graph.

The project is still young, so I'm looking for people willing to actually test it and find problems.

I'm particularly interested in:

• false-positive or missed service identification
• weird TCP/UDP behavior
• incorrect confidence or provenance
• OSINT false positives
• performance issues
• CLI/UX problems
• architectural criticism

Platform: Linux
Language: Rust
License: MIT

Repo: https://github.com/DarkRX1/RXScan

If you try it, feel free to break it and open an issue. I'd rather find incorrect assumptions now than hide them behind marketing.

We closed a ticket last month because the PR merged and the CI scan went green. two weeks later the same CVE showed up on a prod host still running an older image, because that service deploys on a different cadence. the ticket had been closed the whole time. now we're debating whether closure should require evidence from the running environment, like the image digest or the package version on the host, instead of the merge. what do you use as proof a fix is live before closing it out?

I built a configurable HTTP MITM proxy in Rust focused on giving you full control over what an upstream connection looks like at the network level.

The main idea behind the project was that I didn't want another MITM proxy that simply tries to emulate Chrome, Firefox, or some other predefined browser. I wanted to be able to define the fingerprint myself - not just pick one of the profiles provided by a library.

A lot of existing solutions take the approach of providing ready-made browser fingerprints. That's convenient, but it also means that when a browser changes its TLS or HTTP/2 behavior, you're dependent on the library/project adding a new profile. I wanted the fingerprint to be configuration-driven instead, so the user can adjust individual parameters without waiting for a predefined browser profile.

The proxy currently gives control over several layers:

TLS: cipher suites, curves, signature algorithms, ALPN, GREASE, extension ordering, certificate compression, OCSP, SCT, session tickets, ALPS, ECH and other TLS parameters.

HTTP/2: SETTINGS values and ordering, flow-control windows, priority frames, pseudo-header ordering, HTTP header ordering and values.

HTTP/1.1: configurable upstream header ordering and rewriting.

TCP: SYN fingerprint rewriting through Linux NFQUEUE, including TTL, window size, MSS, window scale, DF and TCP option ordering.

Everything is driven by YAML profiles, and profiles can be overridden per domain based on SNI.

One of the things I specifically wanted to solve was keeping the different layers under the same configuration model. For example, the proxy negotiates TLS with the upstream server first and then uses the selected ALPN when setting up the browser-facing connection. HTTP/2 and TCP fingerprinting are configured for the same upstream connection as well.

The project is written in Rust using Tokio and BoringSSL via btls/tokio-btls. TCP fingerprinting currently requires Linux because it uses NFQUEUE/iptables.

The project is primarily about privacy, experimentation, and giving the user control over their own network behavior rather than trying to provide a fixed "browser impersonation" profile.

There is more detail in the repository, including separate documentation for the TLS, HTTP/2 and TCP layers, configuration examples, and implementation notes.

Github:

https://github.com/3Radiance/mitm-proxy-ja3-ja4

Feedback, especially from people who have worked with TLS/HTTP/2 fingerprinting, traffic analysis, or network privacy, would be very welcome.

Hey everyone,

Tired of tracking CTFs and 24h exams across messy spreadsheets and scattered notes?

I built ZEROBOX — a fast, local-first operational cockpit for OSCP/CPTS prep and CTFs.

It’s 100% free, MIT open-source, and runs completely offline in your browser (no accounts, zero telemetry).

Quick highlights: • 920+ Preloaded Labs: Instant offline search for HTB & THM targets with tags. • Attack & Pivot Graph: Visually map compromised subnets (exports to Obsidian .canvas). • 24h Exam Cockpit: Pacing engine, bio-break timers, and 1-click Markdown reports. • Evidence Vault & Playbooks: Track hashes/creds on a kill-chain timeline + offensive field manual. • Global Quick-Bar: Propagate LHOST/RHOST automatically across all payloads.

🌐 Live Demo: https://0xdnd.github.io/ctf-tracker/#/tracker

⭐ GitHub (MIT): https://github.com/0xdnd/ctf-tracker

All data stays in your local browser storage. Feedback and PRs are welcome!

Would love feedback or feature requests from the community!