Киберпреступники совершенствуют технику обмана аналитиков

Киберпреступники совершенствуют технику обмана аналитиков

Киберпреступники совершенствуют технику обмана аналитиков

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

Об этом эксперты «Лаборатории Касперского» рассказали на форуме Virus Bulletin, который проходит в американском Денвере с 5 по 7 октября. 

Идентификация группировок, которые стоят за целевыми и АРТ-атаками, – вопрос, вызывающий большой интерес как у исследователей угроз, так и у жертв, пострадавших от этих атак. Однако выяснить, кем на самом деле являются злоумышленники, крайне сложно, а зачастую даже невозможно. В немалой степени этому способствуют сами атакующие, тщательно «заметающие» свои следы. На примере некоторых индикаторов атак эксперты «Лаборатории Касперского» объясняют, как они это делают.

Временные метки

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

Языковые метки

Во вредоносных файлах имеются строчки, написанные на определенном языке или языках. Также они могут содержать имена пользователей и внутренние названия операций и кампаний. Казалось бы, сам факт наличия конкретного языка позволяет сделать определенные выводы. Однако ничто не мешает злоумышленникам манипулировать этими уликами и вводить исследователей в заблуждение. Например, во вредоносном ПО, использовавшемся в атаках Cloud Atlas, имелись строки на арабском языке (в версии для BlackBerry) и хинди (для Android). При этом аналитики склонны предполагать, что группировка имеет восточноевропейское происхождение.  

Инфраструктура и серверы

Найти командно-контрольный сервер злоумышленников – все равно что узнать их домашний адрес. Сделать это можно, например, в том случае, если атакующие предприняли недостаточно мер для сокрытия интернет-соединений при отправке данных на сервер или при получении от него команд. Но иногда эти «просчеты» злоумышленники совершают намеренно – так, в той же операции Cloud Atlas с целью запутать аналитиков использовались южнокорейские IP-адреса.   

Инструментарий: вредоносное ПО, коды, пароли, эксплойты

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

Цели и жертвы

Иногда понять, кто стоит за атакой, помогает анализ ее жертв и целей. И злоумышленники прекрасно об этом знают. Именно поэтому они могут работать под ложным флагом, прикрываясь именем какой-либо хакерской группировки, необязательно даже реально существующей. Так, в атаках на Sony Pictures Entertainment в 2014 году группа Lazarus пыталась выдать себя за Guardians of Peace. А организаторы атак Sofacy делали все, чтобы их деятельность приписывали сразу нескольким хактивистам. Наконец, до сих пор еще не до конца изученная группировка TigerMilk подписывала свои бэкдоры тем же украденным сертификатом, которым ранее пользовались организаторы атак Stuxnet.     

«Выяснение происхождения атаки – сложная задача, результаты которой всегда ненадежны и субъективны. А поскольку злоумышленники старательно манипулируют индикаторами атак и заметают следы, то о каких-либо конкретных выводах в плане атрибуции угрозы, на наш взгляд, говорить невозможно. Однако это обстоятельство вовсе не снижает ценность расследований кибератак – рядовые пользователи и специалисты по информационной безопасности должны знать, где и с какими именно угрозами они могут столкнуться и каковы будут их последствия. А мы, в свою очередь, должны предложить им надежную защиту. И в данном случае чем больше мы знаем о методах и целях атакующих, тем лучше мы будем распознавать и предотвращать угрозы», – отметил Брайан Бартоломью, антивирусный эксперт «Лаборатории Касперского».

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

34% тестировщиков применяют ИИ для генерации кода, 28% — для тест-кейсов

2ГИС решила разобраться, как себя чувствует русскоязычное QA-сообщество: чем пользуются тестировщики, как устроены процессы и как в работу проникает искусственный интеллект. В исследовании поучаствовали 570 QA-специалистов, почти половина из них работают в крупных компаниях.

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

Лишь 20% приходят в проект только после завершения разработки. А вариант «подключаюсь, когда в продакшене что-то сломалось» — уже почти экзотика.

89% команд используют автотесты — от юнитов до UI. Но вот инструменты вокруг них, вроде поддержки, аналитики и стабильности, применяют далеко не все. Например, код-ревью автотестов делают только 39% опрошенных, а 28% команд вообще не отслеживают никаких метрик и работают «вслепую».

ИИ используют не все, и в основном — для рутинных задач

Хотя ИИ уже прочно вошёл в мир тестирования, чаще всего его применяют для типовых задач:

  • написание тестового кода (34%),
  • генерация тест-кейсов (28%),
  • и тестовых данных (26%).

 

Более продвинутые сценарии вроде анализа тестов, автоматического поиска багов и визуального тестирования пока используются редко. Например, только 5% автоматизируют дефект-дискавери, и лишь 4% пробуют AI для визуальных проверок. А 22% QA-специалистов вообще не используют ИИ в своей работе.

Главные проблемы в тестировании

На первом месте — сжатые сроки. Об этом сказали 71% участников опроса. На втором — слабое вовлечение QA в процессы (40%) и нехватка квалифицированных специалистов (37%).

Как измеряют качество

  • Главная метрика — количество найденных багов (58%).
  • Покрытие автотестами учитывают 43%, покрытие кода — только 23%.
  • Стабильность тестов (например, чтобы они не «флапали») отслеживают всего 15% команд.

Что будет с профессией дальше? Мнения разделились:

  • 37% считают, что всё уйдёт в тотальную автоматизацию;
  • 35% уверены, что ничего особо не поменяется;
  • почти треть верит, что QA станет глубже интегрироваться в специфические направления вроде ИБ и производительности;
  • 27% видят будущее за DevOps и SRE — то есть тесной работой на всех этапах: от разработки до эксплуатации.
AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru