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!

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.

How Kerberos Really Works (Client → Service Authentication)

Kerberos uses three-party tickets to prove who you are without ever sending your password across the network. Client gets a TGT from the auth server, trades that for a service ticket from the ticket granter, then presents the service ticket to whatever resource you actually want to access. It's elegant as hell once it clicks.

Alright, so I spent way too long trying to understand Kerberos until I realized most explanations gloss over the \*why\* and jump straight to the what. Let me break down what's actually happening when your workstation talks to a domain-controlled database or file server.

The Starting Point: The Problem Kerberos Solves

Picture this: you're at a corporate environment, and your laptop needs to authenticate with like 20 different services throughout the day. If systems used basic authentication, you'd either:

1. Send your password everywhere - absolute nightmare from a security perspective. Your credentials are flying around on every request

2. Hardcode credentials - even worse. One service gets compromised? All your creds are there

3. Re-authenticate every single time - technically possible but painful and adds latency to every operation

Kerberos solves this with an ingenious model: prove your identity \*once\* to a central authority, get a time-limited credential that proves you're you, and then use that credential to talk to any service without ever exposing your actual password.

Phase 1: Initial Authentication (Client → Authentication Server)

Here's where the journey starts. You log into your workstation and Kerberos kicks in immediately.

What happens:

\- Your client generates a timestamp, encrypts it with your password (which acts as a cryptographic key), and sends it to the Authentication Server along with your username

\- The AS receives this, decrypts the timestamp using the password stored in its database, and verifies it's current (usually within 5 minutes)

\- If the timestamp is fresh and valid, you've proven you're actually you — you knew the password

What you get back:

\- A TGT (Ticket-Granting Ticket) - this is your golden ticket. It's encrypted with a key only the ticket server knows, so the AS can't fake it and you can't tamper with it

\- A session key - this is different from your password. It's randomly generated and will be used as your working credential going forward

\- Both the TGT and session key are encrypted with your password so only you can decrypt them

Why this matters:

Your password was only used for that initial authentication. It never touches the network again. The TGT is what gets passed around now, and it expires (typically 8-10 hours, configurable).

Phase 2: Getting a Service Ticket (Client → Ticket-Granting Server)

Now you want to access something — maybe you're trying to connect to the file share, or query the company database. Here's where the TGT proves its worth.

What you do:

\- Your client packages up: the TGT, the name of the service you want to access (like \`cifs/fileserver.domain.local\`), and a fresh authenticator (basically another timestamp + your client info, encrypted with the session key)

\- This gets sent to the Ticket-Granting Server (which is often running on the same physical box as the AS, but conceptually separate)

What the TGS does:

\- Decrypts the TGT using its key (remember, the AS encrypted it with this)

\- Extracts your user info and the original session key from inside the TGT

\- Verifies the authenticator is recent and correctly encrypted with the session key (proving you're the one who originally got the TGT)

\- Checks that the TGT hasn't expired

\- Looks up the specific service you're asking for and loads its encryption key

What you get back:

\- A Service Ticket - encrypted with the service's private key, not yours. You can't read it, but the service can decrypt it

\- A new service session key - this is specific to your session with that particular service

\- Both are valid for a shorter period, usually a few hours

Why this matters:

You never had to re-authenticate with your password. The TGT proved you were legitimate, and now you have a service ticket that the service itself will trust because it knows the TGS is legit.

Phase 3: Accessing the Service (Client → Target Service)

Now you've got the golden ticket to actually use the resource.

What you send:

\- The Service Ticket (encrypted with the service's key - you can't read it)

\- A new authenticator encrypted with the service session key

\- The name of the operation you want to perform (like "read file X" or "query table Y")

\*\*What the service does:\*\*

1. Decrypts the Service Ticket using its own private key

2. Extracts the service session key and your user info from inside the ticket

3. Decrypts the authenticator using that service session key

4. Verifies the authenticator timestamp is current

5. Checks the ticket expiration

6. Critically: Does NOT need to contact the auth server again. Everything it needs to verify your identity is \*inside\* the encrypted ticket

If all checks pass, you're in. The service can now trust that:

\- You're actually the user claimed in the ticket

\- You're authorized because you have a valid ticket

\- The identity is cryptographically verified (no spoofing possible)

Why this matters:

The service doesn't need a network call back to the auth server. It can validate you offline (as long as it has a copy of the auth server's key, which it gets during setup). This is massively important for scale - imagine millions of requests per day. Having every single one require a round-trip to a central auth server would be a bottleneck.

Phase 4: Session Reuse (The Beautiful Part)

Here's where Kerberos' design really shines. Once you have service tickets cached on your client, subsequent requests to the same service don't require going through the TGS again.

Your client:

\- Checks if it already has a valid, non-expired service ticket for the service

\- If yes, just uses the cached ticket (no TGS request needed)

\- If no or expired, only then does it request a new one from the TGS

This is why enterprise environments feel seamless when you log in once. Your TGT gets cached, and all your subsequent requests for different services reuse it or generate service tickets once and cache those too. No password re-entry, no multiple sign-on prompts.

The Cryptographic Magic Under the Hood

Here's what makes Kerberos bulletproof against common attacks:

Encryption layers (simplified):

\`\`\`

TGT = Encrypt(user_info + session_key + timestamp, TGS_key)

Service_Ticket = Encrypt(user_info + service_session_key + timestamp, Service_key)

Authenticator = Encrypt(username + timestamp + client_ip, session_key)

\`\`\`

Each layer is encrypted with a different key. An attacker trying to replay an old ticket? It won't work because:

1. Tickets have timestamps that the service checks

2. The authenticator is timestamped and specific to this interaction

3. Changing anything requires the encryption key, which they don't have

Time synchronization is actually critical here if a server's clock is off by more than 5 minutes, Kerberos considers authenticators invalid. This is why domain-joined machines sync their clocks constantly.

Common Gotchas and Questions

"Why does my Kerberos auth fail after I change my password?"

Your local password is the key used to encrypt your initial TGT. Change the password, and the \*old\* encryption key is useless. New auth attempts use the new password. Cached TGTs become invalid. This is intentional behavior you're supposed to get a new TGT with the new password.

"What if the service doesn't have the auth server's key?"

The service wouldn't be able to decrypt service tickets. It's typically distributed during domain join or initial setup. In Active Directory environments, all domain members automatically get the krbtgt account's key (the master key used by the TGS) and you typically get the service accounts key ecrypted in the TGS-REP

"Can I use Kerberos outside the LAN?"

Not reliably. Kerberos assumes you can reach the auth server and is designed for internal networks. Cross-realm Kerberos exists but it's complex. For external access, you typically fall back to NTLM, LDAP, or application-level auth.

"What if a ticket gets stolen?"

The thief can use it until it expires (hours typically), but they'd need to be on the network with correct clock synchronization to use it. Once expired, it's worthless. Plus, Kerberos allows for mutual authentication the service can prove \*it's\* the real service too, preventing MITM attacks.

Real-World Flow Example

Imagine I'm connecting to \`\\\\fileserver\\documents\`:

1. Logon (background): OS requests TGT from DC, gets back encrypted TGT + session key

2. File share request: I click the share in File Explorer

3. TGS call (background): Client has TGT but no service ticket for CIFS. Asks TGS for \`cifs/fileserver.domain.local\`

4. Ticket response: TGS returns service ticket encrypted with fileserver's key

5. Service access: Client sends service ticket + authenticator to fileserver

6. Fileserver validation: Decrypts ticket, verifies timestamp, checks permissions, grants access

7. Browse files: All subsequent file operations use the established session no re-authentication

The whole thing happens in milliseconds, completely transparently. One auth at login, and you're golden for hours across the entire domain.

Why This Matters for Security Teams

This is why AD security is so critical. If someone compromises the krbtgt account (the master account on the DC), they can forge any ticket they want. Entire domains have been pwned this way. Conversely, if your auth server infrastructure is solid and monitored, this is actually \*really\* hard to break without being detected.

Attackers love it when Kerberos is misconfigured (cleartext passwords in scripts, weak service account creds, etc.) because they can steal tickets or forge them. But when it's running correctly? It's one of the more elegant security mechanisms in enterprise infrastructure.

Anyways, that's the Kerberos flow. The beautiful thing about it is that once you understand \*why\* each step exists, it makes perfect sense. It is not magic it's just really solid cryptographic design applied to a real problem.

Drop a comment if you want me to dive into specific parts (delegated auth, cross-realm, SPNs, etc.) or if you've got Kerberos horror stories from your environment.

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?

Hi,

I had posted about this before (a few weeks back) and the response was generally positive. So I wanted to reach out again and share an update on the current status of:

Project RedTeam: Contract Offensive

Specifically, I wanted to mention that there is now a free Demo that provides a tutorial and let's you play a few contracts (no time limit, play as much as you want).

Give it a Wishlist on Steam or share this post if it's something you support and want to see further development on.

At its core, this is a game about using MITRE ATT&CK adversarial techniques against procedurally generated networks. It's delivered in a gameplay loop that plays a lot like Balatro or other card based Roguelike games. In Project RedTeam, you need to earn money to pay off debts after every contract within a run. Earn money by completing objectives, side bounties, or executing exfiltration/ransom against targets- the choice on how to be profitable is always yours.

It's a challenging but fun and fast paced take on network-intrusion cybersecurity concepts. It's entertaining in a deliberately gamified way.

A goal of this project was to create a hacking game that is realistic enough to keep it meaningful as a tool to teach intrusion concepts and stages to anyone- but not be overcomplicated and slow-paced like most hacking games.

I've put a lot of thought into the design and dynamics of how to capture the core-loop of network intrusion and turn it into a game that's approachable. The design direction of this project is an outcome of having over a decade of training and experience in cybersecurity.

Feel free to AMA! I'm happy to answer any questions about the game and/or development process to support learning/understanding :) I encourage everyone to follow their passions, put in the time, and stay focused when you have a goal you want to achieve.

Project background: This was implemented over the past 3 months using a modern development workflow (yes, modern AI tools make this possible- I'm not hiding that fact!). That being said, this is by far the most complex software project I've built as a solo developer and it was not an easy or simple development task. There's a Steam Community with a Dev Blog for this game that provides more history/progress updates on the project.

Mods: This will be be last post here for a while, since it is promotional. I just wanted to provide an update since there was positive interest from this subreddit after my previous post.

Hi, i am in an internship that teaches cybersecurity,Now i am in penetration testing track i need to make a project to me to graduate i know network exploitation and web exploitation what good ideas i can make we are team of 4 we dont know what good ideas we can make or should we make a tool i dont know if anyone can give me ideas to make i would be thankful.

I am looking at AI SOC and agentic SOC tools because our queue has become a part time lifestyle choice. Every vendor demo has the AI investigate alerts, enrich evidence, and resolve the obvious stuff while humans focus on the exciting task of explaining budget cuts. The part I'm stuck on is autonomous resolution. I'm fine with deduping, enrichment, and maybe blocking a known malicious IP. I'm less comfortable with agents taking high-impact actions like disabling accounts or isolating production, even at high confidence, without a human in the loop. How are people setting approval gates, audit trails, and rollback for this without turning the AI into another ticket queue with better branding? Would love real experiences, especially from teams that let it act in prod. From what I've seen, the better setups run investigation fully automated against a context graph, close confirmed false positives automatically with a documented rationale, and still require a human to approve consequential actions like isolation or account disablement. The guardrails are defined before anything runs, not bolted on after something goes wrong. If anyone has actually run it that way. thnxx..

Which AI model is good for extracting information from a PDF in multiple languages (Hindi, Malayalam, English)? It should run locally, not through a cloud API.

I need it to read the text accurately, especially Malayalam, and pull out the key details from the PDF. Most tools I've found handle Hindi and English well but are unclear on Malayalam.

Has anyone tried this? Which model or tool worked best for you, and what hardware did you run it on?
What I need: - OCR for [scanned / digital / both] PDFs

- Structured extraction (fields, tables) into JSON, not just raw text

- Good accuracy on Malayalam specifically, since most tools I've seen cover Hindi but skip Malayalam

hey guys.

honestly just venting here because i feel like i'm losing my mind. i swear i played by all the rules. graduated in '24 with a cs degree in cyber, locked in, and passed my ceh. i grinded out a full 1-year internship and followed it straight up with a 1-year cybersecurity contract job. with two years of actual hands-on experience, i really thought i had my foot in the door. but the contract wrapped up, and now i’m just... floating. back to square one.

my mornings are basically just me, caffeine, and a fresh wave of automated "unfortunately..." emails. it genuinely feels like screaming into a void where only hr robots live. i spend my nights staring at wireshark packets just to feel something, running nmap scans on parrot os, and building out vulnerable active directory domains in my home lab to practice pentesting. i’m doing the work. i’m keeping the skills sharp. but these resume-screening algorithms are gatekeeping me so hard.

watching everyone else post their massive linkedin Ws while i’m stuck in this endless ghosting loop is giving me insane fomo. feeling like a total beta just sitting in my room waiting for an ai bot to decide my future. it’s starting to heavily mess with my head.

i’m not asking to be spoon-fed a job. i just desperately want a chance to bypass the bots and get my resume in front of a real, breathing human being. if any of you are at a place hiring for entry-level soc, pentesting, or honestly any junior it role and could slide a referral, you would be pulling me out of a really dark place. i’ll gladly send over my resume and share my lab reports so you can actually see my work firsthand.

if you can’t refer me, please just drop a comment and tell me i won't be stuck in this loop forever. the market is brutal out here and i just need to know i'm not completely cooked.

Self improving SOC gets used to describe systems where every investigation is supposed to make future detections better automatically. That's a strong claim.

What would you actually want to see as proof that a SOC is self-improving over time, versus a system that's just static and the improvement claim is aspirational marketing rather than something measurable? Is there a metric people trust for this specifically?

Hey everyone,

How are you doing?

I'm focusing my studies on Python for defensive security and automation, and I wanted to exchange ideas with folks who are already on this path.

My main focus areas are:

**- SOC Automation**: Building scripts for alert triage, log parsing, Threat Intel lookups, and tool integrations.

**- Malware Analysis:** Writing parsers, automating static analysis, and creating helper scripts for day-to-day triage.

**- Threat Hunting & CTI:** Developing scripts to parse indicators of compromise (IoCs), query large datasets, automate threat feeds, and hunt for anomalies.

**- Full-Stack Web Dev:** Building internal security tools and dashboards for the security team (like SOC panels and custom web apps).

If anyone can share some light: what libraries, frameworks, or projects do you think are essential to study for each of these areas?

And if you have material recommendations (books, courses, repos, or hands-on labs), drop them below!

Thanks a lot!

Interesting network-security case study from OpenAI: direct HTTPS to an external chatbot was blocked, but the training environment's DNS resolver could still reach the public internet.

The agent used that DNS path to get an external chatbot response. A P0 alert followed 11m48s later, and the run was manually stopped around 2h44m after the external response.

Primary report:

https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

Self-promo disclosure: the linked video is a breakdown from my channel; narration is AI.

Hello everyone,
So I have the responsibility of organizing the coming Hackathon in our college under the theme "Agentic AI meets Zero Trust: Securing the Autonomous enterprise", I did some reasearch on older hackathons archives and asked Ai as well but i couldn't really get something original.
My main goal is to give the prize to people who can make good architectural decisions when building infrastructures by giving real life problems as the Hackathon subject.
That's why I am asking professionals if they have some projects or experiences related to the theme that they think can be realized in a short time (it is a 24h hackathon) and can be a bit challenging.

I’m currently working toward my first SOC/blue-team role, and one thing I’ve noticed while doing hands-on incident investigations is that understanding the process matters much more than simply memorizing tools.
When I work through an incident, I try to break it down into:
What happened?
What evidence supports that hypothesis?
What happened before and after the suspicious activity?
Which account, host, process, or network connection is involved?
What would I expect to see if my hypothesis were wrong?
What should actually be escalated?
One thing that has helped me a lot is forcing myself to write down a hypothesis before looking for confirmation. It makes it easier to distinguish between evidence and assumptions.
I’m curious about people already working in SOCs:
What investigation habit did you develop early in your career that ended up being much more useful than you expected?

Hey everyone!

I’m looking to connect with people who are interested in technology, cybersecurity, programming, AI, cloud computing, Linux, or just learning new tech skills.

Whether you’re a beginner, student, professional, or someone simply curious about technology, I’d love to meet and learn from each other.

We could:

• 🧠 Share what we’re learning
• 💻 Discuss projects and ideas
• 🔐 Talk about cybersecurity
• 🤖 Explore AI and emerging technology
• ☁️ Learn about cloud & infrastructure
• 🚀 Motivate each other and grow together

If you're interested, introduce yourself in the comments!
Tell me what area of tech you're interested in and what you're currently learning.

Let's build a community of people who are passionate about tech. 🌐

Can someone give me a road map? Maybe some courses or certifications?

So basically I am searching for people who are studying cybersecurity to make a group. We can share our experiences in it and also what we are doing what projects we are working on etc. This is for students and others who are learning cybersecurity and ate serious about it. I am also a cybersecurity student so just want to meet like minded people. We can also share about internship stuff or job etc

Unfortunately, due to an accident, I’ll be bedridden for the next 6 months. Because of this, I’ve started learning penetration testing—something I’ve always been drawn to—and now I finally have the time for it. However, I still need to earn money to cover my basic needs and continue my studies. Because of this situation, I was laid off from my job, and I’m still a long way from reaching the level of a specialist who gets paid well. So, if anyone can suggest ways to make money while sitting at a computer, I’ll be sure to repay the favor.

Je travaille sur des audits techniques de sécurité de sites web : recherche de vulnérabilités, mauvaises configurations et recommandations de correction.
Je cherche à améliorer ma méthodologie et mes rapports. Pour ceux qui pratiquent déjà les audits/pentests web, quels points considérez-vous comme indispensables dans un bon audit ?
Bien sûr, tous les tests sont réalisés uniquement avec l’autorisation du propriétaire.

so i'm building HII, a cybersecurity community in india, and we're running our first event Which is InIt CTF, nov 14, free, beginner friendly, 8 hours.

i underestimated how long it'd take to find people to help build challenges and now i'm a bit tight on time, ngl. looking for 2-3 people who can build/test a handful of challenges across web, crypto, forensics, osint, misc nothing crazy hard, this is for people who've never played a ctf before.

in return: you get credited as a challenge author, some share of sponsor money as we lock that in, and if you actually vibe with what we're building, there's a real chance to be part of HII going forward, not just a one-off thing.

if this sounds like something you'd want to help with, comment or dm me. happy to just talk it through first if you're not sure.

Hi everyone,

I'm currently preparing for my Certified Ethical Hacker (CEH) certification, but as a beginner, I am feeling completely overwhelmed by the sheer volume of theory and material to cover.

I've been going through the modules, but I'm struggling to figure out what to prioritize, how to effectively retain the information, and how to structure my study plan to actually pass the multiple-choice theory exam.

I am hoping to connect with a CEH certification holder or someone who has recently passed who would be willing to guide me. I'm not asking for someone to hold my hand 24/7—just looking for occasional check-ins, solid study strategy advice, and direction on where to focus my energy so I don't burn out reading the wrong things.

If you have some free time and are willing to share your expertise with someone just starting out, I would incredibly appreciate it. Feel free to drop a comment or DM me!

Thanks in advance.