10 ответов в этой теме

[News Robot]

Скачать в PDF

24 марта 2022 года

В октябре 2021 года в «Доктор Веб» обратилась одна из казахстанских телекоммуникационных компаний с подозрением на наличие вредоносного ПО в корпоративной сети. При первичном осмотре были обнаружены бэкдоры, ранее использовавшиеся лишь в целевых атаках. В ходе расследования удалось установить, что компрометация внутренних серверов компании началась еще в 2019 году. На протяжении нескольких лет основными инструментами злоумышленников были Backdoor.PlugX.93 и BackDoor.Whitebird.30, утилиты Fast Reverse Proxy (FRP), а также RemCom.

Благодаря ошибке хакеров мы получили уникальную возможность изучить списки жертв, а также узнали, какие инструменты управления бэкдорами были использованы. Исходя из добытой информации можно сделать вывод о том, что хакерская группировка специализировалась на компрометации почтовых серверов азиатских компаний с установленным ПО Microsoft Exchange. Однако есть жертвы и из других стран, среди которых:

• государственное учреждение Египта;
• аэропорт в Италии;
• маркетинговая компания из США;
• транспортная и деревообрабатывающая компании из Канады.

В логи, собранные вместе с управляющим сервером, попали жертвы, зараженные с августа 2021 до начала ноября того же года. При этом в некоторых случаях BackDoor.Whitebird.30 был установлен не только на сервер с Microsoft Exchange, но и на контроллеры домена.

На основе использованных инструментов, методов и инфраструктуры мы делаем вывод, что за атакой стоит хакерская группировка Calypso APT.

Remote Rover

Управляющий сервер для BackDoor.Whitebird.30 называется Remote Rover. Он позволяет удаленно запускать приложения, обновлять конфигурацию бэкдора, а также скачивать и загружать файлы. Помимо этого, с помощью Remote Rover можно использовать командную оболочку. Так выглядит интерфейс управляющего сервера:

К Remote Rover прилагался конфигурационный файл CFGdefault.ini, имеющий следующее содержание:

E:个人专用自主研发远程2021RR配置备份telecom.cfgOneClock.exe

Если перевести содержание с китайского языка на английский, то можно получить такой путь:

E:personal useIndependent research and development remote2021RRConfiguration backuptelecom.cfg

Подробные технические описания обнаруженных вредоносных программ находятся в PDF-версии исследования и в вирусной библиотеке Dr.Web.

• BackDoor.Siggen2.3622
• BackDoor.PlugX.93
• BackDoor.Whitebird.30
• Trojan.Loader.891
• Trojan.Loader.896
• Trojan.Uacbypass.21
• Trojan.DownLoader43.44599

Заключение

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

Специалисты компании «Доктор Веб» рекомендуют регулярно проверять работоспособность сетевых ресурсов и своевременно фиксировать сбои, которые могут свидетельствовать о наличии в сети вредоносного ПО. Основная опасность целевых атак заключается не только в компрометации данных, но и в длительном присутствии злоумышленников. Подобный сценарий позволяет им долгие годы контролировать работу организации, чтобы в нужный момент получить доступ к особенно чувствительной информации. При подозрении на вредоносную активность в сети мы рекомендуем обращаться в вирусную лабораторию «Доктор Веб», которая оказывает услуги по расследованию вирусозависимых компьютерных инцидентов. Выявить вредоносное ПО на серверах и рабочих станциях поможет Dr.Web FixIt! Оперативное принятие адекватных мер позволит минимизировать ущерб, а также предотвратить тяжелые последствия целевых атак.

Индикаторы компрометации.

Читать оригинал

[NickM]

А где *.pdf?

 

404 Not Found

nginx/1.14.2

[sergeyko]

А где *.pdf?

 

404 Not Found

nginx/1.14.2

https://st.drweb.com/static/new-www/news/2022/march/telecom_research_ru.pdf

[SergSG]

 Почему то в сабже не написали, какой АВ использовала эта самая "одна из казахстанских телекоммуникационных компаний ".

[Dmitry Shutov]

 Почему то в сабже не написали, какой АВ использовала эта самая "одна из казахстанских телекоммуникационных компаний ".

Да обычно в таких "исследовательских статьях" и не пишут что за АВ был установлен )

 

По больше таких исследований на АРТ.

[SergSG]

 

 Почему то в сабже не написали, какой АВ использовала эта самая "одна из казахстанских телекоммуникационных компаний ".

Да обычно в таких "исследовательских статьях" и не пишут что за АВ был установлен )

Ворон ворону - корпоративная этика? С точки зрения пользователя было бы этичней озвучить название продукта у которого сетевая защита отсутствует или является фикцией. Ну или написать, что компания-жертва некорректно использует АВ, если таковое имело место быть.

[Dmitry Shutov]

 

 

 Почему то в сабже не написали, какой АВ использовала эта самая "одна из казахстанских телекоммуникационных компаний ".

Да обычно в таких "исследовательских статьях" и не пишут что за АВ был установлен )

Ворон ворону - корпоративная этика? С точки зрения пользователя было бы этичней озвучить название продукта у которого сетевая защита отсутствует или является фикцией. Ну или написать, что компания-жертва некорректно использует АВ, если таковое имело место быть.

 

Думаю да - корпоративная этика.

[Ivan Korolev]

 

 

 Почему то в сабже не написали, какой АВ использовала эта самая "одна из казахстанских телекоммуникационных компаний ".

Да обычно в таких "исследовательских статьях" и не пишут что за АВ был установлен )

Ворон ворону - корпоративная этика? С точки зрения пользователя было бы этичней озвучить название продукта у которого сетевая защита отсутствует или является фикцией. Ну или написать, что компания-жертва некорректно использует АВ, если таковое имело место быть.

 

 

Смысла в этом 0. С любым АВ вендором случается так, что в его присутствии кто-то живет и не всегда это вина вендора. Например, АВ может периодически сообщать о проблеме, но администратор будет просто игнорировать уведомления за не достаточностью квалификации/времени/желания и тд. А могут и просто отсутствовать люди, ответственные за разбор инцидентов, мониторинг логов и тд.

 

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

 

Практически любой инцидент - это провал сразу на нескольких уровнях и сваливать всю вину только на АВ продукт или только на админа/безопасника - не правильно.

Сообщение было изменено Ivan Korolev: 24 Март 2022 - 19:46

[SergSG]

Смысла в этом 0. С любым АВ вендором случается так, что в его присутствии кто-то живет и не всегда это вина вендора. Например, АВ может периодически сообщать о проблеме, но администратор будет просто игнорировать уведомления за не достаточностью квалификации/времени/желания и тд. А могут и просто отсутствовать люди, ответственные за разбор инцидентов, мониторинг логов и тд.

 

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

 

Практически любой инцидент - это провал сразу на нескольких уровнях и сваливать всю вину только на АВ продукт или только на админа/безопасника - не правильно.

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

 

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

 

Любой инцидент - это провал, да. Таргетированные атаки имеют свою специфику - они умножают на 0 и базы и эвристик. Есть у Доктора, например, какие то механизмы защиты от подобных атак? Вопрос риторический.

[Dmitry Shutov]

 

Смысла в этом 0. С любым АВ вендором случается так, что в его присутствии кто-то живет и не всегда это вина вендора. Например, АВ может периодически сообщать о проблеме, но администратор будет просто игнорировать уведомления за не достаточностью квалификации/времени/желания и тд. А могут и просто отсутствовать люди, ответственные за разбор инцидентов, мониторинг логов и тд.

 

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

 

Практически любой инцидент - это провал сразу на нескольких уровнях и сваливать всю вину только на АВ продукт или только на админа/безопасника - не правильно.

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

 

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

 

Любой инцидент - это провал, да. Таргетированные атаки имеют свою специфику - они умножают на 0 и базы и эвристик. Есть у Доктора, например, какие то механизмы защиты от подобных атак? Вопрос риторический.

 

 

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

 

И да можно назвать это чутка пиаром, но это нужно.

 

//Есть у Доктора, например, какие то механизмы защиты от подобных атак? - ничего не стоит на месте, все развиваются.

Сообщение было изменено Dmitry Shutov: 25 Март 2022 - 05:59

[SergSG]

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

Двоякое чувство. Что нашли и добавили - это хорошо, конечно. Но вот то, что этот "кладезь" проник и какое то время работал - это напрягает.
 

//Есть у Доктора, например, какие то механизмы защиты от подобных атак? - ничего не стоит на месте, все развиваются.

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