«Зато не скучно!» — так звучит неформальный девиз сотрудников нашего центра мониторинга киберугроз Solar JSOC (и надо сказать, 2019 год полностью ему соответствовал). В начале нового года многие любят подводить итоги и ставить новые цели, но мы решили вместо этого рассказать несколько «ужасов нашего городка» – кейсов 2019 года, которые впечатлили даже видавших виды аналитиков. Вывод же из этих историй только один: технологии развиваются и эволюционируют, а человеческая лень, халатность и безалаберность вечны.

Продолжим разговор за интересные случаи в работе пентестеров. В прошлом посте речь шла о внешних тестированиях на проникновение, сегодня же расскажем о наиболее занимательных внутренних пентестах, реализованных нами за последнее время. Суть их в том, что мы должны были, находясь во внутреннем периметре заказчика, получить максимальные привилегии в домене и добраться до каких-либо важных данных. Случалось удивляться. Но обо всем по порядку.

Продолжаем цикл статей о Security Awareness или, выражаясь простым языком, об обучении своих сотрудников противодействию фишинговым атакам. Часто такое обучение реализуется на коленке, но по-настоящему эффективным оно может быть только если перерастает в полноценный комплексный процесс на уровне всей организации. С регулярными письмами счастья (а также жадности, тревоги, любопытства и прочих атрибутов фишинга). О том, как мы это себе представляем и как уже реализуем, рассказываем под катом.

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

Всем привет!

Для тех, кто мечтает стать Senior Developer и готов присоединиться к крутой команде Scala-разработчиков, с 1 по 15 декабря 2019 года мы запускаем отбор на бесплатный курс по обучению Scala. По окончании обучения пятеро лучших стажеров смогут присоединиться к самой солнечной в мире команде.



Подробности — под катом.

Пока большой Enterprise выстраивает эшелонированные редуты от потенциальных внутренних злоумышленников и хакеров, для компаний попроще головной болью остаются фишинговые и спам-рассылки. Если бы Марти Макфлай знал, что в 2015 году (а уж тем более в 2020) люди не то что не изобретут ховерборды, но даже не научатся полностью избавляться от нежелательной почты, он бы, наверное, потерял веру в человечество. Более того, спам сегодня не просто назойлив, но часто и вредоносен. Примерно в 70% случаев в ходе реализации killchain киберпреступники проникают в инфраструктуру с помощью вредоносного ПО, содержащегося во вложениях, или через фишинговые ссылки в электронных письмах.

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

Публикуем интервью с Владимиром Карантаевым, руководителем рабочей группы CIGRE по вопросам кибербезопасности (Implementation of Security Operations Centers in Electric Power Industry as Part of Situational Awareness System), руководителем направления кибербезопасности АСУ ТП компании «Ростелеком-Солар», — о трендах атак на сегменты АСУ ТП, архитектурных проблемах в безопасности промышленного интернета вещей, программе «Цифровая экономика» и необходимых шагах для защиты промышленных предприятий от киберугроз.

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



Нам интересно и ваше мнение по поводу каждого из них, поэтому ждем ваших комментариев. Добро пожаловать под кат.

Тема блокчейна не перестает быть источником не только всяческого хайпа, но и весьма ценных с технологической точки зрения идей. Посему не обошла она стороной и жителей солнечного города. Присматриваются люди, изучают, пытаются переложить свою экспертизу в традиционном инфобезе на блокчейн-системы. Пока что точечно: одна из разработок «Ростелеком-Солар» умеет проверять безопасность софта на базе блокчейна. А попутно возникают некоторые мысли по решению прикладных задач блокчейн-сообщества. Одним из таких лайфхаков – как определить адрес смарт-контракта до деплоя с помощью CREATE2 – сегодня хочу с вами поделиться под катом.

Тематика искусственного интеллекта, зародившаяся еще в 60-х годах, сейчас переживает просто сумасшедший бум. Компьютеры обыгрывают шахматистов и поклонников Го, порой точнее врача ставят диагнозы, нейронные сети (на этот раз не имеющие отношения к умам трех инженеров техподдержки) всерьез пытаются решать сложные прикладные задачи, а где-то там на горизонте уже маячит универсальный искусственный интеллект, который когда-нибудь заменит своего прикладного сородича.



Информационная безопасность тоже не остается за границами хайпа вокруг ИИ (или его эволюции — тут уж каждый решает для себя). Все чаще мы слышим о необходимых подходах, прорабатываемых решениях и даже (иногда робко и неуверенно, а иногда громко и, к сожалению, не очень правдоподобно) о первых практических успехах в данной области. Говорить за все ИБ мы, конечно, не возьмемся, но попробуем разобраться, каковы реальные возможности применения ИИ в профильном для нас направлении SOC (Security Operations Center). Кого заинтересовала тема или просто хочется пофлеймить в комментариях — добро пожаловать под кат.

Вчера появилась информация о попытках эксплуатации BlueKeep (CVE-2019-0708), критичной RCE-уязвимости в ОС Windows, с целью установки криптомайнера Monero. Исследователь Kevin Beamount, сообщил в Твиттере, что несколько хостов из его сети RDP-ханипотов ушли в состоянии BSOD, при этом их совокупный Uptime до этого момента был равен почти 6 месяцам.

Проведенный анализ аварийного дампа оперативной памяти позволил обнаружить следы
шелл-кода, предназначенного для скачивания и запуска криптомайнера с удаленного сервера посредством выполнения powershell-скрипта. При этом этот шелл-код идентичен шелл-коду модуля BlueKeep в составе проекта Metasploit.

В процессе работы нам часто задают вопрос: как внедрить статический анализатор в разработку, чтобы всё всем было хорошо. О том, почему для безопасной разработки необходим статический анализатор, мы уже рассказывали. Эта статья будет полезна, если вы выбираете статический анализатор или уже собираетесь его внедрять. Как наладить процесс, чтобы обнаруженные в коде уязвимости стали наконец исправляться? В этой статье мы попробуем помочь вам разобраться с этим вопросом.

Мы в JSOC CERT ежедневно сталкиваемся с событиями из разных песочниц, которые функционируют в составе AntiAPT-решений наших заказчиков и пропускают через себя тысячи файлов из web- и почтового трафика. Стоит отметить, что современные Sandbox-системы в своем развитии ушли намного дальше, чем простой перехват системных вызовов в Kernel Mode и API-функций в User Mode. Все чаще в них используются собственный гипервизор, система эмуляции пользовательской активности, динамическая инструментация, хэширование и кластеризация по участкам кода, анализ покрытия кода и т.д. Такое разнообразие технологий создает иллюзию, что если какой-то файл не отработал в песочнице и не показал свое «истинное лицо», то это наверняка APT или инновационная технология обнаружения виртуального окружения, о котором ИБ-сообществу еще не известно. Но…

Рассказывая о том, как устроена работа центра мониторинга и реагирования на кибератаки (SOC) изнутри, мы уже говорили об инженерах первой и второй линии и об аналитиках. Тогда же мы вскользь упомянули о сервис-менеджерах. Это сотрудники SOC, которые отвечают перед заказчиком за качество оказываемых услуг. За этим коротким определением фактически скрывается следующее: сервис-менеджер определяет практическую реализацию сервиса на площадке заказчика, должен быть готов в любой момент дня и ночи ответить на звонок заказчика или уведомление инженера мониторинга о критичном инциденте, собрать команду реагирования или расследования и выехать на площадку.

В большинстве своем сервис-менеджеры Solar JSOC — это мужчины в возрасте за 30 видавшие виды с разносторонним опытом в ИБ: от проектирования систем защиты информации до аудита процессов. Обязательно владение навыками перевода с птичьего на человеческий технического на бизнесовый и обратно.

Если ваша компания передаёт или получает по сети персданные и другую конфиденциальную информацию, подлежащую защите в соответствии с законодательством, требуется применять шифрование по ГОСТу. Сегодня мы расскажем, как внедрили такое шифрование на базе криптошлюза (КШ) S-Terra у одного из заказчиков. Эта история будет интересна ИБ-специалистам, а также инженерам, проектировщикам и архитекторам. Глубоко погружаться в нюансы технической конфигурации в данном посте мы не будем — остановимся на ключевых моментах базовой настройки. Огромные объемы документации по настройке демонов ОС Linux, на которой базируется КШ S-Terra, есть в свободном доступе в интернете. Документация по настройке проприетарного ПО S-Terra располагается также в открытом доступе на портале производителя.

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

Наверно, все SOC-аналитики спят и видят, как их детектирующие правила отлавливают модные техники проправительственных APT-группировок, а расследования приводят к обнаружению эксплойтов для zero-day уязвимостей. К сожалению (или к счастью), большая часть инцидентов, с которыми приходиться сталкиваться среднему специалисту по реагированию, намного менее романтичны: использование непереименованных PsExec’ов для распространения, классических методов обхода UAC для повышения привилегий и огромное количество уязвимостей, для которых давно выпущены заплатки.



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

С начала сегодняшнего дня и по настоящее время эксперты JSOC CERT фиксируют массовую вредоносную рассылку вируса-шифровальщика Troldesh. Его функциональность шире, чем просто у шифровальщика: помимо модуля шифрования в нем есть возможность удаленного управления рабочей станцией и дозагрузки дополнительных модулей. В марте этого года мы уже информировали об эпидемии Troldesh — тогда вирус маскировал свою доставку с помощью IoT-устройств. Теперь же для этого используются уязвимые версии WordPress и интерфейса cgi-bin.

Эта статья пригодится тем, кто работает в компании, признанной субъектом критической информационной инфраструктуры (КИИ), а значит — обязанной выполнить требования №187-ФЗ и построить центр ГосСОПКА (Государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак), соответствующий требованиям ФСБ России.

В прошлой статье мы затронули самые основы этой темы и рассказали о требованиях ФСБ к техническим средствам, которые должны использоваться в центре ГосСОПКА. Однако эти требования (едва ли не впервые) распространяются не только на технические средства защиты, но и на реализацию конкретных процессов мониторинга, реагирования и расследования инцидентов ИБ. Поэтому сегодня мы расскажем о том, какие кадровые ресурсы вам понадобятся, чтобы все эти процессы обеспечить.

Многие центры безопасности смыслом своей работы, а то и жизни делают борьбу с хакерами и атаками. Дело действительно важное и интеллектуально очень емкое. Исследуем данные Threat Intelligence, собираем атрибуцию на группировки и её TTP (tactics, techniques and procedures), разрабатываем отдельные сценарии и правила выявления инцидентов, внедряем мощные технологические решения. Это огромный и важный кусок работы любой команды по безопасности, а уж тем более любого зрелого SOC.



Но периодически все классические подходы к безопасности через мониторинг просто умножаются на ноль, когда в жизнь приходит большая и неприятная массовая атака. Та самая, о которой узнаёт даже ваша бабушка. Условно назовем такую атаку медиакиберпандемией, чтобы не путать с регулярными рассылками Cobalt или хитрыми инструментами Silence (для бывалых они уже стали чем-то вроде белого шума). Речь о Heartbleed, Shellshock, WannaСry, уязвимости в оборудовании Cisco и прочих. Что их отличает от прочих кибердиверсий? Как в этом случае стоит (или не стоит) вести себя SOC и просто ИБ-службе компании? Давайте разбираться под катом.