TL; DR
ຜູ້ເຜີຍແຜ່ npm ດຽວໄດ້ສົ່ງແພັກເກດຂະໜາດນ້ອຍແປດຊຸດທີ່ຊື່ຂອງມັນອ່ານຄືກັບກ້ອນກໍ່ສ້າງປະຈຳວັນສຳລັບການພັດທະນາ blockchain ແລະກະເປົາເງິນ. base58-utils, abi-encode, eth-dev, arb-kit, layer2-sdk, solana-key-utils, eth-wallet-helpers, ແລະ crypto-validate-libແຕ່ລະອັນມີໂປຣແກຣມທີ່ໃຊ້ງານໄດ້. ເຖິງຢ່າງໃດກໍ່ຕາມ, ຫຼັງຈາກໂປຣແກຣມນັ້ນ, ແມ່ນບລັອກໂຄດທີ່ເອີ້ນໃຊ້ເອງທີ່ເຮັດວຽກທັນທີທີ່ໂມດູນຖືກນຳເຂົ້າ.
ປະມານ 37 ວິນາທີຫຼັງຈາກນໍາເຂົ້າ, ບລັອກນັ້ນຖອດລະຫັດ payload ທີ່ຈັດສົ່ງພາຍໃນແພັກເກດທີ່ປອມຕົວເປັນອຸປະກອນທົດສອບ, ຂຽນມັນໃສ່ໄຟລ໌ທີ່ເຊື່ອງໄວ້ພາຍໃຕ້ໄດເລກະທໍລີຫຼັກຂອງຜູ້ໃຊ້, ລົງທະບຽນຕົວມັນເອງເພື່ອເລີ່ມຕົ້ນໃໝ່ໃນທຸກໆ login ໃນທົ່ວ Windows, macOS, ແລະ Linux, ແລະເປີດໃຊ້ສະຄຣິບທີ່ຖອດລະຫັດເປັນຂະບວນການແຍກຕ່າງຫາກ. ບໍ່ມີຫຍັງກ່ຽວກັບເລື່ອງນີ້ເກີດຂຶ້ນໃນລະຫວ່າງການຕິດຕັ້ງ npm; ມັນລໍຖ້າໃຫ້ລະຫັດຖືກນຳເຂົ້າ ແລະ ເຮັດວຽກ, ເຊິ່ງເປັນຊ່ວງເວລາທີ່ງຽບກວ່າການຕິດຕັ້ງ.
ນ້ຳໜັກบรรทุกບໍ່ຂຸ່ນ. ມັນສົ່ງເປັນ base64 ທຳມະດາ, ສະນັ້ນການຖອດລະຫັດ "ອຸປະກອນທົດສອບ" ຈະກູ້ຄືນຂັ້ນຕອນທີສອງຢ່າງຄົບຖ້ວນ: a ກະເປົາເງິນດິຈິຕອນ ແລະ ຜູ້ລັກຄວາມລັບ ທີ່ລໍຖ້າໃຫ້ເຄື່ອງຢຸດເຮັດວຽກ, ເກັບກຳລະຫັດສ່ວນຕົວ ແລະ ປະໂຫຍກຫຼັກ, ເຂົ້າລະຫັດແຕ່ລະການຄົ້ນພົບດ້ວຍລະຫັດ RSA-4096 ທີ່ຖືກເຂົ້າລະຫັດໄວ້, ແລະ ກັ່ນຕອງມັນອອກໂດຍການປັກໝຸດມັນໄວ້ໃນບ່ອນເກັບຂໍ້ມູນ IPFS ສາທາລະນະ, ແລະ ຈະສົ່ງສັນຍານກັບຄືນທຸກໆ 12 ຊົ່ວໂມງ.
ພວກເຮົາຕິດຕາມກຸ່ມເປັນ PhantomSyncແພັກເກດທັງແປດແມ່ນມີຢູ່ໃນ registry npm ໃນເວລາວິເຄາະ, ເຜີຍແຜ່ພາຍໃຕ້ບັນຊີດຽວ.
| ລະບົບນິເວດ | npm |
| ການຫຸ້ມຫໍ່ | base58-utils, abi-encode, eth-dev, arb-kit, layer2-sdk, solana-key-utils, eth-wallet-helpers, crypto-validate-lib |
| ແພລດຟອມເປົ້າໝາຍ | Windows, macOS, Linux |
| ພຶດຕິກຳຫຼັກ | ເຊື່ອງ dropper ເວລານຳເຂົ້າທີ່ຊັກຊ້າເປັນອຸປະກອນທົດສອບ; ຕິດຕັ້ງ persistence ຂ້າມແພລດຟອມ |
| Payload | ກະເປົາເງິນດິຈິຕອນ ແລະ ຕົວລັກຄວາມລັບ, ການເຂົ້າລະຫັດ RSA-4096, ການລັກລອບຜ່ານການປັກໝຸດ IPFS ສາທາລະນະ |
ກາຍວິພາກການໂຈມຕີ
ແຕ່ລະຊຸດເບິ່ງຄືວ່າບໍ່ໜ້າປະທັບໃຈໃນການອ່ານຄັ້ງທຳອິດ. base58-utilsຕົວຢ່າງ, ແມ່ນລະຫັດຊ່ວຍເຫຼືອ Base58 / Bitcoin-WIF ທີ່ບໍ່ຂຶ້ນກັບສູນຈຳນວນສອງສາມກິໂລໄບຕ໌ — ຄືກັນກັບທີ່ຊື່ສັນຍາໄວ້. ລະຫັດທີ່ກ່ຽວຂ້ອງຕັ້ງຢູ່ ຫຼັງຈາກ ໂມດູນ ໂມດູນ.ສົ່ງອອກ, ບ່ອນທີ່ຜູ້ອ່ານທີ່ກຳລັງອ່ານຜ່ານດ້ານເທິງຂອງໄຟລ໌ບໍ່น่าຈະເບິ່ງ: ຟັງຊັນທີ່ເອີ້ນໃຊ້ດ້ວຍຕົນເອງທີ່ກຳນົດເວລາຕົວມັນເອງດ້ວຍໂມງຈັບເວລາ.
ລະບົບຕ່ອງໂສ້ການດຳເນີນງານ, ສ້າງຂຶ້ນໃໝ່ຈາກແຫຼ່ງທີ່ມາຂອງແພັກເກດ, ດຳເນີນໄປແບບນີ້:
1. Package is required() by the host project
2. A self-invoking function schedules a callback ~37,000 ms later (setTimeout)
3. On fire, the callback reads test/fixtures/keypairs.dat (a base64 blob)
4. It base64-decodes that blob into a Node.js script
5. It writes the script to ~/.cache-db/.node-sync/syncd.js (mode 0o700)
6. It installs login-persistence for that script (see below)
7. It spawns "node syncd.js" as a detached processສອງທາງເລືອກໃນການອອກແບບທີ່ໂດດເດັ່ນ.
ນ້ຳໜັກบรรทุกເຄື່ອນທີ່ເປັນອຸປະກອນທົດສອບ. ຂັ້ນຕອນທີສອງບໍ່ໄດ້ຖືກຂຽນເປັນລະຫັດທີ່ຊັດເຈນ. ມັນອາໄສຢູ່ໃນ ການທົດສອບ/ການແຂ່ງຂັນ/keypairs.dat, ໄຟລ໌ base64 ທີ່ມີຊື່ປະສົມເຂົ້າກັບແພັກເກດທີ່ອ້າງວ່າສາມາດຈັດການຄູ່ຄີໄດ້. ສຳລັບມະນຸດທີ່ກຳລັງອ່ານ tarball, ມັນເບິ່ງຄືກັບຂໍ້ມູນຕົວຢ່າງ; ສຳລັບລະຫັດທີ່ຕິດຄັດມາ, ມັນແມ່ນສະຄຣິບທີ່ຈະຖອດລະຫັດ ແລະ ດຳເນີນການ. ຕົວ dropper ເອງບໍ່ມີທີ່ຢູ່ເຄືອຂ່າຍ - ທີ່ຢູ່ເຫຼົ່ານັ້ນຢູ່ໃນຂັ້ນຕອນທີສອງ - ແຕ່ບໍ່ມີການປິດບັງເພີ່ມເຕີມ: fixture ແມ່ນຊັ້ນດຽວຂອງ base64, ສະນັ້ນການຖອດລະຫັດມັນ (base64 -d) ຟື້ນຟູຄືນມາໄດ້ຢ່າງເຕັມທີ່ syncd.js ແລະ ພຶດຕິກຳເຄືອຂ່າຍຂອງມັນ. ພາກຕໍ່ໄປຈະອະທິບາຍເຖິງສິ່ງທີ່ຂັ້ນຕອນການກູ້ຄືນນັ້ນເຮັດ.
ການລະເບີດແມ່ນຊັກຊ້າ ແລະ ຜູກມັດກັບການນໍາເຂົ້າ, ບໍ່ແມ່ນການຕິດຕັ້ງ. ເພາະວ່າຕົວກະຕຸ້ນແມ່ນ ຮຽກຮ້ອງ () ບວກກັບໂມງຈັບເວລາປະມານ 37 ວິນາທີແທນທີ່ຈະເປັນຕົວຕິດຕັ້ງ, ພຶດຕິກຳດັ່ງກ່າວຫຼີກລ່ຽງການກວດສອບທີ່ພຽງແຕ່ເບິ່ງ npm ຕິດຕັ້ງ ຂັ້ນຕອນ, ແລະຄວາມຊັກຊ້າຈະຢູ່ໄດ້ດົນກວ່າການແລ່ນ sandbox ແລະ CI ທີ່ມີອາຍຸສັ້ນຫຼາຍຢ່າງ. ເມື່ອມີສິ່ງໃດຖືກປະຕິບັດ, ການຕິດຕັ້ງທີ່ດຶງແພັກເກດເຂົ້າມາໄດ້ສຳເລັດໄປດົນແລ້ວ.
ເມື່ອສະຄຣິບຖອດລະຫັດຢູ່ໃນແຜ່ນດິດແລ້ວ ~/.cache-db/.node-sync/syncd.js - ເສັ້ນທາງທີ່ເລືອກໃຫ້ອ່ານຄືກັບໄດເລກະທໍລີແຄດປົກກະຕິ - dropper ເຮັດໃຫ້ມັນຢູ່ລອດຈາກການຣີບູດໃນທັງສາມແພລດຟອມຫຼັກ:
- linux: ລາຍການ cron ທີ່ເປີດໃຊ້ສະຄຣິບຄືນໃໝ່. ລາຍການດັ່ງກ່າວຖືກຕິດຕັ້ງໂດຍການກັ່ນຕອງ crontab ທີ່ມີຢູ່ແລ້ວຜ່ານ grep -v syncd, ເຊິ່ງມີຜົນຂ້າງຄຽງຂອງການປະໄວ້ລາຍການໃໝ່ອອກຈາກລາຍຊື່ທຳມະດາທີ່ greps ສຳລັບຊື່ດຽວກັນ.
- Windows: ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ຊື່ວ່າ WinNodeSync, ຕັ້ງຄ່າໃຫ້ແລ່ນຄືນໃໝ່ໃນໄລຍະຫ່າງ 12 ນາທີ.
- macOS: ວຽກທີ່ເປີດຕົວທີ່ມີປ້າຍຊື່ com.apple.syncd, ມີຢູ່ໃນຫຼາຍໆແພັກເກດ - ປ້າຍຊື່ທີ່ຮຽນແບບການບໍລິການລະບົບ Apple ທີ່ຖືກຕ້ອງຕາມກົດໝາຍ.
ຫຼັງຈາກນັ້ນ, ສະຄຣິບຈະເລີ່ມຕົ້ນທັນທີເປັນຂະບວນການທີ່ແຍກອອກມາ, ສະນັ້ນມັນຈະສືບຕໍ່ເຮັດວຽກຫຼັງຈາກໂປຣແກຣມນຳເຂົ້າອອກ.
ສິ່ງທີ່ຂັ້ນຕອນທີສອງເຮັດ
ເນື່ອງຈາກໂປຣແກຣມເປັນຊັ້ນ base64 ດຽວ, ຂັ້ນຕອນທີສອງຈຶ່ງຖອດລະຫັດໄດ້ຢ່າງສະອາດ ແລະ ສາມາດອ່ານໄດ້ຢ່າງຄົບຖ້ວນ. ແພັກເກດທັງແປດມີໜຶ່ງໃນສາມຕົວແປຂອງສະຄຣິບດຽວກັນ, ເຊິ່ງລະບຸຕົວມັນເອງໃນຄຳເຫັນຫົວຂໍ້ວ່າ phantom syncd v3 — topo durmiente (“ຕົວໜອນນອນຫຼັບ”). ໜ້າທີ່ຂອງມັນຄືການລັກເອົາເອກະສານກະເປົາເງິນດິຈິຕອນ ແລະ ຄວາມລັບຂອງນັກພັດທະນາ ແລະ ສົ່ງອອກຈາກເຄື່ອງ. ມັນເຮັດວຽກໃນຂັ້ນຕອນເຫຼົ່ານີ້:
- 1. ລໍຖ້າຈົນກວ່າເຄື່ອງຈະເຮັດວຽກ. ກ່ອນທີ່ຈະເຮັດຫຍັງ, syncd.js ກວດສອບວ່າຜູ້ໃຊ້ບໍ່ໄດ້ໃຊ້ງານມາດົນປານໃດແລ້ວ ແລະ ດຳເນີນການຜ່ານຂອບເຂດຈຳກັດເທົ່ານັ້ນ (ປະມານ 15 ນາທີ) — xprintidle ໃນ Linux, ໄອເຣັກ HIDIdleTime ໃນ macOS, ແລະ ການສອບຖາມ PowerShell idle-time ໃນ Windows. ດັ່ງນັ້ນ, ການເກັບກ່ຽວມັກຈະເກີດຂຶ້ນເມື່ອບໍ່ມີໃຜຢູ່ແປ້ນພິມ.
- 2. ດຶງເອົາສະວິດເປີດໃຊ້ງານທີ່ຄວບຄຸມຈາກໄລຍະໄກສະຄຣິບດຶງເອົາການຕັ້ງຄ່າຂະໜາດນ້ອຍຈາກ dead-drop ກ່ອນທີ່ຈະເຮັດວຽກ. ແຫຼ່ງຂໍ້ມູນຫຼັກແມ່ນ GitHub gist raw URL (gist.githubusercontent.com/juang55/…/cfg.txt); ສະຄຣິບຈະເປີດໃຊ້ງານພຽງແຕ່ຖ້າການຕັ້ງຄ່ານັ້ນອ່ານ ເຄື່ອນໄຫວ=1ຖ້າ gist ບໍ່ສາມາດໃຊ້ໄດ້, ມັນຈະກັບຄືນໄປຫາຕົວລະບຸເນື້ອຫາ IPFS ທີ່ຖືກລະຫັດໄວ້ສາມອັນ, ເຊິ່ງດຶງມາຜ່ານເກດເວສາທາລະນະ. gateway.pinata.cloud, ipfs.io, ແລະ cloudflare-ipfs.comສິ່ງນີ້ເຮັດໃຫ້ຜູ້ປະຕິບັດງານມີການຄວບຄຸມດ້ວຍແຂນ/ປິດອາວຸດຫຼັງຈາກເຫດການ ແລະ ມີທາງເລືອກທີ່ທົນທານຕໍ່ການດຶງລົງ. (ລຸ້ນທີ່ນ້ອຍທີ່ສຸດ, ຈັດສົ່ງໃນ crypto-validate-lib, ຜູ້ຊ່ວຍໃຊ້ກະເປົາເງິນ eth, ແລະ ກະແຈ solana, ໄດ້ລຶບຊັ້ນ gist ອອກແລ້ວ ແລະ ອີງໃສ່ຕົວລະບຸ IPFS ຢ່າງດຽວ.)
- 3. ເກັບກ່ຽວວັດສະດຸ ແລະ ຄວາມລັບຂອງກະເປົາເງິນ. ສະຄຣິບຈະຍ່າງໄປຫາໄດເລກະທໍລີຫຼັກຂອງຜູ້ໃຊ້ — ~/.config/solana, ~/.ethereum/ບ່ອນເກັບກະແຈ, ~/.ໂຮງຫລໍ່, ~/.hardhat, ~ / .ssh, ແລະ desktop/ເອກະສານ/ດາວໂຫລດ (ລວມທັງຊື່ໂຟນເດີພາສາສະເປນ), ບວກກັບ ~/.env ແລະໄຟລ໌ shell rc, ແລະສິ່ງອື່ນໆທີ່ຄ້າຍຄືກັນ AppData ສະຖານທີ່ຕ່າງໆໃນ Windows. ມັນແນໃສ່ກະແຈສ່ວນຕົວ Ethereum, ກະແຈ Bitcoin WIF, ປະໂຫຍກເມັດ BIP-39, ຄູ່ກະແຈ Solana, JSON ທີ່ເກັບກະແຈ Ethereum, ກະແຈ SSH, ແລະຕົວແປສະພາບແວດລ້ອມທີ່ເປັນຄວາມລັບ. ຕົວແປທີ່ໃຫຍ່ກວ່າ (ໃນ abi-encode, base58-utils, eth-dev) ມີວັດຈະນານຸກົມ BIP-39 ສະບັບເຕັມ 2048 ຄຳ ແລະ ໃຊ້ regular expressions ເພື່ອ ສານສະກັດຈາກ ລະຫັດສ່ວນຕົວ ແລະ ປະໂຫຍກເມັດພັນທີ່ຖືກກວດສອບແລ້ວຈາກຂໍ້ຄວາມໃດກໍ່ຕາມທີ່ມັນອ່ານ; ສອງຕົວແປຂະໜາດນ້ອຍກວ່າຈະຈັບຄູ່ໄຟລ໌ຕາມຄຳສຳຄັນ (ແກ່ນ, ລະລຶກ, wallet, metamask, phantom, ບັນຊີ, trezor, …) ແລະອັບໂຫລດໄຟລ໌ທັງໝົດ.
- 4. ເຂົ້າລະຫັດ ແລະ ກັ່ນຕອງຜ່ານການບໍລິການປັກໝຸດສາທາລະນະ. ການຄົ້ນພົບແຕ່ລະຄັ້ງແມ່ນມາພ້ອມກັບລາຍນິ້ວມືຂອງໂຮດ (ຊື່ຜູ້ໃຊ້@ຊື່ໂຮສ, ແພລດຟອມ, ປະທັບເວລາ) ແລະ ເຂົ້າລະຫັດດ້ວຍກະແຈສາທາລະນະ RSA-4096 ທີ່ຖືກເຂົ້າລະຫັດໄວ້ທີ່ຝັງຢູ່ໃນສະຄຣິບ. ຫຼັງຈາກນັ້ນບັນທຶກທີ່ຖືກເຂົ້າລະຫັດຈະຖືກອັບໂຫລດໂດຍການປັກໝຸດມັນໄວ້ໃນ IPFS ຜ່ານ api.pinata.cloud/pinning/pinJSONToIPFS, ໄດ້ຮັບການຢືນຢັນດ້ວຍຂໍ້ມູນປະຈຳຕົວ Pinata API ທີ່ຖືກເຂົ້າລະຫັດຍາກ. ບໍ່ມີເຊີບເວີ C2 ທີ່ສ້າງຂຶ້ນເປັນພິເສດເພື່ອຍຶດເອົາ: ຂໍ້ມູນທີ່ຖືກລັກແມ່ນຖືກຈອດໄວ້ໃນບ່ອນເກັບຂໍ້ມູນສາທາລະນະແບບກະຈາຍອຳນາດ, ເຊິ່ງຜູ້ປະຕິບັດການສາມາດດຶງຂໍ້ມູນຄືນໄດ້ໂດຍໃຊ້ແຮຊເນື້ອຫາທີ່ເປັນຜົນ. ການອັບໂຫຼດຈະຖືກເວັ້ນໄລຍະຫ່າງດ້ວຍສອງສາມວິນາທີຂອງການກະພິບແບບສຸ່ມ, ແລະບັນທຶກທ້ອງຖິ່ນຂອງ ປະທັບຕາເວລາ | ປະເພດຄີ | ແຮຊທີ່ສົ່ງຄືນ ຖືກເກັບຮັກສາໄວ້ທີ່ ~/.cache-db/.node-sync/.sl.
- 5. ຍັງຄົງຢູ່ ແລະ ເລີ່ມຕົ້ນໃນວົງຈອນ 12 ຊົ່ວໂມງ. ຂັ້ນຕອນທີສອງໄດ້ສ້າງຕັ້ງຄວາມຍືນຍົງຂອງມັນຄືນໃໝ່ - ລາຍການ cron ໃນ Linux, com.apple.syncd ເປີດຕົວວຽກໃນ macOS, ແລະ ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ຊື່ວ່າ WindowsNodeSync ໃນ Windows — ຕັ້ງໃຫ້ເຮັດວຽກຄືນໃໝ່ທຸກໆ 12 ຊົ່ວໂມງ. ໃຫ້ສັງເກດວ່ານີ້ແມ່ນ ທີ່ແຕກຕ່າງກັນ ຊື່ວຽກ Windows ຈາກອັນທີ່ dropper ຕິດຕັ້ງ (WinNodeSync); ທັງສອງຢ່າງຄຸ້ມຄ່າແກ່ການລ່າສັດ.
ກໍານົດເວລາ
ຊຸດທັງແປດໄດ້ຖືກເຜີຍແຜ່ຢ່າງໄວໃນວັນທີ 2026-07-13 ແລະ 2026-07-14. ຫຼາຍຊຸດມີຫຼາຍກວ່າໜຶ່ງລຸ້ນ; ຕົວຢອດແມ່ນຄືກັນໃນແຕ່ລະລຸ້ນ, ໂດຍມີພຽງແຕ່ການຊົດເຊີຍຂອງເສັ້ນທີ່ປ່ຽນໄປເມື່ອຂະໜາດຂອງລະຫັດສາທາລະນຸປະໂພກທີ່ຢູ່ຂ້າງເທິງມັນປ່ຽນແປງ.
ຕະຫຼອດໄລຍະການລະເບີດ, ຊື່ສຽງໃນການລົງທະບຽນຂອງຜູ້ເຜີຍແຜ່ໄດ້ປ່ຽນຈາກລະດັບທີ່ເປັນກາງໃນຕອນເລີ່ມຕົ້ນຂອງກຸ່ມໄປສູ່ລະດັບທາງລົບຢ່າງແຂງແຮງ ຍ້ອນວ່າການກວດພົບໄດ້ສະສົມຂຶ້ນ - ຜົນຂ້າງຄຽງທີ່ສັງເກດເຫັນໄດ້ຂອງແພັກເກດທີ່ຖືກໝາຍ, ບໍ່ແມ່ນຄຸນສົມບັດທີ່ຖືກອອກແບບມາ.
ຕົວຊີ້ວັດຂອງການປະນີປະນອມ
ຕົວຊີ້ວັດທັງໝົດຂ້າງລຸ່ມນີ້ໄດ້ຮັບການຢືນຢັນວ່າມີຢູ່ໃນເວລາວິເຄາະ — ຕົວຊີ້ວັດທີ່ຢູ່ໃນຕາຕະລາງ "ຂັ້ນຕອນທີສອງ" ໂດຍການຖອດລະຫັດ ການທົດສອບ/ການແຂ່ງຂັນ/keypairs.dat ແລະການອ່ານຂໍ້ມູນທີ່ກູ້ຄືນມາໄດ້ syncd.js.
ໄຟລ໌ ແລະ ເສັ້ນທາງ
ໂຄງສ້າງພື້ນຖານເຄືອຂ່າຍຂັ້ນຕອນທີສອງ (ກູ້ຄືນຈາກ syncd.js)
ເປົ້າໝາຍການເກັບກຳໄລຍະທີສອງ (ກູ້ຄືນຈາກ syncd.js)
ສິ່ງປະດິດທີ່ຍືນຍົງ
ພຶດຕິກໍາ
- ຟັງຊັນທີ່ເອີ້ນໃຊ້ດ້ວຍຕົນເອງຖືກຕໍ່ທ້າຍ ໂມດູນ.ສົ່ງອອກ, ກຳນົດເວລາ ກ ຕັ້ງເວລາອອກ ປະມານ 37,000 ມິນລິວິນາທີ ເມື່ອນຳເຂົ້າ.
- child_process spawn(“ໂນດ”, ) ດ້ວຍຊຸດຕົວເລືອກທີ່ແຍກອອກ.
- ການເປີດໃຊ້ງານແບບບໍ່ມີການຄວບຄຸມໃນໄລຍະທີສອງ (xprintidle / ໄອເຣັກ ເວລາຫວ່າງ HIDIdleTime / PowerShell; ~ຂອບເຂດຈຳກັດ 15 ນາທີ).
- ການເຂົ້າລະຫັດ RSA-4096 ຕໍ່ການຄົ້ນຫາ, ຈາກນັ້ນ HTTPS POST ໄປຫາ API ປັກໝຸດ IPFS ສາທາລະນະ.
ແພັກເກດ ແລະ ເວີຊັນຕ່າງໆ (npm, ຜູ້ເຜີຍແຜ່ solbuilder_io)
ສໍານັກພິມ
- solbuilder_io - angel_lopez89[@]proton[.]me, ອີເມວບໍ່ໄດ້ຮັບການຢືນຢັນ, ບໍ່ມີບັນຊີຄວບຄຸມແຫຼ່ງຂໍ້ມູນທີ່ໄດ້ຮັບການຢືນຢັນ, ບໍ່ມີບ່ອນເກັບມ້ຽນທີ່ເຊື່ອມໂຍງ.
ການອ້າງອີງ ແລະ ພຶດຕິກຳທີ່ສັງເກດເຫັນ
ແພັກເກດທັງແປດແບ່ງປັນບັນຊີຜູ້ເຜີຍແຜ່ໜຶ່ງບັນຊີ ແລະ payload ໜຶ່ງອັນ. ແຕ່ລະອັນແມ່ນແພັກເກດທີ່ບໍ່ສຳຄັນ - ລະຫັດຢູທິລີຕີ້ຕົວຈິງສອງສາມກິໂລໄບຕ໌ທີ່ມີ dropper ດຽວກັນຕິດຢູ່ - ເຜີຍແຜ່ໂດຍບໍ່ມີບ່ອນເກັບຂໍ້ມູນເຊື່ອມຕໍ່ ແລະ ພາຍໃຕ້ອີເມວແບບໃຊ້ແລ້ວຖິ້ມທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນ. ຄວາມເປັນເອກະພາບນັ້ນ, ເສັ້ນທາງ drop ທີ່ໃຊ້ຮ່ວມກັນ, ປ້າຍຊື່ persistence ທີ່ແບ່ງປັນ, ແລະ ການແບ່ງປັນ keypairs.dat ໄຟລ໌ staging ແມ່ນສິ່ງທີ່ເຊື່ອມໂຍງ cluster ເຂົ້າກັນ.
ແພັກເກດຕ່າງໆມີຄວາມເປີດເຜີຍຢ່າງເປີດເຜີຍກ່ຽວກັບພຶດຕິກຳຂອງຕົນເອງຢ່າງຜິດປົກກະຕິ. ກະແຈ solana ມີຄຳເຫັນໃນແຖວທີ່ອະທິບາຍບລັອກທີ່ຕິດຄັດມາດ້ວຍຄຳສັບທີ່ງ່າຍດາຍ — ໜຶ່ງຕິດປ້າຍມັນໄວ້ PHANTOM: ຄວາມຄົງທົນທີ່ເບິ່ງບໍ່ເຫັນ, ອີກອັນໜຶ່ງ (ເປັນພາສາສະເປນ) ອ່ານວ່າ Ejecutar topo en background, “ແລ່ນ mole ໃນພື້ນຫຼັງ.” ເຫຼົ່ານີ້ແມ່ນຄຳອະທິບາຍປະກອບຂອງລະຫັດເອງກ່ຽວກັບສິ່ງທີ່ມັນເຮັດ; ຊື່ແຄມເປນໃນໂພສນີ້ແມ່ນດຶງມາຈາກປ້າຍກຳກັບທຳອິດນັ້ນພ້ອມກັບໂຫນດປອມ “sync daemon” (ຊິງຄ໌) ທີ່ເຄື່ອງຈັກຄວາມທົນທານຮຽນແບບ.
ພວກເຮົາອະທິບາຍພຽງແຕ່ສິ່ງທີ່ລະຫັດເຮັດໄດ້ຢ່າງຈະແຈ້ງເທົ່ານັ້ນ. ການຕັ້ງຊື່ຂອງແພັກເກດ - ທັງໝົດແມ່ນຄຳສັບກ່ຽວກັບ crypto, wallet, ແລະ blockchain-tooling - ຊີ້ບອກເຖິງຜູ້ຊົມນັກພັດທະນາທີ່ມີແນວໂນ້ມທີ່ຈະດຶງພວກມັນອອກມາຕາມຊື່; ມັນບໍ່ໄດ້ກຳນົດດ້ວຍຕົວມັນເອງວ່າໃຜເປັນຜູ້ເຜີຍແຜ່. ຂັ້ນຕອນທີສອງສາມາດກູ້ຄືນໄດ້ຢ່າງເຕັມທີ່ໂດຍການຖອດລະຫັດ fixture base64, ແລະພຶດຕິກຳຂອງມັນຖືກອະທິບາຍໄວ້ຂ້າງເທິງ: ມັນເກັບກຳລະຫັດ wallet, seed phrases, ແລະຄວາມລັບ ແລະກັ່ນຕອງພວກມັນ, ເຂົ້າລະຫັດ RSA, ໄປຍັງບ່ອນເກັບຂໍ້ມູນ IPFS ສາທາລະນະຜ່ານ Pinata. ຕົວເລືອກການອອກແບບທີ່ໂດດເດັ່ນແມ່ນການບໍ່ມີເຊີບເວີ C2 ສ່ວນຕົວ - ການຕັ້ງຄ່າມາຈາກ GitHub gist ແລະ IPFS, ແລະຂໍ້ມູນທີ່ຖືກລັກແມ່ນຖືກຈອດໄວ້ໃນບ່ອນເກັບຂໍ້ມູນແບບກະຈາຍສູນກາງສາທາລະນະທີ່ຖືກລະຫັດໂດຍ hash ເນື້ອຫາ, ເຊິ່ງທັງສອງຢ່າງນີ້ຍາກທີ່ຈະຍຶດໄດ້ກ່ວາໂຮດທີ່ຄວບຄຸມໂດຍຜູ້ໂຈມຕີດຽວ. ບໍ່ມີການລາຍງານສາທາລະນະກ່ອນໜ້ານີ້ທີ່ກົງກັບກຸ່ມນີ້ໃນເວລາຂຽນ.
ຜົນກະທົບ, ແນວໂນ້ມ ແລະ ຄຳແນະນຳສຳລັບຜູ້ປົກປ້ອງ
ໃຜຖືກເປີດເຜີຍ. ຜູ້ໃດກໍຕາມທີ່ເພີ່ມໜຶ່ງໃນແພັກເກດເຫຼົ່ານີ້ໃສ່ໂຄງການ Node ແລະຈາກນັ້ນແລ່ນລະຫັດທີ່ນຳເຂົ້າມັນ. ເນື່ອງຈາກການລະເບີດແມ່ນເວລານຳເຂົ້າແທນທີ່ຈະເປັນເວລາຕິດຕັ້ງ, ການມີແພັກເກດຢູ່ນັ້ນບໍ່ພຽງພໍ - ແຕ່ການນຳໃຊ້ປົກກະຕິໃດໆທີ່ໂຫຼດໂມດູນໄປຮອດ payload. ຊື່ລໍ້ລວງແນໃສ່ນັກພັດທະນາທີ່ສ້າງຢູ່ໃນ Ethereum, Solana, Arbitrum, Layer-2, ແລະເຄື່ອງມືກະເປົາເງິນ/ການເຂົ້າລະຫັດທົ່ວໄປ - ປະຊາກອນທີ່ມີແນວໂນ້ມທີ່ຈະມີຊັບສິນທີ່ຂັ້ນຕອນທີສອງລ່າສັດ. ຜູ້ໃດກໍຕາມທີ່ແລ່ນໂມດູນເຫຼົ່ານີ້ໃນເຄື່ອງທີ່ຖືກະແຈກະເປົາເງິນ, ປະໂຫຍກເມັດພັນ, ບ່ອນເກັບກະແຈ, ກະແຈ SSH, ຫຼື .env ຄວາມລັບຄວນປະຕິບັດຕໍ່ຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານັ້ນວ່າຖືກລະເມີດ ແລະ ໝູນວຽນພວກມັນ.
ສອງຮູບແບບທີ່ຄຸ້ມຄ່າແກ່ການນຳມາໃຊ້ພາຍໃນ. ຫນ້າທໍາອິດ, ນ້ຳໜັກบรรทุกເປັນອຸປະກອນຕິດຕັ້ງ: ການຂົນສົ່ງຂັ້ນຕອນທີສອງເປັນ base64 ພາຍໃນໄຟລ໌ຂໍ້ມູນທີ່ມີຊື່ທີ່ໜ້າເຊື່ອຖື (ການທົດສອບ/ການແຂ່ງຂັນ/keypairs.dat) ຮັກສາແຫຼ່ງທີ່ມາຂອງແພັກເກດທີ່ເຫັນໄດ້ຊັດເຈນ ແລະ ສົ່ງເນື້ອຫາທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນໄຟລ໌ທີ່ເຄື່ອງມືທົບທວນ ແລະ ຂໍ້ມູນທີ່ມະນຸດໃຊ້ມັກຈະຖືວ່າເປັນຂໍ້ມູນທີ່ບໍ່ມີປະຕິກິລິຍາ. ອັນທີສອງ, ການປະຕິບັດທີ່ຊັກຊ້າໃນເວລານໍາເຂົ້າດ້ວຍຄວາມຍືນຍົງຂ້າມແພລດຟອມການຍ້າຍຕົວກະຕຸ້ນອອກຈາກ hook ຕິດຕັ້ງ, ການເພີ່ມໂມງຈັບເວລາ, ແລະຫຼັງຈາກນັ້ນສືບຕໍ່ເຮັດວຽກໃນທົ່ວ cron, ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້, ແລະ launchd ເປັນບາດກ້າວທີ່ຕັ້ງໃຈຫ່າງຈາກເຕັກນິກສະຄຣິບຕິດຕັ້ງທີ່ມີສຽງດັງກວ່າທີ່ການສະແກນລີຈິດສະຕິກອັດຕະໂນມັດເບິ່ງຢ່າງໃກ້ຊິດທີ່ສຸດ.
ຄຳແນະນຳສຳລັບຜູ້ປົກປ້ອງ ແລະ ຜູ້ຮັກສາ:
- ປະຕິບັດຕໍ່ລະຫັດທີ່ຕິດຄັດມາຫຼັງຈາກ ໂມດູນ.ສົ່ງອອກ ເປັນບູລິມະສິດໃນການທົບທວນ - ເຫດຜົນຂອງ dropper ມັກຈະຊ່ອນຢູ່ລຸ່ມໜ້າດິນຂອງໂມດູນ "ແທ້".
- ຢ່າສົມມຸດວ່າໄຟລ໌ຂໍ້ມູນບໍ່ມີປະຕິກິລິຍາ. ມີ blob base64 ຢູ່ໃຕ້ ການທົດສອບ/ການແຂ່ງຂັນ/ ທີ່ຖືກອ່ານໃນເວລາແລ່ນ ແລະ ຖອດລະຫັດແມ່ນສາມາດປະຕິບັດໄດ້ທີ່ຢູ່ຕິດກັນ; ການອ່ານໃນເວລາແລ່ນຂອງໄຟລ໌ຕິດຕັ້ງທີ່ປ້ອນຂໍ້ມູນ ຫນ້າທີ່/ການປະເມີນ/ຂຽນ-ແລ້ວ-ນ້ ຳ ພຸ ລະບົບຕ່ອງໂສ້.
- ລ່າຫາເສັ້ນທາງຫຼຸດລົງ ~/.cache-db/.node-sync/ ແລະ ສຳລັບຫົວໜ່ວຍຄວາມຍືນຍົງ WinNodeSync (ໜ້າວຽກທີ່ກຳນົດໄວ້) ແລະ com.apple.syncd (launchd) ໃນເຄື່ອງຂອງນັກພັດທະນາທີ່ດຶງເອົາຊື່ເຫຼົ່ານີ້.
- ແຈ້ງເຕືອນກ່ຽວກັບຂະບວນການຂອງ Node ທີ່ສ້າງລາຍການ cron, ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້, ຫຼືວຽກທີ່ເປີດໃຊ້ - ຫ້ອງສະໝຸດທີ່ຖືກຕ້ອງຕາມກົດໝາຍບໍ່ຄ່ອຍເຮັດແບບນີ້ເມື່ອນຳເຂົ້າ.
- ມັກໄຟລ໌ລັອກ ແລະ ເວີຊັນທີ່ຖືກປັກໝຸດໄວ້, ແລະ ທົບທວນຄວາມແຕກຕ່າງຂອງການເພິ່ງພາອາໄສ "ຢູທິລີຕີ" ຂະໜາດນ້ອຍໃໝ່, ໂດຍສະເພາະ ແພັກເກດທີ່ບໍ່ຂຶ້ນກັບໃຜຖືກເຜີຍແຜ່ແລ້ວ ໂດຍບັນຊີທີ່ບໍ່ໄດ້ຢືນຢັນແລະບໍ່ມີບ່ອນເກັບມ້ຽນທີ່ເຊື່ອມໂຍງ.
ສຳລັບຜູ້ປົກປ້ອງການລົງທະບຽນ, ສິ່ງສຳຄັນທີ່ຄວນຮູ້ຄືການຕິດຕາມກວດກາການຕິດຕັ້ງແບບຕິດຕັ້ງແມ່ນມີຄວາມຈຳເປັນແຕ່ບໍ່ພຽງພໍ: ຕົວຫຼຸດເວລາທີ່ນຳເຂົ້າ ແລະ ຕົວຈັບເວລາທີ່ຊັກຊ້າທີ່ຈັດຢູ່ພາຍໃນໄຟລ໌ຂໍ້ມູນຈະຜ່ານການກວດສອບເວລາຕິດຕັ້ງເທົ່ານັ້ນ, ແລະຂັ້ນຕອນການຄົງຕົວມັກຈະເປັນສັນຍານທີ່ດັງທີ່ສຸດທີ່ສາມາດສັງເກດໄດ້.
