Windows 11 testing

[rabbitstack]

Hi,

I'm researching UAC bypasses to come up with the respective detection tradecraft and UACME caught my attention. The akagi release binary was produced as indicated in one of the previous issues:

• initial build to generate the DLLs + Akagi binary
• naka to generate AES keys
• naka --stable to produce the secrets
• rebuilt Akagi to embed the DLLs inside PE resource directory

The build output shows the resource compilation stage as below:

  Resource.rc.
  Writing ICON:1,       lang:0x409,     size 7336
  Writing ICON:2,       lang:0x409,     size 3240
  Writing GROUP_ICON:104,       lang:0x409,     size 34.
  Writing VERSION:1,    lang:0x409,     size 792.
  Writing RCDATA:100,   lang:0x409,     size 12336.
  Writing RCDATA:200,   lang:0x409,     size 10960.
  Writing RCDATA:103,   lang:0x409,     size 5520.
  Writing RCDATA:104,   lang:0x409,     size 8432.
  Writing RCDATA:300,   lang:0x409,     size 144

However, running the akagi binary doesn't seem to trigger any method, and I tried a dozen of them. The platform is Windows 11 build 22631. Windows Defender services disabled.

Do you have any clues? Is UACME still relevant in Windows 11?

[hfiref0x]

If something doesn't work as you expected then open solution in MSVS, compile debug version and trace program code execution. Finally, show me your results.

[rabbitstack]

Oddly, the binary generated in Debug mode does work as expected. I'm fine with this, so closing the issue. Thanks for the help!

[hfiref0x]

Debug versions are for debug. They contain code that won't normally work outside of the debugger. It breaks any kind of position independent code and a lot of more. This program must be build in Release.

[rabbitstack]

That's weird, because executing a couple of methods resulted in spawning an elevated cmd. I'll try attaching the debugger and get back to you with the findings

[hfiref0x]

Methods that doesn't require anything specific, e.g. registry manipulations, will work fine in all build configurations.

[rabbitstack]

I'm exercising the elevated COM interface technique. Does it pertain to the category of simple methods you're calling out above?

[hfiref0x]

Yes

[rabbitstack]

The debugger is revealing the following exception raised in Akagi\stub.c line 75:

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2875

    Key  : Analysis.Elapsed.mSec
    Value: 24601

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

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

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

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

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

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

    Key  : Failure.Bucket
    Value: INTEGER_DIVIDE_BY_ZERO_c0000094_Akagi.exe!StubInit

    Key  : Failure.Hash
    Value: {2895f328-1204-a57e-8395-38364b51a212}

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 2740

    Key  : Timeline.Process.Start.DeltaSec
    Value: 36

    Key  : WER.OS.Branch
    Value: ni_release

    Key  : WER.OS.Version
    Value: 10.0.22621.1

    Key  : WER.Process.Version
    Value: 3.6.6.2403

NTGLOBALFLAG:  70

APPLICATION_VERIFIER_FLAGS:  0

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ff780323fbb (Akagi!StubInit+0x00000000000000bb)
   ExceptionCode: c0000094 (Integer divide-by-zero)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00001d00

PROCESS_NAME:  Akagi.exe

ERROR_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION}  Integer division by zero.

EXCEPTION_CODE_STR:  c0000094

STACK_TEXT:  
000000e2`0f12f480 00007ff7`8030f597     : 00007ff7`8030674e 00000000`00000000 00000000`00000000 00000000`00000000 : Akagi!StubInit+0xbb
000000e2`0f12f650 00007ffa`c4b4257d     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Akagi!main+0x27
000000e2`0f12f750 00007ffa`c5f8aa48     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x1d
000000e2`0f12f780 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28

FAULTING_SOURCE_LINE:  C:\<redacted>\UACME\Source\Akagi\stub.c

FAULTING_SOURCE_FILE:  C:\<redacted>\UACME\Source\Akagi\stub.c

FAULTING_SOURCE_LINE_NUMBER:  75

FAULTING_SOURCE_CODE:  
    71: 
    72:         __try {
    73:             v = (int)USER_SHARED_DATA->NtProductType;
    74:             d = (int)USER_SHARED_DATA->AlternativeArchitecture;
>   75:             v = (int)(v / d);
    76:         }
    77:         __except (ucmSehHandler(GetExceptionCode(), GetExceptionInformation())) {
    78:             v = 1;
    79:         }
    80: 

SYMBOL_NAME:  Akagi!StubInit+bb

MODULE_NAME: Akagi

IMAGE_NAME:  Akagi.exe

STACK_COMMAND:  dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~0s ; .cxr ; kb

FAILURE_BUCKET_ID:  INTEGER_DIVIDE_BY_ZERO_c0000094_Akagi.exe!StubInit

OS_VERSION:  10.0.22621.1

BUILDLAB_STR:  ni_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  3.6.6.2403

FAILURE_ID_HASH:  {2895f328-1204-a57e-8395-38364b51a212}

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

[hfiref0x]

I don't know if I need to comment this, if you don't understand the source.

[rabbitstack]

Well, you asked me to trace the program's execution and let you know the results. I thought that may be insightful to you. However, if you think there is nothing actionable on your end, that's fine too. Cheers