Archive | May 2019

RDP_CVE-2019-0708

Маєте в мережі Windows XP,7 чи Server 2003 – 2008 (R2)?
Поставте виправлення “дірки” у службі RDP.
Вразливість дозволяє виконання довільного коду без участі користувача.
Це _реально_ важливо, бо саме ця вразливість може бути використана для розповсюдження по мережі (як було із WannaCry та NotPetya).
Microsoft заявляє що вразливість поки не експлуатується “in the wild”, але це не надовго.
Дослідники, які мають доступ до коду експлойту підтверджують його небезпеку:

Патчі для застарілих систем (XP, 2003) беріть тут.
Не будьте жертвою. Оновіться вчасно.

Посилання на виправлення, ще раз:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708
https://support.microsoft.com/en-US/help/4500705/customer-guidance-for-cve-2019-0708

І не публікуйте системи із RDP в Інтернет.
Серйозно. Крім патчів, перевірте свої public IP.

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

VR

#OptiData #VR #safeneversleeps #RDP #CVE_2019_0708

Advertisements

Fxmsp_AdvIntel_McAfee

Усім доброго вечора.

Нещодавно в мережі було опубліковано інформацію про компрометацію трьох виробників антивірусного програмного забезпечення.
Вчора ввечері замовники McAfee отримали розсилку (SNS) стосовно цього інциденту:

У багатьох виникли питання – чи варто хвилюватися?
Ми зі свого боку дослідили ситуацію.

Основні тези (коротко):

#1 Офіційна позиція McAfee на зараз – за фактами опублікованого AdvIntel проводиться розслідування.
Поки що реальних доказів чужої присутності не виявлено. У разі виявлення фактів компрометації компанія не збирається це замовчувати.

#2 Станом на сьогодні ми звернулись до McAfee за подробицями. Очікуємо від них більше конкретики.

#3 Компанія AdvIntel, яка на даний момент залишається єдиним (і поки не підтвердженим) джерелом інформації, до цієї публікації не з’являлася в інформаційному полі.
Їх офіційний сайт та сторінки у соц. мережах були створені на початку травня перед публікацією розслідування. Поки достовірної інформації обмаль, та ще зарано говорити про маніпуляції, але не варто відкидати і таку можливість.

#4 Фактично усі докази компрометації базуються на крихтах інформації, опублікованих AdvIntel.


Дві інші компанії (Trend Micro та Symantec), про які йдеться у публікації AdvIntel, обмежились суперечливими і не чіткими заявами.
Symantec спростовує можливість проникнення, а Trend Micro припускає часткове проникнення на некритичні системи.

Ми розуміємо серйозність даної ситуації.

Саме тому ми закликаємо вас зберігати спокій і чекати на остаточне підтвердження або спростування факту компрометації систем McAfee.

Залишайтесь з нами. Як тільки ми отримаємо нову інформацію – ми вас повідомимо.

Посилання на саме розслідування та додаткові деталі:
https://www.advanced-intel.com/blog/top-tier-russian-hacking-collective-claims-breaches-of-three-major-anti-virus-companies
https://www.bleepingcomputer.com/news/security/hackers-selling-access-and-source-code-from-antivirus-companies/
https://www.bleepingcomputer.com/news/security/new-details-emerge-of-fxmsps-hacking-of-antivirus-companies/
https://www.bleepingcomputer.com/news/security/fxmsp-chat-logs-reveal-the-hacked-antivirus-vendors-avs-respond/

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

OptiData LLC

VR

IOC_digest_04_2019

(Зразки за квітень 2019го)

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

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

08/04/19

розсилали #AZORult, .ZIP > .LNK > GET .HTA > PowerShell > GET .GIF(EXE) > %Public%\???.exe > %AppData%\0mbii\gsir.exe , звіт

11/04/19

розсилали #revengeRAT, .xlam / .doc > mshta GET pastebin1 > powershell > GET pastebin2 (base64) > run decoded exe in memory(!) , звіт

22/04/19

розсилали #formbook, attach .RAR > .EXE  , звіт

25/04/19

розсилали #nanocore, attach .doc (RTF) > OLE > 2 excel > macro_URLDownloadToFileA > GET 1 URL > .exe , звіт

– – – – – – – – – – – – – – – – – – – – – – –

Аналітика

Методи доставки

Якщо розбити по категоріям, тоді отримаємо

  • exe/scr (без приманки) – 1 розсилка
  • RTF (OLE) – 2 розсилки
  • макроси – 2 розсилки
  • powershell2 розсилки

Схоже, що документи із вразливістю 11882 та скрипти WSH втрачають позиції. Або просто на них вже не звертають уваги.

Для обходу фільтрів були застосовані наступні кроки:

  • обфускація команд PowerShell (2);
  • Документи з макросами (1) та документи з OLE (1)

Тенденції

  • PowerShell залишається одним із основних інструментів доставки та виконання payload
  • Доставку та трафіку зі С2 все частіше переводять на HTTPS або ж кодують через B64/XOR
  • Крім 1 зразка, усі інші, залишають сліди через закріплення в реєстрі ОС
  • Посилюється роль додатків MS Office в завантаженні payload

Цікавими з технічної точки зору за березень виявилися два випадки:

  • #revenge #RAT за 11/04 – powershell декодував payload і виконував його в своєму контексті
  • #nanocore #RAT за 25/04 – приманка була подвійною, у RTF файлі через OLE були дві таблиці Excel із макросами

Загалом, усе, що присилали в березні могло створити інциденти тим організаціям які:

  • не оновлюють MS Office та ОС
  • не блокують запуск макросів
  • не відмовилися від RTF
  • не заборонили виклик PowerShell та інших вбудованих механізмів ОС (mshta, cmd etc)
  • не контролюють GET запити на Proxy по User Agent

Узагальнені контрзаходи

  • встановлення виправлень MS Office
  • посилена фільтрація вмісту приєднань – як по типу так і по розширенню
  • заборона запуску cmd, powershell та ?script для рядових користувачів
  • блокування web запитів з пустим або застарілим полем User Agent

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

VR

RevengeRAT або пацюк від Gorgon Group

“Я, видите ли, давно уже отвык рассуждать о человечестве в целом.

Человечество в целом слишком стационарная система, ее ничем не проймешь.”

(c) Валентин Пильман, “Пикник на обочине”

Усім доброго дня.

Продовжуємо розбирати цікаві, нетипові методи зараження.

Цього разу нашим піддослідним буде #RevengeRAT

#1 Метод доставки

З першого погляду цей лист було дуже легко сплутати з масовим фішингом який мав принести типовий #LokiBot, #Trickbot або ж #ursnif

  • підпис відсутній
  • два приєднання, одне з яких .xlam (!)
  • домен відправника не викликає довіри

 

#2 Інфікування

Якщо поштові фільтри не спрацювали належним чином і жертва, не дивлячись на ознаки обману, відкриє будь-яке із приєднань, відбувається виклик службової утиліти mshta, яка призведе до завантаження першої частини інструкцій. Цього разу код розмістили на відомому сервісі pastebin. Обфускація мінімальна:

Як можна помітити  з коду, нападники розраховували заразити системи з антивірусом Avast і сподівалися на те, що приманку запустить користувач з привілеями адміністратора. Поки усе начебто стандартно, але зверніть увагу на виклик PowerShell:

forfiles /c “”cmd /c powershell -noexit [ReFlEcTiOn.AsSeMbLy]::LoAd([CoNvErT]::FrOmBaSe64StRiNg…

Таак, а це вже цікаво. По-перше, знову декодування із Base64 за другим посиланням (теж на pastebin):

Але важливіше інше – ключ -noexit. Значить декодувати зібралися не інструкції для PowerShell а саме тіло основної частини.

Що це їм дає? Обробка першої частини інструкцій спричиняє запуск Powershell, а далі…

На відміну від попередніх прикладів, цього разу дочірнього процесу не з’являється:

Ще раз – за другим посиланням powershell забирає та декодує тіло основної частини.

Але не пише її на диск і продовжує виконувати її у своєму контексті.

Збоку це виглядає як проведення усіх операцій від імені довіреного системного процесу powershell:

Зауважте також елегантне закріплення – через довірений системний mshta із посиланням не на файлову систему (як ми уже звикли)а на друге посилання.

Тобто, при перезавантажені ОС основне тіло буде щоразу збиратися знову з “0”.

Це дозволяє досягти одразу 2х цілей:

  • захист від очистки файлової системи
  • оперативна заміна функціоналу шляхом заміни коду за посиланням

 

#3 Комунікація із С2

Кодована і відбувається по не шифрованому каналу:

 

#4 Висновки

Повний звіт із маркерами по даному зразку тут https://pastebin.com/JKMHyvgx

Отже, якщо не брати до уваги досить явні приманки (xlam та RTF) і не враховувати явних спроб зупинити процеси Avast і Windows Defender, то слід виділити наступні речі:

  • використання pastebin для хостингу інструкцій та payload
  • доставка через два документи (макрос та RTF з OLE) з передачею команд на mshta та powershell
  • mshta > powershell але без запуску окремого процесу для payload
  • закріплення не через файлову систему, довантаження з мережі
  • інфікування проходить з правами звичайного користувача

Проблеми будуть у тих, хто:
– Не контролює запуск mshta та powershell від імені користувача
– Не блокує макроси та не оновлює пакет MS Office

 

– – –  // Бонусний контент для уважних та допитливих

Практичні контрзаходи по цьому зразку (в порядку протікання зараження):

  1. Посилена фільтрація приєднань як за типом так і за розширенням (xlam, dotm і таке інше)
  2. Використання sandbox
  3. Навчання користувачів протидії фішингу
  4. Заборона активації макросів
  5. Оновлення пакету MS Office та ОС
  6. Відмова від RTF як застарілого та небезпечного формату
  7. Контроль/заборона виклику mshta
  8. Контроль/заборона виклику Powershell
  9. Блокування мережевого трафіку для Powershell
  10. Контроль/заборона GET запитів із нетиповим/пустим полем User Agent на рівні Web Proxy
  11. Контроль за зміною параметрів автозавантаження додатків (реєстр, задачі, служби)

– – –  // Бонусний контент для уважних та допитливих

 

Ось і все. До наступного зразка.

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

VR

Mozilla Firefox – деактивовано плагіни

4/05/19 сплив термін дії сертифікату, яким підписували плагіни популярного браузера Mozilla Firefox.

Це призвело до того, що браузер завантажується без плагінів/розширень.

Якщо ви користуєтесь будь-яким плагіном для Firefox – Adblock чи NoScript або ж розширення клієнт-банку, вам необхідно оновитися до версії 66.0.4

Проблема глобальна для усіх версій Firefox (до 66.0.4) на усіх платформах.

Якщо для вашого дистрибутиву ще не доступне оновлення, можна відновити роботу плагінів через Firefox Studies, але це потребує активації телеметрії:

Детальніше про суть проблеми тут https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/comment-page-1/

Завантажити оновлення тут https://www.mozilla.org/uk/firefox/new/

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

VR

McAfee DLP 11.3 vs Google Chrome

Усім привіт. Маю добру звістку для користувачів McAfee DLP.

Як ви певне пам’ятаєте, влітку 2018го з оновленням Google Chrome до версії 68 правила класу Web Protection перестали блокувати публікацію даних.

Багатьом замовникам довелося пристосовуватися і шукати workaround щоб не було витоків через Chrome.

Розробники McAfee дбають про рішення і тому обіцяють повернути контроль над Chrome у DLP 11.3:

… we are re-introducing functionality supporting the blocking of Chrome file uploads in the DLPe product. This feature will provide blocking capability for all Chrome versions; there will be no need for an updated offset.xml file for each new Chrome release.

McAfee SNS Notice

Нагадую, що поточна версія McAfee DLP зараз – 11.2

Оновлення 11.3 з підтримкою блокування Google Chrome очікується:

  • RTS (release to support) – в травні 2019
  • GA (global availability) – в червні 2019

Таким чином, орієнтовно вже в середині травня можна буде отримати 11.3 через запит у підтримку.

Що стосується правильного циклу оновлення/переходу на іншу версію DLP Endpoint, то тут McAfee зазначає наступне:

If you are currently running DLP v11.2, you may continue to do so; support will assist with troubleshooting any issues encountered. However, any hotfixes if needed, will be based on DLP v11.3. Likewise, future update releases will be based on DLP v11.3. Upgrading to DLP v11.3 follows the standard upgrade process. We will offer assistance to any customer that requests help with the upgrade process.

If you are currently considering upgrading to DLP v11.2, we kindly ask you to please wait a few more weeks for the release of DLP v 11.3 so that you can benefit from the new feature and future updates.

McAfee SNS Notice

Якщо ви вже перейшли на 11.2 – ви можете продовжувати користуватись нею і після виходу 11.3 (червень 2019), але усі подальші виправлення та оновлення будуть випускатися уже для версії 11.3. Тому раджу не затримуватися на 11.2, навіть якщо контроль Chrome не входить у перелік ваших пріоритетів.

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

Якщо хочете бути  в курсі оновлень та зміни функціоналу рішень McAfee – підписуйтеся на розсилки SNS тут.

Про доступність версії 11.3 та роботу з Chrome повідомлю додатково.

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

VR