Bối cảnh
Solidity Pro là một tiện ích mở rộng VS Code dành cho các nhà phát triển Solidity/Web3, được định vị công khai như một công cụ hỗ trợ phát triển. Tiện ích cung cấp các tính năng như tra cứu Gas, giá token, đoạn mã code snippet và gợi ý khi biên dịch, v.v. Kho GitHub của nó cũng từng quảng bá các khả năng bảo mật như AI Audit và Security Scanner.
Trong các hoạt động công khai, Solidity Pro lần lượt sử dụng hai publisher (đơn vị/pháp nhân phát hành) là helper-beeps và web3devtoolsx. Tương ứng, Extension ID (định danh duy nhất của tiện ích mở rộng) lần lượt là helper-beeps.solidity-pro và web3devtoolsx.solidity-pro. Mặc dù danh tính phát hành đã thay đổi, nhưng trong các bản dựng sản phẩm sau đó vẫn còn giữ publisher cũ, địa chỉ kho lưu trữ và thông tin bản quyền, cho thấy giữa hai bên có mối quan hệ kế thừa công việc trực tiếp.
Từ ngày 6 đến 7/8/2026, hai Extension ID này lần lượt bị đưa vào danh sách kiểm soát extension độc hại mà Open VSX sử dụng. Theo lẽ ra, tiếp tục kiểm tra theo phiên bản sau đó vẫn sẽ thấy các năng lực độc hại liên quan, nhưng Solidity Pro 4.0.0 (publisher: web3devtoolsx) mà chúng tôi thu được lại cho kết quả hoàn toàn khác: bundle cuối cùng (mã thực thi đã đóng gói) chỉ còn các chức năng thông thường như Gas, giá token và nhật ký; các mô-đun thu thập thông tin xác thực, tải payload từ xa, thực thi tiến trình con và cập nhật VSIX từ xa từng xuất hiện ở phiên bản độc hại lịch sử đều đã biến mất.
Vì thế câu hỏi trở thành: một plugin đã có lịch sử độc hại rõ ràng, vì sao ở các phiên bản sau lại trở nên "sạch"?
Bài viết này sẽ truy ngược từ 4.0.0 về sự thay đổi phiên bản và thay đổi danh tính phát hành của Solidity Pro, phân tích hai phiên bản độc hại trong lịch sử, GitHub Clean commit, sự di chuyển publisher và dòng thời gian hoạt động công khai, đồng thời bàn về điểm mù phát hiện có thể phát sinh nếu chỉ dựa vào phiên bản hiện tại để đánh giá rủi ro extension IDE.
Phân tích trong bài viết này dựa trên bằng chứng tĩnh, không chạy mẫu và không kết nối tới hạ tầng từ xa.
Phản hồi của MistEye
MistEye là nền tảng tình báo mối đe dọa Web3 và giám sát an ninh động do SlowMist tự nghiên cứu, tích hợp năng lực giám sát an ninh và tổng hợp tình báo, cung cấp cho người dùng cảnh báo rủi ro theo thời gian thực và bảo vệ tài sản.
MistEye đã tiến hành liên hệ và đối chiếu hai danh tính phát hành helper-beeps.solidity-pro và web3devtoolsx.solidity-pro cùng các mẫu tương ứng. Kết hợp giải rối tĩnh, kiểm tra chéo năng lực độc hại và dòng thời gian trên nền tảng công khai, hệ thống đã trích xuất mã băm mẫu, Extension ID, đường dẫn request nguy hiểm và hành vi cập nhật từ xa, dùng cho cảnh báo rủi ro chuỗi cung ứng của extension IDE.
Một, phiên bản hiện tại
Để xác định vì sao 4.0.0 không bị phát hiện là chứa mã độc, cần kiểm tra đồng thời hai đối tượng: mẫu 4.0.0 mà bài viết thu được, và trạng thái kho GitHub phù hợp với bundle của nó.
Trong gói VSIX có gì. Bundle cuối cùng của gói 4.0.0 được dựng lại cục bộ chủ yếu bao gồm ApiClient, GasTracker, PriceMonitor và Logger, với truy cập mạng tập trung vào Etherscan và CoinGecko. Sau khi extension được kích hoạt bởi onStartupFinished hoặc workspace có chứa tệp Solidity, nó chỉ khởi chạy Gas tracker, Price monitor và logger, đồng thời đăng ký ba lệnh công khai; lệnh compile chỉ hiển thị một gợi ý Hardhat/Foundry, không thực sự gọi trình biên dịch. Trong các tệp đã kiểm tra và các đường dẫn tĩnh có thể truy cập, không phát hiện bốn năng lực độc hại từng có trong phiên bản lịch sử: thu thập thông tin xác thực, tải payload từ xa, thực thi tiến trình con và cập nhật VSIX từ xa.
Trong kho GitHub còn gì nữa. Bản 4.0.0 tự nó không kèm mã nguồn, nên chúng tôi tiếp tục truy ngược về dự án công khai trên GitHub. Trong kho lưu trữ, một commit có version lùi về v1.0.0, commit 95dce4f, thông điệp là "Clean release", thì out/extension.js của nó và bundle 4.0.0 đều có kích thước 10.633 byte và SHA-256 giống hệt.
out/extension.js của commit đó cũng chỉ chứa ApiClient, GasTracker, PriceMonitor và Logger; các hàm activate và deactivate chỉ làm khởi tạo và dọn dẹp. Nhưng thư mục src/ của cùng commit lại là một bức tranh khác: src/telemetry/Web3Analytics.ts vẫn còn, phần đầu file ghi "Sends install ping immediately, then scans for secrets", bên trong có BIP39 wordlist, nhận diện thông tin xác thực ví, cấu hình exfiltration ra WORKERS và giới hạn thu thập tệp quy mô lớn; src/services/AutoUpdater.ts cũng vẫn được giữ, định nghĩa logic kiểm tra phiên bản theo chu kỳ 30 phút và cài VSIX từ xa.
Kho GitHub (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # Mã nguồn dự án thu thập độc hại vẫn còn
├── src/services/AutoUpdater.ts # Mã nguồn cập nhật VSIX từ xa vẫn còn
├── .vscodeignore # loại trừ src/**, scripts/**, *.ts
└── out/extension.js # bundle sạch nhìn thấy khi đóng gói
Vì sao mã nguồn độc hại không đi vào gói VSIX? Ở đây tồn tại hai ranh giới.
Lớp thứ nhất là điểm vào thực thi: src/extension.ts trong Clean commit đã xóa import và logic khởi động của Web3Analytics và AutoUpdater, nên khi esbuild xây dựng đồ thị phụ thuộc từ điểm vào này, hai mô-đun đó không còn được đưa vào out/extension.js.
Lớp thứ hai là khả năng nhìn thấy bên trong gói: .vscodeignore loại trừ src/**, scripts/** và *.ts, đồng thời giữ lại out/**, vì vậy các tệp nguồn TypeScript còn sót lại cũng sẽ không đi vào VSIX được tạo theo cấu hình đó dưới dạng mã nguồn gốc. Commit v1.0.0 có thông điệp là "Clean release", nhưng các tệp nguồn mô-đun độc hại không bị xóa hay sửa trong commit đó — đầu ra cuối cùng thì sạch hơn, nhưng mô-đun độc hại trong nội bộ dự án vẫn có thể được đưa trở lại thông qua các thay đổi nguồn hoặc thay đổi cấu hình build sau này.
Hai, phiên bản độc hại trong lịch sử
Vì phiên bản hiện tại và bundle của Clean commit đều không phát hiện mô-đun độc hại gốc, cuộc điều tra cần tiếp tục truy vết các phiên bản lịch sử của Solidity Pro dưới cả hai danh tính phát hành.
Solidity Pro không phải lúc nào cũng dùng cùng một kiểu triển khai độc hại. 2.4.1 lấy được dưới danh tính publisher helper-beeps và 3.4.0 dưới danh tính publisher web3devtoolsx cho thấy hai cách thực thi rất khác nhau: bản trước lấy trễ tải xuống và thực thi mã từ xa làm trung tâm, còn bản sau lấy thu thập thông tin xác thực tích hợp và kênh cập nhật từ xa làm trung tâm.
2.4.1: trì hoãn phát hành
Trong mẫu Solidity Pro 2.4.1 mà bài viết thu thập được (publisher: helper-beeps), extension được kích hoạt trong workspace Solidity hoặc Hardhat/Foundry, telemetry mặc định bật. Sau khi kích hoạt, mã không lập tức vào giai đoạn tải xuống mà thiết lập một cửa sổ chờ ngẫu nhiên từ 24 đến 48 giờ:
MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000
Sau khi hết thời gian chờ, mã kiểm tra các biến môi trường như CI, GITHUB_ACTIONS, JENKINS_HOME, GITPOD_WORKSPACE_ID; nếu khớp thì thoát. Sau đó lần lượt dùng fs.existsSync để kiểm tra sáu đường dẫn tương đối của thư mục chủ được mã hóa sẵn; ở giai đoạn này chúng chỉ được dùng để lọc sự tồn tại.
Sau khi lọc, mã lần lượt thử hai endpoint được mã hóa, yêu cầu đường dẫn cố định /firmware tới từng endpoint. Sau khi nhận phản hồi, nó kiểm tra độ dài, dùng crypto.createDecipheriv để giải mã AES-GCM, ghi văn bản sau giải mã vào tệp .py trong thư mục tạm với quyền hạn chế, rồi dùng child_process.spawn ở chế độ detached để thực thi. Khoảng 60 giây sau unlinkSync sẽ dọn dẹp tệp tạm. Vì không thu được phản hồi /firmware thực tế, chức năng cụ thể của giai đoạn hai vẫn chưa rõ.
3.4.0: thu thập thông tin xác thực
Solidity Pro 3.4.0 (publisher: web3devtoolsx) trong package.json của nó khai báo activationEvents gồm cả workspaceContains:*.sol và onStartupFinished. Tiện ích mở rộng có thể tự động vào activate() sau khi VS Code khởi động xong, không yêu cầu người dùng chạy lệnh công khai của nó.
Cấu hình mặc định solidity-pro.telemetry.enabled=true sẽ tạo và khởi chạy Web3Analytics. README nói chỉ thu thập dữ liệu sử dụng ẩn danh, không lưu private key hay source code, nhưng mô-đun này thực tế quét những tài sản cốt lõi trong vùng tin cậy của nhà phát triển:
Ví và vật liệu ký: private key EVM, mnemonic BIP39, keystore, Solana id.json, dữ liệu extension ví trình duyệt (MetaMask, Phantom, Coinbase Wallet, Rabby).
Mã nguồn và thông tin xác thực phát hành: token GitHub ghp_/gho_/github_pat_, GitLab glpat-, .npmrc, token PyPI, .netrc, thông tin xác thực Git.
Đám mây và hạ tầng: AWS access/secret/session key, cấu hình Kubernetes, xác thực Docker, Azure, GCP.
Dấu vết dự án và tương tác: .env và biến thể, API key, token dịch vụ AI (sk-, sk-proj-, sk-ant-), lịch sử Shell và thông tin máy chủ.
Biểu thức chính quy khớp private key EVM bao phủ các tên biến phổ biến như privateKey, PRIVATE_KEY, WALLET_KEY, DEPLOYER_KEY và các giá trị hex 64 ký tự:
var _0x4e0bcc = [
/["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
/(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
/(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
/(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];
Logic thu thập thư mục SSH sẽ liệt kê các tệp private key ứng viên trong ~/.ssh/, đọc nội dung và chuyển cho bộ trích xuất extractSecrets. Kết quả thu thập được gửi ra ngoài qua hai đường dẫn HTTP: JSON dạng text được POST /x bằng HTTPS tới host CFG.WORKERS đã bị làm mờ, còn báo cáo đầy đủ được POST /y dưới dạng multipart/form-data tới cùng nhóm host đó.
Song song với chuỗi thu thập này còn có AutoUpdater. Nó được tạo và khởi chạy vô điều kiện trong activate(), không phụ thuộc vào cấu hình telemetry. Ngay khi khởi động, nó yêu cầu /version một lần, sau đó cứ 30 phút lại thăm dò hai Worker được mã hóa cứng; chỉ cần phản hồi có version và url, mã sẽ so sánh số phiên bản, tải VSIX, gọi lệnh cài đặt của VS Code rồi xóa tệp tạm. Toàn bộ chuỗi cập nhật không có bất kỳ kiểm tra toàn vẹn nào — chính bộ cập nhật cũng không triển khai hash, chữ ký, cố định publisher hay certificate. Điều đó có nghĩa là máy chủ có thể trả về phiên bản cao hơn và địa chỉ tải xuống trong bất kỳ lần thăm dò nào, tự quyết định khi nào kích hoạt cập nhật và phát hành VSIX nào. Quan trọng hơn, trước khi cập nhật chỉ hiện một thông báo có duy nhất nút "OK"; sau khi chờ quy trình thông báo kết thúc, mã tiếp tục cài đặt mà không có lựa chọn hủy thực sự và cũng không đọc kết quả lựa chọn của người dùng.
Toàn bộ chuỗi cập nhật không có bất kỳ kiểm tra toàn vẹn nào — bộ cập nhật không tự triển khai hash, chữ ký, publisher hay certificate pinning. Điều đó có nghĩa là máy chủ có thể trong bất kỳ lần thăm dò nào cũng trả về phiên bản cao hơn và địa chỉ tải xuống, tự quyết định thời điểm kích hoạt cập nhật và phân phối VSIX nào. Quan trọng hơn, trước khi cập nhật chỉ hiện một thông báo chỉ có nút "OK"; sau khi chờ quy trình thông báo kết thúc, mã tiếp tục cài đặt mà không có lựa chọn hủy thực sự và cũng không đọc kết quả lựa chọn của người dùng.
Sở dĩ kiểu mục tiêu thu thập này nguy hiểm là vì chính IDE Extension Host nằm trong vùng tin cậy nội bộ của nhà phát triển. Máy phát triển Web3 thường đồng thời lưu giữ vật liệu ví, thông tin xác thực kho mã nguồn, token phát hành gói, cấu hình CI/CD và nền tảng đám mây; một cuộc tấn công chuỗi cung ứng extension có thể vượt qua cùng lúc nhiều ranh giới an toàn.
Đối chiếu vai trò của bốn nhóm mẫu hoặc phiên bản:
Ba, di chuyển publisher
2.4.1 và 3.4.0 của Solidity Pro không thuộc cùng một Extension ID. Bản trước do helper-beeps phát hành, còn bản sau dùng publisher mới web3devtoolsx. Vì sao vẫn có thể đặt chúng trên cùng một tuyến điều tra?
Metadata nội bộ của commit v3.4.0 ban đầu fe794a2 trả lời trực tiếp câu hỏi này. package.json khai báo publisher: web3devtoolsx, version 3.4.0, repository trỏ tới github.com/web3devtoolsx/solidity-pro. Nhưng out/package.json của cùng commit lại giữ publisher: helper-beeps, version 3.3.0, repository trỏ tới github.com/helper-beeps/solidity-pro. Tệp LICENSE vẫn ghi "Copyright (c) 2026 Helper Beeps".
Hai tệp package.json xuất phát từ cùng một commit, chứng minh rằng thành phần build ban đầu của Solidity Pro dưới danh tính web3devtoolsx trực tiếp đến từ dự án helper-beeps, cho thấy mã nguồn hoặc thành phần build có mối liên hệ nguồn trực tiếp.
Khi chồng lớp quan hệ kế thừa giữa các thành phần build với mốc thời gian gắn cờ độc hại chính thức, mô hình luân chuyển publisher càng trở nên rõ ràng:
helper-beeps.solidity-pro được đưa vào danh sách malicious chính thức (2026-08-06 14:27:24 UTC)
│ 8 giờ 32 phút 48 giây
▼
Tài khoản GitHub web3devtoolsx được tạo (2026-08-06 23:00:12 UTC)
│ khoảng 16 phút
▼
Solidity Pro v3.4.0 mới xuất hiện
│ ngày hôm sau
▼
web3devtoolsx.solidity-pro cũng được đưa vào danh sách malicious chính thức (2026-08-07 12:38:52 UTC)
Bốn, bản phát hành sạch
Chỉ 13 phút 29 giây sau khi GitHub commit bundle v3.4.0 độc hại ban đầu, cùng kho lưu trữ đã commit một clean commit quay phiên bản về v1.0.0. Trong khoảng thời gian cực ngắn này, publisher còn từng nộp rồi tự đóng yêu cầu Open VSX namespace claim (issue không có bình luận, do chính web3devtoolsx đóng).
Những chỉnh sửa của Clean commit tập trung chính xác vào hai nhóm mục tiêu. Ở mặt thực thi, nó loại bỏ kích hoạt Web3Analytics, khởi động AutoUpdater, cấu hình telemetry, phụ thuộc javascript-obfuscator và bước build làm rối. Ở mặt trình bày sản phẩm, nó xóa AI Audit Engine, Security Scanner, badge 100K+ và các mô tả phóng đại năng lực. Số phiên bản bị kéo lùi từ 3.4.0 xuống 1.0.0.
Những thay đổi này tập trung trong cùng một commit mang tên "Clean release". Nó trực tiếp loại bỏ các điểm vào rủi ro cao có thể truy cập công khai và một phần nội dung tiếp thị nổi bật, khiến hệ thống chỉ kiểm tra bundle mới không còn trúng các mô-đun độc hại gốc. Việc dọn dẹp không hoàn toàn: phần mô tả package.json có "Trusted by 100K+" và cách diễn đạt "vulnerability scanner" vẫn chưa bị loại bỏ — badge nổi bật nhất đã bị xóa, nhưng nếu manifest đó thực sự được đóng gói và phát hành, metadata còn có thể ảnh hưởng đến kết quả tìm kiếm và trang cửa hàng vẫn còn đó. Và như đã nói, mã nguồn độc hại vẫn nguyên vẹn trong thư mục src/, chỉ là không đi vào gói cuối cùng do .vscodeignore.
Clean release thay đổi thứ được giao cuối cùng, chứ không thay đổi lịch sử đã xảy ra của dự án này.
Năm, đóng gói độ tin cậy
Gần như đồng thời với thay đổi phiên bản là việc đóng gói nhanh danh tính phát hành mới: trong khoảng 16 phút sau khi tài khoản web3devtoolsx được tạo, hồ sơ kiểu doanh nghiệp, sáu fork dự án nổi tiếng, kho sản phẩm, số phiên bản trưởng thành và tuyên bố 100K+ xuất hiện đồng loạt. Các tín hiệu này xuất hiện tập trung như vậy, về mặt khách quan sẽ làm cho tài khoản mới mang dáng dấp của một tổ chức đã tương đối trưởng thành.
Hồ sơ kiểu doanh nghiệp. Khoảng 15 phút sau khi tài khoản được tạo, Profile đã chứa tên "Web3 Dev Tools", trường công ty, địa điểm Zug, liên kết website, Twitter, một sản phẩm đã ra mắt và hai lộ trình sản phẩm "Coming Q3". Tính đến lần rà soát ngày 12/08/2026, các chỉ số hoạt động dài hạn như followers, following, gists vẫn đều bằng 0.
Sáu fork của các dự án nổi tiếng. Tài khoản trong vòng 13 giây đã liên tục fork OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core và ethers.js. Người truy cập bình thường sẽ thấy các tên dự án Web3 quen thuộc trên trang chủ, nhưng fork chỉ có nghĩa là sao chép kho upstream, không đại diện cho đóng góp, hợp tác hay bất kỳ hình thức xác nhận nào.
Nhãn phiên bản và thời điểm tạo không khớp. Commit ban đầu được tạo 8 giây sau khi kho lưu trữ được tạo đã đồng thời mang năm bộ nhãn phiên bản v2.4.1, v2.4.5, v3.2.3, v3.3.0 và v3.4.0, trong khi phần đầu mã nguồn còn tuyên bố phát hành lần đầu vào năm 2025. Các nhãn phiên bản và tuổi đời này rõ ràng không khớp với lịch sử công khai của tài khoản và kho lưu trữ vừa mới được tạo trong ngày.
Gia tăng bằng chứng xã hội lặp lại. "100K+" đồng thời xuất hiện trong repository description, package.json, out/package.json, badge README, nội dung README và đầu ra build, là tuyên bố về quy mô người dùng được nhấn mạnh lặp đi lặp lại trong tài liệu công khai của dự án. Tài liệu hiện có không thể tự xác minh tính xác thực của con số này, nhưng cách diễn đạt đó, cùng với số phiên bản trưởng thành, profile mang tính doanh nghiệp và các fork dự án nổi tiếng, hợp thành hình ảnh sản phẩm trưởng thành mà Solidity Pro muốn thể hiện ra bên ngoài.
Những nội dung tiếp thị này mâu thuẫn rõ rệt với hành vi mã thực tế đã được xác nhận ở phần trước: README nói không lưu private keys hay source code, cấu hình mô tả telemetry là dữ liệu sử dụng ẩn danh, còn script build gọi quá trình làm rối của javascript-obfuscator là "privacy". Sản phẩm tự quảng bá là AI audit, quét lỗ hổng và phát hiện reentrancy, nhưng các lệnh công khai chủ yếu là truy vấn Gas, hiển thị giá token và một gợi ý được biên dịch qua Hardhat/Foundry.
Tài liệu tổ chức, fork nổi tiếng, số phiên bản trưởng thành, 100K+ cùng các tính năng nhỏ hữu ích và mô tả về quyền riêng tư đều ảnh hưởng đến ấn tượng ban đầu của người xem về extension. Mỗi yếu tố xét riêng có thể đều bình thường, điểm bất thường là các tín hiệu này cùng xuất hiện đồng thời với mã độc, dòng thời gian siêu nhanh và phần dư của build từ publisher cũ.
Sáu, điểm mù của phát hiện đơn phiên bản
Mã độc có thể bị xóa, nhưng lịch sử phiên bản, danh tính phát hành và nguồn gốc dự án sẽ không tự động được xóa sạch.
Khi ghép các phát hiện của năm chương đầu lại với nhau, Solidity Pro thể hiện một mô hình đáng để nền tảng và sản phẩm bảo mật chú ý: một tên extension và publisher vốn đã gắn với lịch sử độc hại rõ ràng, thông qua việc phát hành phiên bản mới không còn chứa năng lực độc hại ban đầu, có thể khiến hệ thống chỉ kiểm tra bản build hiện tại trả về clean, không phát hiện hoặc rủi ro thấp.
Để phân biệt mô hình này với sửa lỗi bảo mật bình thường, không thể chỉ dựa vào việc mã mới có sạch hay không, mà còn phải kiểm tra đồng thời bốn lớp vấn đề:
Câu trả lời theo mã băm và bundle hiện tại: hiện tại tệp này chứa gì.
Câu trả lời theo lịch sử phiên bản: Extension ID hoặc publisher này trước đây đã phát hành những gì.
Câu trả lời theo publisher và nguồn mã: gói hiện tại có liên hệ trực tiếp với những dự án độc hại đã biết nào.
Câu trả lời theo mặt điều khiển từ xa hiện tại và lịch sử: mã cục bộ hiện tại hoặc các phiên bản lịch sử có cho phép máy chủ thay đổi nội dung được phát hành hay không.
Đối với thị trường tiện ích mở rộng và sản phẩm bảo mật, điều này có nghĩa là đối tượng phát hiện cần mở rộng từ "một mã băm tệp đơn lẻ" sang lịch sử phiên bản, thay đổi publisher, khác biệt giữa các thành phần build và mặt điều khiển từ xa:
Lưu hash và kết quả giải rối của các phiên bản lịch sử; khi phiên bản mới loại bỏ nhiều mô-đun nguy hiểm, cần kích hoạt rà soát khác biệt thay vì tự động khôi phục uy tín.
Kết hợp phần dư của publisher cũ, độ tương đồng mã nguồn và script build để thiết lập mối liên hệ nguồn của mã hoặc thành phần build.
Đưa kiểm tra /version định kỳ, URL từ xa và bản ghi cài VSIX tạm thời vào giám sát lúc chạy.
Chỉ dùng lượt tải, stars và profile kiểu doanh nghiệp làm ngữ cảnh, không coi đó là bảo chứng an toàn.
Tóm tắt
Solidity Pro dưới cả hai danh tính phát hành helper-beeps và web3devtoolsx đều có triển khai độc hại rõ ràng: 2.4.1 dùng độ trễ ngẫu nhiên cục bộ và lọc môi trường làm điều kiện đầu vào, rồi tải Python mã hóa từ xa và thực thi; 3.4.0 tự động kích hoạt thu thập thông tin xác thực sau khi VS Code khởi động, xuất qua hai đường dẫn HTTP /x và /y, đồng thời giữ kênh cập nhật VSIX do phản hồi từ xa điều khiển. out/package.json, repository và thông tin bản quyền của 3.4.0 ban đầu vẫn trỏ về helper-beeps, chứng minh các thành phần build của hai danh tính phát hành có liên hệ nguồn trực tiếp.
Bundle cuối cùng của GitHub Clean commit đã loại bỏ các mô-đun độc hại này, nhưng kho lưu trữ vẫn giữ lại các tệp nguồn của mô-đun độc hại; gói 4.0.0 được dựng lại cục bộ cũng không phát hiện mô-đun độc hại gốc. Commit ban đầu chứa điểm vào độc hại và các thành phần build chỉ cách Clean commit 13 phút 29 giây, trong khi hồ sơ kiểu doanh nghiệp, sáu fork nổi tiếng, kho sản phẩm và tuyên bố phiên bản trưởng thành lại tập trung xuất hiện trong khoảng 16 phút sau khi tài khoản được tạo.
Trường hợp này cuối cùng cho thấy: chỉ dựa vào tệp hiện tại hoặc phiên bản hiện tại để đánh giá rủi ro extension là hoàn toàn không đủ. Mã độc có thể biến mất khỏi bundle mới nhất, nhưng dấu vết độc hại trong lịch sử sẽ không vì thế mà mất hiệu lực — một phiên bản mới sạch sẽ không thể xóa đi sự thật rằng cùng tên và cùng publisher đã từng phát hành mã độc.
Khuyến nghị
Nhà phát triển từng cài helper-beeps.solidity-pro hoặc web3devtoolsx.solidity-pro nên trước hết cô lập mạng, đồng thời bảo toàn thư mục extension, bản sao gói cài đặt, tiến trình và nhật ký mạng, rồi vô hiệu hóa và gỡ cài đặt các phiên bản liên quan. Sau đó kiểm tra cây tiến trình VS Code, các tệp Python trong thư mục tạm, bản ghi cài đặt VSIX bất thường, và các yêu cầu /firmware, /x, /y, /version trong nhật ký proxy.
Nếu từng bật và chạy Solidity Pro 3.4.0 (publisher: web3devtoolsx), private key ví, mnemonic, token GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI và token CI/CD có thể đã bị lộ. Nên ưu tiên thu hồi hoặc xoay vòng các thông tin xác thực này từ thiết bị sạch; tài sản mã hóa nên được chuyển sang ví dùng seed hoặc private key hoàn toàn mới, không chỉ đổi mật khẩu ví cũ.
Nếu từng bật và chạy Solidity Pro 2.4.1 (publisher: helper-beeps), chỉ cần máy chủ có thể đã vượt qua cửa sổ trễ của mẫu này, hoặc không thể xác nhận thời lượng chạy thực tế, thì nên xử lý như một sự cố có khả năng thực thi mã cục bộ.
Nhóm bảo mật doanh nghiệp nên ưu tiên tìm kiếm Extension ID, các đường dẫn request nguy hiểm, worker đã biết, tệp tạm và cây tiến trình bất thường, rồi kết hợp hai mã SHA-256 của mẫu, thời điểm cài extension và nhật ký mạng của tiến trình VS Code để xác định phạm vi bị ảnh hưởng. Cần đặc biệt phát hiện tổ hợp hành vi như VS Code Extension Host khởi chạy detached Python, cài VSIX từ đường dẫn tạm, đọc cấu hình giá trị cao rồi phát multipart HTTPS.
Chợ extension nên bắt buộc rà soát thủ công nếu telemetry mặc định xuất hiện khả năng đọc thông tin xác thực, tải từ xa, giải mã để thực thi, hoặc né đường cài đặt VSIX qua kênh chính thức; đồng thời phải lưu giữ lịch sử phiên bản và thực hiện rà soát khác biệt xuyên phiên bản, tránh rủi ro các phiên bản sau không còn mã độc tự động xóa nhãn nguy cơ của phiên bản cũ.
IOC
Tệp độc hại
filename: helper-beeps.solidity-pro-2.4.1.tar.gz
SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz
SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508
Giới thiệu về MistEye
MistEye là nền tảng tình báo mối đe dọa Web3 và giám sát an ninh động do SlowMist tự nghiên cứu, cung cấp qua API năng lực phát hiện hoạt động độc hại trong hệ sinh thái gói mã nguồn mở và cảnh báo rủi ro chuỗi cung ứng.
Toàn bộ gói độc hại và IOC liên quan đến chiến dịch này đã được đưa vào bộ máy phát hiện mối đe dọa MistEye; nhà phát triển có thể dùng API để tự động quét phụ thuộc dự án, nhanh chóng xác định có trúng gói độc hại đã biết hay không và nhận khuyến nghị xử lý.
📖 Tài liệu API：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan công cụ CLI nhẹ, chỉ một lệnh để quét các phụ thuộc dự án và các gói cài đặt toàn cục nhằm tìm các gói độc hại đã biết, hỗ trợ hệ sinh thái npm / PyPI / Rust (Cargo) / Go / RubyGems
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills gói kỹ năng bảo mật cho trợ lý lập trình AI, tự động kích hoạt kiểm tra an toàn MistEye trước khi cài đặt phụ thuộc và truy cập URL
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-Guard DNS relay cục bộ viết bằng Rust, phát hiện tên miền độc hại và truy cập rủi ro, nhận diện các mối đe dọa mạng như phishing, C2.
Bài viết do đội ngũ tình báo mối đe dọa SlowMist kết hợp nền tảng tình báo MistEye và phân tích điều khiển bởi SlowMist Agent AI soạn thảo, nếu có vấn đề xin vui lòng phản hồi góp ý.
Liên kết tham khảo:
[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram