В апреле встречаемся на Alfa CTF!
Пока другие складывают доски, мы запускаем следующий сезон Capture the Flag. Волны принесут новый формат. Что будем делать:
🔴 Исследовать системы и искать флаги
🔴 Решать задачи разного уровня: для профи, новичков и даже школьников (от 14 лет)
🔴 Соревноваться в мастерстве поиска уязвимостей
Скоро расскажем подробно про формат нового запуска: точно будет интересно! Занимайте в своём календаре дату 25 апреля — и регистрируйтесь на нашем сайте.
Go vet не поможет! Статический анализ Golang проектов с помощью PVS-Studio
На нем написан Docker, Kubernetes, Gitea и многие другие проекты самых разных масштабов. Наверное, вы догадались, что речь идёт о Go. Мы никогда не писали об ошибках на Golang проектах, но настало время это исправить, ведь скоро выйдет анализатор PVS-Studio для Go!
Статические анализаторы являются довольно распространёнными инструментами в разработке. В Golang есть встроенный механизм статического анализа — go vet. Однако стандартные линтеры не всегда справляются. Для тех, кто с нами не знаком, мы — компания PVS-Studio, занимаемся разработкой одноименного статического анализатора для C, C++, C# и Java. В последнее время мы активно занимаемся разработкой анализатора для Go и уже скоро планируем выпустить открытую бета-версию.
В новом материале расскажем, какие нашли ошибки в популярных Golang проектах.
Представлен открытый проект Hacking-Tools с набором инструментов, которыми пользуются кибербезопасники и системные администраторы, включая:
Поиск информации: показывает, какие данные о вас и компаниях уже лежат в интернете;
Проверки на уязвимости: находит дыры в сайтах, приложениях и серверах;
Инструменты взлома (для тестов): имитируют атаки, чтобы понять, где всё сломается;
Анализ Wi‑Fi и сетей: проверяют, можно ли перехватить трафик или подключиться без спроса;
Цифровая криминалистика: вытаскивают удалённые файлы, метаданные и следы активности;
Стресс‑тесты: нагружают сайты и сервисы, чтобы проверить нагрузку;
Перехват и анализ трафика: показывают, какие данные гуляют по сети;
Подбор паролей: тестируют, насколько легко взломать слабые комбинации;
Анализ сайтов: ищут скрытые страницы, баги и уязвимый код;
Реверс‑инжиниринг: разбирают программы «по косточкам», чтобы понять, как они работают;
Социальная инженерия: симуляторы фишинга и проверка сотрудников на внимательность.
InfoWatch Traffic Monitor 7.12 сертифицирован в Казахстане
DLP-система InfoWatch Traffic Monitor версии 7.12 получила сертификат по четвертому оценочному уровню доверия (ОУД-4) в Казахстане. В состав сертифицированного комплекса вошли Traffic Monitor, Device Monitor, Data Control, Data Disсоvery и Центр расследований.
Сертификат позволит заказчикам внедрять InfoWatch Traffic Monitor в государственных и коммерческих организациях Казахстана с высокими ИБ-требованиями.
Вебинар 19 февраля начало в 11:00 "Судный день уже наступил. Атаки на промышленность"
Промышленность — лидер по кибератакам: на неё приходится 17% всех инцидентов, опережая банки и госструктуры. Компании сталкиваются с проблемами: конфликт IT/ИБ (обновления vs стабильность), требования Регулятора, работа с инцидентами и ГосСОПКА, контроль угроз от третьих лиц.
Это все отнимает значительное время у служб безопасности.
На вебинаре Тимофей Викулин, разберет кейсы из практики, которые оптимизируют работу ИБ-команд на предприятиях на базе системы SECURITM.
Контроль изменений в инфраструктуре.Покажем ресурсно-сервисную модель для учета, согласования изменений в инфраструктуре, системах и процессах.
Контроль третьих лиц (контрагентов). Автоматизируем учет и контроль задач по предоставлению ресурсов для работ контрагентов.
Оценка соответствия и метрики.Расскажем, как автоматизировать процесс оценки.
Участие бесплатное! Регистрируйтесь!
Продолжаем поддерживать высокие стандарты ГОСТ Р 57580.1-2017 и PCI DSS 4.0 для клиентов К2 Облака
Внешние аудиторы проверили инфраструктуру, процессы и сервисы и подтвердили высокий уровень безопасности К2 Облака по международному стандарту PCI DSS 4.0 и российскому ГОСТ Р 57580.1-2017.
Аудит теперь охватывает и регион в Санкт-Петербурге, а коэффициент соответствия ГОСТ Р 57580.1-2017 вырос с 0,94 до 0,95 по сравнению с прошлым годом — это один из лучших показателей среди публичных облаков в России.
Такой уровень позволяет безопасно переносить критичные финансовые операции в облако. Расширение на Санкт-Петербург открывает для наших клиентов новые возможности по георезервированию облачных инфраструктур.
Русский хакер взломал почту президента Соединенных Штатов Америки Дональда Трампа!
Так могла бы быть озаглавлена статья в каком-нибудь новостном агрегаторе, но, конечно же, это далеко от истины, хотя письма от его имени (с домена POTUS*) я все же могу отправлять. Как такое могло произойти давайте разберем под катом.
Одним из самых распространенных методов обмана людей была и остается рассылка по электронной почте. Еще до индусских колл-центров и служб безопасности банков, в начале нулевых главным средством выманивания денег были африканские e-mail'ы, которые с сожалением сообщали о кончине вашего родственника, но завещавшего вам пару десятков миллионов долларов 🇷🇺.
Со временем, специалисты по ИБ разработали антифишинговые механизмы и ПО, которые блокировали входящую почту по распространенным паттернам, включая подозрительные слова. Именно поэтому, если вы вдруг не знали, фишинговые письма содержат грамматические ошибки - банально чтобы обойти защитные механизмы. Однако сейчас не об этом.
Главными критериями определения легальности письма являются 2 доменные записи: SPF и DMARС (есть еще DKIM, который отвечает за цифровую подпись писем, но о нем как-нибудь в другой раз).
Sender Policy Framework aka SPF — это запись со списком серверов и IP-адресов, с которых разрешается рассылать письма от имени домена. Если письмо пришло с отличного от записанного в SPF айпишника или домена - письмо помечается как подозрительное.
Domain-based Message Authentication, Reporting and Conformance aka DMARC — это политика, которая задаёт сценарий действий с письмами, которые признаны через SPF подозрительными: none - ничего не делать, quarantin - пропускать, но поместить в папку спам, и reject - отклонять.
Соответственно, если у домена в DNS не прописаны SPF и DMARС, то принимаемый mail-сервер не может проверить легальность отправления и не понимает, что с ним делать дальше кроме как пропустить.
Так и случилось в текущем примере: коммерческий домен POTUS.com не имеет соответствующей записи DMARC и любой желающий может отправлять письма от его имени, включая якобы действующего президента 🇺🇸 США.
К счастью, большие почтовые корпорации типа 📧 Google и ❤️ Яндекс, даже при отсутствии или неправильной конфигурации SPF и DMARC, научились отличать фишинг от реального письма. Однако ряд других почтовиков (не будем показывать пальцем) не только пропускают такие письма, но еще и подставляют аватарки (на основе фавиконки с домена), а под письмом пишут, что оно проверено "докторским" антивирусом.
Как же установить, что проверяемый домен подвержен такой атаке? Ранее я пользовался встроенной в Kali утилитой под названием spoofcheck (проверка на спуффинг), но она просто проверяет DNS записи и говорит возможно ли заспуфить проверяемый домен или нет.
Поэтому около года назад я сделал свою утилиту 🧠 HydrAttack PoC eMailSpoofer Module, которая проверяет домен на уязвимость (чекает DNS записи), и если так оно и есть - поднимается майл сервер со всеми необходимыми настройками и отправляется спуффинговое письмо. Особенностью моего ПО является то, что в письмо вложен Excel файл с макросом, который открывает калькулятор.
В общем, за год эксплуатации моя утилита показала свою работоспособность в боевых условиях: и на реальных проектах дала жару, и в рамках Баг Баунти программ от Bi.Zone я также заработал пару тысяч. Поэтому пользуйтесь, но помните, что с большой силой приходит и большая ответственность (с).
🧠 Обязательно поделись с теми, кому это может быть полезно 📱 Телеграм | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
*President of the United States - Президент Соединенных Штатов
Открытые инструменты, которые сканируют Wi‑Fi и Bluetooth‑подключения.
Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.
WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти ВСЕ Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.
MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.
В соцсетях рассказали, как выявить сайт, который продаёт и сливает персональные данные — достаточно при регистрации написать в строке «Отчество» его название.
Кожаным вход запрещён! Что будет дальше с Moltbook?
Разбирая новости и сам проект, анализирую куда всё повернётся. Поделюсь взглядом — он может не оправдаться, воспринимайте это как мой сон.
Обогатятся лишь соратники-основатели. У сервиса своя крипта — впереди байки о «удачливых спекулянтах», стартовавших из развалюхи в глухом городишке, а ныне облюбовавших клочок рая в Карибском море.
Вполне вероятно: Трамп с Маском напишут о ней в соцсетях, взвинтив цену до нескольких десятков миллиардов. Окрестят «гениальным чудом» и «будущим уже сегодня».
Занятнее — впереди. Конкуренты адаптируют концепцию, опубликовав «собственные» версии. Назвав инновационными разработками, но под капотом это лишь перелицованный клон.
Развязка — типичная для крипты: взлёт на ажиотаже («эх, зря не вложился раньше!»). Влиятельные фигуры продадут активы взятые на старте — и моментальный спад.
Биография Мэтта Шлихта спорная. Доступные данные напоминают кейс Элизабет Холмс: от триумфа к краху.
P.S. Поддержать можно подпиской на телегам канал "Инфобез", рассказываю просто про информационную безопасность.
ГК InfoWatch получила лицензию ФСТЭК на создание СЗИ для гостайны
ГК InfoWatch получила лицензию ФСТЭК России на проведение работ, связанных с созданием средств защиты информации, в том числе предназначенных для защиты гостайны.
Лицензия позволяет осуществлять разработку, производство, испытания, ремонт, сервисное обслуживание, установку, монтаж, настройку, наладку и реализацию СЗИ.
До получения новой лицензии компания могла разрабатывать только средства защиты конфиденциальной информации.
MiniFilter и Protector/Rejector (ObCallback) в одном драйвере с управлением через C#
В продолжение этого поста.
Предлагаю вашему внимаю мою поделку основанную на MiniFilter, ObCallback и Avalonia
Можно грабить корованы защищать от закрытия, регулировать доступ к файлам и запрещать запускать процессы.
C# код для управления драйвером:
using System;
using System.Diagnostics;
using Avalonia.Controls;
using Avalonia.Interactivity;
using Avalonia.Threading;
using SharpMiniFilter.Driver.MiniFilter;
using SharpMiniFilter.Driver.Protector;
namespace SharpMiniFilter.Protected;
public partial class MainWindow : Window
{
private bool allowClose = false;
public MainWindow()
{
InitializeComponent();
this.Closing += (sender, args) =>
{
args.Cancel = !allowClose;
if (!args.Cancel)
{
ProtectorClient.ReplaceProtectList(Array.Empty<string>());
ProtectorClient.ReplaceRejectList(Array.Empty<string>());
MiniFilterClient.CloseConnection();
MiniFilterClient.DriverFilter -= DriverClientOnDriverFilter;
}
};
MiniFilterClient.DriverFilter += DriverClientOnDriverFilter;
if (MiniFilterClient.Connect())
{
ProtectorClient.ReplaceProtectList(new[] { $"PID:{Process.GetCurrentProcess().Id}" });
ProtectorClient.ReplaceRejectList(new[] { "*cmd.exe" });
Log_TextBox.Text += "Added current process to protection list." + Environment.NewLine;
Log_TextBox.Text += "Added cmd.exe to reject list." + Environment.NewLine;
}
else
{
Log_TextBox.Text += "Connection to driver failed." + Environment.NewLine;
MiniFilterClient.DriverFilter -= DriverClientOnDriverFilter;
}
}
private void DriverClientOnDriverFilter(MinifilterEventArgs e)
{
Dispatcher.UIThread.Invoke(() =>
{
if (e.Path.Contains("test.txt"))
{
if (!Process.GetProcessById((int)e.ProcessId).ProcessName.ToLower().Contains("notepad"))
{
e.SetHandled(true);
Log_TextBox.Text += "Minifilter: test.txt blocked" + Environment.NewLine;
}
else
{
e.SetHandled(false);
Log_TextBox.Text += "Minifilter: test.txt not blocked for notepad.exe" + Environment.NewLine;
}
}
});
}
private void Button_OnClick(object? sender, RoutedEventArgs e)
{
allowClose = true;
this.Close();
}
}Бонусом - создание .cab файла для отправки в Microsoft на сертификацию при Release сборке.
Ссылка на репозиторий.
P.S. Если вам будет интересно, а у меня силы и карма - то расскажу, что там и как в отдельной статье. А теперь и ответ на всех мучающий вопрос: "Почему пингвин пошёл в горы?"
Тихий враг или молчаливый союзник: коротко о выравнивании в C++. Часть 2
Казалось бы, тайна выравнивания раскрыта. Вы победили невидимого врага — невыровненный доступ. Память под контролем, но производительность по-прежнему шепчет: "Есть ещё нюансы". Что? Нюансы? Какие? Пришло время посмотреть, что происходит, когда структуры начинают наследовать друг друга. Здесь всё становится... интереснее. Правила игры меняются.
Итак, путь ясен: мы погружаемся в мир наследования, чтобы услышать его диалог с памятью. Давайте сразу к делу. Приготовьтесь, правила только что усложнились. В статье поговорим о выравнивании, наследовании POD-структур и множественном наследовании.
Открытый инструмент OSINT‑разведки под названием TGSpyder парсит из Telegram: аудио, видео, участников, их ID, логины и даже номера телефонов, если те открыты. Сервис помогает выкачать историю сообщений даже из закрытых чатов и все пригласительные ссылки. Ищет юзеров по ID и логинам. Собирает все данные в один CSV‑файл и выдаёт в удобном виде. Работает ограничений и не нарушает правила мессенджера.
О поддержке opensource - как показателе безопасности
Случались ситуации, когда компании использовали open source, который перестал развиваться. И в этом open source находили уязвимости. Итог: компаниям сложно ликвидировать уязвимости в используемом open source. По этой причине рождались предложения: дабы не попасть в такую ситуацию - при выборе open source проверять, что проект ещё поддерживается. Мысль здравая. Но, и тут могут быть нюансы. Пример - проект JasperReports (для Java). Судя по репозиторию - проект поддерживается. 16 сентября 2025 была опубликована информация об уязвимости в проекте (критического уровня: 9.8 по шкале CVSS v3.1 - CVE-2025-10492). А 19 сентября 2025 разработчик сообщил, что фикс выйдет только для коммерческой версии.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++
Представьте, ваша программа — образец чистого кода, прошедший ревью и покрытый тестами. Казалось бы, всё идеально. Но производительность не такая, на какую рассчитывали. Вы проверили всё, что знали. А что, если проблема в том, о чём вы могли не знать? Всё может упираться в выравнивание данных в памяти. Для многих этот механизм так и остаётся загадкой.
Предлагаю вам вместе попробовать разобраться в такой непростой теме в этой статье.
Проверьте своих близких. Как WB оформляет «кредиты Шрёдингера» (есть в чеке, нет в БКИ) под 85% годовых
Не успел я отдохнуть после статьи о Femida Search , так напоролся на новое приключение.
Саммари:
Если вы поставили пожилым родственникам полный самозапрет на кредиты через Госуслуги (ФЗ-31), это не гарантирует защиту от рассрочек на маркетплейсах. @WILDBERRIES через прокладку «ООО Престо» выдает деньги, игнорируя записи в БКИ.
Поэтому я сейчас готовлю расследование с разбором чеков, оферт и, надеюсь, ответов ЦБ и ФНС, но ситуация требует предупредить сообщество прямо сейчас.
Дано:
Мама-пенсионер (70 лет).
Активный полный самозапрет на кредитование в БКИ, установленный ещё в марте 2025 через Госуслуги.
Покупка товаров на Wildberries в январе 2026.
Что произошло:
При заказе был «случайно» (темные паттерны UI) активирован способ оплаты «Оплата частями». В итоге:
Товар подменили (вместо Селена прислали Хром, который опасен при применении с препаратами для понижения сахара в крови при диабете). Ну эт ладно, не главное.
На сумму 4 600 руб. накрутили «комиссию» 1 175 руб. (эффективная ставка ~85% годовых!!).
Я был уверен, что полный самозапрет в БКИ отсечет любые попытки выдать кредит. Но схема WB и их партнера ООО «Престо» работает вот так:
В оферте это называется «Договор поручения» (агентская схема, BNPL), якобы чтобы не попадать под регулирование ЦБ.
Но в кассовом чеке (ФНС) в теге 1214 («Признак способа расчета») прямым текстом стоит: «ПЕРЕДАЧА В КРЕДИТ» и «ОПЛАТА КРЕДИТА».
Самое забавное: В кредитной истории (БКИ) этот долг не отображается.
Они выдали «теневой кредит». Если бы они сделали запрос в БКИ (как обязаны по закону и как обещают в своем же договоре), они получили бы отказ из-за самозапрета. Поэтому они просто не делают запрос, но в чеке пишут «Кредит», чтобы легализовать деньги перед налоговой.
Что делать прямо сейчас: Зайдите в приложения Wildberries своих родителей/родственников:
Проверьте раздел «Покупки» -> «Чеки». Ищите чеки от ООО «Престо».
Если видите там слова «Комиссия сервиса» и «В КРЕДИТ» — знайте, это не просто рассрочка, это кредитный продукт, который может висеть «мимо» БКИ. Сохраните все чеки себе на комп, чтобы их не подменили задним числом!
Проверьте, не подключена ли у них «Оплата частями» без их ведома.
P.S. Я уже направил досудебные претензии и жалобу в ЦБ РФ с требованием проверить лицензию данного финтеха. И я заархивировал все доказательства. Полный технический и юридический разбор этой схемы («Кредит Шрёдингера») с комментариями юристов опубликую на Хабре через несколько дней, как только получу (или не получу) официальные ответы.
Берегите родителей, ребята!
Upd (2026-02-09). Текст моей статьи готов, сейчас его проверяют юристы. Полную версию я опубликую на своём сайте (66 минут чтения), а на Хабре более ужатую, чтобы люди хоть могли прочитать.
Upd (2026-02-17) Полная версия статьи готова. Её младшая версия тоже.
Вебинар: Что ждет Службы ИБ в 2026 году. Главные тренды и вызовы
5 февраля в 11:00
В 2025 году атаки участились, регуляторы ужесточились, и многие службы до сих пор тонут в рутине — сборе доказательств, отчетах, контроле уязвимостей — и не успевают анализировать реальные угрозы.
Приглашаем на вебинар с практиками и экспертами отрасли. Разберём не только тренды, но и конкретные шаги для адаптации вашей ИБ-стратегии.
💬 Приглашенные гости:
Николай Казанцев, CEO SECURITM
Лука Сафонов, бизнес-партнёр ГК "Гарда"
Александр Суслов, CISO ГК "Регион"
На вебинаре ответим на ключевые вопросы:
Итоги 2025: главные уроки для ИБ-специалистов. Что устарело, а что стало критически важным?
Тренды 2026: куда движется рынок? Почему SOC, Managed Security и SGRC растут быстрее рынка и как это использовать?
Импортозамещение vs. Безопасность: как выбирать и тестировать российские решения без потери в защищённости?
Финансы и аргументы: как обосновать инвестиции в ИБ руководству? На какие метрики и KPI делать упор в 2026?
ИИ: защита или угроза? Как применять искусственный интеллект, не создавая новых уязвимостей?
Регистрируйтесь прямо сейчас!
Топ-3 популярных заблуждения про NTA и NDR
Многие до сих пор думают, что NTA ‒ это просто «продвинутый IDS», а NDR вообще не работает без полного дампа трафика. Кто-то считает, что NDR ‒ это функция песочницы, а кто-то уверен, что NTA не может работать на базе NetFlow. В реальности дела обстоят несколько иначе.
Мы подготовили видео, в котором Станислав Грибанов, руководитель продукта «Гарда NDR» компании «Гарда», автор блога «Кибербезопасность и продуктовая экспертиза для бизнеса», развенчивает три ключевых мифа про NTA и NDR.
Рекомендуем видео к просмотру всем, кто хочет понять, чем NDR отличается от традиционных средств защиты и когда он действительно нужен.
Еще больше видео о технологиях и трендах в сфере информационной безопасности ‒ на нашей странице «ВКонтакте» и на сайте.
Требования по регистрации событий ИБ часто выглядят формально и обобщенно. Но именно здесь во внедрении возникает больше всего вопросов, рисков и договоренностей, которые важно зафиксировать заранее.
Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.
Почему регистрация событий ИБ — это всегда вызов
Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой.
Звучит просто, но в реальности возникает множество проблем:
требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;
невыполнение требований ИБ может заблокировать весь проект;
нет универсальной базы — нормативные документы дают общее направление, а у каждого заказчика есть свои внутренние требования и особенности.
Откуда берутся требования
Во внедрении я сталкиваюсь сразу с несколькими источниками:
требования по защите персональных данных — например, приказ ФСТЭК № 21;
документы регуляторов с описанием инцидентов и состава событий;
отдельные требования финансовых организаций;
внутренние документы заказчика, к которым не всегда есть доступ;
особые режимы — государственные информационные системы, требования, которые важно учитывать еще на этапе пресейла.
Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.
Как я структурирую требования по событиям ИБ
Чтобы работать с этим массивом, я условно делю требования на четыре группы.
Общие требования
Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.
Общий перечень событий
Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.
Состав полей события безопасности
Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?
Мониторинг и передача в SIEM-систему
Даже здесь возникают сложности — неподдерживаемые протоколы, требования к формату полей и событий, особенности интеграции. Формулировки должны быть максимально точными.
Что я вынесла из практики
Требования в ТЗ — это только часть картины, всегда нужно копать глубже.
Требования меняются по ходу проекта и это нормально.
Все договоренности важно фиксировать письменно.
Нужно учитывать не только нормативные документы, но и локальные требования заказчика.
Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.
Важно заранее договориться, кто и сколько хранит логи.
→ Подробнее своим опытом Лиза поделилась в статье.