MEGANews. Cамые важные события в мире инфосека за май

Админку LockBit взломали

Вы­мога­тель­ская груп­пиров­ка LockBit пос­тра­дала от утеч­ки дан­ных. Нек­то взло­мал панели адми­нис­тра­тора, пред­назна­чен­ные для пар­тне­ров груп­пы, похитил дан­ные, дефей­снул админку и оста­вил пос­лание: «Не совер­шай­те прес­тупле­ний, ПРЕС­ТУПЛЕ­НИЯ — ЭТО ПЛО­ХО, xoxo из Пра­ги».

От похоже­го взло­ма в апре­ле 2025 года пос­тра­дала дру­гая хак­груп­па — Everest. Тог­да зло­умыш­ленник оста­вил такое же сооб­щение на взло­ман­ном сай­те, одна­ко о кра­же дан­ных ничего не сооб­щалось.

В слу­чае LockBit хакер прик­репил к сво­ему сооб­щению ссыл­ку на ска­чива­ние архи­ва paneldb_dump.zip. Этот архив содер­жит SQL-файл, получен­ный из БД MySQL пар­тнерской панели адми­нис­тра­тора.

Сум­марно этот дамп содер­жит двад­цать таб­лиц, вклю­чая:

• таб­лицу btc_addresses c 59 975 уни­каль­ными бит­коин‑адре­сами;

• таб­лицу builds, содер­жащую отдель­ные сбор­ки, соз­данные пар­тне­рами LockBit для атак. В стро­ках таб­лицы перечис­лены пуб­личные клю­чи, но нет при­ват­ных. Для некото­рых бил­дов так­же при­веде­ны наз­вания целевых ком­паний‑жертв;

• таб­лицу builds_configurations, которая содер­жит раз­личные кон­фигура­ции, исполь­зуемые для каж­дой сбор­ки, нап­ример какие сер­веры ESXi про­пус­кать или какие фай­лы шиф­ровать;

• таб­лицу chats, где мож­но про­читать 4442 сооб­щения — перего­воры меж­ду вымога­теля­ми и их жер­тва­ми за пери­од с 19 декаб­ря 2024 года по 29 апре­ля 2025 года;

• таб­лицу users, в которой перечис­лены 75 адми­нис­тра­торов и пар­тне­ров LockBit, имев­шие дос­туп к пар­тнерской панели. При этом пароли хакеров хра­нились в откры­том виде (сре­ди них: Weekendlover69, MovingBricks69420 и Lockbitproud231).

Су­дя по вре­мени соз­дания MySQL-дам­па и пос­ледней записи о дате в таб­лице chats, взлом и утеч­ка про­изош­ли 29 апре­ля 2025 года.

Пред­ста­витель груп­пиров­ки, извес­тный под ником LockBitSupp, под­твер­дил факт взло­ма и сооб­щил, что обош­лось без утеч­ки зак­рытых клю­чей и потери дан­ных.

Не­извес­тно, кто может сто­ять за взло­мом LockBit и Everest и какие цели прес­леду­ет этот хакер.

Microsoft игнорирует проблему RDP

Ис­сле­дова­тели обна­ружи­ли, что про­токол RDP (Remote Desktop Protocol) в Windows поз­воля­ет исполь­зовать уже отоз­ванные пароли для вхо­да в сис­тему. В ответ на это пред­ста­вите­ли Microsoft сооб­щили, что такое поведе­ние не явля­ется уяз­вимостью, в ком­пании не пла­ниру­ют что‑либо менять.

Хо­тя сме­на пароля — один из пер­вых шагов, которые сле­дует пред­при­нять в слу­чае утеч­ки пароля или взло­ма учет­ной записи, в слу­чае с RDP все может быть не так прос­то.

Не­зави­симый ИБ‑иссле­дова­тель Дэни­ел Уэйд (Daniel Wade) обна­ружил, что во мно­гих слу­чаях RDP будет про­дол­жать доверять паролю даже пос­ле того, как поль­зователь его изме­нил. Эксперт уве­домил пред­ста­вите­лей Microsoft о проб­леме и сос­тавил пошаго­вую инс­трук­цию для вос­про­изве­дения такого поведе­ния.

Как под­черки­вает Уэйд, это про­тиво­речит всем общепри­нятым пред­став­лени­ям о том, что пос­ле сме­ны пароля тот боль­ше не может пре­дос­тавлять дос­туп к устрой­ствам и учет­ным записям, свя­зан­ным с ним.

«Это не прос­то ошиб­ка. Это пол­ный под­рыв доверия, — пишет эксперт в сво­ем отче­те. — Люди верят, что сме­на пароля отсе­чет несан­кци­они­рован­ный дос­туп. Это пер­вое, что дела­ет человек, заподоз­ривший ком­про­мета­цию. И все же:

• ста­рые учет­ные дан­ные про­дол­жают работать в RDP даже с совер­шенно новых машин;
• Defender, Entra ID и Azure не отоб­ража­ют никаких пре­дуп­режде­ний;
• у конеч­ных поль­зовате­лей нет никако­го спо­соба для обна­руже­ния и устра­нения проб­лемы;
• нет докумен­тации или руководств Microsoft, которые нап­рямую рас­смат­ривали бы подоб­ные сце­нарии;
• да­же более новые пароли могут игно­риро­вать­ся, тог­да как ста­рые про­дол­жают работать.

Ре­зуль­тат? Мил­лионы поль­зовате­лей (дома, на малых пред­при­ятиях или в гиб­ридных сре­дах) неосоз­нанно под­верга­ются рис­ку».

Воз­можность исполь­зования отоз­ванно­го пароля для вхо­да через RDP воз­ника­ет в том слу­чае, если Windows-машина, под­клю­чен­ная к учет­ной записи Microsoft или Azure, раз­реша­ет уда­лен­ный дос­туп к рабоче­му сто­лу. В этом слу­чае поль­зовате­ли могут вхо­дить в сис­тему через RDP, с помощью спе­циаль­ного пароля, который све­ряет­ся с локаль­но хра­нящи­мися учет­ными дан­ными. Так­же мож­но вой­ти в сис­тему, исполь­зуя дан­ные онлай­новой учет­ной записи, которая исполь­зовалась для вхо­да на машину.

Проб­лема зак­люча­ется в том, что даже пос­ле сме­ны пароля тот оста­ется дей­стви­тель­ным для вхо­да через RDP на неоп­ределен­ный срок. По сло­вам Уэй­да, встре­чают­ся слу­чаи, ког­да некото­рые ста­рые пароли про­дол­жают работать, а новые — нет. В резуль­тате мож­но иметь пос­тоян­ный дос­туп к RDP в обход облачной верифи­кации, мно­гофак­торной аутен­тифика­ции и политик Conditional Access.

Ис­сле­дова­тель пояс­няет, что такое поведе­ние может обер­нуть­ся боль­шими потеря­ми в слу­чае, если учет­ная запись Microsoft или Azure ском­про­мети­рова­на и пароли ста­ли дос­тоянием общес­твен­ности. В такой ситу­ации пер­вым делом нуж­но сме­нить пароль, что­бы не дать зло­умыш­ленни­кам воз­можнос­ти исполь­зовать его для дос­тупа к важ­ным ресур­сам. Одна­ко если сме­на пароля не поз­волит ата­кующим вой­ти в учет­ную запись Microsoft и Azure, то ста­рый пароль все рав­но будет пре­дос­тавлять дос­туп к машине через RDP.

«Это соз­дает незамет­ный уда­лен­ный бэк­дор к любой сис­теме, где ког­да‑либо был кеширо­ван пароль, — пишет Уэйд. — Даже если у зло­умыш­ленни­ка никог­да не было дос­тупа к этой сис­теме, Windows все рав­но будет доверять паролю».

Ко­рень этой проб­лемы кро­ется в механиз­ме кеширо­вания учет­ных дан­ных на жес­тком дис­ке локаль­ной машины. Так, при пер­вом вхо­де поль­зовате­ля в сис­тему с исполь­зовани­ем учет­ных дан­ных Microsoft или Azure RDP под­твержда­ет дей­стви­тель­ность пароля в режиме онлайн. Затем Windows сох­раня­ет учет­ные дан­ные в крип­тогра­фичес­ки защищен­ном фор­мате на локаль­ной машине.

С это­го момен­та сис­тема будет про­верять любой пароль, вве­ден­ный при вхо­де через RDP, срав­нивая его с локаль­но хра­нящи­мися учет­ными дан­ными. При этом анну­лиро­ван­ный пароль по‑преж­нему будет работать.

В ответ на это пред­ста­вите­ли Microsoft заяви­ли, что опи­сан­ное Уэй­дом поведе­ние явля­ется «конс­трук­тивным решени­ем, приз­ванным гаран­тировать, что хотя бы одна учет­ная запись поль­зовате­ля всег­да име­ет воз­можность вой­ти в сис­тему, незави­симо от того, как дол­го она находи­лась в авто­ном­ном режиме».

При этом иссле­дова­телю сооб­щили, что он не пер­вый, кто уве­дом­ляет об этой проб­леме, и Microsoft зна­ет о ней уже око­ло двух лет.

«Изна­чаль­но мы рас­смат­ривали воз­можность изме­нения кода для решения этой проб­лемы, но пос­ле даль­нейше­го изу­чения докумен­тации ока­залось, что изме­нения в коде могут нарушить сов­мести­мость с фун­кци­ональ­ностью, исполь­зуемой мно­гими при­ложе­ниями», — заяви­ли в ком­пании.

При этом под­черки­вает­ся, что такое поведе­ние не явля­ется уяз­вимостью и инже­неры Microsoft не пла­ниру­ют ничего менять. Одна­ко ком­пания все же обно­вила он­лайн‑докумен­тацию, что­бы поль­зовате­ли были луч­ше осве­дом­лены о таком поведе­нии. В обновле­нии говорит­ся:

«Ког­да поль­зователь выпол­няет локаль­ный вход в сис­тему, его учет­ные дан­ные про­веря­ются локаль­но с помощью кеширо­ван­ной копии, преж­де чем прой­ти аутен­тифика­цию в онлай­не, с помощью про­вай­дера иден­тифика­ции. Если про­вер­ка кеша прош­ла успешно, поль­зователь получа­ет дос­туп к рабоче­му сто­лу, даже если устрой­ство работа­ет в авто­ном­ном режиме. Одна­ко если поль­зователь меня­ет пароль в обла­ке, кеширо­ван­ный верифи­катор не обновля­ется, а зна­чит, он все рав­но может получить дос­туп к локаль­ной машине, исполь­зуя ста­рый пароль».

Как сооб­щил изда­нию извес­тный ИБ‑эксперт Уилл Дор­манн (Will Dormann), боль­шинс­тво адми­нис­тра­торов могут поп­росту не заметить это обновле­ние. К тому же Microsoft не ука­зыва­ет, какие дей­ствия сле­дует пред­при­нять для бло­киров­ки RDP в слу­чае взло­ма учет­ной записи Microsoft или Azure. По сло­вам спе­циалис­та, единс­твен­ным вари­антом оста­ется нас­трой­ка RDP на аутен­тифика­цию толь­ко по локаль­но хра­нящим­ся учет­ным дан­ным.

«С точ­ки зре­ния безопас­ности это прос­то бес­смыс­лица, — говорит Дор­манн. — Если бы я был сис­темным адми­нис­тра­тором, я бы ожи­дал, что, как толь­ко я изме­ню пароль для учет­ной записи, ста­рые учет­ные дан­ные для нее боль­ше нель­зя будет исполь­зовать ниг­де. Одна­ко это не так».

DDoS-атак стало на 358% больше

• Ком­пания Cloudflare сооб­щила, что пре­дот­вра­тила рекор­дное количес­тво DDoS-атак в 2024 году. Количес­тво инци­ден­тов уве­личи­лось на 358% по срав­нению с пре­дыду­щим годом и на 198% по срав­нению с пре­дыду­щим квар­талом.
• В отче­те за пер­вый квар­тал 2025 года ком­пания пишет, что в 2024 году она лик­видиро­вала в общей слож­ности 21,3 мил­лиона DDoS-атак. При этом спе­циалис­ты счи­тают, что 2025 год обе­щает стать еще более слож­ным: толь­ко в пер­вом квар­тале Cloudflare уже отре­аги­рова­ла на 20,5 мил­лиона инци­ден­тов.
• 16,8 мил­лиона из них были ата­ками сетево­го уров­ня.
• Ос­новным фак­тором рос­та количес­тва DDoS-инци­ден­тов ста­ли ата­ки сетево­го уров­ня, количес­тво которых уве­личи­лось на 509% по срав­нению с пре­дыду­щим годом.

• Сре­ди целей этих атак была и сама ком­пания Cloudflare, чья инфраструк­тура под­вер­глась 6,6 мил­лиона атак в ходе 18-днев­ной мно­говек­торной кам­пании, вклю­чав­шей SYN-флуд, DDoS-ата­ки, генери­руемые Mirai, ата­ки с уси­лени­ем через SSDP и дру­гие.

• Не осла­бева­ет и тен­денция по уве­личе­нию чис­ла гиперобъ­емных атак: ком­пания зафик­сирова­ла более 700 атак, мощ­ность которых пре­выша­ла 1 Тбит/с и 1 мил­лиард пакетов в секун­ду.
• В пер­вом квар­тале 2025 года количес­тво гиперобъ­емных атак сос­тавля­ло в сред­нем 8 в день, и по срав­нению с пре­дыду­щим квар­талом их количес­тво удво­илось.

Сотрудник xAI слил данные

Как сооб­щил извес­тный жур­налист‑рас­сле­дова­тель Брай­ан Кребс (Brian Krebs), сот­рудник xAI слу­чай­но опуб­ликовал на GitHub при­ват­ный ключ. На про­тяже­нии двух месяцев этот ключ был дос­тупен, поз­воляя любому жела­юще­му зап­рашивать зак­рытые боль­шие язы­ковые модели (LLM), которые, судя по все­му, были соз­даны спе­циаль­но для работы с внут­ренни­ми дан­ными ком­паний Ило­на Мас­ка, вклю­чая SpaceX, Tesla и X.

Пер­вым эту утеч­ку заметил и пре­дал огласке спе­циалист ком­пании Seralys Филипп Катурельи (Philippe Caturegli), который обна­ружил, что сот­рудник xAI слу­чай­но добавил на GitHub API-ключ x.ai.

Со­обще­ние Катурельи прив­лекло вни­мание иссле­дова­телей из ком­пании GitGuardian, спе­циали­зиру­ющей­ся на обна­руже­нии и устра­нении уте­чек сек­ретов в пуб­личных и проп­риетар­ных сре­дах. Так, сис­темы GitGuardian пос­тоян­но ска­ниру­ют GitHub и дру­гие репози­тории на пред­мет рас­кры­тия клю­чей API и отправ­ляют авто­мати­чес­кие опо­веще­ния пос­тра­дав­шим.

Спе­циалист GitGuardian Эрик Фуррье (Eric Fourrier) рас­ска­зал Креб­су, что утек­ший API-ключ, нап­ример, давал дос­туп к нес­коль­ким непуб­личным моделям чат‑бота Grok. В общей слож­ности в GitGuardian обна­ружи­ли, что ключ пре­дос­тавлял дос­туп как минимум к 60 кас­томным и при­ват­ным LLM.

«Учет­ные дан­ные мог­ли исполь­зовать­ся для дос­тупа к API x.ai под лич­ностью поль­зовате­ля, — сооб­щают в GitGuardian. — Свя­зан­ная с ним учет­ная запись име­ла дос­туп не толь­ко к пуб­личным моделям Grok (grok-2-1212 и так далее), но и к еще не выпущен­ным (grok-2.5V), находя­щим­ся в раз­работ­ке (research-grok-2p5v-1018) и при­ват­ным (tweet-rejector, grok-spacex-2024-11-04)».

Фуррье сооб­щил, что GitGuardian пре­дуп­редила сот­рудни­ка xAI об утеч­ке API-клю­ча поч­ти два месяца назад — 2 мар­та 2025 года. Одна­ко по сос­тоянию на 30 апре­ля 2025 года, ког­да ком­пания нап­рямую уве­доми­ла коман­ду безопас­ности xAI о рас­кры­тии клю­ча, тот все еще был дей­стви­телен и при­годен для исполь­зования. В xAI пореко­мен­довали иссле­дова­телям сооб­щить о проб­леме через прог­рамму bug bounty на HackerOne, одна­ко через нес­коль­ко часов репози­торий с рас­кры­тым клю­чом был уда­лен с GitHub.

«Похоже, что некото­рые из этих внут­ренних LLM были обу­чены на дан­ных SpaceX, а некото­рые — на дан­ных Tesla, — пишет Фуррье. — Не думаю, что модель Grok, нас­тро­енная на дан­ных SpaceX, пред­назна­чалась для пуб­лично­го дос­тупа».

Спе­циалис­ты отме­тили, что сво­бод­ный дос­туп к при­ват­ным LLM может обер­нуть­ся нас­тоящей катас­тро­фой. Ведь зло­умыш­ленник, получив­ший пря­мой дос­туп к модели и бэкен­ду модели, подоб­ной Grok, спо­собен исполь­зовать это для пос­леду­ющих атак. К при­меру, хакер может при­менить получен­ный дос­туп для промпт‑инъ­екций, изме­нить парамет­ры модели в сво­их целях или попытать­ся внед­рить код в цепоч­ку пос­тавок.

Хуанг о применении ИИ

Выс­тупая на кон­ферен­ции Инсти­тута Мил­кена, осно­ватель и генераль­ный дирек­тор ком­пании Nvidia Джен­сен Хуанг (Jensen Huang) рас­ска­зал о сво­ем взгля­де на рынок тру­да на фоне пов­семес­тно­го про­ник­новения ИИ.

«Вы можете потерять работу не из‑за искусс­твен­ного интеллек­та, а из‑за людей, которые его исполь­зуют. Я рекомен­дую исполь­зовать все пре­иму­щес­тва ИИ на 100%, не будь­те людь­ми, которые его игно­риру­ют», — совету­ет Хуанг.

Гла­ва Nvidia пред­ложил всем начать поль­зовать­ся, нап­ример, Perplexity и ChatGPT, что­бы луч­ше разоб­рать­ся в этих инс­тру­мен­тах и най­ти вари­анты воз­можно­го при­мене­ния ИИ.

Утечка Steam 2ФА

В середи­не мая хакер под ником Machine1337 (он же EnergyWeaponsUser) выс­тавил на про­дажу мас­сив дан­ных, яко­бы содер­жащий 89 мил­лионов записей, свя­зан­ных с поль­зовате­лями Steam.

Machine1337 заявил, что про­дает дамп за 5000 дол­ларов, но в качес­тве образца выложил в откры­тый дос­туп 3000 записей, которые пос­пешили изу­чить иссле­дова­тели. В резуль­тате в дам­пе обна­ружи­ли SMS-сооб­щения с одно­разо­выми кодами, а так­же номера телефо­нов их получа­телей.

Не­кото­рые SMS явно пред­став­ляли собой коды для под­твержде­ния дос­тупа к акка­унту Steam или при­вяз­ки к нему телефон­ного номера. При этом часть дан­ных была получе­на отно­ситель­но недав­но: мно­гие записи были датиро­ваны началом мар­та.

Сна­чала экспер­ты пред­положи­ли, что инци­дент может быть свя­зан со взло­мом PaaS-ком­пании Twilio и ее про­дук­та Verify API, который может при­менять­ся для отправ­ки SMS-сооб­щений, сооб­щений в мес­сен­дже­рах, элек­трон­ных писем, пуш‑уве­дом­лений, голосо­вых вызовов и TOTP (Time-based One-Time Password), что широко исполь­зует­ся во мно­гих при­ложе­ниях (вклю­чая Steam) для аутен­тифика­ции поль­зовате­лей.

Од­нако вско­ре пред­ста­вите­ли Twilio заяви­ли, что не выяви­ли в сво­их сис­темах никаких приз­наков ком­про­мета­ции, а в Valve и вов­се сооб­щили, что не поль­зуют­ся услу­гами Twilio.

Дру­гая теория гла­сила, что утеч­ка мог­ла про­изой­ти, нап­ример, на сто­роне SMS-про­вай­дера.

Так как эта ситу­ация прив­лекла вни­мание СМИ и ИБ‑экспер­тов, пред­ста­вите­ли Valve пос­пешили успо­коить общес­твен­ность и опуб­ликова­ли офи­циаль­ное заяв­ление. В ком­пании под­чер­кну­ли, что Steam точ­но не был взло­ман, но источник утеч­ки пока неиз­вестен.

«Пока мы пыта­емся опре­делить источник утеч­ки. Ситу­ация осложня­ется тем, что при дос­тавке SMS-сооб­щения находят­ся в незашиф­рован­ном сос­тоянии и про­ходят через раз­ных про­вай­деров, преж­де чем попасть в ваш телефон.

Утеч­ка сос­тоит из ста­рых тек­сто­вых сооб­щений с одно­разо­выми кодами, дей­стви­тель­ными лишь в течение 15 минут, и номеров телефо­нов, на которые они отправ­лялись. Утек­шие дан­ные не поз­воля­ют иден­тифици­ровать акка­унт, узнать пароль, пла­теж­ную информа­цию и дру­гие лич­ные дан­ные поль­зовате­лей Steam по номеру телефо­на. С помощью ста­рых тек­сто­вых сооб­щений нель­зя взло­мать ваш акка­унт Steam. Кро­ме того, каж­дый раз, ког­да вы исполь­зуете SMS-коды для сме­ны сво­его email-адре­са или пароля в Steam, вам при­ходит под­твержде­ние через элек­трон­ную поч­ту и/или защищен­ные сооб­щения в Steam.

Из‑за это­го инци­ден­та вам не нуж­но менять свои пароли или номера телефо­нов. Одна­ко это хорошее напоми­нание о том, что к любым сооб­щени­ям о безопас­ности акка­унта, которые вы не зап­рашива­ли, сле­дует отно­сить­ся с подоз­рени­ем», — заяви­ли пред­ста­вите­ли Valve.

Атаки через IPv6

В ESET сооб­щили, что свя­зан­ная с Кита­ем APT-груп­пиров­ка TheWizards исполь­зует сетевую фун­кци­ональ­ность IPv6 для про­веде­ния атак типа man-in-the-middle, которые перех­ватыва­ют обновле­ния ПО для уста­нов­ки Windows-мал­вари.

Эта груп­пиров­ка активна как минимум с 2022 года, ата­куя орга­низа­ции на Филип­пинах, в Кам­бодже, Объ­еди­нен­ных Араб­ских Эми­ратах, Китае и Гон­конге. В чис­ле жертв TheWizards — час­тные лица, игор­ные ком­пании и дру­гие орга­низа­ции.

В сво­их ата­ках хакеры исполь­зуют кас­томный инс­тру­мент Spellbinder, который зло­упот­ребля­ет фун­кци­ей IPv6 stateless address autoconfiguration (SLAAC) для про­веде­ния SLAAC-атак.

SLAAC — это фун­кция про­токо­ла IPv6, которая поз­воля­ет устрой­ствам авто­мати­чес­ки нас­тра­ивать свои собс­твен­ные IP-адре­са и шлюз по умол­чанию без исполь­зования DHCP-сер­вера. Вмес­то это­го для получе­ния IP-адре­сов от мар­шру­тиза­торов, под­держи­вающих про­токол IPv6, исполь­зуют­ся сооб­щения router advertisement (RA).

Spellbinder зло­упот­ребля­ет этой фун­кци­ональ­ностью, отправ­ляя под­дель­ные RA-сооб­щения и вынуж­дая близ­лежащие сис­темы авто­мати­чес­ки получать новый IPv6-адрес, новые DNS-сер­веры и новый, пред­почти­тель­ный IPv6-шлюз. Адрес это­го шлю­за — IP-адрес Spellbinder, что поз­воля­ет зло­умыш­ленни­кам перех­ватывать соеди­нения и перенап­равлять тра­фик через под­кон­троль­ные им сер­веры.

«Spellbinder отправ­ляет пакет RA multicast каж­дые 200 мс на ff02::1 (все узлы). Windows-машины в сети с вклю­чен­ным IPv6 будут авто­мати­чес­ки кон­фигури­ровать­ся с помощью stateless address autoconfiguration (SLAAC), исполь­зуя информа­цию, пре­дос­тавлен­ную в RA-сооб­щении, и нач­нут отправ­лять IPv6-тра­фик на машину, на которой работа­ет Spellbinder, где пакеты будут перех­вачены, про­ана­лизи­рова­ны и получат ответ, если это необ­ходимо», — объ­ясня­ют экспер­ты ESET.

По сло­вам иссле­дова­телей, Spellbinder раз­верты­вает­ся с помощью архи­ва AVGApplicationFrameHostS.zip, который рас­паковы­вает­ся в каталог, ими­тиру­ющий легитим­ное ПО: %PROGRAMFILES%\AVG Technologies.

В этой дирек­тории находят­ся AVGApplicationFrameHost.exe, wsc.dll, log.dat и легитим­ная копия winpcap.exe. Исполня­емый файл WinPcap исполь­зует­ся для заг­рузки вре­донос­ной wsc.dll, которая заг­ружа­ет Spellbinder в память.

Пос­ле зараже­ния устрой­ства Spellbinder начина­ет перех­ватывать и ана­лизи­ровать сетевой тра­фик, отсле­живая попыт­ки под­клю­чения к ряду доменов, нап­ример свя­зан­ным с китай­ски­ми сер­верами обновле­ния ПО.

По дан­ным спе­циалис­тов, мал­варь отсле­жива­ет домены, при­над­лежащие ком­пани­ям Tencent, Baidu, Xunlei, Youku, iQIYI, Kingsoft, Mango TV, Funshion, Youdao, Xiaomi, Xiaomi Miui, PPLive, Meitu, Qihoo 360 и Baofeng.

Инс­тру­мент перенап­равля­ет зап­росы на заг­рузку и уста­нов­ку вре­донос­ных обновле­ний, которые в ито­ге раз­ворачи­вают в сис­темах жертв бэк­дор WizardNet. Он пре­дос­тавля­ет зло­умыш­ленни­кам пос­тоян­ный дос­туп к заражен­ному устрой­ству и поз­воля­ет уста­нав­ливать допол­нитель­ную мал­варь.

Для защиты от подоб­ных атак спе­циалис­ты рекомен­дуют орга­низа­циям прис­таль­но кон­тро­лиро­вать тра­фик IPv6 или вооб­ще отклю­чать этот про­токол, если он не исполь­зует­ся в инфраструк­туре.

Oniux анонимизирует трафик

Раз­работ­чики Tor анон­сирова­ли инс­тру­мент коман­дной стро­ки Oniux, пред­назна­чен­ный для безопас­ной мар­шру­тиза­ции любых Linux-при­ложе­ний через сеть Tor и ано­ними­зации сетевых соеди­нений.

В отли­чие от клас­сичес­ких методов, которые исполь­зуют user space, Oniux исполь­зует прос­транс­тва имен (namespaces) в Linux для соз­дания пол­ностью изо­лиро­ван­ной сетевой сре­ды для каж­дого при­ложе­ния, пре­дот­вра­щая утеч­ку дан­ных, даже если при­ложе­ние вре­донос­но или нас­тро­ено некор­рек­тно.

Linux namespaces — это фун­кция ядра, которая поз­воля­ет про­цес­сам работать в изо­лиро­ван­ных сре­дах, каж­дая из которых име­ет собс­твен­ное пред­став­ление о кон­крет­ных сис­темных ресур­сах, нап­ример о нет­воркин­ге и про­цес­сах.

Oniux исполь­зует namespaces для изо­ляции при­ложе­ний на уров­не ядра, в резуль­тате чего весь тра­фик при­нуди­тель­но про­ходит через Tor.

«Мы рады пред­ста­вить Oniux: неболь­шую ути­литу коман­дной стро­ки, обес­печива­ющую сетевую изо­ляцию сто­рон­них при­ложе­ний, которые исполь­зуют прос­транс­тва имен Linux, пос­редс­твом Tor, — говорит­ся в сооб­щении раз­работ­чиков. — Пос­тро­енная на базе Arti и onionmasq, Oniux помеща­ет любую Linux-прог­рамму в собс­твен­ное сетевое прос­транс­тво имен, что­бы нап­равить ее через Tor и исклю­чить веро­ятность уте­чек дан­ных».

Нуж­ный эффект дос­тига­ется через раз­мещение каж­дого при­ложе­ния в собс­твен­ном сетевом прос­транс­тве имен без дос­тупа к интерфей­сам хос­та, вмес­то чего исполь­зует­ся вир­туаль­ный интерфейс (onion0), осу­щест­вля­ющий мар­шру­тиза­цию через Tor с помощью onionmasq.

Кро­ме того, инс­тру­мент исполь­зует mount namespaces для внед­рения собс­твен­ного /etc/resolv.conf для безопас­ной работы с Tor DNS, а так­же user/PID namespaces для безопас­ной нас­трой­ки сре­ды с минималь­ными при­виле­гиями. Это поз­воля­ет обес­печить защиту от уте­чек и изо­ляцию Tor в ядре для любого при­ложе­ния Linux.

Раз­работ­чики объ­ясня­ют, что в отли­чие от Oniux Torsocks работа­ет за счет исполь­зования LD_PRELOAD и перех­вата вызовов сетевых фун­кций в динами­чес­ки свя­зан­ных Linux-при­ложе­ниях и перенап­равля­ет их через SOCKS-прок­си Tor.

Проб­лема такого под­хода зак­люча­ется в том, что необ­работан­ные сис­темные вызовы не перех­ватыва­ются Torsocks, а вре­донос­ные прог­раммы могут не исполь­зовать фун­кции libc, что может при­вес­ти к утеч­кам.

Бо­лее того, Torsocks вооб­ще не работа­ет со ста­тичес­кими бинар­никами и не обес­печива­ет нас­тоящей изо­ляции, пос­коль­ку при­ложе­ния все рав­но обра­щают­ся к реаль­ным сетевым интерфей­сам хос­та.

В бло­ге раз­работ­чики опуб­ликова­ли срав­нитель­ную таб­лицу, в которой ука­заны раз­личия меж­ду эти­ми решени­ями.

Нес­мотря на оче­вид­ные пре­иму­щес­тва Oniux, под­черки­вает­ся, что это экспе­римен­таль­ный про­ект, который пока не про­шел всес­торон­нее тес­тирова­ние в раз­ных усло­виях и сце­нари­ях. По этой при­чине инс­тру­мент может работать некор­рек­тно и не рекомен­дует­ся задей­ство­вать его в кри­тичес­ки важ­ных опе­раци­ях.

Вмес­то это­го раз­работ­чики при­зыва­ют энту­зиас­тов про­тес­тировать Oniux и сооб­щить о воз­никших проб­лемах, что­бы побыс­трее под­готовить инс­тру­мент к более широко­му внед­рению.

Tor Project уже опуб­ликовал ис­ходный код Oniux и рекомен­дует всем, кто захочет его про­тес­тировать, пред­варитель­но убе­дить­ся в том, что в их дис­три­бути­ве уста­нов­лен Rust.

88,6% мобильных приложений в РФ имеют уязвимости

• Ана­лити­ки AppSec Solutions про­вели иссле­дова­ние безопас­ности мобиль­ных при­ложе­ний. В выбор­ку вош­ли сер­висы из топ-100 по ска­чива­нию в темати­чес­ких катего­риях.
• Сум­марно иссле­дова­тели изу­чили 1675 мобиль­ных при­ложе­ний, от фин­теха и онлайн‑ритей­ла до здра­воох­ранения, обра­зова­ния и кор­поратив­ных сер­висов.
• Вы­ясни­лось, что 88,6% при­ложе­ний содер­жат уяз­вимос­ти уров­ня critical и high.

• Сум­марно в 2024 году было выяв­лено 29 952 уяз­вимос­ти, сре­ди них 83 кри­тичес­ки опас­ных и 8887 высоко­го уров­ня серь­езности. Для срав­нения: в 2023 году сре­ди всех 41 493 уяз­вимос­тей было обна­руже­но все­го 22 кри­тичес­ких.
• Ли­дера­ми по обще­му количес­тву выяв­ленных проб­лем ока­зались при­ложе­ния в катего­рии «Здо­ровье». Одна­ко боль­шинс­тво этих проб­лем носят нек­ритичес­кий харак­тер.
• На вто­ром мес­те по уяз­вимос­тям —«Полез­ные инс­тру­мен­ты». Это самая раз­нооб­разная катего­рия, куда вхо­дят прог­нозы погоды, перевод­чики, при­ложе­ния для соз­дания ней­роава­таров, музыкаль­ные пле­еры и даже анти­виру­сы.

• Так­же отме­чает­ся, что более 30% уяз­вимос­тей в при­ложе­ниях для обра­зова­ния были уров­ня critical и high. Так, некото­рые при­ложе­ния поз­воля­ют хра­нить чувс­тви­тель­ные дан­ные, вклю­чая пароли или пер­сональ­ные дан­ные поль­зовате­лей, в пуб­личном фай­ле, до которо­го без тру­да могут доб­рать­ся зло­умыш­ленни­ки.

Вредоносные драйверы Procolored

Офи­циаль­ное ПО, которое пос­тавля­лось с прин­терами Procolored, содер­жало тро­ян уда­лен­ного дос­тупа и мал­варь для кра­жи крип­товалю­ты. Про­изво­дитель рас­простра­нял заражен­ный софт не менее полуго­да.

Ки­тай­ская ком­пания Procolored — пос­тавщик решений для циф­ровой печати, выпус­кающий прин­теры типа Direct-to-Film (DTF), UV DTF, UV и Direct-to-Garment (DTG). В час­тнос­ти, ком­пания широко извес­тна бла­года­ря недоро­гим про­дук­там, пред­назна­чен­ным для печати на тка­ни.

Пер­вым мал­варь в ПО Procolored заметил юту­бер Кэмерон Ковард (Cameron Coward), извес­тный под ником Serial Hobbyism. Его анти­вирус пре­дуп­редил о наличии USB-чер­вя Floxif при уста­нов­ке сопутс­тву­юще­го соф­та и драй­веров для прин­тера Procolored V11 Pro.

По сло­вам Ковар­да, он попытал­ся свя­зать­ся с ком­пани­ей Procolored, одна­ко про­изво­дитель отри­цал наличие мал­вари в сво­ем ПО, заяв­ляя, что анти­виру­сы могут генери­ровать лож­ные сра­баты­вания.

«Если я пыта­юсь заг­рузить фай­лы с их сай­та или рас­паковать фай­лы с USB-накопи­теля (который пос­тавлял­ся в ком­плек­те), мой компь­ютер немед­ленно помеща­ет их в каран­тин», — рас­ска­зывал Ковард в сво­ем видео.

Сог­ласно ана­лизу, про­веден­ному иссле­дова­теля­ми из ком­пании G Data, офи­циаль­ные пакеты ПО Procolored дей­стви­тель­но рас­простра­няли мал­варь и это дли­лось не менее шес­ти месяцев.

Эк­спер­ты обна­ружи­ли, что софт еще как минимум для шес­ти моделей прин­теров (F8, F13, F13 Pro, V6, V11 Pro и VF13 Pro), лежащий в фай­лооб­менни­ке Mega, содер­жит вре­донос­ное ПО. Отме­чает­ся, что ком­пания Procolored исполь­зует Mega для хра­нения сво­его прог­рам­мно­го обес­печения, а раз­дел под­дер­жки на офи­циаль­ном сай­те содер­жит пря­мые ссыл­ки на фай­лооб­менник.

В общей слож­ности ана­лити­ки наш­ли 39 фай­лов, которые были зараже­ны сле­дующи­ми вре­доно­сами:

• XRedRAT — мал­варь, ранее изу­чен­ная экспер­тами eSentire. Может исполь­зовать­ся для перех­вата нажатий кла­виш, соз­дания сним­ков экра­на, уда­лен­ного шелл‑дос­тупа и манипу­лиро­вания фай­лами. Жес­тко закоди­рован­ные адре­са управля­ющих сер­веров соот­ветс­тву­ют ста­рым образцам;
• SnipVex — ранее неиз­вес­тный клип­пер, который заража­ет фай­лы .EXE, прик­репля­ется к ним и под­меня­ет BTC-адре­са в буфере обме­на. Обна­ружен в нес­коль­ких заг­ружен­ных фай­лах. Пред­положи­тель­но этим вре­доно­сом зараже­ны сис­темы раз­работ­чиков Procolored или машины для сбор­ки.

Пос­коль­ку фай­лы пос­ледний раз обновля­лись в октябре 2024 года, мож­но пред­положить, что мал­варь пос­тавля­ется вмес­те с офи­циаль­ным соф­том Procolored не менее полуго­да.

От­меча­ется, что на адрес, который SnipVex исполь­зует для получе­ния кра­деной крип­товалю­ты, пос­тупило 9,308 BTC, то есть око­ло мил­лиона дол­ларов по текуще­му кур­су.

Хо­тя пос­ле исходно­го пре­дуп­режде­ния юту­бера пред­ста­вите­ли Procolored все отри­цали, 8 мая 2025 года ком­пания уда­лила заражен­ные прог­рам­мные пакеты и начала внут­реннее рас­сле­дова­ние.

Ког­да спе­циалис­ты G Data обра­тились к про­изво­дите­лю за объ­ясне­ниями, в Procolored приз­нались, что мог­ли заг­рузить фай­лы на Mega.nz с помощью USB-накопи­теля, который был заражен Floxif.

«В качес­тве меры пре­дос­торож­ности с офи­циаль­ного сай­та Procolored было вре­мен­но уда­лено все прог­рам­мное обес­печение, — сооб­щили в Procolored. — Мы про­водим всес­торон­нюю про­вер­ку каж­дого фай­ла на наличие вре­донос­ного ПО. Толь­ко пос­ле про­хож­дения стро­гих про­верок прог­рам­мное обес­печение будет опуб­ликова­но сно­ва».

Эк­спер­ты G Data уже изу­чили «чис­тые» прог­рам­мные пакеты Procolored и под­твер­дили, что они безопас­ны для исполь­зования. Теперь всем поль­зовате­лям Procolored рекомен­дует­ся как мож­но ско­рее заменить ста­рое ПО новыми вер­сиями и выпол­нить ска­ниро­вание сво­их сис­тем для уда­ления XRedRAT и SnipVex.

Firefox не выживет без Google

Раз­работ­чики Mozilla рас­ска­зали, что прек­ращение финан­сирова­ния со сто­роны Google может пос­тавить под угро­зу само сущес­тво­вание бра­узе­ра Firefox.

Де­ло в том, что недав­но финан­совый дирек­тор Mozilla Эрик Мюль­хейм (Eric Muhlheim) давал показа­ния в рам­ках анти­моно­поль­ного раз­биратель­ства по делу США про­тив Google LLC. В ком­пании решили более деталь­но объ­яснить позицию Мюль­хейма в час­тнос­ти и Mozilla в целом.

«Не сек­рет, что доходы от поис­ка сос­тавля­ют боль­шую часть годово­го дохода Mozilla. Firefox — незави­симый бра­узер, у нас нет собс­твен­ной ОС, устрой­ств или магази­на при­ложе­ний. Без это­го дохода Mozilla и дру­гие незави­симые бра­узе­ры будут вынуж­дены сок­ратить мас­шта­бы сво­ей деятель­нос­ти и уре­зать под­дер­жку таких важ­ных про­ектов, как Gecko, единс­твен­ного бра­узер­ного движ­ка, кон­куриру­юще­го с Chromium от Google и WebKit от Apple.

Ин­новации, кон­фиден­циаль­ность и выбор поль­зовате­ля могут проц­ветать лишь тог­да, ког­да бра­узер­ные движ­ки кон­куриру­ют. Без это­го про­падет сти­мул делать интернет более быс­трым, безопас­ным или инклю­зив­ным. Если мы потеря­ем или осла­бим Gecko, интернет будет опти­мизи­рован на ком­мерчес­кие биз­нес‑модели и их при­ори­теты, а не на цен­ности, которые отста­ивает Mozilla: кон­фиден­циаль­ность, дос­тупность и выбор поль­зовате­ля. Откры­тый веб оста­ется откры­тым лишь в том слу­чае, если сай­ты, при­ложе­ния и кон­тент вза­имо­дей­ству­ют и работа­ют вез­де.

Под­линное улуч­шение усло­вий кон­курен­ции и выбора не может решать одну проб­лему за счет соз­дания дру­гой», — пишут раз­работ­чики.

Кро­ме того, пос­ле показа­ний Мюль­хейма выс­казалась и гла­ва Mozilla Лора Чем­берс (Laura Chambers), которая под­чер­кну­ла, что это раз­биратель­ство «опре­делит лан­дшафт кон­курен­ции в интерне­те на дол­гие годы впе­ред».

«Любое средс­тво пра­вовой защиты дол­жно укреплять, а не ослаблять незави­симые аль­тер­нативы, на которые люди полага­ются в поис­ках кон­фиден­циаль­нос­ти, инно­ваций и выбора.

Не­боль­шие незави­симые бра­узе­ры, такие как Firefox, полага­ются на монети­зацию через поис­ковые пар­тнерс­тва, которые поз­воля­ют под­держи­вать нашу работу и инвести­ровать в инно­вации, ори­енти­рован­ные на поль­зовате­лей. Без этих пар­тнерств мы стол­кну­лись бы с серь­езны­ми огра­ниче­ниями, которые не толь­ко помеша­ли бы нам рас­ти, но и лишили бы воз­можнос­ти пре­дос­тавлять неком­мерчес­кую аль­тер­нативу Chrome, Edge и Safari.

Под­ход Mozilla к поис­ку стро­ится на пре­дос­тавле­нии людям выбора. Мы неод­нократ­но стал­кивались с тем, что люди покида­ют наш бра­узер, если им навязы­вают поис­ковую сис­тему, которая им не нра­вит­ся. Без поис­ковых пар­тнерств незави­симые бра­узе­ры, такие как Firefox и бра­узер­ный дви­жок Gecko от Mozilla, стол­кнут­ся с серь­езны­ми огра­ниче­ниями.

Мы приз­наем важ­ность повыше­ния кон­курен­ции в поис­ковой сре­де. Одна­ко это не дол­жно про­исхо­дить за счет кон­курен­ции бра­узе­ров. Мы счи­таем, что суд дол­жен гаран­тировать, что неболь­шие и незави­симые бра­узе­ры не пос­тра­дают при при­нятии окон­чатель­ного решения. Без это­го мы рис­куем про­менять одну монопо­лию на дру­гую, и живой, ори­енти­рован­ный на людей веб, за который мы боролись десяти­лети­ями, может начать исче­зать», — объ­ясни­ла Чем­берс.

Сотрудники Coinbase продали данные пользователей

Крип­тобир­жа Coinbase, которой поль­зуют­ся более 100 мил­лионов человек, сооб­щила, что недоб­росовес­тные сот­рудни­ки служ­бы под­дер­жки про­дали кибер­прес­тупни­кам дан­ные кли­ентов. Хакеры пот­ребова­ли выкуп в раз­мере 20 мил­лионов дол­ларов за нераз­гла­шение укра­ден­ной информа­ции.

В Coinbase заяви­ли, что не будут пла­тить. Вмес­то это­го бир­жа учре­дила спе­циаль­ный фонд для вып­латы воз­награж­дения в раз­мере 20 мил­лионов дол­ларов за любую информа­цию, которая поможет най­ти зло­умыш­ленни­ков, орга­низо­вав­ших эту ата­ку.

11 мая 2025 года хакеры нап­равили руководс­тву Coinbase пись­мо с угро­зами и тре­бова­нием выкупа в раз­мере 20 мил­лионов дол­ларов. В про­тив­ном слу­чае они угро­жали слить в откры­тый дос­туп укра­ден­ную информа­цию о некото­рых кли­ент­ских сче­тах и внут­реннюю докумен­тацию.

Сог­ласно офи­циаль­ному заяв­лению бир­жи, хакеры получи­ли эту информа­цию от под­рядчи­ков и сот­рудни­ков служ­бы под­дер­жки, которые находи­лись за пре­дела­ми США. Зло­умыш­ленни­ки зап­латили инсай­дерам за дос­туп к внут­ренним сис­темам ком­пании.

Ког­да о слу­чив­шемся ста­ло извес­тно, все тор­говав­шие информа­цией сот­рудни­ки были уво­лены. При этом не сооб­щает­ся, в какой имен­но стра­не работа­ли инсай­деры.

Из­началь­но заяв­лялось, что в руках хакеров ока­зались пер­сональ­ные дан­ные при­мер­но 1% кли­ент­ской базы Coinbase (око­ло мил­лиона человек). Одна­ко в уве­дом­лении об утеч­ке, нап­равлен­ном в Генераль­ную про­кура­туру шта­та Мэн, пред­ста­вите­ли Coinbase сооб­щили о 69 461 пос­тра­дав­шем.

Под­черки­вает­ся, что зло­умыш­ленни­кам не уда­лось похитить при­ват­ные клю­чи или пароли кли­ентов, а так­же получить дос­туп к сче­там Coinbase Prime, горячим и холод­ным кошель­кам пос­тра­дав­ших или самой бир­жи.

За­то сре­ди укра­ден­ных дан­ных были:

• име­на, адре­са, телефо­ны и email-адре­са;
• за­мас­кирован­ные номера соци­аль­ного стра­хова­ния (толь­ко пос­ледние четыре циф­ры);
• за­мас­кирован­ные номера бан­ков­ских сче­тов и некото­рые бан­ков­ские иден­тифика­торы;
• изоб­ражения удос­товере­ний лич­ности (нап­ример, водитель­ских прав, пас­портов);
• дан­ные о сче­тах (снап­шоты балан­са и исто­рии опе­раций);
• не­кото­рые кор­поратив­ные дан­ные (вклю­чая докумен­ты, обу­чающие матери­алы и сооб­щения, дос­тупные аген­там служ­бы под­дер­жки).

«Кибер­прес­тупни­ки под­купили и завер­бовали груп­пу инос­тран­ных сот­рудни­ков служ­бы тех­ничес­кой под­дер­жки, что­бы те похити­ли дан­ные кли­ентов Coinbase для про­веде­ния атак с исполь­зовани­ем соци­аль­ной инже­нерии, — говорит­ся в офи­циаль­ном заяв­лении Coinbase. — Пароли, при­ват­ные клю­чи и средс­тва поль­зовате­лей не пос­тра­дали, а так­же инци­дент не кос­нулся сче­тов Coinbase Prime. Мы воз­местим все убыт­ки кли­ентам, которых обма­ном вынуди­ли отпра­вить средс­тва зло­умыш­ленни­кам».

Пред­ста­вите­ли Coinbase не сооб­щили, сколь­ко имен­но кли­ентов пос­тра­дали от атак с исполь­зовани­ем соци­аль­ной инже­нерии и переве­ли день­ги мошен­никам. По оцен­кам ком­пании, рас­ходы на устра­нение пос­ледс­твий это­го инци­ден­та и воз­мещение ущер­ба кли­ентам сос­тавят от 180 до 400 мил­лионов дол­ларов США.

В ком­пании заяви­ли, что вско­ре Coinbase откро­ет новый центр под­дер­жки в США, воз­местит все рас­ходы пос­тра­дав­шим и уве­личит инвести­ции в обна­руже­ние внут­ренних угроз, а так­же модели­рова­ние и авто­мати­зацию реаги­рова­ния на угро­зы, что­бы пре­дот­вра­тить подоб­ные утеч­ки в будущем.

Кли­ентам рекомен­дует­ся сох­ранять бди­тель­ность, так как зло­умыш­ленни­ки могут пытать­ся выдать себя за сот­рудни­ков Coinbase, обма­ном зас­тавить перевес­ти средс­тва или зап­рашивать кон­фиден­циаль­ную информа­цию, нап­ример пароли или коды двух­фактор­ной аутен­тифика­ции.

Нет администратору в Chrome

Из­менения в Chromium не поз­волят бра­узе­ру Chrome запус­кать­ся от име­ни адми­нис­тра­тора. Раз­работ­чики объ­ясня­ют, что эта мера нап­равле­на на повыше­ние безопас­ности Windows.

Еще в 2019 году ком­пания Microsoft внед­рила подоб­ную фун­кци­ональ­ность в бра­узер Edge. Ког­да поль­зовате­ли запус­кали Edge с повышен­ными пра­вами, появ­лялось пре­дуп­режде­ние, рекомен­дующее заново переза­пус­тить его без при­виле­гий адми­нис­тра­тора. Поз­же Microsoft изме­нила эту фун­кцию таким обра­зом, что­бы запуск Edge с повышен­ными пра­вами стал невоз­можен в целом.

Те­перь ана­логич­ные изме­нения появят­ся в Chromium, а раз­работ­чики Microsoft уже отпра­вили соот­ветс­тву­ющий ком­мит. В Microsoft объ­ясня­ют, что Chrome будет авто­мати­чес­ки понижать при­виле­гии, если поль­зователь попыта­ется запус­тить его с повышен­ными пра­вами.

«Авто­мати­чес­кое пониже­ние прав поль­зовате­лей, запус­кающих Chrome с повышен­ными при­виле­гиями. Этот CL осно­ван на изме­нени­ях, которые мы внес­ли в Edge: начиная с 2019 года бра­узер пыта­ется авто­мати­чес­ки понизить пра­ва, если запус­кает­ся с повышен­ным уров­нем split/linked-токена, — пишет раз­работ­чик Microsoft Edge Сте­фан Смо­лен (Stefan Smolen). — Это озна­чает, что он авто­мати­чес­ки пыта­ется переза­пус­тить бра­узер еще раз, а затем, если попыт­ка не уда­лась, воз­вра­щает­ся к текуще­му поведе­нию (запуск с пра­вами адми­нис­тра­тора)».

Кро­ме того, Microsoft добави­ла параметр коман­дной стро­ки -do-not-de-elevate, что­бы пре­дот­вра­тить пониже­ние прав пос­ле авто­мати­чес­кого переза­пус­ка и избе­жать бес­конеч­ных цик­лов.

Эта фун­кци­ональ­ность не работа­ет для про­цес­сов Chrome, запущен­ных с повышен­ными пра­вами в режиме авто­мати­зации, что­бы не мешать работе инс­тру­мен­тов, которые дол­жны запус­кать­ся авто­мати­чес­ки.

В Microsoft напоми­нают, что запус­кать бра­узер с пра­вами адми­нис­тра­тора — не очень хорошая идея в целом. Ведь ког­да Chrome запус­кает­ся от име­ни адми­нис­тра­тора, он нас­леду­ет повышен­ные при­виле­гии и все, что заг­ружа­ется и откры­вает­ся через бра­узер, так­же запус­кает­ся с пра­вами адми­нис­тра­тора и несет серь­езную угро­зу безопас­ности.

Опасные расширения Chrome

Ана­лити­ки DomainTools Intelligence (DTI) обна­ружи­ли более 100 вре­донос­ных рас­ширений для бра­узе­ра Chrome, замас­кирован­ных под VPN, ИИ‑ассистен­ты и крип­тоути­литы. Рас­ширения исполь­зуют­ся для кра­жи фай­лов cookie и скры­того выпол­нения уда­лен­ных скрип­тов.

По сло­вам экспер­тов, неиз­вес­тные зло­умыш­ленни­ки рас­простра­няют эти рас­ширения с фев­раля 2024 года.

«Зло­умыш­ленни­ки соз­дают сай­ты, ими­тиру­ющие легитим­ные сер­висы: инс­тру­мен­ты для повыше­ния про­изво­дитель­нос­ти, помощ­ники для соз­дания и ана­лиза рек­ламы и меди­афай­лов, VPN-сер­висы, крип­тоинс­тру­мен­ты, бан­ков­ские сер­висы и мно­гое дру­гое. Такие сай­ты побуж­дают поль­зовате­лей уста­новить соот­ветс­тву­ющие вре­донос­ные рас­ширения из Chrome Web Store», — рас­ска­зыва­ют иссле­дова­тели.

Не­кото­рые из обна­ружен­ных сай­тов‑при­манок выдава­ли себя за легитим­ные про­дук­ты и сер­висы, вклю­чая DeepSeek, Manus, DeBank, FortiVPN, YouTube и Site Stats, что­бы убе­дить поль­зовате­лей заг­рузить и уста­новить рас­ширения.

Пос­ле это­го зло­умыш­ленни­ки собира­ют из бра­узе­ра фай­лы cookie, получа­ют про­изволь­ные скрип­ты с уда­лен­ного сер­вера и уста­нав­лива­ют WebSocket-соеди­нения для работы в качес­тве прок­си и мар­шру­тиза­ции тра­фика.

На пер­вый взгляд рас­ширения дей­стви­тель­но выпол­няют заяв­ленные фун­кции, одна­ко при этом они вору­ют учет­ные дан­ные и фай­лы cookie, перех­ватыва­ют сеан­сы, внед­ряют в бра­узер рек­ламу, соз­дают вре­донос­ные перенап­равле­ния, манипу­лиру­ют тра­фиком и занима­ются фишин­гом, манипу­лируя DOM.

Кро­ме того, рас­ширения нас­тро­ены на пре­дос­тавле­ние себе чрез­мерных прав через файл manifest.json, что поз­воля­ет им вза­имо­дей­ство­вать с каж­дым посеща­емым сай­том, выпол­нять про­изволь­ный код, получен­ный с кон­тро­лиру­емо­го зло­умыш­ленни­ком домена, осу­щест­влять вре­донос­ные редирек­ты и даже внед­рять на стра­ницы рек­ламу.

Рас­ширения исполь­зуют обра­бот­чик события onreset в DOM (Document Object Model) для выпол­нения кода, веро­ятно, в попыт­ке обой­ти CSP (Content Security Policy).

По­ка неяс­но, как имен­но жертв замани­вают на фик­тивные сай­ты, но иссле­дова­тели пред­полага­ют, что для это­го исполь­зуют­ся обыч­ные методы, вклю­чая фишинг и пуб­ликации в соци­аль­ных сетях.

«Пос­коль­ку рас­ширения появ­ляют­ся как в Chrome Web Store, так и на сай­тах, они могут отоб­ражать­ся в резуль­татах обыч­ного веб‑поис­ка и при поис­ке в магази­не Chrome, — объ­ясня­ют ана­лити­ки. — Мно­гие из сай­тов‑при­манок исполь­зовали тре­кинг ID Facebook * , что наводит на мысль о том, что они исполь­зуют при­ложе­ния Facebook/Meta ** для прив­лечения посети­телей. Воз­можно, рас­ширения прод­вига­ются с помощью стра­ниц в Facebook, групп и даже рек­ламы в соц­сети».

На дан­ный момент неиз­вес­тно, кто сто­ит за этой вре­донос­ной кам­пани­ей. Получив информа­цию от иссле­дова­телей, инже­неры Google уда­лили из офи­циаль­ного магази­на поч­ти все опас­ные рас­ширения.

Пол­ный спи­сок вре­донос­ных доменов с рек­ламой рас­ширений дос­тупен на GitHub DTI.

• Зап­рещена в Рос­сии. При­над­лежит ком­пании Meta, которая приз­нана экс­тре­мист­ской и зап­рещена на тер­ритории РФ. ** Де­ятель­ность Meta Platforms приз­нана экс­тре­мист­ской и зап­рещена в РФ.