Привет, Хабр! Меня зовут Антон, я ведущий инженер по ИБ в компании R-Vision, принимаю активное участие в развитии экспертизы в части расследования инцидентов и реагирования на них. А в свободное время я увлекаюсь расследованиями в направлении Digital Forensics & Incident Response (DFIR), Malware Analysis.

В последнее время публичное пространство пестрит новостями о резонансных инцидентах в России и мире, связанных с фишинговыми атаками на крупные компании и государственный сектор.

Замечу, что одной из самых популярных техник взлома крупных мировых корпораций был и остается фишинг с вредоносным вложением T1566.001. Пожалуй, яркий тому пример – взлом Garmin в июле 2020 года, когда известный производитель умных устройств подвергся атаке хакеров-вымогателей. Преступники атаковали системы Garmin с помощью малвари WastedLocker. В результате, сервисы компании на три дня вышли из строя, так как авторы малваря зашифровали данные и требовали выкуп в размере $10 млн за ключи дешифровки.

Как известно, логика подобного проникновения в инфраструктуру довольно проста: атакующие проводят таргетированную фишинговую кампанию – targetor sprear[T1566.001], доставляют в корпоративную среду зловреды с помощью рассылки электронных писем с вредоносными вложениями и ссылками. Пользователь открывает файл (pdf, xlsx, docx и др.), тем самым запуская вложенный туда вредоносный код, который подгружает недостающие для атаки компоненты (вирусы, трояны, шифровальщики, бэкдоры и тд.).

В этой статье я не буду углубляться в тактики и инструменты фишинговых атак, а хочу поделиться с вами личным опытом разбора техники с фишингом вредоносного файла * pdf и наглядно продемонстрировать ход расследования подобного инцидента на примере лабораторного задания GetPDF с ресурса Cyberdefenders.

В предыдущей статье мы рассказали о разновидностях ловушек и приманок. Итак, когда приманки готовы, осталась самая малость - разложить их по нужным хостам. Тут в дело вступает другой критерий выбора Deception-решения, а именно, каким способом доставляются приманки на хосты.

Дисклеймер: В статье частично используются материалы отчета Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems.

Одним из самых резонансных событий конца 2021 года по направлению кибербезопасности стало обнаружение критической уязвимости нулевого дня Log4Shell (CVE-2021-44228), получившей максимальный уровень угрозы — 10 баллов из 10 возможных, что бывает крайне редко. В пиковые дни по данным различных отчетов количество атак с ее использованием достигало десятков тысяч в час во всем мире.

Кратко напомним, что данная уязвимость связана с библиотекой Log4j – инструментом, который используется практически в каждом приложении Java. Log4Shell позволяет получить удаленный доступ и контроль над серверами и веб-приложениями, давая злоумышленнику возможность импортировать в них вредоносное программное обеспечение. Причем для этого хакерам даже не нужно обладать высокой квалификацией. При эксплуатации уязвимости вектор атаки направлен на Public-Facing Application [T1190] и External Remote Services  [T1133]. Выгода для злоумышленников может быть разной, но в большинстве случаев их основная цель – внедрение бэкдоров на серверы с целью дальнейшего заражения вредоносным ПО для кражи данных.

Подробное описание техник и тактик атак, в которых эксплуатировалась Log4shell можно прочитать здесь.

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

Привет, Хабр! Меня зовут Гриша. В компании R-Vision я занимаюсь внедрением наших продуктов, которые, как правило, сопровождаются созданием сопутствующих процессов. Достаточно часто в своей практике я пользуюсь MITRE. В этой статье хочу поделиться своими размышлениями на тему этих самых матриц MITRE и их прикладного использования.

"Золотой стандарт" или что умеют современные Deception-решения: ловушки и приманки. Часть 1

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

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

Привет, меня зовут Марина Чикина. В R-Vision я проджект-менеджер и scrum-master. У нас в компании принято заботиться об эмоциональном состоянии сотрудников: эмоциональное выгорание включили в международную классификацию болезней, и игнорировать тот факт, что мы не роботы, сегодня попросту невозможно. Во многом за этим вопросом следят руководители, но недавно мы дополнительно задумались об использовании превентивных мер и решили попробовать практики коучинга как один из вариантов. Мы вообще всё время что-то пробуем, чтобы улучшить внутренние процессы и атмосферу.

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

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

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

Меня зовут Лера, я инженер нагрузочного тестирования в R-Vision. В апреле у нас в компании стартовала первая стажёрская программа по подготовке специалистов-тестировщиков. Как автору идеи запустить стажировку мне пришлось взять основной удар по подготовке на себя. Но один в поле не воин, и в этом деле мне очень помогал и поддерживал руководитель отдела тестирования, а также коллеги из различных подразделений разработки наших продуктов. Сегодня я расскажу, с чего началась наша стажёрская программа, как она проходила и, главное, — чем завершилась.

Время от времени при исследовании продуктовых идей и гипотез наша команда разрабатывает прототипы. У нас есть мнение, что некоторые из них могут быть полезными ИБ-сообществу. Сегодня мы хотим поделиться моделью для ранжирования индикаторов компрометации, которую реализовали на основе исследования «Scoring model for IoCs by combining open intelligence feeds to reduce false positives» Амстердамского университета. Эта модель решает одну из ключевых задач threat intelligence: ранжирование индикаторов компрометации по ряду параметров для того, чтобы выделить из них наиболее опасные и сузить фокус поиска угроз.

Привет, Хабр! Меня зовут Александр Зинин, я разработчик платформы управления данными киберразведки R-Vision Threat Intelligence Platform (TIP).

В проекте TIP мы используем актуальный стек технологий: React для фронта, Node.js и TypeScript для не особо нагруженного бэкенда, Rust для тех мест, где важна предсказуемость и скорость. В части БД у нас достаточно стандартный набор: PostgreSQL, Redis, RocksDB, ClickHouse.

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

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

Конечно, внутри компаний есть (или должны быть) специально обученные люди, занимающиеся поиском уязвимостей. Но объем таких работ огромен, и увеличивается он ежедневно. Что можно предпринять? Найти нужные «рабочие руки» — всех желающих, кто хочет и может этим заняться, причем за вознаграждение. Так возникла идея Bug Bounty — открытой краудсорсинговой альтернативы внутренней ИБ-службе, реализованной как своего рода мегаконкурс по поиску уязвимостей в программах компаний (разумеется, все это не за бесплатно, хотя есть исключения).

Увы, джентльменам не верят на слово в современном мире, а потому, если вы решили попробовать заработать на bug hunting, придется соблюдать правила игры. В статье я попытаюсь очертить круг возможностей «охотников за ошибками» и расскажу о вариантах участия в программах вознаграждения за найденные ошибки: сторонних платформах Bug Bounty (marketplaces) и программах, спонсируемых компаниями.

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

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

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

Согласно отчету 2021 SANS Cyber Threat Intelligence (CTI) Survey, 66,3% компаний используют открытые источники для сбора индикаторов компрометации и стараются работать одновременно с несколькими источниками. Казалось бы, сбор индикаторов из открытых источников — достаточно простая задача: надо просто скачать с какого-то сайта файлик txt или csv, и всё. В действительности на этом пути можно столкнуться с большим количеством проблем. В статье мы расскажем, что это могут быть за сложности, от чего зависят структура и формат фида, какие метрики помогают оценить полезность фидов, а также покажем на реальном примере, что можно узнать из фида.  Для большей объективности эту статью мы подготовили вместе с Колей Арефьевым из компании RST Cloud, занимающейся агрегацией, обогащением, очисткой и ранжированием индикаторов, публикуемых независимыми ИБ-исследователями.

Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов — MISP и STIX — и целая плеяда менее значимых, которые реже используются или считаются legacy/deprecated: MAEC, IODEF, OpenIOC (Cybox), CAPEC, IODEF, VERIS и множество иных. При этом порядочное количество community-фидов до сих пор распространяется в виде txt или csv, а также в виде человекочитаемых аналитических сводок, бюллетеней и отчетов. 

В статье я разберу более-менее общепринятые практики обмена данными о киберугрозах: специализированные стандарты и форматы общего назначения, предназначенные не только для обмена TI. Какие-то сугубо проприетарные, редкие и «собственные велосипеды» форматов рассматривать не буду. Также пока за бортом оставлю тематические блоги, новостные порталы, сообщества в мессенджерах и иные источники TI в человекочитаемых форматах. Сегодня фокус на машиночитаемых форматах.

Привет! Меня зовут Антон, я владелец продукта R-Vision Threat Intelligence Platform (TIP). От создания первых прототипов решения до реализации пилотных проектов по его внедрению прошло уже более трех лет, и мне захотелось поделиться накопленным опытом и набитыми шишками с сообществом. Поэтому я решил выпустить серию статей по теме threat intelligence, показать, что это понятие действительно существует как практика и как процесс, а не только как модное веяние, принесенное Gartner и витающее в воздухе любой конференции по информационной безопасности.

Рассказывать буду о различных аспектах TI, проведу параллели и аналогии с нашим продуктом и продуктовыми решениями, затрону альтернативные решения, не обойду вниманием и open-source решения. В первом посте поделюсь своим видением того, что представляет собой TI. Поехали!