Наш форум переведен в режим работы "только для чтения", публикация новых тем и сообщений недоступна. Мы искренне благодарны вам за то, что были с нами, но пришло время двигаться дальше. После официального ухода компании ESET с российского рынка мы приступили к разработке новых продуктов вместе с новыми партнёрами. Приглашаем вас присоединиться к нашему новому форуму PRO32.
Мы более не являемся эксклюзивным дистрибьютором программных продуктов словацкого разработчика ESET в России, Республике Беларусь, Казахстане, Азербайджане, Узбекистане, Кыргызстане, Таджикистане, Туркменистане, Молдове, Грузии и Армении.
Купить и продлить лицензии ESET на нашем сайте больше нельзя.
Предлагаем вам попробовать новые продукты компании PRO32.
PRO32 — это технологичные решения, надежная защита от киберугроз и максимальная производительность устройств. Для действующих клиентов ESET мы предлагаем промокод на скидку в размере 15% — ESET15. Скопируйте его и после добавления товара в корзину, не забудьте его применить в корзине.
судя по списку установленного ПО, у вас версия 15.0.1497.2 кумулятивного обновления Microsoft Exchange Server 2013 Cumulative Update 23 выпуск этого обновления был от Exchange Server 2013 CU23 18 июня 2019 г. 15.0.1497.2 15.00.1497.002
после этого Exchange Server 2013 CU23 18 июня 2019 г. 15.0.1497.2 15.00.1497.002 были еще новые выпуски:
Exchange Server 2013 CU23 Jul21SU 13 июля 2021 г. 15.0.1497.23 15.00.1497.023 Exchange Server 2013 CU23 May21SU 11 мая 2021 г. 15.0.1497.18 15.00.1497.018 Exchange Server 2013 CU23 Apr21SU 13 апреля 2021 г. 15.0.1497.15 15.00.1497.015 Exchange Server 2013 CU23 Mar21SU 2 марта 2021 г. 15.0.1497.12 15.00.1497.012
возможно, некорректное отображение версии обновления в списке установленного ПО, а возможно, установлено неактуальное обновление для Microsoft Exchange Server 2013
ProxyShell активно используется для установки веб-шеллов В настоящее время эксплойт сбрасывает веб-оболочку размером 265 КБ в папку c: \ inetpub \ wwwroot \ aspnet_client \. веб-оболочки состоят из простого защищенного аутентификацией сценария, который злоумышленники могут использовать для загрузки файлов на скомпрометированный сервер Microsoft Exchange. злоумышленники используют первую веб-оболочку для загрузки дополнительной веб-оболочки в папку с удаленным доступом и два исполняемых файла в папки C: \ Windows \ System32 Если два исполняемых файла не могут быть найдены, в следующей папке будет создана другая веб-оболочка в виде файлов ASPX со случайным именем. C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ FrontEnd \ HttpProxy \ owa \ auth \ Злоумышленники используют вторую веб-оболочку для запуска исполняемого файла (пример: createhidetask.exe), который создает запланированную задачу с именем (например:PowerManager), которая запускает исполняемый файл (например:ApplicationUpdate.exe ) в 1 час ночи каждый день. исполняемый файл ApplicationUpdate.exe - это пользовательский загрузчик .NET, используемый в качестве бэкдора. «ApplicationUpdate.exe - это загрузчик .NET, который загружает другой двоичный файл .NET с удаленного сервера (который в настоящее время обслуживает полезную нагрузку)
возможно, это адрес кошелька + pool.supportxmr.com:443
Apr 29 2021
Цитата
Exchange Server Vulnerability - Still Having Issues after all Patch and CU20 Updates
Hello everyone,
As per Microsoft Recommendations, we already installed all security patches earlier in the March and installed CU 20 updates. Here are the details about our issues. Any help on this will be appreciated:
Issue: High CPU utilization due to cmd.exe process
Exchange 2016 Standard
Work done so far: All patches installed, CU 20 installed, Performed multiple scan with Microsoft Safety Scanner, every time it finds and remove "Backdoor:MSIL/Chopper.F!dha " but next day same issue occurs
Opened CMD.exe file with process explorer today and found following scripts:
RP55 RP55 написал: На V.T. обновили базы теперь файл cef5aa279f639d500f83f51ae3bb846a2908019d определяется как 1/68: ESET-NOD32 A Variant Of MSIL/Agent.URR
теперь уже 14 детектов. Дрвеб добавил - DrWeb Trojan.LoaderNET.3, и ЛК -- Kaspersky HEUR:Trojan.MSIL.Agent.gen
Владимир Шариков написал: santy написал:1. запуск происх примерно в одно и тоже время на обоих серверах.
я бы не сказал, 03:48:12 [2021.07.30] и 17:34:15 [2021.08.07]Цитата
нет, имел ввиду, что когда происходит запуск какой-то день, то запуске происходят примерно в одно и то же время на обоих серверах.
по 2021.07.30 у нас были логи только с одного сервера
а вот 2021.08.07 есть логи от обоих серверов, и здесь видно, что время запуска примерно одинаковое
17:34:15 [2021.08.07] на SPHVMAIL01 17:43:35 [2021.08.07] на IZTVMAIL01
с другой стороны, согласен, что четкого расписания по времени нет в разные дни
склоняюсь к версии, либо проникновение возможно в сеть, либо удаленный запуск через доступную уязвимость + имеет смысл проверить дату изменения паролей учетных записей (если не было изменений после взлома, то сменить пароли) --------- вот опять недавно пишут про новую обнаруженную уязвимость ProxyShell
ProxyShell - это название трех уязвимостей, которые при объединении в цепочку выполняют удаленное выполнение кода без проверки подлинности на серверах Microsoft Exchange.
Эти связанные уязвимости используются удаленно через службу клиентского доступа (CAS) Microsoft Exchange, работающую на порту 443 в IIS.
В атаках ProxyShell используются три связанных уязвимости:
CVE-2021-34473 - Pre-auth Path Confusion leads to ACL Bypass (исправлено в апреле KB5001779) CVE-2021-34523 - Повышение привилегий для серверной части Exchange PowerShell (исправлено в апреле, KB5001779) CVE-2021-31207 - Запись произвольного файла после авторизации приводит к RCE (исправлено в мае KB5003435)
если есть возможность, проверьте по журналам было ли вторжение в локальную сеть (проникновение или удаленное выполнение кода в данных интервалах времени 17:34:15 [2021.08.07] на SPHVMAIL01 17:43:35 [2021.08.07] на IZTVMAIL01
Цитата
Это самое сложное "В нужный момент". Я так понял что если перезаписывает лог каждый час, необходимо попасть(не спать) в этот час?
да, успеть создать образ автозапуска пока система не затерла в логах DNS нужные записи, связанные с запуском процесса. в принципе, можно создать скрипт с созданием образа автозапуска из uVS, который бы сработал на запуск майнера. автоматически сразу после обнаружения процесса запуска майнера. (важно, чтобы отслеживание на сервере было уже включено: и процессов и DNS) ну, собственно прописать в скрипте: "создать образ автозапуска" выгрузить процесс майнера после завершения создания образа автозапуска" и "отключить отслеживание".
или создать задачу, которая бы с определенной периодичностью запускала скрипт, скрипт сканирует список процессов если находит процесс с майнером, то запускает uVS на создание образа автозапуска, после завершения выгружает процесс майнера, закрывает отслеживание + отправляет сообщение на почту администратору.
важно определить сколько по времени займет однократный процесс сканирования, чтобы определить с какой периодичностью можно запускать задачу.