Тест на фішинг, або Як не потрапити у пастку хакера. Наш експеримент 

Отже, співробітникам не звикати. Але на цей раз головред у листі просив «ознайомитися з важливим документом за посиланням» та суворо дотримуватися цих інструкцій.

Так співпало, що на той час головний редактор якраз був у відпустці. Він не відповідав колегам у загальний чат на питання, чи це від нього лист і що взагалі відбувається. 

Тому колеги вирішили не відкривати посилання та через деякий час просто забули про існування цього звернення.

Після нового року головред не вгамувався. Він знову написав листа журналістам: 

Реакція від колег була миттєвою. Заступниця головного редактора Марія Бровінська запостила скрін із цим листом у загальний чат і написала:

Марія одразу помітила, що це нетиповий лист головреда. І це не може бути він. Бо зазвичай головред наспіх робить багато помилок в українській. А тут прямо все ідеально!

Точно такий саме лист прийшов і бухгалтеру редакції. А цей e-mail взагалі ніде не світився. І було незрозуміло, звідки він у зловмисників.  

І цього разу, і минулого у колег вже не було жодного сумніву, що це пише не Стас Юрасов, а хтось інший.

Наступного дня на планерці Стас розповів, що це дійсно був не він. Але йому було добре відомо про наміри відправника. 

Насправді вони були зовсім не злочинні. Це був тест, перевірка на безпеку, яку провели для редакції фахівці компанії GigaCloud.

І редакція його успішно пройшла. 

А тепер — розбір, чому ніхто не попався і як часто на такому попадаються інші.

Ну і наостанок: корисні рекомендації: що робити, щоб команда не кликала на фішингові листи, а обходила їх десятою дорогою.

Поїхали!

Чому редакцію не вдалося обдурити

Максим (ім’я ми приховали) — керівник інформаційної безпеки хмарного провайдера GigaCloud. Саме він декілька тижнів прокачував поштовий сервер та з неіснуючої поштової адреси [email protected] робив розсилку по редакції. Адреси йому заздалегідь передав Стас. 

Максим розповів, які були труднощі при виконанні цього експерименту:

1. У вас дуже красивий домен (dev.ua). Якщо взяти навіть, наприклад, наш домен — gigacenter.ua, то слово center там пишеться через два «е». Якщо друге «е» прибрати (вийде gigacentr.ua), то, на перший погляд, і не зрозумієш, що це несправжній, підставний домен. «dev.ua як я не крутив — нічого не прибереш», — підкреслює Максим.
2. Домени другого рівня в національних доменах (UA) для зловмисників, які використовують фішинг, — це просто біль і сльози. Бо такий домен можна зареєструвати тільки тоді, коли в тебе є відповідна торговельна марка в Україні.
3. Наступна проблема для фішингової атаки — дуже коротка e-mail адреса головного редактора — [email protected]. Комбінацій для того, щоб зробити подібну фейкову — обмаль. 
4. У вас дуже маленький колектив, усі всіх знають, між собою спілкуються. І якщо навіть якісь підозрілі листи приходять на пошту, то є загальний чат, де одразу починаються обговорення чогось підозрілого. 

Яка є статистика подібного фішингового прийому в цілому

Як каже Максим, 70% співробітників компаній відкривають лист і переходять на подібні посилання. 50% вводять свої облікові дані.

Тобто, КОЖЕН ДРУГИЙ співробітник попадається. 

До речі, сам факт відкриття листа не несе ніякої шкоди для користувача, тільки клік на те, що в нього вкладається, може буди небезпечним.

Яка може бути небезпека за посиланням

Під час переходу за посиланням можуть попросити ввести логін та пароль, наприклад від Google акаунту. «Жертву перекидає на вхідне віконце клієнту. І він навіть не зрозуміє, що передав інформацію комусь не тому», — підкреслює спеціаліст з кібербезпеки GigaCloud. 

І цей логін і пароль, який ввів співробітник компанії, зберігається у базі даних хакера.

Якщо не налаштована двофакторна авторизація, тепер зловмисний може віддалено увійти в систему, подивитися корпоративне та приватне листування, документи, отримати віддалене керування системою.

Доступ до облікових записів також може бути використаний так званими хакерам-шифрувальниками, які блокують доступ до даних жертви та вимагають гроші.

Зловмисники також можуть під’єднати вже заражений комп’ютер до участі у DDOS-атаках.

То що ж робити

Немає такої пілюлі, яка захистить від усього. Найдієвіше — це підвищувати рівень обізнаності в кібербезпеки серед своїх співробітників.

Тому дуже важливо проводити в колективі навчання та тренінги з безпеки та розбирати типові ситуації нападу зловмисників.

1. Саме просте: «Коли тобі пишуть слово „Привіт!“ та водночас не звертаються до тебе по-звичному (Скажімо: „Привіт, Стасе!“), це вже становить підозру», — розповідає Максим.
2. Коли співробітника спонукають щось зробити швидко — це також є ознакою того, що це може бути фішинговий лист.
3. Коли у листі є якісь вкладення, а зазвичай від цієї людини ніяких вкладень у листах не приходило — також підозріло. 

Основне правило: якщо це масова розсилка й у листі вказано багато отримувачів, то скоріш за все це НЕ БУДЕ фішинговий лист.

Бо фішери, як правило, вказують одну адресу жертви для розуміння, з якого ж комп’ютеру надійшов користувач. Бо посилання у фішинговому листі — воно для кожного з них буде персональне.

Як змінився вектор атак під час війни

Атаки під час війни були направлені на держсектор, на медіа та на рітейл і банківський сектор. 

Ось для прикладу два вектори атаки

Перше — незахищений вхід до державних систем

Українське законодавство донедавна забороняло використовувати хмарні технології у держсекторі. Тому у відомих організаціях використовувався так званий on premise exchange server. Як це у загальному працює: ви заходите на свою поштову скриньку через вебзастосунок у браузері, вводите логін і пароль. 

Щоб це працювало не тільки з офісної мережі (а нагадаємо, був карантин і люди працювали з домівок), цей вхід можна було зробити не тільки всередині відомства, а і зовні — через зовнішній IP-адрес.

А через те, що інформаційна безпека у нас ще не на дуже високому рівні, наші вороги шукали дані працівників міністерств у відкритому доступі (наприклад, через електронні декларації). Брали ім’я та прізвище (логін) та підбирали пароль. При чому через браузерну версію блокування спроб не відбувалося після певної кількості невірних спроб. Воно просто було відключено у деяких випадках.

На сучасних хмарних технологіях захист від таких дії зловмисників апріорі встановлений. І такі недоліки у налаштуванні систем безпеки просто відсутні.  

Крім того, є готові рішення в хмарі з віртуальними робочими столами.

Друге — недбалість адмінів.

Коли почалася війна, для адмінів різних компаній і відомств зробили можливість віддаленої роботи. 

Але хтось з них забув свій комп’ютер, хтось не міг виїхати. І адміни почали підключатися до ІТ-інфраструктури з різних пристроїв, які були під рукою.

І тут спрацювали старі закладки (пристрої вже могли бути уражені раніше і зберігали зловредну програму), які на них зберігалися. 

Які можна зробити висновки

1. Фішингова атака, якщо вона добре підготовлена і спрямована безпосередньо на жертву замовника, з великою ймовірністю пройде успішно, не надійтеся на антивірусні та антифродові системи. Адже, в основу такої атаки буде закладатися соціальна інженерія: жертва навіть не помітить, що її обманюють. Сама все видасть.
2. Краща профілактика від фішингових атак — регулярні тренінги з командою. А тим більше зараз, коли співробітники часто працюють у віддаленому режимі, використовуючи некорпоративні гаджети та мережі.    
3. Якщо хтось може професійно подбати про вашу безпеку, то краще не нехтувати цим питанням. Не завжди вдасться відслідкувати дії адмінів, чи співробітників на релокейті. Тому надійна диверсифікована (зберігається у різних ЦОДах) хмара — це мінімум, який треба мати під час війни.

Читайте головні IT-новини країни в нашому Telegram

По темi

Читайте головні IT-новини країни в нашому Telegram