Mastodawn

Last Updated: 2026-05-21T20:32:38Z (UTC)

What's Happening

A widespread GitHub Actions attack codenamed "Megalodon" has compromised over 5600 GitHub repos. The payload is an infostealer that of course has worming capabilities.

SafeDep has the details.

https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows/

Actions

Review the commit messages, users, and contents for presence in your repositories. Also note the exfiltration server at 216.126.225[.]129:8443, although these connections will likely be made from a GitHub Actions VM, unless you're using custom runners. If so, watch those for suspicious activity.

Discuss this on our forum.

IFIN Threat Intel 2d ago

Last Updated: 2026-05-19T06:10:31Z (UTC)

What's Happening

Hundreds of NPM packages have been compromised in yet another TeamPCP attack. The attack vector appears to be a single maintainer, atool.

https://opensourcemalware.com/blog/teampcp-compromises-npm-maintainer-with-over-540-packages

https://socket.dev/blog/antv-packages-compromised?utm_medium=feed

Actions

Review the list of affected packages and versions and check for presence in your environments. Review GitHub repos for indicators of compromise.

Once again, bun is used as the malware executor. Seek bun installs to non-standard locations and process executions from those locations.

Notes

Antv is a popular AI visualization ecosystem from Alibaba. A lot of downloads are involved in this one—millions per week.

Discuss this on our forum.

TeamPCP compromises NPM maintainer with over 540 packages

A threat actor tracked as TeamPCP has compromised two npm maintainer accounts — including the one behind the AntV data-visualization suite — republishing 324 packages with over 16 million combined weekly downloads.

IFIN Threat Intel 3d ago

Observable:

msMaliciousIps20260518.txt (7.6 KB)

Observable Type: IP Addresses

Admiralty: B2

Details: These IPs were observed in an M365 tenant and associated logins were specifically blocked by Microsoft "because it came from an IP address with malicious activity." It's a good start to hunt for more related IPs / clusters.

Discuss this on our forum.

Malicious IPs Flagged by Microsoft

Observable: msMaliciousIps20260518.txt (7.6 KB) Observable Type: IP Addresses Admiralty: B2 Details: These IPs were observed in an M365 tenant and associated logins were specifically blocked by Microsoft “because it came from an IP address with malicious activity.” It’s a good start to hunt for more related IPs / clusters.

IFIN

IFIN Threat Intel 6d ago

Last Updated: 2026-05-15T18:08:25Z (UTC)

What's Happening

CVE-2026-20182 Authentication Bypass in Cisco Catalyst SD-WAN controller has been found exploited in the wild. It has a severity rating of 10.

Rapid 7, who initially disclosed the vulnerability, has published their own in-depth analysis and timeline.

https://www.rapid7.com/blog/post/ve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed/

Rapid7 has also released a Metasploit Module that exploits this vulnerability.

https://github.com/rapid7/metasploit-framework/pull/21463

Cisco has released an update and disclosed a number of IOC's related to the ongoing exploitation.

https://blog.talosintelligence.com/sd-wan-ongoing-exploitation/

The NIST CVE entry.

https://nvd.nist.gov/vuln/detail/CVE-2026-20182

Actions

Update Cisco SD-WAN. This table from Rapid7 shows patched versions for all fixed releases:

| Cisco Catalyst SD-WAN Release | First Fixed Release ||----|----|| Earlier than 20.9\* | Migrate to a fixed release || 20.9 | 20.9.9.1 || 20.10 | 20.12.7.1 || 20.11\* | 20.12.7.1 || 20.12 | 20.12.5.4, 20.12.6.2, 20.12.7.1 || 20.13\* | 20.15.5.2 || 20.14\* | 20.15.5.2 || 20.15 | 20.15.4.4, 20.15.5.2 || 20.16\* | 20.18.2.2 || 20.18 | 20.18.2.2 || 26.1.1 | 26.1.1.1 |

Indicators of Compromise

Note that the Cisco Talos IoCs listed in their linked GitHub repo appear to be for a different campaign.

|Value | Type | Description||--- | --- | ---||38.181.52\[.\]89 | IPv4 | Cluster 1||89.125.244\[.\]33 | IPv4 | Cluster 1||89.125.244\[.\]51 | IPv4 | Cluster 1||71.80.85\[.\]135 | IPv4 | Cluster 2||212.83.162\[.\]37 | IPv4 | Cluster 3||38.60.214\[.\]92 | IPv4 | Cluster 4||65.20.67\[.\]134 | IPv4 | Cluster 4||104.233.156\[.\]1 | IPv4 | Cluster 4||194.233.100\[.\]40 | IPv4 | Cluster 4||f6f8e0d790645395188fc521039385b7c4f42fa8b426fd035f489f6cda9b5da1 | sha256 | Cluster 5 -- AdaptixC2 sample||194.163.175\[.\]135:4445 | IPv4:port | Cluster 5 -- AdaptixC2 C2 server||194.163.175\[.\]135 | IPv4 | Cluster 5 -- AdaptixC2 C2 IP||02654acfb21f83485393ba8b14bd8862b919b9ec966fc6768f6aac1338a45ee8 | sha256 | Cluster 6 -- Sliver sample||mtls://23.27.143\[.\]170:443 | url | Cluster 6 -- Sliver C2 over mTLS||23.27.143\[.\]170 | IPv4 | Cluster 6 -- Sliver C2 IP||0ed72d52347bfe4a78afff8a6982a64050c8fc86d8957a20eeb3e0f3f5342ed0 | sha256 | Cluster 7 -- XMRig downloader script||96fc528ca5e7d1c2b3add5e31b8797cb126f704976c8fbeaecdbf0aa4309ad46 | sha256 | Cluster 7 -- XMRig sample||7aa88a64a527ade7d93c20faf23b54f2ee33ad9b1246cdc2f8ded2ab639affb1 | sha256 | Cluster 7 -- XMRig configuration||83.229.126\[.\]195 | IPv4 | Cluster 7 -- XMRig remote location IP||hxxp://83.229.126\[.\]195:8081/xmrig | url | Cluster 7 -- XMRig remote URL||hxxp://83.229.126\[.\]195:8081/config.json | url | Cluster 7 -- XMRig configuration file remote location||0c87871642f84e09e8d3fb23ec36bf55601323e31151a7017a85dbec929cf15d | sha256 | Cluster 8 -- Nim-based backdoor||hxxps://1a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p.worf.replit\[.\]dev/download | url | Cluster 8 -- Download URL for the Nim-based backdoor||1a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p.worf.replit.dev | hostname | Cluster 8 -- Attacker controlled sub-domain hosting the Nim-based backdoor||79.135.105\[.\]208 | IPv4 | Cluster 8 -- Attacker IP that downloaded the Nim-based backdoor||hxxp://13\[.\]62\[.\]52\[.\]206:5004 | url | Cluster 8 -- C2 for Nim-based backdoor||13.62.52\[.\]206 | IPv4 | Cluster 8 -- C2 IP for Nim-based backdoor||18d77c9c5bbb5b9d5bdfd366fdfcf26bad9e64c63ca865fad711bcce8e3d5a80 | sha256 | Cluster 8 -- KScan scanning tool||176.65.139\[.\]31 | IPv4 | Cluster 8 -- IP related to Nim-based backdoor and KScan||d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa | sha256 | Cluster 9 -- gsocket sample||5bc5998161056b7c8f70c9724d8a63abc7ff8c3843b91c30cffab0899e39b7f8 | sha256 | Cluster 9 -- gsocket secret file||47.104.248\[.\]7 | IPv4 | Cluster 9 -- IP related to Miner activity||b0f51b098842cd630097b462aab0ec357e2c7824af37cca6d08165265da2c2d3 | sha256 | Cluster 10 -- VManage credential extractor script||72f570ce97de3eaaffef33d90b0c337a153fc9690cc34ee207b557d868360060 | sha256 | Cluster 10 -- Check for root escalation||17302d903baf182f94dc3be40ab1e0874dd0eb2ec5255bf9131fd53591efe925 | sha256 | Cluster 10 -- Check for root escalation|

Notes

Discuss this on our forum.

IFIN Threat Intel May 14

Socket.dev has yet another NPM package compromise, in this case the node-ipc packages.

https://socket.dev/blog/node-ipc-package-compromised

Affected versions:

Initial access appears to be email domain takeover from a dormant maintainer.

Assuming the npm account recovery email for atiertant was indeed hosted on atlantis-software[.]net , the new domain owner was then able to trigger a standard npm password reset, receive the reset email at a mailbox under their control, and gain publish rights without ever compromising any of the maintainer's own infrastructure

Indicators of Compromise

|Value | Type | Description||--- | --- | ---||96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144 | SHA256 | node-ipc.cjs||449e4265979b5fdb2d3446c021af437e815debd66de7da2fe54f1ad93cbcc75e | SHA256 | node-ipc-9.1.6.tgz ||c2f4dc64aec4631540a568e88932b61daebbfb7e8281b812fa01b7215f9be9ea | SHA266 | node-ipc-9.2.3.tgz||78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a7002981 | SHA256 | node-ipc-12.0.1.tar.gz||sh[.]azurestaticprovider[.]net | Domain | Bootstrap resolver||bt[.]node[.]js | Domain | Exfiltration domain||37.16[.]75.69 | IPv4 | Boostrap IP|

In addition to these indicators, a common exfil pattern was observed in longer domains.

xh......bt[.]node[.]jsxd......bt[.]node[.]jsxf....0..bt[.]node[.]js

Discuss this on our forum.

IFIN Threat Intel May 13

Here are some domains that appear to be a part of a Chinese domain reseller network. I'd suggest hunting on them and blocking if possible.

resellerDomains20260513.txt (51.0 KB)

Discuss this on our forum.

Domain Reseller Network

Here are some domains that appear to be a part of a Chinese domain reseller network. I’d suggest hunting on them and blocking if possible. resellerDomains20260513.txt (51.0 KB)

IFIN

IFIN Threat Intel May 11

Last Updated: 2026-05-12T17:22:17Z (UTC)

What's Happening

Around 170 NPM packages have been compromised by the same group executing other "Mini Shai-Hulud" attacks. The attack seems to have begun with TanStack, a popular web UI frontend framework, had its npm packages compromised Initial discovery by Step Security. The attack has moved over to PyPi as well.

https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem

TanStack has published their post-mortem here:

https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

OpenSourceMalware has a breakdown of the current spread, now at 170 packages. These include the Mistral AI clients.

https://opensourcemalware.com/blog/teampcp-mistralai-opensearch-compromised

Actions

Review Socket's very long list of compromised packages and search in your environment. It appears all affected packages share a new router_init.js file.

If these indicators are found, rotate all relevant secrets, session tokens, etc.

Indicators of Compromise

Notes

The relevant issue on their router package appears to be a good source of updates. They are working on an incident report now.

https://github.com/TanStack/router/issues/7383

Socket has another writeup.

https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack

Looks like quite a few examples of the attack code have been published to GitHub:

https://github.com/search?q=Shai-Hulud%3A+Here+We+Go+Again+&type=repositories

Discuss this on our forum.

IFIN Threat Intel May 11

Found this report via HackerNews. Attackers are getting victims to download Obsidian, enable community plugins, and use a shared "vault" to automatically download and execute scripts from a malicious plugin. End result is the phantompulse RAT on the system.

IOCs include Obsidian.exe spawning powershell.exe or cmd.exe on Windows or Obsidian spawning osascript on MacOS.

Details:

https://cyber.netsecops.io/articles/obsidian-plugin-abused-in-campaign-to-deploy-phantom-pulse-rat/

Discuss this on our forum.

Obsidian Plugin Abused in Social Engineering Campaign to Deliver New PHANTOMPULSE RAT

A sophisticated campaign is abusing the Obsidian note-taking app to deliver a new RAT, PHANTOMPULSE, to targets in the finance and crypto sectors using social engineering and malicious plugins.

CyberNetSec.io

IFIN Threat Intel May 10

Mexican water utility hit with a Claude-generated tool.

https://www.dragos.com/blog/ai-assisted-ics-attack-water-utility

No listed IoCs in the PDF, but the full report is worth a read to see how attackers are using these tools to orchestrate and execute attack chains.

dragos-2026-ai-mexico-water-attack-intel-brief (1).pdf (3.1 MB)

Discuss this on our forum.

IFIN Threat Intel May 7

Direct action you can take to confound the adversary? Yes please.

Thanks to the always-amazing Will Dormann, we have some valuable information on the continued exploitation of .URL file extensions by threat actors. And it turns out, per Will, that Microsoft doesn't view this as a problem—indeed, it is "expected behavior."

https://infosec.exchange/@wdormann/116533862391306228

So how do you fix it?

Registry haxx, of course.

For the current user:

reg add HKCU\Software\Classes\.url /ve /d DisabledURLFile /freg add HKCU\Software\Classes\DisabledURLFile /ve /d "Disabled Internet Shortcut" /freg add HKCU\Software\Classes\DisabledURLFile\shell\open\command /ve /d "notepad.exe \"%1\"" /freg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.url /f

In an elevated shell for the system:

reg delete HKCU\Software\Classes\.url /freg delete HKCU\Software\Classes\DisabledURLFile /freg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.url /freg delete HKLM\Software\Classes\.url.original /freg copy HKLM\Software\Classes\.url HKLM\Software\Classes\.url.original /s /freg delete HKLM\Software\Classes\.url /freg add HKLM\Software\Classes\.url /ve /d DisabledURLFile /freg add HKLM\Software\Classes\DisabledURLFile /ve /d "Disabled Internet Shortcut" /freg add HKLM\Software\Classes\DisabledURLFile\shell\open\command /ve /d "notepad.exe \"%1\"" /f

And while you're at it, do the same thing for .js files to prevent JScript malware.

reg add HKCR\JSFile\shell\Open\Command /ve /d "notepad.exe \"%1\"" /f reg add HKLM\SOFTWARE\Classes\JSFile\shell\Open\Command /ve /d "notepad.exe \"%1\"" /f reg add HKCU\SOFTWARE\Classes\JSFile\shell\Open\Command /ve /d "notepad.exe \"%1\"" /f

Discuss this on our forum.

Will Dormann (@[email protected])

Attached: 1 image Let's talk about Windows `.URL` (InternetShortcut) files. Last year there was discussion about a vulnerability in how Windows handles `.URL` files. Specifically, when a `.URL` file specifies a `WorkingDirectory` directive, an otherwise harmless app being launched would load DLLs from the remote (e.g. WebDAV) server specified. You know, being the current working directory of the app being launched and all. This vulnerability was being [exploited in the wild](https://www.virustotal.com/gui/file/e0a44274d5eb01a0379894bb59b166c1482a23fede1f0ee05e8bf4f7e4e2fcc6), and it worked well because it bypassed annoying (to attackers) things like SmartScreen. Sure, it required the victim to click `Open` on a dialog saying `Type: Unknown File Type` (😂), but we all know that users are click-happy, so this is fine. Besides, the file clearly has a `.pdf` extension, so it should be safe (😂). Microsoft recognized the vulnerability and published an [update in the form of CVE-2025-33053](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33053). If we were to believe the [Microsoft documentation at the time](https://web.archive.org/web/20250710095434/https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts), > When the user clicks the icon, the browser is launched and displays the site associated with the shortcut. But wait... How did this `.URL` file cause a program to be launched? The `URL=` parameter specifies a website address to be loaded in the browser. Oh, naive child. Obviously a `.URL` file can directly point to code on a remote (e.g. WebDAV) server. This technique is also [being exploited ITW as well](https://www.virustotal.com/gui/file/93a2d60d1ccfe3e009b1a81951653b559e0cae01c2454244a3a0fbd49a5e4539). I reported this to Microsoft, as this has the **EXACT SAME IMPACT** as CVE-2025-33053. So if that's a vulnerability, then this too is a vulnerability, right? Bless your innocent soul. Per MSRC: > When the Shell invokes an app from a remote share, it's expected that you will see the legacy Windows Security prompt, not the SmartScreen one. SmartScreen Application Reputation (AppRep) evaluation applies to locally downloaded files that bear an Internet Zone mark of the web. It is not meant to apply to execution of files from Network Shares. Okie dokie. I'm sure Windows users surely appreciate this. But what about the [incorrect documentation](https://archive.ph/MgBI8)? After my prodding, they [updated the wording](https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts): > When the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser. Leaving in the quite misleading first sentence: > The Internet shortcut object is used to create desktop shortcuts to Internet sites. (An "Internet site" is a web page, right?) How can CVE-2025-33053 warrant a CVE, while the behavior I described has the exact same trigger and impact is **not** CVE worthy? That's pretty easy. Microsoft assigns CVEs to **updates**, not **vulnerabilities**. They are the decider as to what is a vulnerability and what is not. What can we do about it? At the very least, turn off the Windows feature that hides file extensions, **even if you have the option turned on to see file extensions**. The disdain that Microsoft has for Windows users is tangible here. On what planet would I not want to see the actual extension of a file? Go to `HKCU\InternetShortcut` and delete the `NeverShowExt` value. After this, your `pwned.pdf` file will reveal its true self as being `pwned.pdf.url`. More powerful protection would be to block the ability to receive `.URL` files via email, web browsers, etc. There is no workflow that I can imagine that requires a user to double-click on a `.URL` file that **came from the internet**. Even more powerful than that would be to disassociate `.URL` files from opening in Windows (thx @mttaggart ). This screen recording is a Windows 11 system that has no internet connectivity. The fact that no warning was displayed that SmartScreen cannot be reached is evidence that SmartScreen is not in play at all. And that dialog... `Do you want to open this file?` and `Type: Unknown File Type` Do you think that users are presented with enough information to make an informed security decision? Of course not. But obviously we all know that we can't rely on users making informed security decisions in general. Don't put users in that position.

Infosec Exchange