IFIN Threat Intel

29 Followers
0 Following
61 Posts

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.

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

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.

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.

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

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

Value | Type | Description-|-|-ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c | SHA256 | Hash of router_init.jsrouter_init.js | String | Filename of common indicator filefilev2.getsession.org | Domain | Session C2 Domainapi.masscan.cloud | Domain | C2 Domaingit-tanstack.com | Domain | C2 Domainbun run tanstack_runner.js | Process Command Line | Launches router_init.js

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.

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

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.

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

This one went entirely under the radar for me yesterday. But it looks spicy. No-priv, un-auth.

https://security.paloaltonetworks.com/CVE-2026-0300

From Palo Alto:

Description

A buffer overflow vulnerability in the User-ID(tm) Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to execute arbitrary code with root privileges on the PA-Series and VM-Series firewalls by sending specially crafted packets.

The risk of this issue is greatly reduced if you secure access to the User-ID(tm) Authentication Portal per the best practice guidelines by restricting access to only trusted internal IP addresses.

Prisma Access, Cloud NGFW and Panorama appliances are not impacted by this vulnerability.

Product Status

| Versions | Affected | Unaffected ||:---:|:---:|:---:|| Cloud NGFW | None | All || PAN-OS 12.1 | < 12.1.4-h5< 12.1.7 | \>= 12.1.4-h5 (ETA: 05/13)>= 12.1.7 (ETA: 05/28) || PAN-OS 11.2 | < 11.2.4-h17< 11.2.7-h13< 11.2.10-h6< 11.2.12 | \>= 11.2.4-h17 (ETA: 05/28)>= 11.2.7-h13 (ETA: 05/13)>= 11.2.10-h6 (ETA: 05/13)>= 11.2.12 (ETA: 05/28) || PAN-OS 11.1 | < 11.1.4-h33< 11.1.6-h32< 11.1.7-h6< 11.1.10-h25< 11.1.13-h5< 11.1.15 | \>= 11.1.4-h33 (ETA: 05/13)>= 11.1.6-h32 (ETA: 05/13)>= 11.1.7-h6 (ETA: 05/28)>= 11.1.10-h25 (ETA: 05/13)>= 11.1.13-h5 (ETA: 05/13)>= 11.1.15 (ETA: 05/28) || PAN-OS 10.2 | < 10.2.7-h34< 10.2.10-h36< 10.2.13-h21< 10.2.16-h7< 10.2.18-h6 | \>= 10.2.7-h34 (ETA: 05/28)>= 10.2.10-h36 (ETA: 05/13)>= 10.2.13-h21 (ETA: 05/28)>= 10.2.16-h7 (ETA: 05/28)>= 10.2.18-h6 (ETA: 05/13) || Prisma Access | None | All |

Required Configuration for Exposure

This issue is applicable only to PA-Series and VM-Series firewalls that are configured to use User-ID(tm) Authentication Portal.

You can verify whether you have User-ID(tm) Authentication Portal configured in the User-ID(tm) Authentication Portal Settings page (Device > User Identification > Authentication Portal Settings -> Enable Authentication Portal).

Severity: CRITICAL, Suggested Urgency: HIGHEST

The risk is highest when you configure the User-ID(tm) Authentication Portal to enable access from the Internet or any untrusted network.CRITICAL - CVSS-BT: 9.3 /CVSS-B: 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N/E:A/AU:Y/R:U/V:C/RE:M/U:Red)

You can greatly reduce the risk of exploitation by restricting User-ID(tm) Authentication Portal access to only trusted internal IP addresses and preventing its exposure to the internet.HIGH - CVSS-BT: 8.7 /CVSS-B: 8.7 (CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N/E:A/AU:Y/R:U/V:C/RE:M/U:Red)

Exploitation Status

Limited exploitation has been observed targeting Palo Alto Networks User-ID(tm) Authentication Portals that are exposed to untrusted IP addresses and/or the public internet. Customers following standard security best practices, such as restricting sensitive portals to trusted internal networks are at a greatly reduced risk.

Exploitation Details/IOCs

Unit 42 has more details in their report.

https://unit42.paloaltonetworks.com/captive-portal-zero-day/

Starting April 9, 2026, there were unsuccessful exploitation attempts against a PAN-OS device. A week later, the attackers successfully achieved RCE against the device and injected shellcode. Following the compromise, the attackers immediately conducted log cleanup to mitigate detection by clearing crash kernel messages, deleting nginx crash entries and nginx crash records, as well as removing crash core dump files.

The attackers deployed a number of tools with root privileges four days later, before conducting Active Directory (AD) enumeration using the firewall’s service account credentials to target domain root and DomainDnsZones. Following enumeration, the attackers deleted ptrace injection evidence from the audit log and deleted the SetUserID (SUID) privilege escalation binary.

Known attackers are using and downloading the Earthworm and ReverseSocks5 tools.

  • 67.206.213[.]86
  • 136.0.8[.]48
  • 146.70.100[.]69 (C2 Staging)
  • 149.104.66[.]84
  • hxxp[:]//146.70.100[.]69:8000/php_sess (EarthWorm Download)
  • hxxps[:]//github[.]com/Acebond/ReverseSocks5/releases/download/v2.2.0/ReverseSocks5-v2.2.0-linux-amd64.tar[.]gz (ReverseSocks5 Download)
  • e11f69b49b6f2e829454371c31ebf86893f82a042dae3f2faf63dcd84f97a584 (EarthWorm)
  • Safari/532.31 Mozilla/5.5 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 Edg/138.0.0.0 (Attacker User Agent String)
  • /var/tmp/linuxap, /var/tmp/linuxda, /var/tmp/linuxupdate (Tunneling Tools)
  • /tmp/.c (Unidentified Python Script)
  • /tmp/R5, /var/R5 (ReverseSocks5)

IFIN Recommendations

  • Follow above mitigation strategies
  • Monitor Palo Alto service accounts for activity, particularly AD enumeration
  • Wherever possible, monitor for the use of mentioned tools


Discuss this on our forum.