FIN7 Supply Chain Social Engineering (2024)

Why is FIN7 still in the threat-intel conversation?

Because it keeps reinventing itself. FIN7 has been publicly tracked by Mandiant, Microsoft, Sophos, and others since at least 2015, starting as a point-of-sale malware operation and evolving through multiple rebrands and RaaS affiliations (connections have been reported to Darkside, BlackMatter, and later ransomware brands). The 2024 era of FIN7 is noteworthy because the group industrialized its tooling and distribution in ways that look a lot more like a software supply chain attack than a classic spear-phishing operation.

Two things defined 2024 for FIN7 publicly:

• The sale and use of AuKill / AvNeutralizer, an EDR-killing utility publicly reported by Sophos and subsequently by SentinelOne. Multiple ransomware affiliates were observed using it, suggesting FIN7 had moved into a tooling-provider role.
• Large-scale malvertising and typosquatting campaigns delivering fake versions of popular business and developer software, reported by companies including eSentire and others. Lookalike landing pages masquerading as ChatGPT, 7-Zip, PuTTY, Advanced IP Scanner, Notepad++, and others were used to lure employees into installing loaders.

Both patterns target people, not perimeters.

Why call this a supply chain attack at all?

Answer first: because the employee's "supply chain" of software tools - the utilities they install themselves outside IT procurement - is an unmanaged ingress point. Attackers who poison that supply chain via malvertising and SEO are running a supply chain operation just as much as Clop hitting MOVEit is, even if the CISO's dashboard does not show it that way.

Think of it as shadow IT weaponized. Every engineer who downloads PuTTY from whichever Google search result shows up is making a software sourcing decision on behalf of the company. If the first result is a paid ad pointing at a FIN7-controlled domain with a signed installer containing a loader, the company has just onboarded attacker code through no fault of procurement.

What does the fake-installer kill chain look like?

Based on public reporting of FIN7 and adjacent clusters in 2024:

1. Attackers register typosquatted domains (e.g., putty-download[.]co, 7zlp[.]org, variants on brand names). These are hosted with valid TLS and sometimes with EV-grade care taken for appearances.
2. Google Ads campaigns are purchased for target keywords, pushing the malicious domain above the legitimate result.
3. Visitors download an installer that bundles the legitimate application with an embedded loader, often signed with a valid code-signing certificate issued to a shell company. The application itself works, which delays detection.
4. The loader establishes persistence and pulls a second-stage payload such as NetSupport RAT or Carbanak successors. In FIN7 cases, subsequent activity has included data exfiltration and ransomware deployment.
5. Lateral movement and, if applicable, EDR tampering using AuKill/AvNeutralizer.

None of these steps require a perimeter vulnerability. All of them require one employee with admin rights.

What makes AuKill / AvNeutralizer interesting from a defender's perspective?

It is a productized BYOVD tool. Sophos's 2023-2024 reporting described it using a legitimate but vulnerable Windows driver (ProcExp) to terminate EDR processes. FIN7's reported role was not only using AuKill but offering it to other criminal groups. That changes the defender calculus: if one crew builds a reliable EDR-killer and rents it out, the tool shows up in many different intrusions run by many different affiliates, which is exactly what 2024's telemetry showed.

The defensive implication is the same as in the RansomHub story: you cannot rely on EDR alone. Your blocklist-driver enforcement, HVCI posture, and local-admin reduction are the actual controls.

How do you defend against malvertised installers inside the enterprise?

• Block paid search result redirects at the corporate proxy by stripping Google ad click-through parameters or by enforcing a policy against ad-served downloads. This has friction, but it dramatically cuts exposure.
• Deploy a managed software repository (Chocolatey for Business, winget enterprise, an internal MSI catalog) and make it the only sanctioned source for common utilities. Engineers will tolerate this if it is fast and well-stocked.
• Revoke local admin across the developer population and provide a fast elevation workflow for legitimate needs. Most fake-installer kill chains need local admin at step one.
• Application control (WDAC or AppLocker) with a publisher allowlist. A loader signed by "Shell Company LLC" does not match Microsoft, JetBrains, or your internal CA.
• DNS and proxy filtering of newly-registered domains. Commercial threat feeds flag typosquat domains aggressively; plug one into your DNS and you will see and block a surprising amount of this.
• Train engineers specifically on the malvertising pattern. Most generic phishing training does not cover "the first Google result might be malicious." A single 10-minute video explaining the PuTTY-lookalike problem changes behavior measurably.

How do you catch a FIN7-style compromise after initial installation?

• Hunt for loaders spawned by MSI or NSIS installers that reach out to uncommon domains within five minutes of execution. Parent-child process telemetry plus DNS makes this tractable.
• Monitor creation of scheduled tasks and run keys by processes living in user profile directories. FIN7's loaders have used these for persistence.
• Baseline LOLBins. rundll32, regsvr32, mshta, and wscript spawning from AppData are the top-of-funnel signal.
• Watch for driver loads that are not on your approved list. Enabling kernel driver load auditing plus a simple allowlist is one of the highest-fidelity detections available to Windows defenders.

Is law enforcement making a dent in FIN7 specifically?

Public reporting suggests continued activity, brand shifts, and the emergence of splinter groups. Prior DOJ actions resulted in convictions of several alleged FIN7 members years ago, and multiple vendors have linked FIN7 tooling to later ransomware affiliate programs. The brand is effectively a tradecraft lineage at this point rather than a single fixed crew. Defenders should assume the malvertising + EDR-killer + exfil-then-extort pattern persists independent of attribution.

What should security leaders take into 2026 planning?

• Your "third-party risk" program likely does not cover the software your engineers install themselves. It should.
• EDR is a layer, not a fortress. Expect it to be targeted.
• The weakest link is often a convincing Google Ads result and a local admin account.
• Code-signing trust is not proof of safety; it only tells you which shell company paid a CA.

How Safeguard.sh Helps

Safeguard.sh extends supply chain visibility to the software your employees actually run, not just the packages your procurement team signed POs for. We monitor newly-registered lookalike domains in your brand space and in the tool space your engineers use, correlate installed-software inventories across your endpoint telemetry against campaigns attributed to FIN7-class operators, and flag executables that carry suspicious code-signing provenance. When a malvertising wave crests against a category of tooling your team uses, you see it as a ranked alert with the affected hosts, not as a forensic finding after the fact.