Две недели назад, когда мы сообщили об обнаружении шпионской программы Flame, мы говорили о том, что не усматриваем никакого совпадения в её коде или стиле программирования с платформой Tilded, на которой были основаны Stuxnet и Duqu.

Flame и Tilded совершенно разные проекты, основанные на разной архитектуре, и каждая использует свои уникальные трюки. Так, например, во Flame никогда не использовались драйвера, тогда как для Stuxnet и Duqu именно драйвер был основным способом загрузки модулей на исполнение.

Но мы оказались неправы. Неправы в том, что считали Flame и Stuxnet независимыми проектами.

Наше исследование выявило неизвестные ранее факты, которые полностью изменяют существующую на данный момент историю создания Stuxnet.

Flame внутри Stuxnet

Для начала необходимо вспомнить историю Stuxnet. Как считается, всего было создано три варианта этого червя – в июне 2009 года и в марте и апреле 2010.

Вариант от марта 2010 года вызвал наибольшее число заражений и был обнаружен в июне 2010 специалистами белорусской компании «ВирусБлокАда». Именно этот вариант и подвергся наиболее детальному исследованию со стороны антивирусных компаний.

Чуть позднее, когда о Stuxnet уже стало широко известно, были выявлены его файлы, относящиеся к июню 2009 года. Это так называемый Stuxnet.A (1.0), который достаточно сильно отличается от вариантов 2010 года.

Основными отличиями считались:

• Вариант 2009 не использует уязвимость в обработке LNK-файлов (MS10-046).
• В 2009 году Stuxnet содержал только один файл драйвера, в то время как в 2010 их стало два (второй был добавлен именно для распространения при помощи LNK-уязвимости).
• В 2009 году Stuxnet использовал трюк с autorun.inf для заражения USB-дисков.

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

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

Список ресурсов в Stuxnet 2010 года

Список ресурсов в Stuxnet 2009 года

Несмотря на то, что Stuxnet был объектом детального исследования многих компаний и экспертов, и об его устройстве написано множество текстов, каким-то образом ресурс 207 от 2009 года остался практически неисследованным. Но именно он и оказался тем самым связующим звеном между, казалось бы, совершенно разными проектами – Flame и Stuxnet.

История Tocy

В октябре 2010 года наша автоматическая система обработки получила из «дикой природы» файл. Он был автоматически проанализирован и классифицирован как новый вариант Stuxnet – Worm.Win32.Stuxnet.s.

Stuxnet в тот момент был громкой темой, и мы посмотрели на файл более внимательно, пытаясь понять, что же это такое. Выяснилось, что он не был похож на Stuxnet от 2010 года, отличия были весьма значительными. Посетовав на «глупую автоматическую систему», мы решили переименовать его в Trojan-Spy.Win32.Tocy.

Когда в 2012 году мы обнаружили Flame, мы стали искать старые экземпляры этого червя, которые могли быть получены нами ранее. Среди файлов, которые выглядели почти идентичными Flame, мы нашли Tocy.

Проверив в логах историю обработки файлов, мы установили, что изначально этот файл был классифицирован как Stuxnet. Мы задумались — как это могло произойти? Почему система думала, что этот образец Flame был связан со Stuxnet? Более детальный анализ логов показал, что Tocy, один из ранних модулей Flame, в действительности очень похож на 207 ресурс из Stuxnet.

Они настолько похожи, что наша автоматическая система посчитала его Stuxnet-ом. Более того, Tocy похож только на Stuxnet — и ни на какой другой файл в нашей коллекции.

Вредоносная программа Flame использует для своего распространения несколько различных методов. Наиболее интересный – использование службы Microsoft Windows Update. Этот метод реализован в модулях SNACK, MUNCH и GADGET, входящих в состав Flame. Будучи составными частями Flame, эти модули легко поддаются перенастройке. Поведением этих модулей управляет глобальный реестр Flame – база данных, содержащая тысячи вариантов настроек.

SNACK: подмена NBNS

Модуль SNACK создает сетевой RAW-сокет для всех или предопределенных сетевых интерфейсов, после чего начинает получать все сетевые пакеты. Он ищет пакеты NBNS, посылаемые другими машинами, которые ищут в локальной сети компьютеры с определенными именами. При получении такого пакета он записывается в зашифрованный файл (“%windir%\temp\~DEB93D.tmp”) и передается на дальнейшую обработку.

Когда имя в запросе NBNS имеет вид «wpad*» или «MSHOME-F3BE293C», модуль SNACK отвечает отправкой IP-адреса компьютера, на котором он установлен. Если для переменной SNACK.USE_ATTACK_LIST установлено значение «True», то модуль также проверяет, какие из пакетов отправлены с IP-адресов, указанных в его списке SNACK.ATTACK_LIST, и отвечает тем машинам, адреса которых найдены в списке.

Wpad – это имя, используемое для автоматического обнаружения прокси-сервера. Отвечая на запросы «wpad» собственным IP-адресом, модуль SNACK объявляет зараженную машину прокси-сервером в локальной сети.

Модули SNACK и MUNCH также обмениваются данными с модулем GADGET, обеспечивающим обработку различных событий, приходящих из других модулей. Реестр Flame содержит модули, написанные на языке Lua, для обработки таких событий, как «MUNCH_ATTACKED», «SNACK_ENTITY.ATTACK_NOW».

MUNCH: поддельный прокси-сервер и перехват запросов в службу Windows Update

«MUNCH» – имя модуля Flame, выполняющего функции HTTP-сервера. Модуль запускается, только если переменная MUNCH.SHOULD_RUN установлена в значение «True» и не выполняются никакие программы, способные оповестить жертву о заражении. Эти программы (антивирусы, сетевые экраны, сетевые снифферы и т.д.) определены в реестре Flame в списке под названием «SECURITY.BAD_PROGRAMS»

При запуске модуля MUNCH он считывает буфер из переменной MUNCH.WPAD_DATA, заменяет шаблон «%%DEFAULT%%» IP-адресом наилучшего подходящего сетевого интерфейса и ожидает HTTP-запросов.

Содержимое переменной MUNCH.WPAD_DATA

Буфер MUNCH.WPAD_DATA – это фактически WPAD-файл, запрашиваемый сетевыми клиентами, в которых включено автоматическое обнаружение прокси-сервера. Код в файле WPAD сопоставляет MD5-хеш имени хоста, с которым соединяется клиент, с собственным списком и, если значение хеша найдено в списке, предлагает себя в качестве HTTP прокси-сервера. Нам удалось определить имена, соответствующие хешам:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com

Таким образом, когда компьютер, на котором настроено автоматическое определение прокси-сервера, пытается установить соединение с одним из серверов Windows Update, он получает от модуля SNACK IP-адрес зараженной машины, а затем получает IP-адрес той же машины в качестве прокси-сервера из файла wpad.dat, выданного модулем MUNCH. С этого момента все запросы в службу Windows Update проходят через сервер, поднятый модулем MUNCH.

Когда сетевой клиент устанавливает соединение с сервером MUNCH и запрашивает URI, отличающийся от «/wpad.dat» и «/view.php», сервер:

1) Запускает «MUNCH.SHOULD_ATTACK_SCRIPT» – скрипт на Lua, проверяющий, соответствует ли заголовок User-Agent хотя бы одному из шаблонов, указанных в «MUNCH.USER_AGENTS.CAB_PATTERN_*». В имеющихся у нас файлах реестра Flame содержатся следующие шаблоны:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Проверяет, соответствуют ли запрашиваемые URI какому-нибудь из шаблонов, указанных в списке строк под названием «MUNCH.GENERIC_BUFFERS.*.data.PATTERN». Если одно из выражений соответствует запрашиваемому, сервер получает буфер, указанный в соответствующем значении «MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA», считывает значение имени вредоносного модуля в переменной «MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA» и отправляет соответствующий вредоносный модуль клиенту.

Все вредоносные модули перечислены в реестре Flame под именами, начинающимися с «MUNCH.GENERIC_BUFFERS_CONTENT.payload_name», и зашифрованы с помощью алгоритма RC4 с фиксированным 104-байтным ключом.

Шаблон URI	Имя вредоносного модуля
*v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab*	WUREDIR
*/v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab*	WUSETUP
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab*	XP_WUIDENT
*v5/redir/wuredir.cab*	XP_WUREDIR
*download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/ AU/x86/XP/en/wusetup.cab*	XP_WUSETUP
*muauth.cab*	MUAUTH
*muredir.cab*	MUREDIR
*muident.cab*	MUIDENT
*/version_s.xml	VISTA_7_VERSION_S
*/version.xml	VISTA_7_VERSION
*v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab*	VISTA_7_WUREDIR
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab*	VISTA_7_WUSETUPHANDLER
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab*	VISTA_7_WUCLIENT
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab*	VISTA_7_WSUS3SETUP
*v9/windowsupdate/selfupdate/wuident.cab*	VISTA_7_WUIDENT

Большинство вредоносных модулей представляют собой подписанные CAB-архивы. Архивы, содержащие вредоносный код, подписаны «MS» в декабре 2010 и ноябре 2011 года, в то время как остальные архивы, по-видимому, действительно взяты из настоящей службы Windows Update и подписаны «Microsoft Corporation».

Имена вредоносных модулей	Содержимое	Подпись
WUREDIR_VISTA_7_WUREDIR_	wuredir.xml	Microsoft Corporation_01 июля 2009 г.
WUSETUP	Default/wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _Default/wuconf.ini _Default/wusetup.ocx _wsus3setup.cat _wsus3setup.inf _wuapplet2.ocx _wuaucom.dat _wuauinfo.ocx _wuconf.ini _wups2.cab _wups2.cat _wusetup.cat _wusetup.inf _wusetup.ocx_	MS 10 ноября 2011 г.
XP_WUIDENT	wuident.txt	Microsoft Corporation 25 мая 2005 г.
XP_WUREDIR	wuredir.xml	Microsoft Corporation 16 июня 2005 г.
XP_WUSETUP	Default/ wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _wups2.cab _wusetup.cat _wusetup.inf _wusetup.ocx_	MS 28 декабря 2010 г.
MUAUTH	authorization.xml	Microsoft Corporation 05 июня 2008 г.
MUREDIR	wuredir.xml	"Microsoft Corporation 01 июля 2009 г.
MUIDENT	muident.txt	MS 28 декабря 2010 г.
VISTA_7_VERSION_S	отсутствует	не подписано
VISTA_7_VERSION	92 bytes, not a CAB file	не подписано
VISTA_7_WUSETUPHANDLER	WuSetupV.exe	MS 28 декабря 2010 г.
VISTA_7_WUCLIENT	update.cat _update.mum_	MS 28 декабря 2010 г.
VISTA_7_WSUS3SETUP	WUClient-SelfUpdate- ActiveX~31bf3856ad364e35~x86~ ~7.0.6000.381.mum _WuPackages.xml_	MS 28 декабря 2010 г.
VISTA_7_WUIDENT	wuident.txt	MS 28 декабря 2010 г.

Поскольку CAB-файлы имеют действительные подписи (на данный момент отозванные Microsoft), служба Windows Update принимает и обрабатывает их как обычные обновления Windows. Они загружаются и устанавливаются, что приводит к выполнению вредоносного модуля.

Основной вредоносный модуль, содержащийся в этих CAB-файлах, представляет собой компонент-загрузчик под названием «Wusetup.ocx» или «WuSetupV.exe». Он собирает общие данные о компьютере, в т.ч. информацию о часовом поясе, и пытается обратиться к «http://MSHOME-F3BE293C/view.php», причем к URI в запросе добавляется информация о хосте. Поскольку имя «MSHOME-F3BE293C» обрабатывается модулем SNACK, URL указывает на действующий сервер MUNCH, который обслуживается главным модулем Flame «mssecmgr.ocx».

WuSetupV загружает этот файл, сохраняет его в «%windir%\Temp\~ZFF042.tmp», загружает его как DLL и запускает его функцию «DDEnumCallback», представляющую собой процедуру установки Flame. Таким образом, еще один компьютер оказывается заражен.

Даже «лучше», чем эксплойт нулевого дня

Сразу же после того, как мы обнаружили Flame, мы принялись искать в его коде хотя бы один эксплойт, использующих уязвимость нулевого дня для распространения Flame и заражения других машин в локальной сети. Учитывая сложность программы и тот факт, что она заражала машины, работающие под управлением Windows 7 с установленными необходимыми обновлениями, такой эксплойт должен был присутствовать. То, что мы обнаружили, даже «лучше» любого эксплойта нулевого дня. Это, скорее, напоминает чит-код в компьютерной игре, который включает «режим бога» – код, подписанный сертификатами, которые изначально были выписаны Microsoft. Цифровая подпись была обнаружена и немедленно отозвана Microsoft, после чего компания сразу же опубликовала информационное сообщение об угрозе (security advisory) и выпустила обновление KB2718704.

27 мая 2012 года иранский координационный центр CERT (MAHER) опубликовал сведения об обнаружении новой целевой атаки, получившей название Flamer. 28 мая в 9 часов утра (часовой пояс восточного побережья США — EST) после проведения расследования, организованного по просьбе Международного союза электросвязи, «Лаборатория Касперского» и венгерская лаборатория CrySyS Lab объявили об обнаружении вредоносной программы Flame (она же Skywiper) — сложнейшего набора инструментов для кибершпионажа, мишенями которого стали прежде всего Windows-компьютеры в странах Ближнего Востока.

Несколько часов спустя, около 4 часов пополудни по Гринвичу, была отключена инфраструктура командных серверов Flame, проработавшая несколько лет.

В течение последних недель «Лаборатория Касперского» осуществляла детальный мониторинг инфраструктуры командных серверов (C&C) Flame. В сотрудничестве с GoDaddy и OpenDNS нам удалось переключить на sinkhole-маршрутизатор большинство вредоносных доменов, используемых инфраструктурой C&C Flame, и получить уникальные сведения о работе этой вредоносной программы.

«Лаборатория Касперского» хотела бы поблагодарить отдел по борьбе с сетевыми злоупотреблениями GoDaddy (GoDaddy Network Abuse Department) и Уильяма МакАртура (William MacArthur) за их быстрый отклик и неоценимую поддержку этого расследования. Группа исследования проблем безопасности OpenDNS (OpenDNS security research team) также оказала нам ценнейшее содействие в ходе расследования.

Результаты нашего анализа инфрастуктуры Flame приведены ниже.

Введение

Поскольку похоже, что и Flame, и Duqu нацелены на одни и те же регионы и создавались с учетом аналогичных целей, мы приводим сравнительный анализ инфраструктуры C&C-серверов Flame и Duqu.

Ранее «Лаборатория Касперского» проводила анализ инфраструктуры C&C-серверов Duqu и обнаружила несколько важных деталей (например то, что киберпреступники предпочитают CentOS и используют SharpSSH для контроля прокси-серверов), а также большое количество атакованных прокси-серверов, используемых для сокрытия подлинной identity киберпреступников.

В инциденте с Flame мы провели похожий анализ. Прежде всего, интересным является отличие от Duqu: в то время как все известные C&C Duqu работали под CentOS, все известные C&C Flame функционируют на Ubuntu.

Помимо этого, если Duqu использовал очень незаметный способ сокрытия настоящего IP-адреса основного сервера, используя для передачи SSH-порт, скрипты Flame просто работают на соответствующих серверах. Причина проста — в понедельник 28 мая все контрольные скрипты начали показывать ошибки 403/404. В случае с Duqu реальные вредоносные скрипты находились на удаленном сервере и не были ни разу обнаружены.

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

Ниже мы приводим сравнение инфраструктуры C&C-серверов Duqu и Flame:

Как уже упоминалось в прошлом блогпосте про Flame, его объем кода и функциональность настолько обширны, что их полный анализ займёт несколько месяцев. Мы планируем по мере обнаружения публиковать наиболее важные и интересные подробности, связанные с его функционалом.

В данный момент мы получаем множество запросов о том, как проверить компьютеры на наличие заражения Flame. Естественно, самый простой ответ (для нас) — это посоветовать использовать Анитвирус Касперского или Kaspersky Internet Security. Наши продукты успешно детектируют и удаляют все возможные модификации главного модуля и дополнительных компонентов Flame.

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

MSSECMGR.OCX

Основной модуль Flame — это DLL-файл под названием mssecmgr.ocx. Мы обнаружили две модификации этого модуля. На большинстве заражённых машин содержалась «большАя» версия — 6 Мбайт, которая содержит в себе и развёртывает дополнительные модули. «Малая» версия весит всего 900 Кбайт и не содержит дополнительных модулей. После установки малый модуль соединяется к одному из C&C-серверов и пытается загрузить оттуда и установить оставшиеся компоненты.

Вирусы Duqu и Stuxnet повысили градус кибервойны на Ближнем Востоке, однако недавно мы обнаружили, пожалуй, самое изощренное кибероружие на сегодняшний день. Червь Flame, созданный для кибершпионажа, попал в поле зрения экспертов «Лаборатории Касперского» при проведении исследования по запросу Международного союза электросвязи (МСЭ), обратившегося к нам за содействием в поиске неизвестной вредоносной программы, которая удаляла конфиденциальные данные с компьютеров, расположенных в странах Ближнего Востока. В процессе поиска этой программы, получившей название Wiper, мы обнаружили новый образец вредоносного ПО, который был назван Worm.Win32.Flame.

Хотя Flame имеет иной функционал, чем печально известные образцы кибероружия Duqu и Stuxnet, все эти вредоносные программы имеют много общего: географию атак, узкую целевую направленность в сочетании с использованием специфических уязвимостей в ПО. Это ставит Flame в один ряд с «кибернетическим супероружием», развертываемым на Ближнем Востоке неизвестными злоумышленниками. Без сомнения, Flame является одной из самых сложных киберугроз за всю историю их существования. Программа имеет большой размер и невероятно сложную структуру. Она заставляет переосмыслить такие понятия, как «кибервойна» и «кибершпионаж».

Подробную информацию об этой изощренной угрозе читайте ниже.

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

В тематической встрече на министерском уровне приняли участие вице-президент Еврокомиссии по развитию цифровых технологий Нели Крус (Neelie Kroes), комиссар по внутренним делам ЕС Сесилия Мальмстрём (Cecilia Malmström) и глава департамента внутренней безопасности США Джанет Наполитано. Они определили также приоритетные сферы деятельности совместной Рабочей группы по кибербезопасности и борьбе с киберпреступностью. Эта специализированная группа была учреждена в ноябре прошлого года и занимается разработкой методик коллективного противостояния растущим киберугрозам и киберпреступности.

В числе важных направлений совместных усилий участники встречи назвали активное взаимодействие с частным сектором в таких областях, как борьба с ботнетами, безопасность систем управления промышленными объектами, надежность сетевых ресурсов. Повысить качество и оперативность реакции на киберинциденты поможет реализация межгосударственной программы спецподготовки, по итогам которой полезно будет провести совместные киберучения для представителей США и ЕС. В ходе совещания было также отмечено, что укрепление связей с регистраторами доменов и администраторами реестров в борьбе с распространением детской порнографии в интернете дает положительные результаты и остается важной сферой международного сотрудничества.

США уязвимы для стратегических кибератак со стороны внешних врагов. С таким заявлением выступили перед членами комитета Палаты представителей по внутренней безопасности эксперты в области информационной защиты, сообщает сайт Darkreading.com. В докладе было отмечено, что существующие сейчас меры киберзащиты устарели и оставляют страну уязвимой — «не для обычного оружия, а для кибернетического».

«Мы — нация, которая не готова должным образом защитить себя и восстановиться после стратегической хакерской атаки», — заявил президент некоммерческой ассоциации «Профессионалы за киберзащиту» Сами Сайдьяри (Sami Saydjari). «Зарубежные спецслужбы, должно быть, рыдают от счастья, когда изучают американские государственные сети. Это проблема не гипотетического характера. В течение 20 последних лет мы наблюдали мародерство в американских государственных базах данных», — отметил старший партнер и директор программы при Центре стратегических и международных исследований Джеймс Льюис.

Министерство торговли США отключило от интернета несколько сот компьютеров в результате серии атак со стороны хакеров, предположительно находившихся в Китае, сообщает сайт SecurityFocus.com.

Представители Бюро промышленности и безопасности (BIS) при Министерстве торговли сообщили информационным агентствам, что несколько учетных записей в сети ведомства были взломаны, однако никаких важных данных при этом похищено не было.

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

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

Марокканские хакеры атаковали в среду более 750 израильских сайтов. Массированная хакерская атака стала ответом арабов на военную операцию, которую проводит израильская армия в секторе Газа, сообщает газета Yedioth Ahronoth.

Организаторами атаки оказались участники хакерской группы Team Evil, на счету которой большинство атак на израильский интернет за последний год. Эта атака стала самой крупной. В число организаций и компаний, пострадавших от деятельности марокканцев попали банк «Апоалим», больница «Рамбам», представительства БМВ и «Субару», билетный центр Globus Group. На атакованных ресурсах хакеры разместили текст: «Вы убиваете палестинцев, мы убиваем серверы».

Ежедневно в Израиле подвергаются атаке множество сайтов. Большинство из них — небольшие ресурсы, не имеющие адекватной системы информационной безопасности. Атака Team Evil отличается тем, что в число взломанных сайтов попали исключительно ресурсы крупных компаний и организаций, обладающих средствами защиты от подобных действий.

В прошлом Team Evil удалось взломать сайты нескольких небольших, но известных в Израиле компаний. В апреле марокканские хакеры атаковали десятки сайтов, в том числе сайты детского магазина «Шилав», супермаркета Blue Square и McDonald's. Представитель хакеров и раньше заявлял: «Мы — группа марокканских хакеров, которая взламывает сайты в рамках войны с Израилем. Мы атакуем израильские сайты каждый день. Это наш долг... компьютерные взломы — не преступление». Все члены Team Evil — марокканцы в возрасте до 20 лет.

Рост хакерской активности, следующий за военными операциями, — известный феномен, как в Израиле, так и в остальных частях мира. Подобный всплеск атак как против израильских, так и против арабских сайтов в начале второй интифады.

Исламские террористические и экстремистские группировки из Юго-Восточной Азии не способны проводить интернет-атаки в ближайшее время. В этом убежден глава центра по вопросам политического насилия и терроризма при Сингапурском институте обороны и стратегических исследований Рохан Гунаратна, сообщает Reuters.

Экстремисты стали использовать интернет для вербовки боевиков и сбора финансовых средств, но они не способны проводить кибератаки, считает Гунаратна: «Пройдет очень много времени прежде, чем группировки из Юго-Восточной Азии станут способны атаковать интернет. Вместо того чтобы атаковать интернет, они его используют».

Свое заявление Гунаратна сделал, находясь в Малайзии, на учебных сборах для офицеров служб безопасности Юго-Восточной Азии, проводившихся при поддержке США. Представитель контртеррористических органов Малайзии Йен Йок Хенг заявил собравшимся, что угроза кибератак в регионе реальна, однако не привел никакой конкретной информации: «Угроза реальна. Вопрос не звучит "как" или "что", вопрос звучит "когда". Нам нужна лучшая координация, чтобы быть более готовыми к любым кибератакам со стороны террористов».

Власти Малайзии недавно объявили о намерении создать центр для борьбы с кибератаками, которые могут повлиять на экономическое благополучие любой страны. Премьер-министр Малайзии Абдулла Ахмад Бадави сообщил, что ряд антивирусных компаний («Лаборатория Касперского», Symantec Corporation, Trend Micro) готовы стать ключевыми партнерами в деле борьбе с кибертерроризмом.