4 способа, которыми киберпреступники скрывают атаки с заполнением учетных данных

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

Усугубляет давление тот факт, что злоумышленники намеренно маскируют заполнение учетных данных, чтобы мошеннические попытки доступа выглядели легальными и не были обнаружены. «Атаки с заполнением учетных данных имитируют запросы, которые сделал бы законный пользователь», - сообщил Трой Хант, исследователь безопасности и основатель службы уведомления об утечке данных Have I Been Pwned. «Злоумышленники спрашивают: как выглядит законный запрос? Как мы можем подражать этому? Что становится по-настоящему интересным, так это когда мы смотрим на боевые действия между защитниками и нападающими», - рассказал он.

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

Регулирование запросов, чтобы препятствовать управлению ограничением скорости

Обычный трюк, когда дело доходит до маскировки атак с подменой учетных данных, - это регулирование запросов, говорит технический евангелист Salt Security и бывший аналитик Gartner Майкл Исбитски. «Ограничения скорости и ограничения ресурсов часто рекомендуются в качестве передовой практики безопасности для механизмов посредничества API», - рассказал он CSO.

Например, организации могут установить ограничение скорости в 10 запросов в минуту для данного API, опосредованного шлюзом API. Если вызывающий API делает 11 запросов в минуту, первые 10 будут работать при условии, что у запрашивающего есть доступ, а последний будет явно заблокирован. «Этот порог обычно сбрасывается в следующую минуту, в то время как некоторые механизмы ограничения скорости допускают динамические ограничения, когда вызывающий API, считающийся чрезмерным, может быть ограничен на более длительный интервал, подобно порогу блокировки учетной записи.

Когда злоумышленники ограничивают запросы, они настраивают свои инструменты или скрипты так, чтобы они работали близко к этому пределу, не достигая его, а затем отступают», - добавляет Исбитски. Этот метод часто работает, поскольку ограничения скорости основаны на обычных моделях потребления без учета случаев злоупотреблений. «Динамическое ограничение скорости, основанное на непрерывном анализе поведения вызывающих API в рамках сеансов, является лучшей защитой от этой техники», - говорит он.

Обход CAPTCHA для маскировки роботизированных входов в систему

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

Субъекты заполнения учетных данных тратят время и усилия на поиск решений, позволяющих обойти этот барьер. Хант приводит реальный, прошлый случай найма службы решения CAPTCHA под руководством человека, которая получала бы постоянный поток задач CAPTCHA для решения и отправки обратно через соответствующие API за минимальную плату. «Показатель успеха был высоким - что-то вроде более 90%. Было интересно посмотреть, как можно обойти даже антиавтоматизацию за небольшие деньги», - говорит он.

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

Изменение данных заголовка HTTP, чтобы избежать обнаружения

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

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

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

Географическое распределение запросов API для отмены списков запретов и разрешений

Списки разрешенных и запрещенных IP-адресов опосредуют вызовы внутреннего API и могут быть настроены для блокировки сетевого подключения, если вызов API исходит с IP-адреса или пространства, которые, как известно, являются вредоносными. Чтобы предотвратить это, злоумышленники используют прокси-серверы, чтобы попытки входа в систему выглядели так, будто они исходят из разных мест.

«Этот метод может геолоцировать злоумышленника в другой стране, где он может проживать, и приводит к тому, что сетевые защитники наблюдают за пакетами, исходящими с исходного IP-адреса, который не генерировал трафик», - рассказал старший аналитик по киберугрозам в Digital Shadows Крис Морган. Он добавил, что злоумышленники используют сетевые туннели для маскировки исходного IP-адреса и геолокации, что затрудняет атрибуцию для сетевых защитников.

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

По словам Исбитски, облачные IP-адреса, особенно с контейнерными формами вычислений, слишком эфемерны, чтобы организации могли идти в ногу с ними с помощью списков разрешенных/запрещенных IP-адресов. «Если и когда CSP завоюет популярность, злоумышленник перейдет к новым формам вычислений или новым CSP. Подобно ограничению скорости, защита безопасности должна быть более динамичной, чтобы она могла определить, когда злоумышленник перемещается, откуда исходят его запросы API, или когда он проявляет оскорбительное поведение», - спрогнозировал эксперт.

Предотвращение атак с заполнением учетных данных

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

Двухфакторная аутентификация - это следующий лучший шаг, говорит Хант, указывая на то, что такая базовая аутентификация, как SMS-аутентификация, полезна и проста в реализации. «Предоставление инструментов людям - хорошая идея, и вопрос в том, что происходит в фоновом режиме, не слишком сильно мешая процессу входа в систему. Мы не хотим делать что-то, что мешает людям пользоваться сервисом с минимальными трудностями».

Оттуда могут быть введены более сложные пороги достоверности, которые срабатывают, когда появляется комбинация красных флажков входа в систему, которые требуют дополнительных проверок аутентификации. «Если наша уверенность падает ниже определенного порога, мы можем сказать: вы указали правильное имя пользователя и пароль, но это звучит не совсем правильно, поэтому мы отправили вам электронное письмо с токеном подтверждения, и если это всего лишь один клик , это не так уж плохо с точки зрения пользователей», - говорит Хант.

Наконец, и это, возможно, самое главное, Хант советует организациям четко понимать значения рисков для всего спектра своих услуг и измерять влияние потенциально подозрительных входов в систему на каждую из них в отдельности. «Одно дело, если кто-то зашел в мою учетную запись Chrome, чтобы прокомментировать фотографии кошек, и совсем другое дело, если они вошли в криптовалютный кошелек. Таким образом, должны быть соразмерные меры контроля риска и воздействия», - отметил он.