Иногда возникает необходимость не просто получить данные о размере файла или файлов в директории, а также на целом разделе вашего Linux сервера, но и провести н...
Блог компании 3v-Hosting
15 мин.
Когда говорят про кибератаки, то многие до сих пор представляют себе устаревшую картину, когда пришло фишинговое письмо, кто-то открыл вложение, на сервер попал вредоносный файл, антивирус что-то нашёл или не нашёл, а дальше началась привычная история. Так вот свежий отчёт Mandiant M-Trends 2026 показывает совсем другую реальность и эта реальность становится грубее и неприятнее для тех, чья работа связана с серверной инфраструктурой. Для хостингов это вообще плохая новость, потому что атакующие всё чаще бьют туда, где держится вся техническая жизнь клиента, например в публичные сервисы, панели, edge-устройства, резервные копии, систему учётных записей, слой виртуализации. Иными словами, в те узлы, которые раньше многим казались просто обслуживающими.
Конечно, индустрия хостинга всегда находилась рядом с риском, тут ничего нового. Новым тут становится сам характер атаки. Mandiant пишет, что в 2025 году самым частым начальным вектором снова стали эксплойты, уже шестой год подряд. На их долю пришлось 32% расследований, где удалось установить точку входа. На втором месте - голосовая социальная инженерия, vishing, 11%. Email-фишинг при этом просел до 6%, хотя ещё в 2024 занимал 14%. Картина сместилась и теперь злоумышленнику уже не обязательно массово рассылать письма, рискуя быть забаненым за SPAM. Иногда ему достаточно дозвониться до help desk, выдать себя за сотрудника компании и убедить кого-то сбросить пароль, изменить MFA или подтвердить доступ к "легитимному" SaaS-приложению. Для владельца VPS или выделенного сервера это означает простую вещь, что вход в атаку всё чаще начинается не с вредоносного файла на диске, а с доверия, спешки и человеческой ошибки.

Источник: Mandiant M-Trends 2026
Можно сказать, что серверы из-за этого стали ближе к переднему краю борьбы. Раньше веб-сервер могли воспринимать как одну из частей бизнеса, теперь же он часто является той первая дверью, в которую ломятся злоумышленники. Публичный сайт, CRM, админка, self-hosted сервис, панель управления, VPN-шлюз, почтовый веб-интерфейс, сервер виртуализации, API-узел - всё это тем или иным образом смотрит наружу и будьте уверены - всё это прощупывают автоматические скрипты в режиме нон-стоп. Mandiant отдельно выделяет, что в 2025 году самыми часто эксплуатируемыми были уязвимости в интернет-доступных корпоративных платформах: SAP NetWeaver, Oracle E-Business Suite, Microsoft SharePoint. Логика тут очень понятная. Ведь если через одну уязвимость можно сразу зайти в систему, где есть документы, доступ к внутренним процессам, сервисные учётные записи и точки для дальнейшего движения по сети, то атакующий туда и пойдёт. Для хостинга это плохой сигнал ещё и потому, что на стороне клиента очень часто нет ни нормального окна на быстрые обновления, ни зрелого процесса управления уязвимостями. Сервер "работает же", а "если работает - не трожь". Но это только до первого взлома.
Есть ещё одна неприятная деталь. В отчёте прямо сказано, что между первичным доступом и передачей этого доступа другой группе иногда проходит меньше 30 секунд. Вот это уже очень похоже на инфраструктурную угрозу нового типа. Один злоумышленник находит уязвимый сервер, получает foothold, после чего доступ почти сразу уходит тем, кто умеет выжимать из компрометации максимум: шифровать, воровать, ломать резервные копии, рушить восстановление. Раньше у многих команд была привычка считать "небольшой" alert чем-то второстепенным. Будь то подозрительная команда в консоли, короткая аномалия в логах, странный логин, не до конца понятный PowerShell, временный web shell в директории сайта - всё это часто ставили в хвост очереди задач. А вот сейчас это роскошь. В современных атаках незначительный, на первый взгляд, сигнал иногда живёт в системе считаные секунды, а потом начинается совсем другой этап атаки.
Для тех, кто пользуется услугами хостинга отсюда следует важный вывод. Предлагаемые услуги больше нельзя оценивать только по CPU, RAM и диску, эта методология давно устарела. Клиент может арендовать мощный сервер с хорошим тарифом, быстрым NVMe и с множеством ядер, но если панель управления не обновлялась, если токены лежат в открытом виде в репозитории а на гипервизоре нет нормального контроля доступа, то весь этот "ресурс" превращается просто в удобную площадку для чужой работы или игры. И это уже касается не только enterprise, так как и малый бизнес, владельцы интернет-магазинов, студии, разработчики, даже обычные self-hosted проекты на VPS - все попадают в ту же логику.
Отдельно бросается в глаза, как сильно изменился смысл ransomware. Ещё недавно массовое представление об этом типе атак было довольно простым: пришли, украли файлы или зашифровали их, оставили записку, потребовали выкуп. Mandiant описывает сдвиг, который выглядит гораздо неприятнее. Операторы ransomware всё чаще бьют по возможности восстановиться. Их цель - не только украсть данные, теперь они целятся в backup infrastructure, identity services и virtualization management planes. Это очень показательный момент. Атакующий понимает, что восстановление для жертвы - это последний шанс не платить выкуп. Значит, ломать надо именно восстановление. Не архив как таковой, а саму способность организации встать на ноги после инцидента.
Отчёт прямо советует держать оффсайтные и air-gapped копии резервных данных и регулярно проверять восстановление из изолированной среды. Это звучит скучно, но применимо к реальной жизни это одна из самых полезных мыслей из всего документа. Бэкап, который никто никогда не разворачивал в тесте, есть просто надежда в виде файла. Когда атака бьёт по хостингу, времени на философию уже нет. Нужно быстро поднять VM, откатить проект, вернуть базу, восстановить панель, проверить консистентность и запустить сервис. Вот тут и выясняется, что часть архивов битая, скрипт восстановления старый, ключей нет, а нужный снапшот хранится в том же сегменте, где уже сидит атакующий. Исходя из критичности вопроса, мы даже публиковали отдельную статью о важности бекапов.
Слой виртуализации теперь тоже в зоне повышенного интереса и это логично. Ведь если злоумышленник получает контроль над средой, где живут виртуальные машины клиента, то он сразу выходит на другой уровень воздействия и теперь можно отключать, снапшотить, читать, удалять, мешать восстановлению и всячески ломать связность инфраструктуры. Для выделенного сервера риск выглядит чуть иначе, но суть похожая: удар идёт туда, где сосредоточено управление, в частности ipkvm интерфейсы. А вот для клиентов VPS это плохая новость ещё и потому, что обычный пользователь виртуального сервера почти никогда не видит, насколько защищён верхний слой. Он видит только свою машину и свой SSH, а вот реальный масштаб риска может жить этажом выше.
Статистика по dwell time тут тоже цепляет. Глобальная медиана времени присутствия атакующего в среде до обнаружения выросла с 11 до 14 дней. Внутреннее обнаружение - около 9 дней. Внешнее уведомление - почти 25 дней. Для владельца веб-сервера это число почти физическое. Две недели - это много и за это время можно выкачать базу клиентов, подложить web shell, закрепиться через легитимные инструменты, подготовить lateral movement, собрать токены, прочитать конфиги, отключить защиту, потрогать бэкапы и только потом перейти к активной фазе. Особенно если злоумышленник работает тихо и использует штатные функции системы. Mandiant отдельно пишет, что финансово мотивированные группы и шпионские группы активно злоупотребляют нативными возможностями on-prem и cloud-среды, а также легитимными инструментами. Отсюда следует очень неприятная мысль, что сигнатурная защита по malware уже давно не даёт той опоры, на которую многие всё ещё рассчитывают. Если атакующий действует через PowerShell, PsExec, RDP, SMB, rclone, сетевые сканеры, встроенные утилиты ОС и легальные RMM-инструменты, поведение становится гораздо труднее отличить от обычной админской работы.

Источник: Mandiant M-Trends 2026
Любопытно, что email-фишинг при этом не исчез, он просто перестал быть главным героем. Его доля упала, но он по-прежнему используется для расширения уже начатой компрометации. Для веб-проектов и клиентов хостинга тут есть побочный риск, о котором часто забывают, ведь компрометация почты и сервера очень хорошо усиливают друг друга. Через почту можно воровать доступы и расширять охват, через сервер - поднимать фальшивые страницы, фишинговые формы, редиректы, скрытые API и вредоносные вложения. А дальше инфраструктура клиента становится частью чужой кампании.
Искусственный интеллект в отчёте тоже мелькает, но без напускной истерики. Mandiant не пишет, что 2025 стал годом, когда ИИ сам по себе начал ломать всё вокруг. Картина куда спокойнее и от этого правдоподобнее. Да, ИИ используется, но как усилитель, как инструмент для первичной разведки, для социальной инженерии, а также для ускорения отдельных стадий атаки. Но это не отменяет главного, что по прежнему число успешных вторжений растёт из человеческих ошибок и системных слабостей.
Тут есть интересная мысль для клиентов виртуальных и выделенных серверов. Раньше вопрос безопасности часто выглядел как спор о разделении ответственности, о том, где заканчивается зона ответственности провайдера, а где начинается зона ответственности клиента. Формально это полезная рамка, но на практике атака спокойно проходит по обе стороны. Провайдер может отлично держать сеть и гипервизор, а клиент оставит старую CMS, лишний sudo и публичный бакет с дампами. Клиент может образцово держать свой проект, а провайдер прозевает слабую административную панель или доступ к резервной инфраструктуре. И вот уже весь разговор про то, чья это ответственность, становится довольно пустым, потому что ущерб уже общий: сервер лежит, данные утекли, почта не ходит, сайт недоступен. Дальше начинается восстановление, а именно по нему сейчас и бьют всё чаще, как я писал выше.
Если посмотреть на всё это глазами владельца обычного проекта на VPS, то можно сделать довольно очевидные выводы. Сервер теперь рискует не только потому, что на нём открыт 22-й порт или стоит WordPress. Он рискует потому, что живёт в разветвленной сети связей, где в сложную паутину вплетены git и CI/CD, почта с доменом, CDN и бэкапы, а также ноутбук администратора, Telegram или Slack и многое многое другое. Любая из этих точек может превратиться в точку входа. Иногда атакующий даже не будет особенно интересоваться самим сервером до тех пор, пока через другой актив не получит удобный способ туда дойти.
И тут, мы вынуждены сделать главный неприятный вывод для всей отрасли. Хостинг раньше ассоциировался исключительно с размещением серверов (сайтов) и всем, что с этим связано, т.е. стабильностью, аптаймом, быстрым каналом связи, понятными тарифами. Теперь же он всё сильнее ассоциируется с тем, переживёт ли клиент чужую атаку. Это уже другой рынок, даже если многие продолжают говорить и думать в устаревшей парадигме. Клиенту мало знать, сколько ядер у его VM. Ему всё чаще хочется понимать степень устойчивости своего провайдера к максимальному числу кризисных ситуаций.
Отчёт Mandiant хорош тем, что он не уходит в страшилки ради страшилок, он довольно трезвый. И его главный нерв я бы сформулировал так: атаки стали ближе к инфраструктуре, ближе к повседневной админской работе и ближе к человеческим процедурам. Вот почему хостинг теперь под более плотным давлением. Не потому что "все вдруг начали атаковать серверы", их и раньше часто атаковали. Давление выросло потому, что сервер сегодня - это часть большой связанной системы, а атакующие научились работать по этой системе быстро, по ролям и с прицелом на невозможность восстановление жертвы.
Для владельцев сайтов, веб-серверов, VPS и dedicated-серверов из этого следует очень простая мысль. Проверять надо уже не только проект, проверять надо весь контур вокруг него, потому что атаки изменились. Они стали ближе, а хостинг, как выясняется, давно уже не фон для бизнеса, а одна из самых чувствительных его точек к выбору которой нужно подходить с умом.
Что такое UFW, его особенности и преимущества. Разбираем базовую настройку файервола в Linux: логика правил, открытие портов, управление доступом и типичные оши...
Что означает ошибка HTTP 500, почему она возникает и как её быстро диагностировать. Практические шаги, примеры и советы для серверов, CMS и приложений.
Как понять, что сайт тормозит из-за CPU, RAM или диска, а не из-за кода? Разбираем признаки, диагностику и реальные кейсы, чтобы быстро найти узкое место и прин...