GitHub 3分鐘群發5000條釣魚帖，開發者郵箱被精準爆破

上周某個周二下午，GitHub 上超過 3000 個倉庫突然涌入大量「討論帖」。發件人都是新注冊或長期休眠的賬號，內容卻出奇一致：你的 VS Code 擴展有漏洞，點擊這個 Google Drive 鏈接下載補丁。

從第一個帖子出現到最后一個，全程不到 180 秒。被 @ 到的開發者手機開始瘋狂震動——郵件通知、App 推送、桌面彈窗，三重轟炸。

這不是漏洞預警，這是精準計算過的恐慌營銷。

攻擊者賭的就是一個時間差：當你正在開會、趕 deadline、或者剛睡醒迷糊的時候，看到「官方」發來的安全提醒，會不會手比腦子快？Google Drive 的域名是白的，文件名帶著版本號和「security_patch」字樣，一切看起來都那么合理。

唯一不合理的是：微軟什么時候用谷歌網盤分發補丁了？

釣魚工業化：從廣撒網到流水線

這次攻擊的精密程度，堪比產品經理做 A/B 測試。攻擊者沒有隨機轟炸，而是專門挑選了依賴郵件通知的開發者群體——那些把 GitHub 通知當工作流的人。

他們算準了三件事：GitHub 的討論功能對所有人開放、新賬號發帖不會觸發即時風控、以及郵件標題里的「@你的用戶名」會繞過大腦的前額葉審查。

結果呢？有人真的點了。有人在 Slack 群里問「這個補丁靠譜嗎」，被同事緊急叫停。還有人直到第二天才看到郵件，后背發涼。

這種「通知疲勞攻擊」正在變成標準作業流程。去年類似的案例是偽造的 npm 安全警報，今年換成了 VS Code 擴展。明年可能是 Docker 鏡像、PyPI 包、或者你正在用的任何開發者工具。

攻擊者的工具鏈也在升級。批量注冊賬號、自動化內容生成、甚至根據倉庫語言自動切換補丁說明的措辭——Python 項目看到「pip 兼容修復」，Node 項目看到「npm 安全更新」。

開發者信任的基礎設施，正在被當成攻擊向量來拆解。

登錄成功之后，才是真正的考題

另一個被低估的場景：當你看到「登錄成功」四個字，故事其實才剛開始。

用戶名對，密碼對，二次驗證也過了。系統記錄顯示這是一次「正常登錄」，IP 地址在合理范圍內，設備指紋沒有異常。但操作者可能根本不是賬號主人，而是一個拿著偷來的憑證、在正確時間出現在正確地點的替身。

2025 年，勒索軟件團伙 tracked 了超過 7000 起事件，涉及 129 個活躍組織。這個數字背后是一個完整的地下經濟：信息竊取木馬（infostealer）批量收割瀏覽器保存的密碼、Cookie、自動填充的信用卡信息，打包成「日志」在暗市批發。

買家拿到這些日志，不會立刻動手。他們會先「養號」——觀察目標的使用習慣，記錄登錄時段，甚至模仿打字節奏。等到一個周五下午，當真正的用戶已經關機去喝酒，替身才悄悄上線。

勒索金額從 2024 年的 8.92 億美元微降到 2025 年的 8.2 億美元。別急著歡呼，這不是防御變強了，是攻擊者變得更挑食了。他們開始放棄「廣撒網加密一切」的粗暴模式，轉向「精準打擊高價值目標+數據勒索雙重勒索」的精品路線。

被加密的數據只是籌碼，真正值錢的是「如果你不付，我們就把客戶名單賣給競爭對手」。

WhatsApp 上的 VBS 文件：社交工程的終極形態

誰會主動雙擊運行一個 .vbs 文件？

這個問題本身就有問題。攻擊者從不問「誰會」，他們只問「怎么讓」。最新的案例是通過 WhatsApp 發送惡意 VBS 腳本，文件名偽裝成「發票.pdf.vbs」或者「訂單確認.jpg.vbs」——Windows 默認隱藏已知擴展名，用戶看到的只是「發票.pdf」。

點擊之后，腳本會靜默連接遠程服務器，下載下一階段載荷?？赡苁擎I盤記錄器，可能是瀏覽器密碼提取工具，也可能只是先睡個幾周，等待指令。

WhatsApp 的端到端加密在這里成了雙刃劍。消息內容連 Meta 自己都看不到，安全團隊自然也無法掃描惡意附件。攻擊者吃準了這一點，把私人聊天頻道變成了免安檢的走私通道。

更隱蔽的是「熟人背書」效應。當文件來自家族群、同事群、或者某個你記不清什么時候加過的客戶，警惕性會天然降低。社交工程的本質不是技術，是心理學：利用關系鏈中的信任 residue，繞過理性審查。

去年 FBI 的報告顯示，商業郵件詐騙（BEC）造成的損失已經超過傳統勒索軟件。今年的趨勢是把 BEC 的套路下沉到個人場景——你的舅舅不會發釣魚郵件，但他可能會轉發一條「緊急稅務通知」到家庭群。

數字遺產：一個沒人想談但必須談的話題

說點更沉重的。

如果你現在突發意外，你的家人能打開你的手機嗎？能進你的郵箱嗎？能處理你掛在各個交易所的加密貨幣，或者關掉那些按月扣費的訂閱服務嗎？

大多數人對這個問題的反應是：「以后再說?！?/p>

但「以后」可能不來。蘋果、谷歌、微軟都有「遺產聯系人」功能，允許你指定某人在你去世后訪問賬號。前提是：你必須活著的時候設置好。死了之后，這些公司的客服只會對著死亡證明搖頭，哪怕來申請的是你結婚二十年的配偶。

更麻煩的是加密貨幣。私鑰沒有「忘記密碼」選項，硬件錢包沒有后門。你的家人可能在整理遺物時發現一個 Ledger 設備，但如果沒有助記詞，那就是一塊塑料。反之，如果把助記詞存在顯眼的地方，活著的時候又面臨被盜風險。

這是一個經典的可用性-安全性 trade-off，只是賭注從「賬號被盜」變成了「資產永久凍結」。

有人選擇把助記詞拆成三份，分別交給律師、配偶和信得過的朋友。有人用 Shamir 秘密共享方案，設置「任意兩份可還原」的閾值。還有人干脆什么都不做，賭自己不會那么倒霉——這種策略在數學上叫「俄羅斯輪盤」，勝率取決于你的年齡和體檢報告。

防御清單：這周你可以做的 4 件事

沒有銀彈，但有一些降低概率的操作。

第一，把 GitHub 的郵件通知改成「只接收我參與的」。設置路徑：Settings → Notifications → Email → 取消勾選「Automatically watch repositories」。這不會阻止所有釣魚，但至少減少噪音中的信號丟失。

第二，給重要賬號開通行密鑰（Passkey）而不是短信二步驗證。釣魚可以騙你輸入密碼，但很難騙過硬件綁定的加密簽名。iPhone 用戶可以用 Face ID，Android 用戶可以用指紋，Windows 用戶可以用 Windows Hello。

第三，檢查你的「遺產聯系人」設置。iCloud 在「設置 → Apple ID → 登錄與安全 → 遺產聯系人」；Google 在「管理你的 Google 賬號 → 數據和隱私 → 更多選項 → 閑置賬號管理器」；微軟在「賬戶 → 安全 → 高級安全選項 → 遺產設置」?；?5 分鐘，避免未來的 5 個月扯皮。

第四，如果你用 WhatsApp 辦公，關掉自動下載。設置 → 存儲和數據 → 媒體自動下載 → 全部改為「從不」。收到文件時手動確認發送者身份，多這一步，能過濾掉 90% 的惡意載荷。

最后一條不是技術建議，是產品思維：安全功能的設計者默認用戶會主動尋找設置入口，但真實用戶的行為路徑是「除非被打斷，否則繼續使用默認」。把安全選項埋在三層菜單之下，等于假設所有人都是安全研究員。

這個假設，和假設沒人會點 .vbs 文件一樣，都是產品經理的傲慢。

你的 GitHub 通知設置改了嗎？還是準備先看完這篇，然后被下一個彈窗打斷，永遠忘記？