TL; DR
2026 წლის ივლისის ბოლოს და აგვისტოს დასაწყისში ორი დღის განმავლობაში გამოქვეყნებული ოცი npm პაკეტი წარმოდგენილია, როგორც შიდა UI კომპონენტების ბიბლიოთეკები და საერთო backend უტილიტები. არცერთი მათგანი არ ახორციელებს მათ მიერ რეკლამირებულ ფუნქციონალს. თითოეული მათგანი შეიცავს stub კლასს, README-ს, რომელიც აღწერს პაკეტს, როგორც შიდას, და ფაილს სახელწოდებით _polyfill.js.
საინტერესო ის არის, თუ საიდან ხდება ამ ფაილის გამოძახება. ეს ინსტალაციის კაუჭი არ არის — მანიფესტებში საერთოდ არ არის მითითებული წინასწარი ინსტალაცია, ინსტალაცია ან პოსტინსტალაცია. ამის ნაცვლად, ბოლო ხაზი index.js ნათქვამია: try { require("./_polyfill"); } catch (_) {}დატვირთვა ირთვება აპლიკაციის კოდის პაკეტის პირველად იმპორტირებისას. ინსტალაცია --ignore-scriptsსაქართველოს standard რჩევები მიწოდების ჯაჭვის ზემოქმედების შესამცირებლად ინსტალაციის დროს, ხელს არ უშლის.
რა _polyfill.js ეს არის პლატფორმის სპეციფიკური შესრულებადი ფაილის მოძიება სამი Cloudflare Workers ჰოსტიდან ერთ-ერთიდან, მისი ჩაწერა დროებით დირექტორიაში შემთხვევითი სახელით, მისი შესრულებად მონიშვნა და მშობელი პროცესიდან გამოყოფილად გაშვება. ეს შესრულებადი ფაილი თავად არის ჩამტვირთავი: ის ჩამოთვლის საბოლოო წერტილის უსაფრთხოების პროდუქტებს პროცესის სახელის მიხედვით, ამოწმებს მიმდინარე მომხმარებლის სახელს ცნობილ ანალიზის გარემოს ანგარიშებთან, ახდენს AMSI და ETW ტელემეტრიის ინტერფეისების პატჩირებას მეხსიერებაში, აყენებს persistence-ს Windows-ის აუდიო კომპონენტის სახელით და იღებს მესამე ბინარულ ფაილს რამდენიმე მეგაბაიტის ზომის. მესამე ეტაპი დაშიფრულია და არის გაშიფრული და შესრულებული მეხსიერებაში დისკზე ჩაწერის ნაცვლად.
1 აგვისტოს, პაკეტების ხელით შემოწმების შედეგად მავნედ დადასტურებიდან დაახლოებით ოთხი საათის შემდეგ, ოცი სახელიდან ცხრამეტი npm-დან მათივე გამომცემელმა ოცდახუთი წამიანი თანმიმდევრობით წაშალა. 2 აგვისტოს ამ სახელებიდან ერთ-ერთი ხელახლა დარეგისტრირდა — სხვა ანგარიშის მიერ, იგივე კოდით. მიწოდების ინფრასტრუქტურა სამივე ეტაპს ემსახურებოდა, როდესაც ეს იწერებოდა.
| პაკეტები | 20 npm სახელი, ~74 გამოქვეყნებული ვერსია |
| თემების დასახელება | beaver-ui-* (13) accounts-* (3), პლუს afisha-storybook-default, bcore-bravo-eslint-config, arbocrate-sla-prober-arbocrate-sla-prober-core, a.poltoradnev-package-c |
| Trigger | მოდულის იმპორტი (require), არა npm სასიცოცხლო ციკლის სკრიპტი |
| სცენა 1 | _polyfill.js — ამოღება და გაშვება |
| სცენა 2 | სტატიკურად დაკავშირებული ჩამტვირთავი, UPX-შეფუთული Linux-ზე; საბოლოო წერტილის უსაფრთხოების ჩამოთვლა, AMSI/ETW პატჩირება, მუდმივი მუშაობა |
| სცენა 3 | beacon_linux.bin / beacon_mac.bin / update_win.exe, 4–13 მბ; მიწოდებული დაშიფრული, შესრულებული მეხსიერებაში |
| პლატფორმების | Linux x64 და arm64, macOS უნივერსალური, Windows x64 |
| გამომცემელთა | ორი ანგარიში, ერთი კოდის ბაზა |
| სტატუსი | 20-დან 19 სახელი გამოუქვეყნებელია ოპერატორის მიერ; 1 ხელახლა გამოქვეყნებული და მოქმედი; მიწოდების ინფრასტრუქტურა მოქმედია |
შეტევის ანატომია
ეტაპი 1 - პაკეტი
ყველა წევრი აგზავნის ერთსა და იმავე სამფაილიან ფორმას. index.js აექსპორტებს კლასს a-თი ინიციალი() რომელიც ადგენს ლოგიკურ მნიშვნელობას, a ვერსია()და კონფიგურაცია() რომელიც აერთიანებს ოფციების ობიექტს. სხვა არაფერი. README.md იძლევა ინსტალაციის ხაზს, მოითხოვს ხაზი და წინადადება „შიდა პაკეტი. ინსტრუქციებისთვის იხილეთ CONTRIBUTING.md“ — CONTRIBUTING.md ტარბოლში არ არის.
_polyfill.js 5 კბ-ზე ოდნავ ნაკლებია და იკითხება როგორც ჩვეულებრივი ინფრასტრუქტურის კოდი. ის იხსნება სამი გარემოს შემოწმებით:
if (process.env.DISABLE_TELEMETRY ||
process.env.ANALYTICS_OPT_OUT ||
process.env.DO_NOT_TRACK)
return;ეს ცვლადები წარმოადგენს კონფიდენციალურობის ტრადიციულ კონტროლს. აქ ისინი აკონტროლებენ, ჩამოტვირთულია თუ არა ბინარული ფაილი და შესრულებულია თუ არა. მანქანა, რომელიც ადგენს არ_აკონტროლოთ მთლიანად გამოტოვებულია.
შემდეგ მოდის ერთჯერადი შტამპი: ფაილი /tmp/.analytics_state, ან ანალიტიკის_მდგომარეობა ქვეშ % ᲢᲔᲛᲞᲘ% Windows-ზე, რომლის მოდიფიკაციის დრო შედარებულია 20,357 წამიან ფანჯარასთან. ამ ფანჯარაში მოდული დაუყოვნებლივ ბრუნდება, ამიტომ აწყობის დროს განმეორებითი იმპორტი იწვევს ერთ მოძიების მცდელობას ათეულების ნაცვლად.
დანიშნულების ჰოსტები ლიტერალების სახით არ არის წარმოდგენილი. ისინი ფრაგმენტებიდან აწყობილია გაშვების დროს:
["oob-worker.cf102-","baf.workers.d","ev"].join("") ამ გზით აგებულია სამი ჰოსტი და გამოყენებამდე ისინი არეული ხდება, ამიტომ მათი თანმიმდევრობა შესრულების მიხედვით განსხვავდება. მოძიება არის HTTPS GET, რომელიც მიმაგრებულია IPv4-ზე მომხმარებლის აგენტი of კვანძის მოძიება/2.6 — Node პროცესის მიერ გამოსაგზავნი დამაჯერებელი მნიშვნელობა. 1,000 ბაიტზე ნაკლები პასუხის შემთხვევაში პასუხი გაუქმდება და შემდეგი ჰოსტი ცდება.
თუ სამივე ვერ მოხერხდა, მოდული ისევ DNS-ზე გადადის. ის გასცემს TXT მოთხოვნას გ. ნაწილების რაოდენობის მისაღებად, შემდეგ ითხოვს 0. მეშვეობით ნ. ათი პაკეტად, პასუხებს აერთიანებს და შედეგს base64-ით გაშიფვრავს. ეს გზა DNS TXT ჩანაწერებზე იმავე შესრულებად ფაილს ატარებს, რომელიც გადარჩება იმ გარემოში, სადაც გამავალი HTTP ფილტრირებულია, მაგრამ DNS გარჩევადობა - არა.
მოძიებული ბაიტები იწერება /var/tmp/.cache_<8-hex> Unix-ზე, ან %TEMP%\dotnet_diag_<8-hex>.exe Windows-ზე — ფაილის სახელი, რომელიც იკითხება როგორც .NET დიაგნოსტიკური არტეფაქტი. Unix-ზე ფაილს ენიჭება რეჟიმი 0755. გაშვება არის ქვირითობა ერთად განცალკევებული: მართალია, stdio: „იგნორირება“და ურეფერენსი(), ამგვარად, ბავშვი ცოცხლობს Node პროცესზე მეტხანს, რომელმაც ის დაიწყო; Windows-ზე გამოძახება ემატება windowsHide: true.
სურათს ორი დეტალი ავსებს. დამხმარე, რომელიც განისაზღვრება, როგორც const _l = (…a) => process.stderr.write(“”) გამოძახება ხდება აღდგენის თითოეულ ეტაპზე — ის წერს ცარიელ სტრიქონს და უარყოფს მის არგუმენტებს, იკავებს ადგილს, სადაც ჟურნალირება იქნებოდა. და ყველა პაკეტი აგზავნის 81 კბ ფაილს lib/telemetry.js რომლის სათაურის კომენტარი აღწერს „Analytics SDK“-ს „HTTPS ტრანსპორტით საბოლოო წერტილის როტაციით და ხელახალი ცდით“ და „DNS-ზე დაფუძნებული სერვისის აღმოჩენით failover-ისთვის“. მიმდინარე ვერსიაში ეს არ არის საჭირო.
ეტაპი 2 - დამტვირთავი
Linux x64 ბინარული ფაილი არის სტატიკურად დაკავშირებული ELF ფაილი, რომელიც შეკუმშულია UPX 3.96-ით. macOS-ის ბილდი არის უნივერსალური ბინარული ფაილი, რომელიც მოიცავს x86_64-ს და arm64-ს; Windows-ის ბილდი არის PE32+ კონსოლის გაშიშვლებული შესრულებადი ფაილი. ოთხივე ფაილი მოიძიეს და სტატიკურად შემოწმდა; არცერთი არ შესრულებულა.
Windows-ის ბილდის იმპორტი და სტრიქონების ცხრილი მის ქცევას ნათლად აღწერს. ის წყვეტს IsDebuggerPresent, CheckRemoteDebuggerPresentდა NtQueryInformationProcessდა კითხულობს SYSTEM\CurrentControlSet\Services\Disk\Enum — რეესტრის გზა, რომლის მნიშვნელობები განსაზღვრავს ვირტუალური დისკის კონტროლერებს. ის იძახებს GetDiskFreeSpaceExW მდე GlobalMemoryStatusEx, რაც შეესაბამება იმის შემოწმებას, შეესაბამება თუ არა მასპინძლის რესურსები ხანმოკლე ანალიზის ინსტანციას.
მას აქვს მომხმარებლის სახელების სია: მიმდინარე მომხმარებელი, IT ადმინ, ჰონგ ლი, სატესტო ყუთი, ჰაპუბსი, მილოზები, ტიმი, admin, malware, ნიმუში, ვირუსი, გარემოსრამდენიმე მათგანი საჯაროდ დოკუმენტირებული ანალიტიკური გარემოს არტეფაქტებია.
ის ასევე შეიცავს საბოლოო წერტილის უსაფრთხოების პროდუქტების სიას და მათი პროცესების სახელებს, რომლებიც ჩამოთვლილია შემდეგნაირად: CreateToolhelp32Snapshot მდე Process32FirstW/Process32NextW:
- CrowdStrike Falcon (
csfalconservice,CSFalconContainer) - Carbon შავი (
cb.exe) - ცილანსი (
cylancesvc.exe) - BitDefender (
bdagent.exe) - Kaspersky (
avp.exe,kavfs.exe) - Trend Micro და Deep Security (
coreServiceShell,ds_agent.exe) - FireEye/Trellix (
xagt.exe) - ტანიუმი (
taniumclient.exe) - HitmanPro (
hmpalert.exe) - ელასტიური (
elastic-agent.exe,elastic-endpoint,filebeat.exe,winlogbeat.exe) - ვაზუჰი და OSSEC (
wazuh-agent.exe,ossec-agent.exe) - Check Point
- Windows დამცველი
კიდევ ორი სიმბოლოა წარმოდგენილი: AmsiScanBuffer, შესვლის წერტილი, რომელსაც Windows ხსნის მეხსიერებაში არსებული კონტენტის სკანირებისთვის და EtwEventWrite, ფუნქცია, რომლის მეშვეობითაც Windows-ის Event Tracing იწერს მოვლენებს. ორივე წარმოადგენს პროცესის მიმდინარე მოდიფიკაციის საერთო სამიზნეს, რომელიც თრგუნავს ტელემეტრიას, რომელსაც სხვა შემთხვევაში ეს ინტერფეისები წარმოქმნიდნენ.
Windows-ზე Persistence ორჯერ ჩნდება. ბინარული ფაილი კოპირდება %APPDATA%\Microsoft\Windows\Themes\SystemSoundsService.exeდა ორი მექანიზმი მიუთითებს მასზე: მნიშვნელობა ქვეშ პროგრამული უზრუნველყოფა\Microsoft\Windows\CurrentVersion\Runდა დაგეგმილი დავალება რეგისტრირებულია, როგორც
schtasks /Create /F /SC ONLOGON
/TN "\Microsoft\Windows\Multimedia\SystemSoundsService"
/TR "\"%s\""
/RL HIGHESTდავალების გზა, დავალების სახელი და შესრულებადი სახელი ასახავს ნამდვილ Windows-ის აუდიო კომპონენტს. /RL უმაღლესი ითხოვს პრივილეგიების უმაღლეს დონეს.
macOS-ის ბილდი იგივე ნიმუშს მიჰყვება პლატფორმის შესაბამისი სახელებით: ის წერს თვისებების სიას ~/Library/LaunchAgents/com.apple.windowserver.helper.plist და მის შესრულებად მისამართზე ათავსებს ~/.local/share/runtime/com.apple.runtimeის ამოწმებს /აპლიკაციები/VMware Fusion.app მდე /ბიბლიოთეკა/აპლიკაციის მხარდაჭერა/VMware ინსტრუმენტები.
ქსელის შესაძლებლობები მოიცავს სამ ტრანსპორტს: WININET.dll HTTPS-ისთვის https://%s:%d%s ფორმატირების სტრიქონი, WS2_32.dll სოკეტები და DNSAPI.dll ერთად DnsQuery_A ერთად დაახლ.%s.%s ფორმატის სტრიქონი — იგივე ბლოკების დათვლის მოთხოვნის ფორმა, რომელსაც პირველი ეტაპი იყენებს.
ზემოთ მოცემული აღწერა არის ის, რასაც ბინარული ფაილის იმპორტი, სტრიქონები და რეესტრის ბილიკები აჩვენებს შემოწმებისას. იმავე Windows ნიმუშის საჯარო მრავალძრავიანი ანალიზი ამატებს დეტალებს, რომელთა დადგენა იმპორტის ცხრილის სტატიკური წაკითხვით დამოუკიდებლად შეუძლებელია და აქ არის მიკუთვნებული, ვიდრე ხელახლა წარმოდგენილი, როგორც პირველი ხელის დაკვირვება. ეს ანალიზი იუწყება, რომ AMSI და ETW მითითებები არა მხოლოდ მოგვარებულია, არამედ გასწორებულია — AmsiScanBuffer in amsi.dll მდე EtwEventWrite in ntdll.dll — რომელიც თრგუნავს მეხსიერებაში არსებული შინაარსის სკანირებას და პროცესის მოვლენების თვალყურის დევნებას. ის ანტიანალიზის შემოწმებებს აცნობებს, როგორც დროზე დაფუძნებულს, გარდა ამისა, CheckRemoteDebuggerPresentდა განსაზღვრავს GetThreadContext გამოძახება, როგორც აპარატურული შესვენების წერტილის შემოწმება, კითხულობს გამართვის რეგისტრებს. ის ასევე იუწყება ერთი ინსტანციის mutex-ის შესახებ, Global\{7A3B9E1F-C2D4-4F8A-B5E6-D7A1F0C3E2B9}და სახელები სისტემის ხმის სერვისი როგორც Run-key მნიშვნელობა. ეს mutex მნიშვნელობა აქ აღდგენილ სტრიქონებს შორის არ იყო — გამოყენებული ექსტრაქციის ფილტრი გამორიცხავდა დიდი ასოებით შეკრული თექვსმეტობითი ნიშნების შემცველობას — და ის ინდიკატორის ცხრილში ჩაწერილია ამ საჯარო ანალიზის სიძლიერის მიხედვით და არა პირდაპირი დაკვირვების საფუძველზე.
სცენა 3
ჩამტვირთავი იმავე ჰოსტებზე არსებული გზების დამატებით ნაკრებს მიუთითებს. ანალიზის დროს ყველა მათგანი ხელმისაწვდომი იყო: beacon_linux.bin 5.3 მბ-ზე, beacon_mac.bin 13.3 მბ-ზე, update_win.exe 10.3 მბ-ზე და arm.bin 4.3 მბ-ზე. ესენი არ იქნა ამოღებული და მათი ქცევა უცნობია.
Windows-ის გზის შემთხვევაში, ჩამტვირთავის საჯარო ანალიზი აღწერს, თუ როგორ ხორციელდება ეს მესამე ეტაპი: ის WinINet-ის საშუალებით მოიძიება, დაშიფრული სახით მოდის, მეხსიერებაში იშიფრება და რეფლექსიურად სრულდება — მეხსიერება გამოიყოფა, იმპორტი წყდება, გადაადგილებები მუშავდება და კონტროლი ახალ ნაკადს გადაეცემა. შექმნა თემაამ მიზეზით, მესამე ეტაპი არასდროს იწერება ფაილურ სისტემაში, ამიტომ ფაილებზე დაფუძნებული აღმოჩენისა და ინციდენტის შემდგომი დისკის ფორენზიკის მიერ მისგან აღსადგენად არაფერია საჭირო. ეს ასევე ნიშნავს, რომ მიწოდების ჰოსტიდან ბაიტების მოძიება მოგვცემს დაშიფრულ ტექსტს და არა ანალიზირებად შესრულებად ფაილს.
Timeline
ყველა დროის ნიშნული UTC-ია და მომდინარეობს npm რეესტრის მეტამონაცემებიდან, რომელიც აღრიცხავს პაკეტის შექმნას და გამოქვეყნების გაუქმებას ნებისმიერი დამკვირვებლისგან დამოუკიდებლად.
ამ ჩანაწერებიდან ორზე ყურადღების გამახვილება ღირს.
13:04-ის აფეთქებამ ოთხ წამში ცხრა პაკეტი შეიყვანა რეესტრში, თითოეულს თორმეტში ერთი ვერსია ჰქონდა და არც ერთი. 0.0.1 მის ქვეშ. ამ მასშტაბის ვერსიის ნომრები, ერთი დღის წინანდელ სახელებზე, გამოშვების ისტორიას არ აღწერს.
გამოუქვეყნებელი თანმიმდევრობაც ისეთივე მექანიკურია: ცხრამეტი სახელი, ოცდახუთი წამი, თანაბარი ინტერვალი. npm აღრიცხავს მათ, როგორც ჩვეულებრივ გამოუქვეყნებელ მოვლენებს და არა როგორც რეესტრის მიერ ინიცირებული წაშლის შედეგად დატოვებულ ჩანაცვლების ველს, რომელიც მოქმედებას ათავსებს გამოქვეყნების ანგარიშზე და არა რეესტრში.
კომპრომისის ინდიკატორები
ჰოსტები და ბილიკები დეფანგირებულია. არ გადაწყვიტოთ ან არ ამოიღოთ ისინი საწარმოო სისტემიდან.
პაკეტის სახელები
ატრიბუცია და დაკვირვებული ქცევა
საქმე ეხება ორ npm ანგარიშს. ცხრამეტი გამოუქვეყნებელი სახელი ერთმა ანგარიშმა გამოაქვეყნა; a.poltoradnev-პაკეტი-c ხელახლა დარეგისტრირდა 2 აგვისტოს სხვა ანგარიშის სახელითა და სხვა ელფოსტის დომენით. ორივე შემთხვევაში კოდი ერთი და იგივე წარმოშობისაა და მეორე რეგისტრაციას იგივე მიწოდების ჰოსტები, იგივე DNS სარეზერვო დომენები, იგივე drop-path კონსტრუქცია და იგივე გაშვების შტამპი აქვს.
ხელახლა გამოქვეყნებული წყვილი ასევე აჩვენებს, თუ როგორ იყო ის აწყობილი. ვერსიები 0.0.2 მდე 33.9.5 ბაიტების მიხედვით იდენტურია ვერსიის სტრიქონისგან განსხვავებით პაკეტი.jsonდა index.js გაიგზავნა როგორც 0.0.2 აცხადებს const ვერსია = "33.9.5"ორივე არტეფაქტი ერთი წყაროს ხიდან მოიჭრა და შემდეგ დანომრა. არ არსებობს 0.0.2 განვითარების ისტორია -სთვის 0.0.2 გათავისუფლება წარმოადგენლად.
მთელი ნაკრების ვერსიების ნუმერაცია იმავე ლოგიკას მიჰყვება. ამ კამპანიაში პაკეტების სახელები იკითხება, როგორც ის, რაც ორგანიზაციის შიგნით იარსებებდა და არა საჯარო რეესტრში: UI კომპონენტების ნაკრები, ESLint კონფიგურაცია, SLA პრობერი, პიროვნების სახელობის პაკეტი. როდესაც ბილდი დამოკიდებულებას სახელით წყვეტს და საჯარო რეესტრთან ერთად კერძო რეესტრსაც განიხილავს, უფრო მაღალი ვერსიის ნომერი იმარჯვებს. სახელი, რომელიც შეიქმნა 0.0.1 ორშაბათს და ატარებს 12.9.6 სამშაბათს ამ შედარებისთვის არის პოზიციონირებული.
ორი გამოქვეყნების ტალღა ასევე განსხვავდება იმით, რაც იტერაციაზე მიუთითებს. ადრინდელ კოდში მისი დატვირთვის ფაილი დასახელდა setup.js და ჩამოთვალა ხუთი მიწოდების ჰოსტი; მიმდინარე ფაილი დასახელებულია _polyfill.js და სამი მათგანია ჩამოთვლილი. წინა ვერსიამ გაშვებიდან ხუთი წამის შემდეგ წაშალა წაშლილი ფაილი, რის შედეგადაც პროცესი წაშლილი ინოდიდან მუშაობდა; მიმდინარე ვერსია კი ამას არ აკეთებს. lib/telemetry.js ორივე მხარეს ტარბოლშია, ისევ მიწოდებულია და აღარ არის შეერთებული.
ერთი დაკვირვება, რომელიც „kill switch“-ის შესახებ უნდა აღინიშნოს, წინასწარ უნდა ითქვას:cisელი, რადგან ეს ეწინააღმდეგება ჩვეულებრივ წაკითხვას. გამორთვა_ტელემეტრია, ანალიტიკა_გამორიცხვადა არ_აკონტროლოთ პატივს სცემენ და ისინი შემოწმებულია ნებისმიერი სხვა რამის მოხდენამდე. მკვლევარი, რომლის ანალიზის გარემოც რომელიმე მათგანს აყენებს, აკვირდება პაკეტს, რომელიც საერთოდ არაფერს აკეთებს.
გავლენა და რა შეუძლიათ დამცველებს გააკეთონ
იმპორტის დროის ტრიგერის პრაქტიკული შედეგი ვიწროა და ცალკე აღნიშვნის ღირსია. npm ინსტალაცია – იგნორირება-სკრიპტები ხელს უშლის სასიცოცხლო ციკლის სკრიპტების გაშვებას და ეს გონივრული რჩევაა. აქ მას არანაირი ეფექტი არ აქვს, რადგან ეს კოდი არ იყენებს სასიცოცხლო ციკლის სკრიპტს. დატვირთვა იშვება მაშინ, როდესაც აპლიკაციის კოდი, სატესტო გაშვება, პაკეტი ან ლინტერი ჯერ მოდულს იმპორტირებს. CI გამშვები მოწყობილობაზე, რომელიც ინსტალაციას და შემდეგ დაუყოვნებლივ აწყობს, ეს ორი წამით არის დაშორებული.
ნადირობისთვის, მდგრადი სიგნალები უფრო სტრუქტურულია, ვიდრე პირდაპირი. მასპინძლები, ფაილის სახელი და ჩამოგდების გზები შეიცვლება; ამ ფორმების შეცვლა უფრო რთულია:
- მოდულის შესასვლელი წერტილი, რომლის საბოლოო ინსტრუქციაა სცადეთ { მოითხოვს(“./x”); } დაჭერა (_) {} ფაილის გარშემო, რომელიც ექსპორტირებული API-ს ნაწილი არ არის. ნამდვილი პოლიფილის მქონე პაკეტი მას ზედა მხრიდან იმპორტს ახდენს და მის შედეგს იყენებს. ფაილის ქვედა ნაწილიდან იმპორტირებული ყველა შეცდომის გადაყლაპვა შეცდომების დამუშავებას არ წარმოადგენს.
- მასპინძელი სტრიქონები აწყობილია .შეერთება(“”) ფრაგმენტების მასივიდან. ლეგიტიმურ კოდს არ აქვს მიზეზი, რომ ჰოსტის სახელი მასივის ელემენტებს შორის გაყოს.
- პაკეტი, რომლის გამოცხადებული დამოკიდებულებები ცარიელია, მაგრამ რომელიც https, დნსდა შვილობილი_პროცესი იმპორტის დროს. მომხმარებლის ინტერფეისის კომპონენტის რეკლამირების პაკეტში მოძიება და შესრულება მთელი დასკვნაა.
- ვერსიის ნომრები არ შეესაბამება პაკეტის ასაკს. სახელი, რომელიც პირველად რამდენიმე დღის წინ გამოქვეყნდა ორნიშნა დიდი ვერსიით, შუალედური გამოშვებების გარეშე, მისი განვითარების გარდა სხვა რამეს აღწერს.
- წერს / var / tmp or % ᲢᲔᲛᲞᲘ% მოჰყვა chmod 07:55-მდე და მოწყვეტილი ქვირითი. თანმიმდევრობა მოკლეა, მოწესრიგებული და იშვიათად კეთილთვისებიანი ერთად.
Windows-ის ჰოსტებზე არსებობს ორი იაფი, მაღალი სანდოობის შემოწმება. მუდმივი არტეფაქტები ფიქსირებული სტრიქონებია და არცერთი მათგანი არ ეკუთვნის სუფთა სისტემას: დაგეგმილი დავალება \Microsoft\Windows\Multimedia\SystemSoundsService, სახელწოდებით Run-key მნიშვნელობა სისტემის ხმის სერვისიდა ამ სახელის მქონე შესრულებადი ფაილი, %APPDATA%\Microsoft\Windows\Themes\ნამდვილი Windows-ის აუდიო სერვისი ამ ადგილებიდან არცერთში არ არის განთავსებული. მეორეც, ჩამტვირთავი იყენებს ფიქსირებულ ერთინსტანციურ მუტექსს, Global\{7A3B9E1F-C2D4-4F8A-B5E6-D7A1F0C3E2B9}; მისი ყოფნა ჰოსტზე ინდიკატორია და რადგან ჩამტვირთავი არსებულ მუტექსს „უკვე გაშვებულად“ მიიჩნევს, მისი წინასწარი შექმნა მოკლევადიანი ინოკულაციის სიცოცხლისუნარიანი საშუალებაა, სანამ რემედიაცია იგეგმება.
მესამე ეტაპზე აღმოჩენა უფრო რთული პრობლემაა და მისი გარკვევა ღირს. საჯარო ანალიზის მიხედვით, ის დისკზე ჩაწერის ნაცვლად მეხსიერებაში იშიფრება და აისახება, ამიტომ ფაილების სკანირება და დისკის ფორენზიკა მას ვერ ხედავს. დაკვირვებადი რჩება ჩამტვირთავის საკუთარი კვალი - მუდმივი ჩანაწერები, mutex და გამავალი მოთხოვნები მიწოდების ჰოსტებზე ან DNS-TXT დომენებზე.
იმ გარემოებისთვის, რომლებიც დამოკიდებულებებს როგორც კერძო, ასევე საჯარო რეესტრიდან წყვეტენ, შემსუბუქება აქ არ იცვლება: შიდა სახელების სფერო, რათა საჯარო სახელმა ვერ დააკმაყოფილოს ისინი და ამ სფეროებისთვის რეზოლუციის შიდა რეესტრში მიმაგრება. ზემოთ აღწერილი ვერსიის გადიდების ქცევა მხოლოდ მაშინ მუშაობს, როდესაც უფრო მაღალ საჯარო ვერსიას შეუძლია სახელის მოპოვება.
და ბოლოს, გამოუქვეყნებელი ვერსია უფრო ყურადღებით წაკითხვად ღირს, ვიდრე დასასრულად. ცხრამეტი სახელი რეესტრიდან ოცდახუთ წამში გავიდა, ერთი კი ერთი დღის შემდეგ ახალი ანგარიშით დაბრუნდა, მიწოდების ინფრასტრუქტურა კი მთელი პროცესის განმავლობაში ხელუხლებელი დარჩა. პაკეტების წაშლა ოპერაციის წაშლას არ ნიშნავს; ჰოსტებმა განაგრძეს ყველა ეტაპის მომსახურება, სანამ ეს იწერებოდა. ნებისმიერი დამოკიდებულების ხე, რომელმაც ამ სახელებიდან ერთ-ერთი გადაჭრა 31 ივლისიდან 1 აგვისტომდე პერიოდში, უნდა ჩაითვალოს პირველი ეტაპის შესრულების შესაძლებლობად, მიუხედავად იმისა, არსებობს თუ არა სახელი.
ლიტერატურა
- Windows-ის ჩამტვირთავის მრავალძრავიანი ანალიზი — ზემოთ მოყვანილი AMSI/ETW პატჩის, მეხსიერებაში ამრეკლავი შესრულების და mutex დეტალების წყარო.
- npm სკრიპტების დოკუმენტაცია — სასიცოცხლო ციკლის მოვლენები, რომლებსაც ეს კამპანია არ იყენებს.
- npm ინსტალაციის დოკუმენტაცია — გადასაფარებლები –იგნორირების სკრიპტები და მისი ფარგლები.
