Информационная безопасность IT

Всем привет!

Продолжаем погружение в мир информационной безопасности. Я уже рассказывал про типичные ошибки людей, рассказывал про фишинг, вишинг, спам, слабые пароли, про мошенников и про много чего еще с чем можно ознакомиться на канале. И сегодня как вы поняли из названия я предлагаю познакомить вас с очередным видом малвары – Червями.

Что такое черви в цифровом мире?

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

Червь — это один из наиболее опасных и распространённых типов вредоносного программного обеспечения в сфере информационной безопасности. Если по-простому, то это один из видов «вирусов», но в отличие от обычных вирусов, которые внедряются в существующие файлы и требуют запуска со стороны человека, черви существуют как отдельные программы и используют уязвимости операционных систем или приложений для проникновения на новые устройства.

Его основной механизм действия — самокопирование. Попав на компьютер, червяк сканирует компьютер на наличие путей дальнейшего копирования. Например, проверяет стоит ли почтовый клиент, открыт ли мессенджер, вставлена ли флешка, подключен ли компьютер к сети и есть ли в этой сети другие уязвимые устройства. И через эти «каналы распространения» он копирует себя дальше, для этого он использует открытые порты, слабые пароли, ошибки в почтовых клиентах или сетевых службах. После заражения червь может замедлять работу системы, создавать ботнеты (сети из заражённых компьютеров) для проведения DDoS-атак по командам из вне, рассылки спама, кражи персональных данных или служить «входной точкой» для других вредоносных программ. Все зависит от того какую «полезную нагрузку» в него добавил его создатель и для какой цели червяк был создан.

Но как и откуда черви появились? И почему называются, именно червяк?

Как появились черви?

Происхождение компьютерных червей уходит корнями в 1960-е годы, задолго до появления современного интернета. В 1961 году в американской компании Bell Labs была создана игра под названием «Дарвин». Её суть заключалась в том, что одни программы-«организмы» должны были захватывать оперативную память компьютера, вытесняя чужие «организмы». Это считается одним из первых концептуальных прототипов самораспространяющегося кода, который по своей логике предвосхитил появление будущих сетевых червей. А уже первые черви как вредоносные программы появились позже и начались с простого эксперимента.

В 1971 году программист Боб Томас, работавший в компании Bolt, Beranek and Newman, создал программу под названием Creeper ее и считают первым компьютерным червем. Самое интересное, что целью Боба было не навредить, а просто проверить теорию: может ли программа перемещаться с одного компьютера на другой по сети (тогда это была сеть ARPANET). Creeper делал именно это — он «переползал» с машины на машину и на экране заражённого компьютера появлялась надпись:

«I'M THE CREEPER: CATCH ME IF YOU CAN» («Я — Криппер: поймай меня, если сможешь»).

Затем другой программист, Рэй Томлинсон (тот самый, который придумал символ @ для электронной почты), написал программу Reaper. Это был, по сути, первый в истории антивирус. Его задачей было тоже ползать по сети, находить копии Creeper и останавливать их работу.

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

И лишь в конце 1980-х годов стали появляться зловреды. Знаменитый Morris Worm (1988) заразил тысячи компьютеров с UNIX-системами. В дальнейшем мир столкнулся с такими угрозами, как ILOVEYOU (2000), Code Red (2001), Mydoom (2004), Conficker (2008), WannaCry (2017) и тд. Эти инциденты приводили к многомиллионным убыткам, парализовывали работу компаний и государственных учреждений по всему миру. О них мы и поговорим далее.

Самые известные инциденты с червями

Самым первым червем, получившим широкое распространение в сети ARPANET стал - Morris Worm (1988). Его создал аспирант Роберт Моррис. Червь не был предназначен для уничтожения данных, но из-за ошибки в коде он бесконтрольно размножался, что привело к отказу в работе тысяч компьютеров. Ущерб от атаки составил миллионы долларов, а сам инцидент привлёк внимание всего мира к проблеме киберугроз.

«Золотой эрой» червей принято считать период с 2000 по 2010 год. Именно тогда мир столкнулся со следующими вредителями:

• ILOVEYOU (2000) Один из самых «романтичных» и разрушительных червей. Он распространялся по электронной почте с темой «ILOVEYOU» и вложением «LOVE-LETTER-FOR-YOU.TXT.vbs». Пользователи, открывшие вложение, запускали скрипт, который повреждал файлы и рассылал червя всем контактам из адресной книги. За несколько дней было заражено около 10% всех подключённых к интернету компьютеров, а общий ущерб превысил $10 млрд. Среди пострадавших оказались Пентагон и парламент Великобритании.

• MyDoom (2004) Этот червь стал самым дорогостоящим в истории. Он распространялся через электронную почту и на пике эпидемии отвечал за четверть всего мирового почтового трафика. MyDoom не только заражал компьютеры, но и использовал их для DDoS-атак на сайты таких корпораций как Microsoft. Ущерб от его деятельности оценивается в $38,5 млрд.

• Stuxnet (2010) Первый в истории пример кибероружия. Червь был нацелен не на обычных пользователей, а на промышленную инфраструктуру — конкретно на иранские центрифуги для обогащения урана. Stuxnet вывел из строя около 20% оборудования, существенно замедлив ядерную программу страны. Самое интересное что по легенде Stuxnet был создан из-за одной фотографии сделанной на ядерном объекте Ирана, на которой было видно какая программа использовалась для управления центрифугами, а для аутентификации червь пробовал предустановленные производителем логины и пароли (и даже на таком секретном объекте люди не меняли дефолтные пароли и поплатились).

• Mirai (2016) Червь для устройств интернета вещей (IoT). Он заражал умные камеры, роутеры и другие гаджеты со стандартными паролями, объединяя их в огромные ботнеты. С помощью Mirai была проведена одна из самых мощных DDoS-атак в истории, которая временно отключила значительную часть интернета на восточном побережье США.

• WannaCry (2017) Глобальная эпидемия шифровальщика, который использовал уязвимость Windows (EternalBlue). WannaCry зашифровал данные на более чем 200 000 компьютерах в 150 странах мира и требовал выкуп в биткоинах. Ущерб превысил $4 млрд. В России пострадали крупные государственные и коммерческие структуры: МВД, РЖД, Сбербанк, «Мегафон». Из интересного, что эпидемия WannaCry была остановлена случайно, благодаря бывшему хакеру, который решил проанализировать код червя. Увидел в нем адрес управляющего сервера, как он считал, но доменное имя оказалось не существующим и как только он зарегистрировал доменное имя и как только что-то стало отзываться по этому адресу шифрования остановились. Но до сих пор остатки WannaCry гуляют по сетям предприятий.

• NotPetya (2017) Изначально маскировался под программу-вымогатель Petya, но на деле оказался «вайпером» — вредоносом, уничтожающим данные без возможности восстановления. Он распространялся через бэкдор в бухгалтерском ПО и нанёс колоссальный ущерб бизнесу по всему миру. Например, датская логистическая компания Moller-Maersk оценила свои потери из-за простоя в $200–300 млн.

Как защититься от червей?

И как же защититься от этих зловредов? Если честно, на 100% это не возможно, но можно минимизировать вероятность соблюдая простые правила:

• Используйте современный (не бесплатный) антивирус и регулярно обновляйте его базы.

• Своевременно устанавливайте обновления безопасности для операционной системы и всех установленных у вас программ.

• Не открывайте электронные письма и вложения от неизвестных отправителей, особенно с заметной/побуждающей темой письма.

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

• Обязательно проверяйте антивирусом ВСЕ внешние носители перед использованием, даже свои.

• Регулярно создавайте резервные копии важных данных.

Помимо соблюдения этих правил приучите себя обращать внимание на косвенные признаки заражения вашего компьютера:

• Резкое замедление работы компьютера и интернета, без видимых причин.

• Исчезновение или повреждение файлов.

• Письма в отправленных вашего почтового ящика, которые вы не отправляли.

• Антивирус, firewall, защитник Windows или другие установленные вами средства защиты информации отключены или не запускаются.

• Появление новых, неизвестных вам программ.

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

• Немедленно отключить устройство от интернета и локальной сети.

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

• Если антивирус не запускается, используйте загрузочный диск (Live CD/USB). Если вы подозреваете, что червь блокирует работу антивируса или глубоко интегрирован в систему, перезагрузите компьютер с помощью специального аварийного диска (например, Kaspersky Rescue Disk, Dr.Web LiveDisk). Это позволит запустить проверку вне зараженной операционной системы, что значительно повышает шансы на обнаружение.

• Так как основная задача червя самокопирование, то проверьте сетевой трафик, автозагрузку и планировщик задач:

1. Откройте «Диспетчер задач» (Ctrl+Shift+Esc) и перейдите на вкладку «Производительность» -> «Ethernet» (или «Wi-Fi»). Если вы не используете интернет, но сетевая активность (отправка/получение данных) присутствует — это тревожный знак.

2. В том же «Диспетчере задач» есть вкладка «Журнал приложений» и «Процессы». Обратите внимание на незнакомые процессы, которые потребляют много ресурсов процессора или сети.

3. Введите команду netstat -ano. Она покажет все активные сетевые подключения и идентификаторы процессов (PID), которые их используют. Если вы видите множество подключений к внешним IP-адресам от неизвестного процесса — это признак сетевого червя или ботнета.

4. Откройте «Диспетчер задач» (Ctrl+Shift+Esc) и перейдите на вкладку -> «Автозагрузка». Просмотрите список программ, запускающихся вместе с системой. Если там есть подозрительные или незнакомые приложения, отключите их.

5. Также если если сможете проверьте библиотеку планировщика задач на наличие подозрительных заданий с непонятными названиями.

Если вы обнаружили и удалили червя:

1. Немедленно смените все пароли (от почты, соцсетей, банковских приложений), так как они могли быть украдены.

2. Обновите операционную систему и все установленные программы, чтобы закрыть уязвимости, через которые проник червь.

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

4. Включите автоматическое обновление баз антивируса и регулярно создавайте резервные копии важных данных на какой-нибудь внешний носитель (внешний жесткий диск или флешку).

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

Вывод

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

Помните:

Кто осведомлен, тот вооружен.

Ставьте пальцы вверх и оставляйте комментарии, а я пошел формулировать новые Мысли Starого.

Подписывайтесь на все мои остальные мои ресурсы:

ЖЖ

Teletype

Дзен

Телеграмм

VK

Max

Если у вас есть мысли, факты, истории, которыми вы хотели бы поделиться, присылайте на почту: stariithinks@gmail.com или stariithinks@yandex.ru

Ну начнем. Пришел я значит в больницу. На дворе июль 2024 год. Там уже три месяца как выделили несколько объектов критической информационной инфраструктуры, но не знали что с ними делать. Цитирую: я читаю 187 - ФЗ, но не понимаю, как его реализовать. За обеспечение безопасности ЗОКИИ на 0.25 ставки были устроены два программиста, но они ничего не делали, т.к., со слов одной: "вот пришел к нам запрос от регулятора, что - то просят, а я понять не могу, о чем вообще речь. У меня есть специальная папочка, я беру её и пуляю им. Пусть сами разбираются". К слову, в папочке под полтинничек экз. документов, приказов и прочего. БОльшая часть из которых потеряла актуальность. Но из - за всеобщей расхлябанности ребята просто не знают, как СУИБ должна быть организована и работать.
Я несколько дней потратил на ознакомление с документацией, составил план действий. Первичный конечно же. Среди первых шагов выявил необходимость реализации запрета подключения личных устройств к АРМам - клиентам. Столкнулся с отсутствием вообще какой - либо документации, хотя бы в виде технического паспорта на ИС. Сколько в ИС АРМов? "Ну примерно......" и начиналось гадание на кофейной гуще. Окей. Сколько коммутаторов? "А это тебе ещё зачем? вся информация обрабатывается на серверах". Но предоставить доказательства этого, никто не мне не торопился.
Ну да ладно. В моем понимании работа должна была быть реализована так: я ставлю в известность начальника о какой - либо необходимости, мы это перетираем, составляем "дорожную карту" (т.к. организация большая, только клиентов более 2 тысяч) и с этой точки пляшем.
Но у начальника было другое мнение. Забыл упомянуть. Я как спец по инфобезу числился в отделе информационных технологий. Для тех, кто задаст справедливый вопрос, а как же "конфликт интересов", отвечу: он был. То, что необходимо было реализовать - очень сильно мешало. Соответственно, я разрабатываю проект, а начальник его отвергает. Мол, это усложнит работу.
Прихожу к начальнику. А он такой - да какой запрет флэшек? Ну давай как - то без этой паранойи. В его кабинете сидел один из программистов и он мне задал вопрос с подковыркой, мол, вот запретим мы флэшки, нам тут будут звонить отовсюду, мы что, будем здесь сутками сидеть и отвечать, почему мы осложняем людям работу? Вообще-то людям нужно информацию с флэшек кидать на комп и обратно.
Для этой организации это было нормой.
Это было первым звоночком того, что там лютое очко и работы нормальной не будет. Именно тогда нужно было сказать: окей, вот заявление, увольте меня одним днем и до свидания. Но задачи были сложными, плюс нужно было как - то доносить о необходимости все же внедрять защиту информации.
Ну да ладно. Через неделю я заболеваю короной, ухожу на больничный, а когда возвращаюсь, коллега мне говорит: Автор, ты сейчас очешуеешь!
Случился несанкционированный доступ к информационной системе.
В условиях тотального разгильдяйства, заведующий отделением передал подчиненной на время своего отпуска логин и пароль от своей учетной записи в ОС и в МИС . Да, там разные учетки. Через некоторое время подчиненная увольняется.
Проходит пол года, она уже не работая в учреждении, приводит пациентку частной клиники. Одевает белый халат, идет в ординаторскую приемного покоя. Там естественно никого. Садится за рабочее место, в котором торчит ЭЦП. Оформляет пациентку частной клиники и экстренно направляет на КТ.
Подписывает это все дело вставленной ЭЦП. Выходит так, что заведующий отделением оформил пациентку, а другой врач это дело подписал.
Все вскрывается в тот момент, когда эта бумага ложится на стол зама. главного врача по хирургической части.
Он смотрит, проводил осмотр зав. отделением, который находился в отпуске!
Что думаете случилось, когда дело дошло до главного врача? Аа он принял решение все это дело замолчать. Об этой ситуации гудела вся больница, свидетелей была орда. Я говорил начальнику, что необходимо это дело провести официально, ибо есть много людей, которые захотят по той или иной причине это все вывести на свет. Но он был неприхотлив. Через время пришел запрос из ФСБ по этой ситуации. Я лично проводил "внутренне расследование" и отправлял отчеты.
По итогу - тишина.
Да, здесь конечно ситуация не касается личных накопителей. Здесь она касается безалаберности и всеобщего наплевательства. С тем же успехом человек мог получить доступ к любому компьютеру и слить любую информацию из обменника. А её там много.
Следующая ситуация касалась личных накопителей. Когда встал вопрос, а какого хрена люди приходят с личными устройствами и подключают их. Мне был ответ - ну там же антивирус есть, что случится?
Как пример: к нам в отдел пришел с претензией врач. Говорит, я скачал себе приблуду, пытаюсь её установить, а она не устанавливается. Вы тут чем занимаетесь вообще? Вы должны помогать, а вы только работать мешаете.
Ко мне его привел программист, который первым попался ему на глаза. Я стал задавать ему вопросы. Мужичек сначала вскипел, мол, а че это ты мне тут вопросы свои задаешь? Мне работать нужно. Давай устанавливай мне приблуду и я пошел.
Пришлось немного "обломать" ему рога. Объяснить, что он вставил флэшку в АРМ, на флэшке был троян, этот троян скопировал с его рабочего места конфиденциальную информацию и слил в сеть. В данный момент я провожу внутреннее расследование, готовлю материалы для отправки в ФСБ, поэтому и задаю вопросы. Он не поверил, я показал ему старое письмо с грифом "дсп" от конторы, показал мельком. Говорю, можем не общаться, глав врач дал указание провести расследование и результат ему на стол. Я просто пишу служебку, что такой - то отказался, а результаты я сам накопаю. Мужичок притих, а я ему говорю - ну вот так могло бы оказаться.
Этот индивид дома скачал архиватор который ему "удобнее", скинул его на флэшку, которую он пихает вообще везде, принес на работу, а в архиваторе троян. АВЗ сработала и удалила его. А человек даже не поняв, что произошло, пришел "качать АСУшников", ибо бездельники.
Я снова поднял вопрос о запрете подключений личных устройств, но у начальника как обычно "не было времени" проводить работы по этой теме.

Переходим к МВД.
Высшего образования у меня нет. Недавно на собеседовании мне задали вопрос: а вот почему тебе уже 30 лет, а ты до сих пор вышку не получил? Вопрос честно говоря, поставил меня в ступор.
1. Мне диплом ради диплома не нужен. Мне нужны знания, которые будут подкреплять мой опыт, и которые я смогу применять на практике, а не работать водителем такси с высшим образованием. Да и вообще у меня не было возможности получить вышку.
2. Со мной в одном кабинете работали два человека. Обоим по 45 лет. ВО у них тоже нет. Это не мешает им быть как минимум хорошими специалистами в своем деле. Как минимум.
Как - то искал работу. На ххру была вакансия в МВД, связанная с ЗИ. Отправил им резюме. Мне звонит девушка, говорит - ой, а у вас вышки нет, да? Ну тогда мы не сможем вас взять. У нас только с вышкой (с того момента прошло более года, вакансия до сих пор висит). К слову, в данный момент меня берут на должность, где точно также требуется наличие высшего образования. Но т.к. у меня опыт работы в сфере ИБ более трех лет и в следующем году я получаю вышку, то берут так. Ибо там требуется специалист, а не диплом.
До этого у них работал мальчик. Просто мальчик. Закончил мальчик какой - то институт по специальности ИБ и..... сидел антивирус обновлял. Что такое техпаспорт? Да зачем он нужен. Я и так знаю, что и где у меня стоит. Писать политику ИБ и внедрять ее - это вообще был недосягаемый для него уровень. Делал документы по строго по шаблону. Но потом пришла проверка из ФСБ и мальчику говорит: ты уху ел? С какого перепугу у тебя журнал учета СКЗИ в электронном виде? Почему у тебя координаторы не учтены? Мальчик до увольнения ходил в непонятках, зачем какой - то журнал вести вручную, если уже все давно в электроне? Ведет он таблицу и чего с ней будет?
И много других вопросов. Недолго он там проработал. Первый штраф - и ушел на вольные хлеба.
Зато у него диплом о ВО есть.

Ну и напоследок самая мякотка. Районная администрация. Все как обычно. Начальник АСУ не осложняет себе жизнь какими - то защитами конфиденциальной информации, а руководитель вообще очень слабо разбирается во всех этих ваших интернетах. Вот есть АСУшник, он пусть и разгребает. Ну паренек Валера и разгребал, как умел.
Все началось с того, что Валера без собеседования пригласил меня работать. Но из - за "реорганизации", пока что не мог найти помещение и рабочее место.

Но через время собеседование все таки понадобилось.
Прихожу, разъясняют. Нужно с нуля организовать СУИБ (ПДн) в администрации и продумать момент, где в ближайшем будущем будут присоединены ещё пара организаций в виде ЗАГСа и управления хозяйством. Но они будут выведены как отделы, просто территориально находятся в за пределами границы контролируемой зоны. Также необходимо выполнять работы, связанные с защитой гос. тайны. Лично для меня ничего нового или сверхсложного.
Мне задают вопрос.
Вот у нас есть подрядчик, связанный с защитой информации, он говорит, что может организовать все наши ИСПДн, ИС, СКУД в одну ИСПДн. Насколько актуальна эта информация и сможете ли это сделать сами??
Я понимаю, что подрядчик просто хочет срубить баблишка на работе, не имеющей смысла, но в слух не проговариваю.
Говорю - нужно вникнуть в суть работы, сделать проект. Но самое важное - определить цели.
Собеседник онемел, в глазах пустота.
Ну да, хороший вопрос. О целях мы как - то не думали - и сидят переглядываются с сис. админом.
Далее меня "сшибают" с ног вопросом о том, как я буду строить им СУИБ, с учетом того, что нужно выполнить требования регуляторов, но при этом "не уйти в бюрократию, чтобы все работало быстро, без ограничений".
Сопоставив два факта, а именно то, что передо мной типичный айтишник и то, что он явно плавает в теме ИБ, говорю: прежде чем ответить, мне необходимо задать некоторые уточняющие вопросы.
К слову, были идиоты, которые не давали мне задать вопросы и собеседование завершалось по моей инициативе, досрочно. Я думаю вы согласитесь с тем, что если на собеседовании тебе запрещают задавать вопросы, то это как говорится "ред флаг" и не стоит тратить на них время.
Первым делом я задал вопрос об ответственности. Кто будет нести ответственность, допустим, при утечке данных из ИС. В ходе диалога выяснилось, что за это буду нести ответственность я, как профильный специалист, но все меры по СУИБ согласовывать будет нач. АСУ. "А утечек данных у нас не было никогда. Ну если есть какие - то нарушения, то мы на них закрываем глаза. Вот у нас даже в СЗИ от НСД журналы отключены. Чтобы проверяющие не видели, что у нас тут делается".
Второй вопрос был посвящен этим самым журналам. В случае какого - либо инцидента, как мы будем устанавливать злоумышленника и степень ответственности пользователя ?
Человек явно не понял мой вопрос, ибо потребовалось прояснить, что ещё за "злоумышленник" такой. Ведь у них таких никогда не было.
Я прояснил. Заодно выяснил, что человек глубоко плавает в луже, ибо даже понятие "модель угроз безопасности" ему не знакомо. Это айтишник со стажем более 10 лет работы, который в том числе "обеспечивал" защиту персональных данных в ИС. Ну как обеспечивал? С его слов, документация по ИСПДн неактуальна уже лет 5.
В конечном итоге я задал вопрос по флэш накопителям и подключениям личных устройств к АРМам. Этот вопрос я задаю всегда. Он ярко демонстрирует состояние дел внутри организации. Да, находятся индивиды "ачотакова, у нас нормально с этим все, никто ничего не вставляет". В этом случае мне ответом было то, что у них "никто ничего не подключает". И улыбочка. Под столом стоял системный блок в котором торчал флэш накопитель. Да, вы можете возразить, "а может это рабочая флэшка". Но я думаю, что нет. Исходя из состояния дел в организации.
Мы попрощались и человек пропал. Я через две недели дозвонился до него, он не узнал меня, либо сделал вид что не узнал. Не важно. Сказал "перезвоню" и исчез. Я все же дожал его. Через ххру написал, что жду от него ответ, он в этот же день перезвонил и признался, что мою кандидатуру не рассматривает, ибо "у нас тут будет не система безопасности, а бюрократия какая - то, все станет сложнее и будет работать медленнее". К тому моменту я взвесил все "за" и "против", и уже не собирался туда идти. Но все же сторонник обратной связи. А всякие наглые Валеры пусть динамят кого другого.
Забыл упомянуть. Во время разговора выяснилось, что парнишка все контейнеры эл. подписи держит.... в реестре. "Мне так удобнее". Для тех кто не сталкивался. Когда приходит проверка из ФСБ, они за это натягивают. Разбирать почему нежелательно хранить в реестре - не буду. А то вылезут свидетели секты "ачотакова, даничонебудет, унасжнебылоникогда", а я даже смотреть в их сторону не хочу.

В общем, вот такой получился длиннопост. Поэтому когда автор сказал, что звонил девушке в МВД и она ему буднично ответила "хорошо" - нет ничего выдающегося. Девушка гуманитарий, в этих ваших интернетах скорее всего шарит на уровне включить впн и зайти в инстаграмм. А ситуация такая же, как с Валерой из Администрации.
Начальник не понимает, а Валеру не дрючат. Либо он хитро выкручивается. Вот и все.

Приходит начальник с грустным лицом и говорит: нужен ответ. Займись, а? Мне глав. врач спустила, а я сам не разбираюсь в этом.
Должности специалиста по защите перс. данных в учреждении нет. Я единственный, занимающийся защитой информации, но профиль чуть не мой. Соглашаюсь. Даю ответ. Параллельно написанию ответа все глубже погружаюсь в ворох проблем, связанных с обработкой персональных данных. Но это уже история для другого поста. Пока наслаждайтесь требованием уничтожить все данные к больнице, не имеющей никакого отношения к "федеральному регистру доноров".

Где-то пишут, мол, надо adb shell cmd device_config, но я сделал прямо из шелла и норм всё получилось.

А теперь самое забавное. Граждане из Mullvad VPN рассказали, что об этой уязвимости было сообщено Android Security Team, но тикет был закрыт как невыполнимый. После консультаций с автором первоначальной публикации, Mullvad VPN разместили тикет на Android Issue Tracker, но вскоре Гугл пометил этот тикет как недоступный.

Я просто погуглил команду, и вот итог:

В общем, теория заговора во всей красе: КОРПОРАЦИЯ СКРЫВАЕТ КРИТИЧЕСКУЮ УЯЗВИМОСТЬ! МЫ ВСЕ АПАСНАСТЕ!! А-А-А-А-А!!!

На самом деле всё не так страшно, конечно. Пока что это подтверждено только на одной сборке Android 16 (если я правильно понял) и только на телефоне Google Pixel.

Кому надо технических подробностей: в исходном посте на lowlevel.fun всё есть. Проблему уже обсуждают в твитторе. Способ проверки, актуальна ли уязвимость, описан на Гитхабе.

Финансирование группировки остаётся загадкой, но координированность атаки на вендора security tooling указывает на серьёзные ресурсы. Socket зафиксировала, что TeamPCP атаковала Checkmarx ещё в марте 2026, параллельно компрометируя Trivy и LiteLLM — это системная кампания против инструментов безопасности.

Три хода до полного контроля

Kill chain Shai-Hulud 2.0 состоит из трёх этапов, каждый из которых демонстрирует эволюцию npm-угроз.

Этап 1: Bootstrap через bw_setup.js
Пакет @bitwarden/cli@2026.4.0 маскируется под легитимный Bitwarden CLI и запускается двумя способами: через preinstall lifecycle script (автоматически при npm install) или через bin-поле, которое регистрирует bw_setup.js как команду bw в PATH пользователя. Даже если preinstall заблокирован флагом --ignore-scripts, малвар сработает при следующем вызове команды bw.

Bootstrap скачивает Bun runtime v1.3.13 с github.com/oven-sh/bun (легитимный источник), определяет архитектуру системы и запускает основной payload bw1.js. Использование Bun вместо Node.js критично — payload использует Bun-специфичные API для shell execution и gzip-сжатия.

Этап 2: Многоуровневая обфускация
Файл bw1.js весит 10 МБ и содержит 285,000 строк после форматирования. Обфускация включает:
- String table rotation через функцию _0x214e с hex-индексами
- Seeded ASCII shuffle cipher с PRNG, засеянным 0x3039 (12345)
- Gzip+Base64 embedded payloads для RSA-ключей и GitHub Actions workflow
- Mangled identifiers типа _0x3865d8

C2-домен audit.checkmarx[.]cx хранится как массив [0x42, 0x6e, 0x36, 0x4b, 0x2b, 0x5c, 0xd, 0x57, 0x0, 0xd, 0x7, 0x26, 0x42, 0x3, 0x2a, 0x5c, 0xd, 0x2a], который декодируется через детерминированную таблицу подстановки.

Этап 3: Credential harvesting и worm propagation
Червь развёртывает пять provider-классов:
- File System Provider: читает ~/.npmrc, ~/.ssh/id_*, .git/config, .env файлы
- Shell Provider: выполняет `gh auth token` для кражи GitHub CLI токена
- GitHub Actions Provider: парсит {"value":"...","isSecret":true} из runner context
- AWS SSM Provider: через SSMClient читает Parameter Store
- Azure Key Vault и Google Cloud Secret Manager: полный доступ к секретам

Все результаты сканируются regex-паттернами для извлечения npm-токенов (npm_[A-Za-z0-9]{36}) и GitHub PAT (gh[pousr]_[A-Za-z0-9]{36,255}).

Двойная эксфильтрация и GitHub-бэкдоры

Shai-Hulud 2.0 использует двухуровневую систему эксфильтрации, которая гарантирует доставку данных даже при блокировке C2.

Primary channel: данные сжимаются gzip, шифруются AES-256-GCM случайным ключом, ключ шифруется RSA-4096 и отправляется POST-запросом на hxxps://audit.checkmarx[.]cx:443/v1/telemetry.

Secondary channel: используя украденные GitHub-токены, червь создаёт публичные репозитории под аккаунтом жертвы с описанием "Checkmarx Configuration Storage" и Dune-тематическими именами (gesserit-melange-813). Зашифрованные файлы коммитятся в директорию results/, а токены встраиваются в commit messages в формате LongLiveTheResistanceAgainstMachines:<base64_token>.

Самая опасная функция — GitHub Actions workflow injection. При наличии токена с repo и workflow scopes червь:
1. Перечисляет репозитории с push-доступом, приоритизируя активные
2. Проверяет наличие GitHub Actions secrets
3. Создаёт новую ветку и коммитит .github/workflows/format-check.yml

Этот workflow запускается на каждом push и pull request, обеспечивая persistence в CI/CD pipeline. Время от компрометации до обнаружения составляет в среднем 12-15 дней — достаточно для массового распространения.

Как их узнать в своей сети

Network indicators:
- C2: audit.checkmarx[.]cx:443 (94.154.172[.]43)
- HTTP POST /v1/telemetry с gzip-сжатыми данными
- Загрузки с github.com/oven-sh/bun/releases/download/bun-v1.3.13/

File system artifacts:
- Временные файлы bun-* в /tmp или %TEMP%
- Файлы с именами _0x[hex] в node_modules/.bin/
- Новые .github/workflows/format-check.yml в репозиториях

Process indicators:
- Процессы bun с аргументами bw1.js
- Выполнение `gh auth token` из npm-контекста
- Массовые обращения к AWS SSM, Azure Key Vault, Google Secret Manager

GitHub activity patterns:
- Создание репозиториев с описанием "Checkmarx Configuration Storage"
- Commit messages с паттерном LongLiveTheResistanceAgainstMachines:
- Новые workflow файлы с trigger на push/pull_request

Registry indicators:
Пакеты с preinstall scripts, скачивающие бинарные файлы, особенно если:
- Размер package.json превышает обычный для типа пакета
- Присутствуют обфусцированные строки или hex-массивы
- bin-поля конфликтуют с популярными CLI-утилитами

Что делать российским командам прямо сейчас

Этот кейс критичен для российских SOC по трём причинам. Во-первых, многие российские компании используют Checkmarx для SAST-анализа — компрометированные образы могли попасть в production. Во-вторых, техники TeamPCP уже копируют другие группировки, включая те, что специализируются на российских targets. В-третьих, блокировки GitHub и npm в России создают теневые mirror-репозитории, где такие пакеты могут циркулировать месяцами без обнаружения.

Немедленные действия:
1. Проверить все Checkmarx-образы: docker images | grep checkmarx и сверить с официальными хэшами
2. Аудит GitHub Actions workflows: найти все .github/workflows/ файлы, созданные после марта 2026
3. Ротация всех npm-токенов и GitHub PAT, особенно с repo/workflow scopes

Детекты для SOC:
- Event ID 4688 (Windows): процессы bun.exe с CommandLine содержащим bw1.js
- Sysmon Event ID 1: Image содержит bun и CommandLine содержит node_modules
- Event ID 5156 (Windows Firewall): исходящие соединения на 94.154.172.43:443
- Auditd (Linux): execve syscalls с аргументами gh auth token из npm-процессов

Sigma-правило для GitHub API abuse:

title: Suspicious GitHub Repository Creation Patternlogsource: category: webserverdetection: selection: cs-uri-stem: '/user/repos' cs-method: 'POST' cs-user-agent|contains: 'octokit' keywords: - 'Checkmarx Configuration Storage' - 'gesserit-' - 'melange-'

Network signatures:

- Suricata: alert http any any -> any 443 (msg:"Shai-Hulud C2"; content:"POST"; http_method; content:"/v1/telemetry"; http_uri; sid:1001;)

- Snort: alert tcp any any -> 94.154.172.43 443 (msg:"Shai-Hulud C2 IP"; sid:1002;)

Добавить в мониторинг сегодня:

- Все исходящие HTTPS-соединения от npm/node процессов на нестандартные домены

- Создание файлов в node_modules/.bin/ с исполняемыми правами

- Массовые обращения к cloud secret managers из CI/CD окружений
- GitHub API calls для создания репозиториев с automation tokens

Shai-Hulud 2.0 показывает, что npm превратился в платформу для enterprise-уровневых APT-атак. Группировки больше не ограничиваются кражей данных — они строят persistent backdoors в CI/CD pipelines, которые могут работать месяцами. Следующие 6-12 месяцев покажут, сколько других APT-групп освоят wormable propagation через package managers. Я ожидаю появления аналогичных червей для PyPI, RubyGems и Go modules — техники TeamPCP слишком эффективны, чтобы остаться уникальными. Самое тревожное: если группировка может одновременно компрометировать четыре канала дистрибуции одного вендора, то координированная атака на npm registry целиком — вопрос времени. В @kibergvardiola мы продолжаем отслеживать эволюцию supply chain угроз и их адаптацию под российские реалии.

@kibergvardiola — подписывайтесь, чтобы не пропустить киберважное.

#SupplyChain #npm #Malware #ThreatIntelligence