Розслідування інциденту ІБ по гарячих слідах

1. Зміст статті бекграунд
2. ТТХ
3. інцидент
4. Аналіз логів OWA
5. слід знайдено
6. Як захистити свій iDevice
7. вердикт

Зміст статті

бекграунд

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

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

ТТХ

Компанія N досить прогресивна в своїй сфері, тому внутрішнє забезпечення служби ІТ на висоті: хороші засоби комунікації, сучасне обладнання, пристойні зарплати. Свого часу була створена служба безпеки, яка займається питаннями інформаційної, економічної та фізичної безпеки. Запрошений підрядник допоміг побудувати захищену ІТ-інфраструктуру і ввести режим комерційної таємниці.

IT-інфраструктура являє собою наступне:

• сервери розташовуються в демілітаризованій зоні, доступ по мережі в ДМЗ обмежується міжмережевими екранами;
• повсюдно введена віртуалізація серверів;
• присутній сегментація мережі з обмеженням доступу між сегментами. Робочі станції рознесені по VLAN'ам, з фільтрацією трафіку між ними, відповідно до внутрішньої ієрархією;
• права доступу користувачам виділяються за принципом мінімальних привілеїв;
• централізовано софт оновлюється тільки для продуктів Microsoft;
• ведеться централізований моніторинг серверів, правда, в основному з позиції доступності.

інцидент

На початку року кістяк топ-менеджменту компанії N відправився на корпоративний виїзд в далекі країни. Поїздка передбачала не тільки розваги, а й робочі моменти, проте їм не судилося відбутися: матеріал, який планували презентувати і обговорити по-сучасному - з мобільного планшета, був загублений.

Прекрасне сонячний ранок запаморочилось: смартфони та планшети всіх присутніх в готелі на березі океану (і не тільки їх) виявилися невинно чисті.

Дана інформація була доведена до служби безпеки, яка розумно припустила, що тут не обійшлося без зовнішнього втручання. Очевидно, що у всіх відразу акаунти iCloud зламати не могли, і служба безпеки запідозрила, що загроза виходить з корпоративної мережі. Віддалено очистити мобільні пристрої можна тільки через відповідний сервіс, наприклад через корпоративний сервер Microsoft Exchange. Команда, що дозволяє очистити пристрій користувача з адресою [email protected], виглядає наступним чином:

Clear-MobileDevice -Identity WM_TonySmith -NotificationEmailAddresses "[email protected]" Віддалений вайп через веб-інтерфейс адміністратора OWA

ІТ-службі поставили завдання перевірити журнали сервера OWA: чи не було підозрілої активності щодо акаунтів постраждалих і компрометації пароля адміністратора сервера MS Exchange. Адміністратори виявили зачіпку - доступ до акаунтів постраждалих в попередні інциденту дні неодноразово здійснювався з декількох нетипових для них IP-адрес. Як я пізніше з'ясував, засвічені IP-адреси були вихідними Tor-нодамі.

Аналіз логів OWA

Список OWA зберігаються за замовчуванням в% SystemRoot% \ System32 \ logfiles \ w3svc1. Структура логів - звичайні текстові файли, вивчати які без допоміжного інструменту, особливо при великій кількості користувачів, втомлює. На допомогу прийде Log Parser - дуже цінний інструмент, який стане в нагоді не тільки в подібній ситуації.

Для зручності перетворимо всі наявні логи в один файл формату CSV:

c: \ Program Files \ Log Parser 2.2> LogParser.exe -i: iisw3c "select * into d: \ temp \ alllog.log from% SystemRoot% \ System32 \ logfiles \ w3svc1 \ *" -o: csv

Після чого складемо список подій, що відображають доступ користувачів до OWA:

c: \ Program Files \ Log Parser 2.2> LogParser.exe -i: csv "select cs-username, date, time, c-ip, cs-uri-stem, cs (User-Agent) FROM d: \ temp \ alllog .log to d: \ temp \ access.csv "-o: csv

З'ясовуємо, хто звертався до функцій OWA, що відповідає за видалення даних з пристрою:

c: \ Program Files \ Log Parser 2.2> LogParser.exe -i: csv "select cs-username, date, time, c-ip, cs-uri-stem, cs-uri-query, cs (User-Agent) FROM d: \ temp \ alllog.log to d: \ temp \ access2.csv WHERE cs-uri-query LIKE '% wipe%' "-o: csv Список OWA

Судячи з системним логам, аккаунт адміністратора сервера OWA скомпрометований не був. Цілий день адміни читали логи серверів, а служба безпеки тим часом розмовляла з усіма адміністраторами по черзі, припускаючи, що диверсант всередині компанії. Однак це ні до чого не привело. Тоді вони звернулися по старому знайомству до мене.

Поставили вони такі завдання:

• встановити джерело загрози - внутрішній або зовнішній;
• з'ясувати сценарій атаки;
• визначити наслідки - скомпрометовані акаунти і системи;
• визначити подальші дії для ліквідації загрози.

Опинившись на місці, я опитав ІТ-персонал. За підсумками склав схему мережі, визначив розташування серверів і сервісів, зібрав інформацію про використовувані операційних системах, налаштування міжмережевих екранів, пральний політиці, політиці поновлення софта, персональних зонах відповідальності адміністраторів.

Перевірив ще раз результати аналізу логів адміністраторами. За допомогою ntfswalk проаналізував MFT на наявність віддалених останнім часом файлів. Сервер OWA був чистий і незайманий.

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

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

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

Інтерфейс R-Studio

Так як у мене в дослідженні були тільки образи віртуальних машин, процедура кілька спрощувалася - не потрібно витрачати час на зняття образів жорсткого диска і оперативної пам'яті. Файли жорстких дисків віртуальних машин можна або конвертувати в raw, або монтувати як є, за допомогою відповідних утиліт. Образ RAM і файл збереженого стану можна конвертувати в «сирий» образ. Не варто забувати і про файли підкачки - в них теж часом знаходиться багато цікавого. Volatility версії 2.3 вміє все це розбирати і конвертувати в разі потреби.

Відмінності роботи з фізичної системою від віртуальної в тому, що образ пам'яті дістати складніше - це пов'язано з ризиком пошкодити поточний стан і втратити дані, які можуть виявитися істотними. Також при дослідженні фізичної системи необхідно застосовувати додаткові інструменти і методики для визначення прихованих областей (наприклад, Host Protected Area - HPA і Device Configuration Overlay - DCO).

Обстежити Windows-машини в моєму випадку я вирішив за наступним сценарієм:

1. Визначити, які файли і їх атрибути піддавалися модифікації (створювалися, відкривалися, редагувалися, віддалялися). Для цього я використовую інструментntfswalk або logparser. Наприклад, командою: c: \ Program Files (x86) \ Log Parser 2.2 \ LogParser.exe "-i: FS -o: CSV -preserveLastAccTime: ON" Select HASHMD5_FILE (Path), CreationTime, LastWriteTime, LastAccessTime, Name, Path, Size into 'D: \ FileTreeFD.csv' From 'Y: \ *. *'

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

   Вивчення атрибутів файлів

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

2. Необхідно визначити, підключалися чи зовнішні носії. У реєстрі завжди залишається запис про підключення нового пристрою. В логах System.evtx за замовчуванням зберігається запис c ID 20001. Для роботи з логами є відповідні утиліти, наприклад Windows USB Storage Parser. Цей кейс розглядається на випадок, якщо ми маємо справу з внутрішнім порушником, який просто закинув необхідний інструментарій з флешки, скопіював що потрібно і забрав додому для подальшої роботи.
3. Необхідно простежити, щодо яких облікових записів домену відбувалися такі події: вхід, вихід, зміна пароля, груп та інших властивостей. Записи про ці зміни зберігаються в реєстрі і базах NTDS.dit або SAM. В логах залишаються події з ID: 46274, 46265, 4634, 4624, 4778 (при підключенні по RDP).
4. Необхідно визначити, які програми або команди виконувалися. Записи залишаються в логах, в папці Prefetch, в реєстрі (NTUSER.DAT).
5. Необхідно визначити, які мережеві підключення були. Дані про це зазвичай можна зняти або з живої системи, або з образу пам'яті, знятого з живої системи. Модулі Netscan або Linux_netstat в Volatility. У роботі над зліпком оперативної пам'яті я, як і багато, використовую Volatility і в деяких випадках Redline. Redlineінтересна тим, що дозволяє повністю провести аналіз, а потім наочно візуалізує результат. При цьому Redline дозволяє завантажувати хеші відомих файлів (які можна також складати самостійно), що спрощує завдання з аналізу - утиліта підкаже, що файл довірений.

інтерфейс Redline

Крім цього, можна витягти вміст процесу в файл для подальшого дослідження.

слід знайдено

В оперативній пам'яті одного з контролерів домену виявилися явні ознаки компрометації:

• процес svchost.exe запущений з C: \ Windows \ WOW64, а не з System32, як йому належить;
• вихідні підключення, на IP-адресу приватного хостингу в Штатах;
• невідомий процес запущений з PPID, що не що відображаються в списку процесів.

Процес був ідентифікований за допомогою утиліти vol.exe.

vol.exe pslist -f image.vmem --profile = Win2008R2SP1x64> pslist Offset (V) Name PID PPID 0xfffffa801996cb30 spintlx64.exe 2820 +1388 ....

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

vol.exe dumpfiles -r spintlx64 -f image.vmem --profile = Win2008R2SP1x64 -D ./

При перевірці на VirusTotal показник виявлення був 34/50. При поверхневому аналізі виявилося, що дата компіляції і збірки бінарники 1992-06-19 22:22:17, а знайдений при офлайн-аналізі образу диска файл мав типові для малварі зміни в атрибутах. Дата створення, зміни, останнього звернення були однакові і набагато старше інших системних файлів. Файл мав невелику вагу, створював логи в зашифрованому вигляді і відправляв їх по мережі за допомогою HTTPS. На вигляд - типовий кейлоггер. Цікаво, тепер належить розібратися, звідки і коли він потрапив в систему.

Після відновлення даних все лог-файли були завантажені в Event Log Explorer для подальшого аналізу. Штатні засоби в такій ситуації не підходять: вони не так повороткі при пошуку, а розміри балок дуже великі (> 30 Гб).

Вивчення подій за допомогою Event Log Explorer

Відсортувавши події за мережевою адресою джерела, я отримав кілька записів логів, що показують, що здійснювався мережевий вхід (тип 3) одного з адміністраторів з сервераZabbix. За подією входу була визначена дата установки кейлоггера. Її підтвердило час появи перших файлів, створюваних кілоггерів, - вони віддалялися, але їх вийшло відновити разом з атрибутами. Більше нічого підозрілого ні в логах, ні в пам'яті, ні в реєстрі виявлено не було. Додатково я проаналізував домашні каталоги користувачів сервера, але це не принесло нових результатів.
Завершивши роботу з контролером домену, я перемкнув увагу на сервер Zabbix - саме з нього здійснювався доступ до контролера домену через мережу.

Обстеження Linux-системи концептуально не відрізняється від обстеження Windows-системи. Шукаємо все те ж саме: історію дій, вироблених з системою. Якщо копнути глибше, то досліджувати можна все, від апаратного рівня до історії запуску Microsoft Paint або набраних текстів. Але на щастя, зазвичай такого завдання не варто. Найчастіше завдання досить конкретна і немає необхідності витрачати час на те, що не принесе результату.

В даному випадку потрібно було обстежити Linux-систему на предмет несанкціонованого доступу. Про сервері попередньо було відомо наступне: встановлено Suse Linux, Apache + PHP + MySQL + Zabbix з супутнім програмним забезпеченням - всім знайомим LAMP. З'ясувалося, що співробітник, відповідальний за сервер, з ОС Linux спілкується на «ви». Встановив і обслуговував сервер його попередник, який давно пішов з компанії.

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

Вивчати образ вмісту оперативної пам'яті системи Linux можна тим же комплектом Volatility, бажано останнього стабільного релізу, хоча після версії 2.0 він цілком справляється. Існує деяка різниця в порівнянні з аналізом образів RAM сімейства Windows - в Volatility немає і в принципі не може бути шаблонів структури пам'яті для кожного ядра. Тому шаблон доведеться створити. Для цього необхідно:

• запустити копію досліджуваної системи;
• скопіювати туди директорію volatility / tools / linux;
• зібрати проект, отримавши в результаті файл module.dwarf, і скопіювати його разом з актуальним /boot/System.map того ядра, на якому працювала система при знятті способу RAM, назад на систему дослідника;
• упакувати обидва файли, наприклад в Linux.zip, і помістити архів вvolatility / plugins / overlays / linux /.

Тепер при запуску Volatility з ключем --info створений тобою профайл буде видно в списку і з ним уже можна почати роботу над образом. Без цього нічого не вийде, тому що Volatility необхідно знати структури даних ядра (module.dwarf) і мати імена змінних, функцій і їх адреси в пам'яті (System.map).

Повернемося до дослідження. У мене була підозра, що система, на якій встановлений Zabbix, був скомпрометована. Залишилося зрозуміти, як і хто це зробив. Зайвих ключів для SSH, сторонніх облікових записів в системі не виявилося. Я припустив, що в системі є backdoor, а можливо, і руткит. Для установки подібного роду софта часто потрібні максимальні привілеї. Це очевидно, досить згадати основні принципи роботи більш-менш передових руткітів в Linux-системах:

• завантаження модуля ядра;
• приховування процесів, входів користувачів, модулів ядра, файлів, мережних з'єднань;
• підміна системних файлів.

В першу чергу необхідно було перевірити найпростіші речі, а саме історію виконаних команд: vol -f image.vmem -profile = Linux, x86 linux_bash

Історія команд була зовсім невеликий, і перше, що кинулося в очі, - це insmod rt.ko. До речі, в файлі історії на диску, звичайно, нічого подібного не було, більш того, відновити будь-які дані з файлу історії також не вдалося - вміст вже було перезаписано швидко генерує балками. Так що без образу пам'яті ці дані були б невідомі. Далі треба було знайти згаданий в історії команд модуль ядра. Модуль був виявлений на диску в директорії PHP-скриптів інтерфейсу Zabbix.

Подальший аналіз цього файлу показав, що він ховає сам себе, маскує при необхідності файли, надає привілеї root по команді. Управління ведеться через файлову систему / proc / rt. З мережею не взаємодіє.

Довідка від руткита

Перегляд мережевих з'єднань в образі пам'яті показав, що веб-сервер з Zabbix доступний з інтернету. Звичайно, я про це не питав, але мав на увазі, що систему моніторингу в мережу ніхто не виставляє. Пізніше я з'ясував у адміністраторів, що вони так стежать за системою, коли знаходяться поза офісом (незважаючи на наявність VPN-аккаунта у кожного). Зручно, нічого не скажеш.

Я звернув увагу на Zabbix і пошкодував, що ні придивився до нього раніше, - версія була підозріло стара - 1.8.4. Пошук по exploit-db.com показав, що в даній версії в скрипті popup.php присутній SQL-ін'єкція, що дозволяє отримати хеші користувачів (CVE: 2011-4674). Перевірка уразливості показала її повну працездатність.

Експлуатація уразливості в Zabbix

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

Схема підключення зловмисника стала очевидна: через веб-шелл запускався back connect, що надає інтерактивний шелл, після чого привілеї підвищувалися за допомогою руткита. При такій схемі зловмисник використовував цей хост як проміжний для передачі зловреда на контролер домену, а також для передачі базиntds.dit і SYSTEM. Для ефективного пошуку за допомогою утиліти md5deep була створена база MD5-хешей всіх файлів, відновлених з образу сервера, після чого серед них проведений пошук хешу кейлоггера. Як результат - шуканий файл був знайдений (правда, не з тим ім'ям), а поруч лежав psexec і інші супутні утиліти, які були видалені.

Тепер можна було точно сказати, як стався інцидент: зловмисник, скориставшись вразливістю Zabbix, отримав і підібрав хеш пароля адміністратора Zabbix. За допомогою скриптів Zabbix був завантажений і запущено допоміжний інструмент, зокрема ncat для створення зворотного з'єднання, за допомогою якого був завантажений і запущено локальний експлойт, - версія ядра була півторарічної давності.

До речі кажучи, Zabbix зберігає скрипти в БД, і їх сліди були виявлені в файлі ibdata1.

Сліди експлуатації в БД MySQL

Після підвищення привілеїв зловмисник використовував цю систему і підібрані паролі, які у одного з адмінів виявилися однаковими як в домені, так і в Linux-системі, для проникнення на контролер домену. Отримавши доступ до контролера домену з правами адміністратора домену, зловмисник заволодів базою даних хешів паролів користувачів. Так як правила генерації паролів користувачами були вельми прості, а паролі не змінювалися по кілька років, вони були підібрані без особливих зусиль. Володіючи обліковими даними більшості користувачів, зловмисник міг читати їх пошту.

Заради експерименту я спробував сбрутіть хеші користувачів домену. Легко і невимушено за пару годин були розкриті 90% паролів.

По всій видимості, коли зловмисникові набридло просто читати пошту, він вирішив її видалити - тим самим розважитися, або помститися, або виконати замовлення конкурентів? Його мотивація мені невідома.

Схема проникнення у внутрішню мережу

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

Адміністраторам було рекомендовано відновити контролер домену з більш ранньої, ніж зараження резервної копії, оновити версію Linux і Zabbix скомпрометованої системи, поміняти паролі.

Як захистити свій iDevice

Будь iDevice спілкується з сервером Exchange за допомогою протоколу ActiveSync. З позиції користувача - захиститися за замовчуванням ніяк не можна. Політика сервера Exchange має на увазі, що якщо пристрій підключено до корпоративної мережі, то адміністратор повинен мати можливість коли завгодно управляти цим пристроєм для припинення доступу до конфіденційної інформації. Крім цього, користувач, у разі втрати або крадіжки, може зайти в OWA через будь-який браузер і запустити процес віддаленої очищення.

Якщо в організації є розуміє адміністратор Exchange - звернутися до нього і попросити прибрати права на виконання даної операції, а ще краще - прибрати доступ до пункту «Мобільні пристрої» з веб-інтерфейсу OWA.

Очищення девайса з OWA

вердикт

Настав час підбити підсумки. До ситуації, що склалася привели помилки адміністрування мережі і систем:

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

По можливості намагайтеся уникати цього :).