Summarizer

Network egress monitoring

How StepSecurity Harden-Runner detected the attack by flagging anomalous outbound connections to the C2 domain sfrclak.com

← Back to Axios compromised on NPM – Malicious versions drop remote access trojan

The detection of this supply-chain attack via automated network monitoring underscores a shift toward prioritizing runtime behavior over manual code audits, as commenters highlight that tools flagging anomalous outbound connections often catch threats within hours. While some advocate for a seven-day delay on package updates to leverage "herd immunity" from early-adopting "pioneers," others maintain that the most robust protection is strict network filtering across all environments to prevent data exfiltration. This includes sophisticated strategies such as blocking newly registered domains and using proxies to restrict traffic to read-only endpoints, which can neutralize malware even when supply-chain integrity is compromised. Ultimately, the discussion reveals a growing reliance on automated agents and network-level oversight to identify suspicious activity that human reviewers and static analysis might otherwise overlook.

20 comments tagged with this topic

View on HN · Topics
If I remember correctly, in all the recent cases it was picked up by automated scanning tools in a few hours, not because someone updated the dependency, checked the code and found the issue. So it looks like even if no one actually updates, the vast majority of the cases will be caught by automated tools. You just need to give them a bit of time.
View on HN · Topics
What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
View on HN · Topics
Their analysis was triggered by open source projects upgrading en-masse and revealing a new anomalous endpoint, so, it does require some pioneers to take the arrows. They didn't spot the problem entirely via static analysis, although with hindsight they could have done (missing GitHub attestation).
View on HN · Topics
A security company could set up a honeypot machine that installs new releases of everything automatically and have a separate machine scan its network traffic for suspicious outbound connections.
View on HN · Topics
The problem is what counts as suspicious. StepSecurity are quite clear in their post that they decide what counts as anomalous by comparing lots of open source runs against prior data, so they can't figure it out on their own.
View on HN · Topics
The fact threat researchers and especially their automated agents are not all that good at their jobs
View on HN · Topics
Those threat researchers and their autonomous agents caught this axios release.
View on HN · Topics
Can you elaborate? Why do you believe that motivated threat hunters won’t continue to analyze and find threats in new versions of open source software in the first week after release?
View on HN · Topics
Worth noting this attack was caught because people noticed anomalous network traffic to a new endpoint. The 7-day delay doesn't just give scanners time, it gives the community time to notice weird behavior from early adopters who didn't have the delay set. It's herd immunity, not personal protection. You benefit from the people who DO install immediately and raise the alarm
View on HN · Topics
But wouldn't the type of people that notifes anomalous network activity be exactly the type of people who add a 7 day delay because they're security conscious?
View on HN · Topics
There's another element to the solution here: runtime behavioral analysis. No matter how completely the maintainer's credentials are compromised, no matter how well the malware is concealed, it still has to act like malware (in the case of LiteLLM, credential harvesting, in this case a remote-access Trojan). It's possible to detect the behavior, rather than relying on supply-chain integrity. We built a free tool that runs local behavior analysis on your machine, it's caught every supply-chain attack in the last couple weeks: https://www.producthunt.com/products/axios-litellm-detector
View on HN · Topics
Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments. The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through, and those domains must not be publicly controllable by attackers. ie. github.com is not safe to allow, but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it. Network firewalls that perform SSL interception and restrict DNS queries are an option also, though more complicated or expensive than the above. This stops both DNS exfil and HTTP exfil. For your devenv, software like Little Snitch may protect your from these (I'm not 100% on DNS exfil here though). Otherwise run your devenv (ie vscode) as a web server, or containerised + vnc, a VM, etc, with the same restrictions.
View on HN · Topics
Thats true. Setting to 7 days saves you from a supply chain attack, but opens you to zero days. Another example why network filtering is a better solution.
View on HN · Topics
> but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it But raw.githubusercontent.com still contains code and now the attacker can publish the code he wants no!? Don't get me wrong: I love the idea to secure as much as possible. I'm running VMs and containerizing and I eat firewalling rules for breakfast, my own unbound DNS with hundreds of thousands (if not millions) of domains blocked, etc. I'm not the "YOLO" kind of guy. But I don't understand what's that different between raw.githubusercontent.com and github.com? Is it for exploits that are not directly in the source code? Can you explain a bit more?
View on HN · Topics
In the case of compromised code, the attacker has already loaded what he wants, so loading extra code from raw.githubusercontent.com is not the issue, or our threat model. We are already compromised! The issue is that code then extracting secrets and data from your organisation, ie. data exfil. raw.githubusercontent.com can not be used to submit data to, it's read only, but github.com obviously can. Note, if you really needed github.com access in your application or environment, then you need to use SSL interception (using squid or a firewall) and allow certain URLs and methods ie. GET requests only from your organisations path, to make it safe.
View on HN · Topics
I know there is a cooldown period for npm packages, but I’m beginning to want a cooldown for domains too. According to socket, the C2 server is sfrclak[.]com, which was registered in the last 24 hours.
View on HN · Topics
NextDNS has a setting to block newly registered (<30d) domains.
View on HN · Topics
FWIW I vibe coded https://github.com/astrostl/surplies to detect evidence of the Axios and LiteLLM malware, using StepSecurity's writeups as a data source.
View on HN · Topics
The attacker went through the hassle to compromise a very widely used package, but use a non standard port (8000) on their C2... If you plan to do something like that, use 443 at least, many corporate network do not filter this one ;)
View on HN · Topics
I'm impressed how this was caught as a network anomaly in a GitHub actions monitoring tool. This might have taken a lot longer to discover, otherwise.