Истории из техподдержки::
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 4941
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6203
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7434
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7762
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6818
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Истории из техподдержки

Архив номеров / 2020 / Выпуск №09 (214) / Истории из техподдержки

Рубрика: Безопасность /  Антивирусы

 ВИЗИТКА 

Вячеслав Медведев,
старший эксперт отдела развития компании Доктор Веб

 

Истории из техподдержки

Бывают ли непогрешимые системы? И к чему может привести слепая вера в надежность того или иного оборудования, ПО, сервиса?

 

История первая.
«Нас взломали!»

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

Несанкционированный вход в компьютер с удалением ВАЖНОЙ ИНФОРМАЦИИ – файлов 10 Гб (с заменой заставки-картинки рабочего стола, как насмешка)

Дело вполне возможное – пользователи в массе своей и патчи не ставят, и с паролями не напрягаются (а иногда и вообще их может не быть). Но, как оказалось, на этот раз все было иначе. Анализ присланных по запросу данных показал, что «эвент лог забит сообщениями о битых секторах на диске». Диск находился на грани смерти.

В системном журнале есть большое количество сообщений вида The device, \Device\Harddisk1\DR1, has a bad block.
Обычно это означает проблему с жестким диском или файловой подсистемой, что может прямым образом коррелировать с той ситуацией, которая у вас возникала.

Файлы пропали, но взлома не было.

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

В сбоях-неполадках-аномалиях пользователи (причем и корпоративные тоже) первым делом зачастую винят антивирус. Или вирус, хотя и тут антивирусу может достаться: «вы его не ловите». А потом выясняется, что причина в «посыпавшемся» диске, поврежденной файловой системе («ах, да, у нас на днях электричество неожиданно отключалось»), остановившемся вентиляторе.

Рекомендация. Следите за состоянием вашей файловой подсистемы и компьютера в целом.


История вторая.

«Раньше же все работало!»

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

Пришел китайский станок лазерной резки. На борту ОС Windows 7.
Вставили гарантированно чистую от вирусов флешку, для копирования файлов программ со станка, принесли на рабочий ПК, получили оповещение о вирусе:
Worm.Siggen.12242 (Инфицирован) и все файлы на флешке исчезли, появился скрытый раздел. Также со станком шло ПО, на usb-носителе, при попытке скопировать с него файлы дистрибутивов получили множество детектов, см. вложение.

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

Если кто не сталкивался, так выглядит часть раздела статистики Центра управления Dr.Web Enterprise Security Suite. Здесь мы даем только фрагмент скриншота, удалив информацию о конкретных адресах сети клиента.

Как видим, богатая коллекция – одним Worm.Siggen.12242 дело не ограничилось! Кстати, Worm – это червь, так что возможно злоумышленник надеялся заразить всю сеть клиента. А может, и нет – просто китайский бардак.

Техподдержка сразу запросила отчет со станции и образцы вредоносного ПО для анализа.

Почему и какие файлы удалились, нужно смотреть в логах со станции. Без сэмпла файла и логов мы, к сожалению, ничего не можем вам сказать.Почему и какие файлы удалились, нужно смотреть в логах со станции. Без сэмпла файла и логов мы, к сожалению, ничего не можем вам сказать.Можете собрать логи утилитой http://download.geo.drweb.com/pub/drweb/tools/dwsysinfo.exe и прикрепить отчет к запросу.

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

Важно! Время перевода денег по России – 3-5 минут. Каждая итерация запрос-ответ – это иногда не минуты, а дни (очень многие запросы закрывают по причине длительной неактивности пользователей). Поэтому огромная просьба: будьте готовы к инциденту, заранее изучите, что необходимо прикрепить к запросу для максимально быстрого анализа ситуации. Ведь на кону – ваши деньги или деньги вашей компании.

Для Dr.Web все просто: иконка паука в трее " Поддержка " Перейти к Мастеру отчетов " Создать отчет.

На скриншоте, если что, Dr.Web Security Space 12.

Но вернемся к клиенту.

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

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

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

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

Анализ выявил чудесное: вирус оказался древним.

Старый вирус, который создает ярлыки вместо папок и скрывает файлы. Сейчас такое уже редко встречается. Судя по всему, все файлы на флешке сейчас просто скрыты.
Включите в настройках отображения папок в проводнике отображение скрытых и системных файлов. Или через командную строку от имени администратора дайте команду attrib -s -h -a -r E:\* /s /d
Она должна вернуть все атрибуты файлов на место.
Если флешка до этого точно была чистая, то очевидно, что этот вирус был записан в момент перемещения файлов со станка, а значит – заражен сам станок, возможно еще с завода.
В первую очередь, если это возможно, необходимо просканировать сам станок утилитой.

Кстати, клиент параллельно связался и с китайским поставщиком.

Поддержка китайцев на уровне: «Это не вирус, просто отключите свой антивирус и работайте спокойно».Поддержка китайцев на уровне: «Это не вирус, просто отключите свой антивирус и работайте спокойно».

Вот и верь после этого поставщикам!

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

Соответственно, вредоносный код можно удалить. Троян же размножаться не умеет, лечить его невозможно, так как он изначально вредоносный, его можно только удалить.

Ясное дело, терять станок клиенту было жалко, поэтому нужно было понять, можно ли систему пролечить.

Этим же заходом запустить на станке утилиту FixIt! (скачайте по индивидуальной ссылке https://хххххх). После запуска на станке нажать Start Scanning, а по завершении сканирования – скопировать и прислать нам для анализа файл отчета. Мы его проанализируем и проверим, осталось ли еще что-то, что нужно удалить, если да, то вышлем вам новую утилиту FixIt, которая автоматически обезвредит все, что нужно.Этим же заходом запустить на станке утилиту FixIt! (скачайте по индивидуальной ссылке https://хххххх). После запуска на станке нажать Start Scanning, а по завершении сканирования – скопировать и прислать нам для анализа файл отчета. Мы его проанализируем и проверим, осталось ли еще что-то, что нужно удалить, если да, то вышлем вам новую утилиту FixIt, которая автоматически обезвредит все, что нужно.

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

Если он его удалит, у нас вместо лазерной установки груда железа.

Но пролечить удалось, и все заработало. Хэппи энд!

Выводы (в дополнение к вышесказанному).

  1. Старые вирусы не умирают – скорее умрут те системы, на которых они запускаются. Но до этого еще далеко.
  2. На компьютерах сети должен быть корпоративный антивирус, отслеживающий в числе прочего статистику заражений. Мало ли кто и куда флешку вставит (как сказал один из начальников флота США: самый страшный враг для подводной лодки – это матрос с флешкой, ищущий, куда ее воткнуть).
  3. Купил компьютер – проверь антивирусом.
  4. Ясно, что на станок антивирус ставить нежелательно. Но мы совершенно не удивимся, если в подобной ситуации и все программы, и сама ОС – древние и без всяких патчей безопасности. И дыр там немерено. Поэтому рекомендуется изолировать подобные системы в отдельную подсеть, закрыть ненужные службы и порты. По возможности проверять трафик, идущий в подсеть, ограничить список используемых сменных носителей.
  5. Перед лечением важных систем делайте бэкап.



История третья.
«Непогрешимые операционные системы – а есть ли такие в природе?»

Запрос был многоплановый, у клиента нашлось много чего интересного. Выделим только малую часть. Началось все со странности.

Теперь на серверах начал меняться адрес DNS, на 8.8.8.8 и 9.9.9.9, хотя там установлен ДрВеб.

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

Судя по последнему отчету, у вас в сети должен быть сервер с адресом    , на котором видна подозрительная сетевая активность.
С этого сервера предположительно идет брут. Нужна комплексная проверка.

Этот сервер был на Линукс, и, конечно, антивируса там не было.

Во избежание вопросов сразу скажем: мы не утверждаем, что антивирус должен быть везде (пример тому был приведен выше). Автор видел системы без антивируса, но и вирусных инцидентов там не случалось годами.

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

Для любой системы нужно принимать меры защиты. Хотя бы устанавливать патчи безопасности, о чем и продолжение истории.

Анализируем вредоносное ПО:

Целый комбайн с брутом rdp, эксплуатацией eternalblue, сканом на bluekeep и smbghost.

Знакомые слова. Напомним: это та же уязвимость, через которую проникал WannaCry в 2017 году.

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

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

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

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

К сожалению, примеров некорректной настройки сети – огромное количество.

И в завершение. Признаемся, что рекомендации, которые мы выдавали клиентам в данном случае, по сути, советы Капитана Очевидность.

Но мы их повторяем вновь и вновь, по новым обращениям. Вот так и живем.


Подпишитесь на журнал
Купите в Интернет-магазине

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru