Backdoor ScreenConnect, розгорнутий через шкідливий електронний лист

Резюме

Фішингова кампанія електронною поштою видає себе за Управління соціального забезпечення, щоб доставити шкідливе навантаження. Жертви перенаправляються на фальшивий веб-сайт, що пропонує завантажити інсталятор клієнта ScreenConnect з налаштованим підбором параметрів. Після встановлення програмне забезпечення працює як бекдор, надаючи атакам постійний віддалений доступ до скомпрометованої системи.

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

Розслідування досліджувало заголовки шкідливих електронних листів, фішинговий веб-сайт та відповідний мережевий трафік. Аналітики ідентифікували конкретну IP-адресу, яка використовувалася для доставки фішингових електронних листів, та домен, що розміщував фальшиву цільову сторінку SSA. Мережевий аналіз також підтвердив зашифровані комунікації ScreenConnect через порт 443.

Пом’якшення

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

Відповідь

Якщо виявлено шкідливу активність, уражений хост слід негайно ізолювати, щоб зупинити подальший обмін командами та управління. Респонденти повинні провести повний судово-медичний аналіз, щоб визначити обсяг компрометації. Можливо, піддані ризику облікові дані слід анулювати, а системи перевірити на наявність додаткових механізмів стійкості, впроваджених під час віддаленого сеансу.

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

• Наратив атаки і команди: Зловмисник отримав закріплення на системі та має намір використовувати інстанцію ScreenConnect для підтримання віддаленого доступу. Щоб обійти стандартне виявлення, яке шукає відомі шкідливі IP-адреси, вони використовують офіційний механізм ретрансляції ScreenConnect. Зловмисник виконує з’єднання з instance-udppxf-relay.screenconnect.com через порт 443. Ця дія розроблена так, щоб виглядати як законний зашифрований веб-трафік, але вона конкретно відповідає цільовому домену, визначеному в правилі детекції.

• Сценарій регресійного тестування:

  # Сценарій симуляції: Виклик виявлення домену ScreenConnect
  # Цей сценарій намагається під'єднатися до конкретного домену, який є ціллю правила.
  
  $TargetDomain = "instance-udppxf-relay.screenconnect.com"
  $Port = 443
  
  Write-Host "Спроба з'єднатися з $TargetDomain на порт $Port, щоб викликати детекцію..." -ForegroundColor Cyan
  
  try {
      # Ми використовуємо TCP-клієнт, щоб симулювати спробу з'єднання без потреби у повному веб-стеку
      $TcpClient = New-Object System.Net.Sockets.TcpClient
      $Connect = $TcpClient.BeginConnect($TargetDomain, $Port, $null, $null)
      $Success = $Connect.AsyncWaitHandle.WaitOne(5000, $false)
  
      if ($Success) {
          Write-Host "Успішно встановлено з'єднання з $TargetDomain. Детекція повинна спрацювати." -ForegroundColor Green
          $TcpClient.EndConnect($Connect)
          $TcpClient.Close()
      } else {
          Write-Host "Час з'єднання вичерпано. Домен може бути поза мережею, але спробу все ж слід зареєструвати фаєрволом." -ForegroundColor Yellow
      }
  } catch {
      Write-Host "Виникла помилка: $($_.Exception.Message)" -ForegroundColor Red
  }

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

  # Жодних стійких змін зроблено не було сценарієм. 
  # Просто переконайтесь, що TCP-з'єднання закрито (обробляється у сценарії).
  Write-Host "Очищення симуляції завершено. Артефактів на хості не залишено." -ForegroundColor Green