IX Международная студенческая научная конференция Студенческий научный форум - 2017

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

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

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

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

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

Инциденты информационной безопасности

Инцидент информационной безопасности - одно или серия нежелательных или неожиданных событий в системе информационной безопасности, которые имеют большой шанс скомпрометировать деловые операции и поставить под угрозу защиту информации [2].

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

• Отказ в обслуживании

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

Существует два основных типа инцидентов ИБ, связанных с отказом в обслуживании, создаваемых техническими средствами: уничтожение ресурсов и истощение ресурсов.

Некоторыми типичными примерами таких преднамеренных технических инцидентов ИБ "отказ в обслуживании" являются:

- зондирование сетевых широковещательных адресов с целью полного заполнения полосы пропускания сети трафиком ответных сообщений;

- передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу;

- одновременное открытие нескольких сеансов с конкретной системой, сервисом или сетью в попытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение).

Инциденты ИБ "отказ в обслуживании", создаваемые нетехническими средствами и приводящие к утрате информации, сервиса и (или) устройств обработки информации, могут вызываться, например, следующими факторами:

- нарушениями систем физической защиты, приводящими к хищениям, преднамеренному нанесению ущерба или разрушению оборудования;

- случайным нанесением ущерба аппаратуре и (или) ее местоположению от огня или воды/наводнения;

- экстремальными условиями окружающей среды, например высокой температурой (вследствие выхода из строя системы кондиционирования воздуха);

- неправильным функционированием или перегрузкой системы;

- неконтролируемыми изменениями в системе;

- неправильным функционированием программного или аппаратного обеспечения.

• Сбор информации

В общих чертах инциденты ИБ "сбор информации" подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки. Подобные инциденты ИБ предполагают проведение разведки с целью определения:

- наличия цели, получения представления об окружающей ее сетевой топологии и о том, с кем обычно эта цель связана обменом информации;

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

Типичными примерами атак, направленных на сбор информации техническими средствами, являются:

- сбрасывание записей DNS (системы доменных имен) для целевого домена Интернета (передача зоны DNS);

- отправка тестовых запросов по случайным сетевым адресам с целью найти работающие системы;

- зондирование системы с целью идентификации (например, по контрольной сумме файлов) операционной системы хоста;

- сканирование доступных сетевых портов на протокол передачи файлов системе с целью идентификации соответствующих сервисов (например электронная почта, протокол FTP, сеть и т. д.) и версий программного обеспечения этих сервисов;

- сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов (горизонтальное сканирование).

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

Инциденты, направленные на сбор информации, создаваемые нетехническими средствами, приводят к:

- прямому или косвенному раскрытию или модификации информации;

- хищению интеллектуальной собственности, хранимой в электронной форме;

- нарушению учетности, например, при регистрации учетных записей;

- неправильному использованию информационных систем (например, с нарушением закона или политики организации).

Инциденты могут вызываться, например, следующими факторами:

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

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

• Несанкционированный доступ

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

- попытки извлечь файлы с паролями;

- атаки переполнения буфера с целью получения привилегированного (например, на уровне системного администратора) доступа к сети;

- использование уязвимостей протокола для перехвата соединения или ложного направления легитимных сетевых соединений;

- попытки расширить привилегии доступа к ресурсам или информации по сравнению с легитимно имеющимися у пользователя или администратора.

Инциденты несанкционированного доступа, создаваемые нетехническими средствами, которые приводят к прямому или косвенному раскрытию или модификации информации, нарушениям учетности или неправильному использованию информационных систем, могут вызываться следующими факторами:

- разрушением устройств физической защиты с последующим несанкционированным доступом к информации;

- неудачной и (или) неправильной конфигурацией операционной системы вследствие неконтролируемых изменений в системе или неправильного функционирования программного или аппаратного обеспечения [3].

Расследование инцидентов информационной безопасности

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

Организация процесса реагирования на инцидент преследует следующие цели:

• предупредить нескоординированные действия и в кратчайшие сроки восстановить работоспособность компании при возникновении инцидента;

• подтвердить или опровергнуть факт инцидента ИБ;

• представить детализированный отчет о произошедшем инциденте и полезные рекомендации;

• создать условия для накопления и хранения точной информации о компьютерных инцидентах;

• обеспечить быстрое обнаружение и/или предупреждение подобных инцидентов в будущем (путем анализа случившихся в прошлом инцидентов, изменения политики ИБ, модернизации системы ИБ и др.);

• обеспечить сохранность и целостность доказательств произошедшего инцидента;

• создать условия для возбуждения гражданского или уголовного дела против злоумышленника;

• минимизировать нарушение порядка работы и повреждения данных ИТ-системы;

• минимизировать последствия нарушения конфиденциальности, целостности и доступности ИТ-системы;

• защитить репутацию компании и ее ресурсы;

• провести обучение сотрудников компании о процессе реагирования на инцидент.

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

Рисунок 1. Алгоритм выявления и реагирования на инциденты ИБ

Понятно, что по различным инцидентам ИБ процедуры реагирования могут различаться, в зависимости от вида инцидента, степени его критичности, возможного ущерба, реакции руководства организации и т.п.

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

Можно выделить следующие основные этапы процесса реагирования на инцидент:

• Подготовка к факту возникновения инцидента ИБ. Предпринимаются действия для подготовки компании к ситуации возникновения инцидента (чтобы минимизировать его последствия и обеспечить быстрое восстановление работоспособности компании). Формирование комиссии по расследованию (CSIRT) инцидентов. Этот этап является одним из самых важных, от него зависит успех в проведении расследования потенциального инцидента.

• Обнаружение инцидента - идентификация инцидента ИБ.

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

• Формулирование стратегии реагирования. Стратегия базируется на всех известных фактах и определяет лучший путь реагирования на инцидент. Подтверждается топ-менеджментом компании. Стратегия также определяет, какие действия будут предприняты по факту возникновения инцидента (возбуждение гражданского или уголовного дела, административное воздействие), в зависимости от предполагаемых причин и последствий возникновения инцидента.

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

• Отчет - детализированный отчет, содержащий полученную в ходе расследования информацию. Представляется в форме, удобной для принятия решения.

• Решение - применение защитных механизмов и проведение изменений в процедурах ИБ.

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

Источниками информации при расследовании инцидентов могут быть:

• Системные журналы (логи, история команд);

• Сетевой трафик;

• Исполняемые процессы;

• Содержимое оперативной памяти;

• Открытые сетевые соединения;

• Открытые порты;

• Открытые файлы;

• Файлы и файловая система;

• Архивы (электронной почты, теневых копий DLP-систем);

• Журналы систем защиты (антивирусы, IDS и т.д.).

Volatility Framework: возможности инструмента

Volatility Framework - программа для исследования копий (образов) оперативной памяти. Фрэймворк с полностью открытым кодом, представляющий собой набор Python – инструментов для извлечения цифровых артефактов из энергонезависимой памяти (RAM). Эта утилита может быть полезна при расследовании инцидентов информационной безопасности или просто при исследовании работы программы с критичными данными.

Самой последней версией Volatility Framework является версия 2.5, выпущенная в октябре 2015 года. Более поздние версии также доступны в разделе Releases на официальном сайте Volatility Framework [5]. Некоторые параметры командной строки, опции и плагины могут незначительно отличаться от версии к версии. С полным списком команд Volatility Framework можно ознакомиться в [6].

Volatility Framework распространяется как в виде открытого исходного кода, так и в виде исполняемого файла (только для Windows).

На сегодняшний день программа поддерживает следующие платформы: Windows, Linux, OS X.

Сейчас Volatility Framework поддерживается компанией Volatile Systems и является одним из самых многофункциональных пакетов для исследования памяти.

В его возможности входит извлечение информации о:

- списке запущенных процессов;

- списке открытых сетевых соединений;

- списке открытых сетевых сокетов;

- списке загруженных динамических библиотек (DLL) для каждого процесса;

- именах открытых файлов для каждого процесса;

- адресуемую память;

- открытых записей реестра;

- извлечение образов процессов;

- маппинг физических смещений на виртуальные адреса и др.

Ход работы

Как было описано выше, целью данной работы является анализ тестовой операционной системы посредством применения возможностей инструмента Volatility Framework.

В ходе исследований было выполнено:

1. Изучение теоретического материала: инциденты ИБ, менеджмент инцидентов, его цели и задачи. Рассмотрены средства и инструменты расследования инцидентов, возможности пакета Volatility Framework.

2. Установлен пакет Volatility Framework версии 2.5.

3. Получение первичной информации об образе памяти Task3.vmem (ImageInfo).

4. Получение списка процессов, их детальный анализ (Pslist).

5. Выявление подозрительных процессов, их анализ.

6. Построения дерева подозрительных процессов (Pstree).

7. Получение списков открытых сетевых соединений и открытых сетевых сокетов (Connections, Sockets). Анализ полученных списков.

8. Получение списка загруженных библиотек, их количественный анализ (Dlllist).

9. Поиск скрытых DLL для подозрительных процессов (malfind). Получение для подозрительных процессов Crash Dump Files.

10. Анализ полученных файлов на сайте VirusTotal.

11. Получение списка драйверов, его анализ (modscan).

12. Выводы. Анализ материалов по найденной вредоносной программе.

Результаты работы и их анализ

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

Рисунок 2. Первичная информация о тестовом образе памяти

Анализ первичной информации позволяет выяснить дату и время получения данного образа памяти, а также тип операционной системы: Windows XP Service Pack 3 (x86).

В первую очередь, после получения первичной общей информации об образе памяти, был проанализирован список процессов:

C:UsersДНСDesktopvolatility_2.5.win.standalone>volatility-2.5.standalone.exe

--profile=WinXPSP3x86 -f C:UsersДНСDesktopvolatility_2.5.win.standalonetas

k3.vmem pslist

Volatility Foundation Volatility Framework 2.5

Offset(V) Name PID PPID Thds Hnds Sess Wow64 Star

t Exit

---------- -------------------- ------ ------ ------ -------- ------ ------ ----

-------------------------- ------------------------------

0x823c8830 System 4 0 59 403 ------ 0

0x820df020 smss.exe 376 4 3 19 ------ 0 2010

-10-29 17:08:53 UTC+0000

0x821a2da0 csrss.exe 600 376 11 395 0 0 2010

-10-29 17:08:54 UTC+0000

0x81da5650 winlogon.exe 624 376 19 570 0 0 2010

-10-29 17:08:54 UTC+0000

0x82073020 services.exe 668 624 21 431 0 0 2010

-10-29 17:08:54 UTC+0000

0x81e70020 lsass.exe 680 624 19 342 0 0 2010

-10-29 17:08:54 UTC+0000

0x823315d8 vmacthlp.exe 844 668 1 25 0 0 2010

-10-29 17:08:55 UTC+0000

0x81db8da0 svchost.exe 856 668 17 193 0 0 2010

-10-29 17:08:55 UTC+0000

0x81e61da0 svchost.exe 940 668 13 312 0 0 2010

-10-29 17:08:55 UTC+0000

0x822843e8 svchost.exe 1032 668 61 1169 0 0 2010

-10-29 17:08:55 UTC+0000

0x81e18b28 svchost.exe 1080 668 5 80 0 0 2010

-10-29 17:08:55 UTC+0000

0x81ff7020 svchost.exe 1200 668 14 197 0 0 2010

-10-29 17:08:55 UTC+0000

0x81fee8b0 spoolsv.exe 1412 668 10 118 0 0 2010

-10-29 17:08:56 UTC+0000

0x81e0eda0 jqs.exe 1580 668 5 148 0 0 2010

-10-29 17:09:05 UTC+0000

0x81fe52d0 vmtoolsd.exe 1664 668 5 284 0 0 2010

-10-29 17:09:05 UTC+0000

0x821a0568 VMUpgradeHelper 1816 668 3 96 0 0 2010

-10-29 17:09:08 UTC+0000

0x8205ada0 alg.exe 188 668 6 107 0 0 2010

-10-29 17:09:09 UTC+0000

0x820ec7e8 explorer.exe 1196 1728 16 582 0 0 2010

-10-29 17:11:49 UTC+0000

0x820ecc10 wscntfy.exe 2040 1032 1 28 0 0 2010

-10-29 17:11:49 UTC+0000

0x81e86978 TSVNCache.exe 324 1196 7 54 0 0 2010

-10-29 17:11:49 UTC+0000

0x81fc5da0 VMwareTray.exe 1912 1196 1 50 0 0 2010

-10-29 17:11:50 UTC+0000

0x81e6b660 VMwareUser.exe 1356 1196 9 251 0 0 2010

-10-29 17:11:50 UTC+0000

0x8210d478 jusched.exe 1712 1196 1 26 0 0 2010

-10-29 17:11:50 UTC+0000

0x82279998 imapi.exe 756 668 4 116 0 0 2010

-10-29 17:11:54 UTC+0000

0x822b9a10 wuauclt.exe 976 1032 3 133 0 0 2010

-10-29 17:12:03 UTC+0000

0x81c543a0 Procmon.exe 660 1196 13 189 0 0 2011

-06-03 04:25:56 UTC+0000

0x81fa5390 wmiprvse.exe 1872 856 5 134 0 0 2011

-06-03 04:25:58 UTC+0000

0x81c498c8 lsass.exe 868 668 2 23 0 0 2011

-06-03 04:26:55 UTC+0000

0x81c47c00 lsass.exe 1928 668 4 65 0 0 2011

-06-03 04:26:55 UTC+0000

0x81c0cda0 cmd.exe 968 1664 0 -------- 0 0 2011

-06-03 04:31:35 UTC+0000 2011-06-03 04:31:36 UTC+0000

0x81f14938 ipconfig.exe 304 968 0 -------- 0 0 2011

-06-03 04:31:35 UTC+0000 2011-06-03 04:31:36 UTC+0000

Полученный список процессов был проанализирован. Большинство из процессов являются системными, остальные связаны с работой программы VMware. В сети Интернет выполнен поиск описания по каждому из процессов. В ходе анализа была найдена информация о том, что один из процессов lsass.exe – необходимый системный процесс, отвечающий за работу локального сервера проверки подлинности, политику безопасности и авторизацию пользователей. Взаимодействует со службой Winlogon. Однако, lsass.exe может также быть процессом, известным как троянский вирус. Эта троянская программа позволяет злоумышленникам получать доступ к вашему ПК, похищать пароли и персональные данные. Под именем lsass.exe известен также downloader — программа, загружающая данные (в том числе вирусы) из Интернета на ПК пользователя без их ведома [7].

В ходе более детального исследования процесса lsass.exe было отмечен его неоднократный старт, причем с ощутимой разницей во времени старта. Более того, процесс lsass.exe находится в числе «первых» загружаемых при загрузке. В силу этого значение идентификатора этого процесса является небольшим. Однако подозрительные процессы с PID = 868 и PID = 1928 имеют более высокое значение идентификатора, нежели процесс с PID = 680.

Также можно заметить, что процесс с PID = 680 был порожден процессом с PID = 624 (а именно, процессом winlogon.exe). Это является правильным поведением процесса lsass.exe, так как он взаимодействует со службой Winlogon. В случае процессов с PID = 1928 и PID = 868 такого взаимодействия не наблюдается. В этом можно наглядно убедиться, построив дерево процессов:

C:UsersДНСDesktopvolatility_2.5.win.standalone>volatility-2.5.standalone.exe

--profile=WinXPSP3x86 -f C:UsersДНСDesktopvolatility_2.5.win.standalonetas

k3.vmem pstree

Volatility Foundation Volatility Framework 2.5

Name Pid PPid Thds Hnds T

ime

-------------------------------------------------- ------ ------ ------ ------ -

---

.. 0x81da5650:winlogon.exe 624 376 19 570 2

010-10-29 17:08:54 UTC+0000

... 0x82073020:services.exe 668 624 21 431 2

010-10-29 17:08:54 UTC+0000

.... 0x81c47c00:lsass.exe 1928 668 4 65 2

011-06-03 04:26:55 UTC+0000

.... 0x81c498c8:lsass.exe 868 668 2 23 2

011-06-03 04:26:55 UTC+0000

... 0x81e70020:lsass.exe 680 624 19 342 2

010-10-29 17:08:54 UTC+0000

В ходе дальнейшего исследования были проанализированы список открытых сетевых соединений и список открытых сетевых сокетов. Было установлено, что на момент получения образа памяти никаких сетевых соединений не было установлено (рис. 3).

Рисунок 3. Список открытых сетевых соединений

Анализ списка открытых сетевых сокетов (рис. 4) дает еще одно основание полагать, что процесс с PID = 680 является безопасным процессом с характерным для него поведением. Дело в том, что назначение процесса lsass.exe предполагает, как правило прослушивание портов (в данном случае, это порты 500 и 4500. В то же время, анализ сокетов дает еще один аргумент в пользу подозрительности процессов с PID = 868 и PID = 1928.

Рисунок 4. Список открытых сетевых сокетов

Затем для каждого из процессов с PID = 680, 868, 1928 был получен список загруженных библиотек. Их анализ позволил выявить небольшое количество DLL для подозрительных процессов с PID = 868, 1928 по сравнению с PID = 680 (в четыре и два раза меньшее количество DLL соответственно). Ниже представлен список DLL для процесса с PID = 868:

C:UsersДНСDesktopvolatility_2.5.win.standalone>volatility-2.5.standalone.exe

--profile=WinXPSP3x86 -f C:UsersДНСDesktopvolatility_2.5.win.standalonetas

k3.vmem dlllist -p 868

Volatility Foundation Volatility Framework 2.5

************************************************************************

lsass.exe pid: 868

Command line : "C:WINDOWSsystem32lsass.exe"

Service Pack 3

Base Size LoadCount Path

---------- ---------- ---------- ----

0x01000000 0x6000 0xffff C:WINDOWSsystem32lsass.exe

0x7c900000 0xaf000 0xffff C:WINDOWSsystem32ntdll.dll

0x7c800000 0xf6000 0xffff C:WINDOWSsystem32kernel32.dll

0x77dd0000 0x9b000 0xffff C:WINDOWSsystem32ADVAPI32.dll

0x77e70000 0x92000 0xffff C:WINDOWSsystem32RPCRT4.dll

0x77fe0000 0x11000 0xffff C:WINDOWSsystem32Secur32.dll

0x7e410000 0x91000 0xffff C:WINDOWSsystem32USER32.dll

0x77f10000 0x49000 0xffff C:WINDOWSsystem32GDI32.dll

Далее, используя ключ –malfind, был выполнен поиск скрытых DLL для подозрительных процессов. Для подозрительных процессов были получены Crash Dump Files:

C:UsersДНСDesktopvolatility_2.5.win.standalone>volatility-2.5.standalone.exe

--profile=WinXPSP3x86 -f C:UsersДНСDesktopvolatility_2.5.win.standalonetas

k3.vmem malfind -p 868 -D C:UsersДНСDesktopvolatility_2.5.win.standaloneАле

ксеев1

Volatility Foundation Volatility Framework 2.5

Process: lsass.exe Pid: 868 Address: 0x80000

Vad Tag: Vad Protection: PAGE_EXECUTE_READWRITE

Flags: Protection: 6

0x00080000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............

0x00080010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......

0x00080020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

0x00080030 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 ................

Для дальнейшего анализа файлы были загружены на VirusTotal. Каждый из файлов был распознан большинством антивирусов как троянская программа – Stuxnet(рис. 5).

Рисунок 5. Результат анализа файлов

Затем был проанализирован список драйверов (рис. 6) с помощью команды modscan (позволяет получить список ранее выгруженных драйверов и драйверов, которые были скрыты). Попытка поиска в сети Интернет имени первого же драйвера из списка принесла результат: Первая модификация червя Stuxnet, созданная в 2009 году, использовала только один файл драйвера — mrxcls.sys, — и в нем отсутствовала цифровая подпись. В 2010 году авторы создали второй драйвер mrxnet.sys (его целью было сокрытие файлов червя на USB-дисках) и снабдили mrxnet.sys и драйвер mrxcls.sys цифровыми сертификатами компании Realtek [8].

Рисунок 6. Список драйверов

Выводы

В ходе проведенного исследования тестового образа памяти Task3.vmem было обнаружено действие вредоносной троянской программы – Stuxnet. Win32/Stuxnet — компьютерный червь, поражающий компьютеры под управлением операционной системы Microsoft Windows. Данный вирус использует четыре уязвимости системы Microsoft Windows (уязвимость «нулевого дня» (zero-day) и три ранее неизвестные уязвимости), позволяющие ему распространяться при помощи USB-flash накопителей.

В ходе работы установлено, что червь установил в систему два драйвера, один из которых является драйвером-фильтром файловой системы, скрывающим наличие компонентов вредоносной программы на съемном носителе. Второй драйвер используется для внедрения зашифрованной динамической библиотеки в системные процессы и содержит в себе специализированное ПО для выполнения основной задачи. Драйверы, которые троян устанавливает в систему, снабжены цифровыми подписями, украденными у производителей легального программного обеспечения. Известно об использовании подписей, принадлежащих таким компаниям, как Realtek Semiconductor Corp. и JMicron Technology Corp. Злоумышленники используют цифровую подпись для «тихой» установки драйверов руткита в целевую систему. В системах безопасности многих производителей файлы, подписанные известными фирмами, заведомо считаются безопасными, и наличие подписи дает возможность беспрепятственно, не выдавая себя, производить действия в системе. Кроме того, червь располагает механизмами контроля количества заражений, самоликвидации и дистанционного управления.

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

Список использованных источников:

1. Информационная безопасность [Электронный ресурс]: – Режим доступа: https://ru.wikipedia.org/wiki/Информационная_безопасность

2. Инцидент информационной безопасности [Электронный ресурс]: - Режим доступа:http://www.wikisec.ru/index.php?title=Инцидент_информационной_безопасности

3. Примеры инцидентов информационной безопасности и их причин [Электронный ресурс]: Режим доступа: http://zakonbase.ru/content/part/1254066

4. В. Сердюк // Особенности использования практических инструментов для выявления и расследования инцидентов безопасности [Электронный ресурс]: Режим доступа: http://www.pcweek.ru/upload/iblock/69f/dialog-nauka.pdf

5. Volatility Framework [Электронный ресурс]: Режим доступа: http://www.volatilityfoundation.org/

6. Volatility Framework - Command Reference [Электронный ресурс]: Режим доступа:https://code.google.com/archive/p/volatility/wikis/CommandReference.wiki

7. Программы, сервисы, процессы в Windows XP [Электронный ресурс]: Режим доступа: http://articles.org.ru/cn/showdetail.php?cid=5721

8. Stuxnet/Duqu: эволюция драйверов XP [Электронный ресурс]: Режим доступа:https://securelist.ru/analysis/obzor/81/stuxnetduqu-e-volyutsiya-drajverov/

Код для цитирования: Скопировать