The IT Nerd

Saturday, real estate lender tech provider SitusAMC confirmed a November 12 cyberattack impacting the sensitive personal information on the clients of hundreds of some of the nation’s biggest banks, including JPMorgan Chase.

The data exposed was related to residential mortgages, the company said. JPMorgan Chase, Citi, and Morgan Stanley are among those that have been notified that their client data may have been taken. 

   “The incident is now contained and our services are fully operational. No encrypting malware was involved,” the statement reads.

   “We remain focused on analyzing any potentially affected data,” SitusAMC’s chief executive, Michael Franco said.

SitusAMC manages extensive sensitive data collected through mortgage applications, including Social Security numbers. The fintech also provides regulatory compliance services to ensure lenders’ loans meet state and federal requirements. As a result, a breach could expose highly confidential information about lenders and their real estate portfolios.

   “We remain committed to identifying those responsible and safeguarding the security of our critical infrastructure,” FBI Director Kash Patel said in a statement.

Michael Bell, Founder & CEO, Suzu Labs had this to say:

   “SitusAMC proves that Wall Street’s hundreds of millions spent on bank cybersecurity is irrelevant when a third-party vendor holding SSNs, mortgage applications, and regulatory compliance data gets compromised.

   “The attackers bypassed JPMorgan, Citi, and Morgan Stanley’s defenses entirely by hitting the shared services provider with access to all their customer data.

   “Pentesting offers a lens inside these third-party environments and the lack of controls protecting customer data is shocking. Organizations need to start auditing vendor security postures with the same rigor they apply to their own perimeters.”

Damon Small, Board of Directors, Xcape, Inc. follows with this:

   “The recent cyberattack on SitusAMC underscores the significant and widespread third-party risk that major US financial institutions like JPMorgan Chase, Citi, and Morgan Stanley are currently exposed to.

   “Despite claims of containment, the breach resulted in the confirmed exfiltration of highly sensitive residential mortgage data, including Social Security numbers and private real estate holdings, all valuable targets for identity theft.

   “This incident confirms that the security of financial service providers is only as strong as the weakest link within their specialized fintech supply chain. Under regulations like GLBA, banks are ultimately accountable for protecting client data across their entire vendor network, necessitating the immediate implementation of Zero Trust principles for all third-party access.

   “Banks should treat this breach as if client data has been exposed by immediately activating dark-web monitoring, placing fraud alerts, and closely monitoring for unauthorized changes of address and wire instructions within their mortgage and servicing systems.

   “Lenders also need to immediately rotate tokens and credentials for SitusAMC integrations, implement stricter least-privilege access controls, and enforce breach-notification service-level agreements and data minimization practices through contractual obligations.

   “Regulators will be expecting concrete evidence of third-party risk management, including vendor audits, immutable backups, and well-tested incident response playbooks that cover the entire lifecycle of loan origination, servicing, and secondary market data flows.

   “Wall Street learned the hard lesson again: In the modern financial supply chain, the security of a bank’s information assets is only as effective as the least-protected mortgage application.”

This latest supply chain attack is going to be bad given the type of data that is now out there. I feel sorry for anyone who is potentially affected as this will not end well for them at all.

 There is new research that shows that hundreds of trojanized versions of well-known packages have been planted in the npm registry in a new Shai-Hulud supply-chain campaign. Which is of course, really, really bad.

Ensar Seker, CISO at SOCRadar, has provided the following comment: 

“This campaign marks a dramatic escalation in software supply‑chain threats. Unlike earlier attacks that compromised only a handful of packages or relied on drop‑in malicious dependencies, Shai‑Hulud is a self‑propagating worm that abuses developer workflows, steals developer/CI CD credentials, publishes them to public GitHub repositories, and then uses those credentials to infect additional packages. 

What makes it especially pervasive is that it targets npm packages with multi‑million download counts, packages such as @ctrl/tinycolor, Zapier, ENS Domains, PostHog and Postman have been impacted.  Through the injection of malicious scripts (often via lifecycle hooks like postinstall/preinstall) and hidden GitHub Actions workflows, the attacker turns every infected developer workstation and CI runner into a distribution node. 

To defend against this kind of attack, dev and security teams must treat npm package management and CI/CD pipelines as part of the threat surface. This means enforcing strict token/scoped access policies, limiting or auditing lifecycle scripts (especially preinstall/postinstall hooks), monitoring secrets in build environments and using behavioral analytics to detect unusual GitHub Actions workflows or outbound connections from build hosts. Given the worm‑like nature of Shai‑Hulud, time is of the essence: any delay in rotating tokens or cleaning compromised build agents can lead to rapid spread.

In short, Shai‑Hulud isn’t a typical “package compromise”; it’s a worm embedded into the dev supply chain. It signals that attackers are shifting from targeting compiled binaries and runtime environments toward the very processes developers use to build and ship software. No organization should assume “we don’t use npm, so we’re safe”, because even downstream dependencies or dev toolchains can become the launch pad.”

This illustrates the need for a software bill of materials so that it is clear where software components come from. But beyond that, developers need to know and have full confidence in the components that they use. That way the chances of this sort of attack are lessened.