Everest Ransomware вніс Capgemini Engineering до списку жертв: заява непідтверджена

Що заявив Everest Ransomware про Capgemini Engineering

Група програм-вимагачів Everest додала Capgemini Engineering до свого сайту витоку, публічно назвавши постачальника інженерних і технологічних послуг жертвою. Як це зазвичай буває з такими списками, заява була опублікована без незалежно перевірних доказів, без підтвердженого зразка викрадених файлів, без доказів шифрування внутрішніх систем і без жодного підтвердження з боку самої Capgemini Engineering на момент написання матеріалу.

Саме так працює більшість списків груп програм-вимагачів. Ім'я з'являється на даркнет-сайті витоку, іноді з таймером зворотного відліку чи розмитим описом «викрадених даних», а решта історії залишається на здогади, доки компанія не підтвердить інцидент або група не опублікує докази на підтримку своєї заяви. У цьому випадку таких доказів не з'явилося.

Чому заява залишається непідтвердженою

Дослідники безпеки, які моніторять список, не знайшли жодних ознак, що підтверджували б компрометацію систем Capgemini Engineering. Немає підтвердженої події шифрування, немає перевіреного зразка даних і немає заяви компанії про визнання витоку. Аналітичні платформи загроз, які фіксують заяви програм-вимагачів, позначили цю як одноджерельну, тобто вона повністю походить із публікації на власному сайті витоку Everest, а не з будь-якого незалежного підтвердження.

Ця відмінність важлива. Групи програм-вимагачів регулярно вносять організації до списків як тактику тиску, іноді ще до фактичного завершення вторгнення, а іноді взагалі без жодного зламу компанії. Список — це заява, а не підтверджений інцидент. Поки Capgemini Engineering або довірена третя сторона не перевірить деталі, правильна позиція — обережний скептицизм, а не паніка.

Як групи програм-вимагачів використовують непідтверджені витоки як тактику тиску

Everest далеко не єдина група, яка покладається на публічний осуд як важіль впливу. Внесення назви компанії до сайту витоку генерує заголовки, медіа-висвітлення та репутаційну тривогу задовго до того, як будь-які дані фактично перевірять або опублікують. Сама ця увага може бути цінною для зловмисників, оскільки посилює тиск на названу організацію, щоб вона тихо заплатила викуп, а не ризикувала тривалим розголосом.

Ця схема вже проявлялася в інших нещодавніх випадках, пов'язаних із тією ж групою. Everest раніше націлювався на індійську технологічну фірму Greenbotz, погрожуючи опублікувати викрадені дані, якщо вимоги не буде виконано, — це внесення до списку повторювало подібний сценарій публічних заяв до повної верифікації. Інші групи програм-вимагачів і вимагачів використовують схожі тактики; наприклад, заявлена атака групи Direwolf на Statista GmbH мала ту саму базову структуру: публічна заява, обмежені початкові докази та компанія, яка змушена реагувати під публічним тиском.

Висновок не в тому, що такі заяви слід відкидати повністю, а в тому, що їх слід вважати непідтвердженими, доки не доведено протилежне. Реакція з панікою до встановлення фактів лише посилює саму тактику вимагання.

Що бізнесу та клієнтам слід робити для перевірки безпеки постачальників

Для компаній, які працюють із великими інженерними, IT- чи консалтинговими фірмами, як-от Capgemini Engineering, непідтверджена заява програм-вимагачів усе одно є корисним приводом переглянути практики безпеки постачальників, навіть якщо цей конкретний список виявиться безпідставним. Кілька практичних кроків мають сенс незалежно від того, як завершиться ця конкретна справа:

• Прямо запитайте постачальників про їхній процес реагування на інциденти та про те, як вони повідомляють про підтверджені витоки на відміну від непідтверджених заяв.
• Перегляньте договірні формулювання щодо термінів повідомлення про виток даних і вимог до доказів.
• Підтвердьте, які категорії ваших даних постачальник фактично зберігає або до яких має доступ, щоб ви могли оцінити реальний рівень впливу, якщо заяву пізніше підтвердять.
• Слідкуйте за джерелами аналітики загроз і трекерами сайтів витоку програм-вимагачів для отримання оновлень, а не покладайтеся лише на новинні заголовки.

Що це означає для вас

Якщо ваша організація працює з Capgemini Engineering або будь-яким подібним великим постачальником, немає потреби вживати радикальних заходів на основі лише цього списку. Жодне шифрування, ексфільтрація чи витік даних не підтверджені. Тим не менш, це гарна нагода перевірити власний процес управління ризиками постачальників: чи знаєте ви, як швидко партнер повідомить вас, якщо виток буде підтверджено, і чи маєте ви уявлення про те, які дані вони зберігають від вашого імені?

Ширший урок із заяви про Capgemini Engineering стосується менше цього окремого інциденту, а більше того, як діють групи програм-вимагачів. Публічні списки на сайтах витоку створені, щоб викликати відчуття терміновості та репутаційний тиск, незалежно від того, чи стався фактичний злам. Вважати кожну заяву підтвердженим фактом — це гра на руку цій стратегії; вважати кожну заяву автоматично хибною — ігнорувати реальний ризик. Відповідальна середина — це верифікація перед реакцією.

Ключові висновки

• Програма-вимагач Everest вніс Capgemini Engineering до списку жертв, але жодних незалежних доказів шифрування чи викрадення даних немає.
• Заява наразі є одноджерельною — походить виключно з власного сайту витоку групи, що є типовою схемою в тактиці вимагання програм-вимагачів.
• Подібні непідтверджені або ранні заяви з'являлися й щодо інших компаній, зокрема Greenbotz і Statista GmbH, за подібними сценаріями.
• Бізнесу слід використовувати такі моменти, щоб переглянути зобов'язання постачальників щодо реагування на інциденти та обсяг доступу до даних, а не чекати підтвердженого витоку, щоб ставити складні запитання.
• Стежте за оновленнями через надійні джерела аналітики загроз, а не реагуйте лише на публікації на сайтах витоку.