[EP_X0FF]

Fresh sample md5: 6855c03e4f1b1cb7f93d5f732edf3f17

VT 6/56

Unpakced:
VT 35/55

Have you figured out how it UAC bypass method works? It seems kinda promising ;) See attach.

Code: Select all

dropper ? x86-32 uacdll->explorer.exe[SeServer32.dll]
        ? x86-64 uac64->uacdll64->explorer.exe[SeServer64.dll]

[r3shl4k1sh]

Fresh sample md5: 6855c03e4f1b1cb7f93d5f732edf3f17


Have you figured out how it UAC bypass method works? It seems kinda promising ;) See attach.

I didn't look how it is implemented yet but one thing for sure is that it isn't as clean as the Shim nor as the Dll Hijack methods since the user gets a warning as soon as the UAC is disabled:

[EP_X0FF]

Well I'm not finished looking it yet but I can give a hint.

Use Se.exe from my archive under debugger to see some magic. This malware uses client-server LPC based communication mechanism where dll in explorer.exe is server and dropper (or x64 loader in case of x64) are clients. See magic in x64 loader Se.exe!0000000140001868. From what I see it uses seems undocumented {4D111E08-CBF7-4f12-A926-2C7920AF52FC} com object, ISecurityEditor inferface (you can check it permissions with OleView tool) to access HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and disable UAC.

[sysopfb]

Here's one my yara rule just pinged me on 13/55

MD5 df1add2ca597d0ee03a012f7b99dd61b
SHA-1 e63af8a0b3018b1b65fe73cbaa456b5edd5c2312
SHA-256 0e0fa2c08ac724c57a1db484cca1df25597e731ca0d5f7f9d5c9778fda33dc4b

https://www.virustotal.com/en/file/0e0f ... /analysis/

[EP_X0FF]

OK, did some investigations.

Full algorithm:

Dropper determinates OS type and depending on this acts differently.

In case of x86-32 dropper decrypts and drops component internally named SeServer32.dll to the %TEMP% folder and after this injects it into Explorer.exe memory with CreateRemoteThread(LoadLibrary).
In case of x86-64 dropper decrypts and drops x64 component internally named Se.exe to the %TEMP% folder and starts Se.exe with parameters ON or OFF (affect what it will do with UAC next). Se.exe extracts and drops x64 dll SeServer64.dll and after this injects it into Explorer.exe memory with CreateRemoteThread(LoadLibrary);

SeServer32 and SeServer64 are both created from one source and doing the same stuff.

Inside SeServer library implemented small LPC based server, dll creates and waits for commands on named port {A67077FD-5A57-4d0e-8D2A-3BC14D2E7D8A}0.1. Dll acquires COM object with {4D111E08-CBF7-4f12-A926-2C7920AF52FC} which stands for ISecurityEditor.

Interface


Access permissions


Client side (in case of x64 it is SE.exe) connects to the named port {A67077FD-5A57-4d0e-8D2A-3BC14D2E7D8A}0.1 and sends requests as LPC messages. There two type of requests - GetSecurityDescriptor and SetSecurityDescriptor.

On GetSecurityDescriptor command SeServer dll uses ISecurityEditor->GetSecurity method and replies back to the caller with acquired data.
On SetSecurityDescriptor command SeServer dll uses ISecurityEditor->SetSecurity method and replies back to the caller was it successful or not.

Communication in details.

Se.exe/dropper requests security data for the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key, so it can save SD and restore it after.
SeServerXX.dll receives parameters and uses it for ISecurityEditor->GetSecurity as shown below

Code: Select all

pObjectName = MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
ObjectType = SE_REGISTRY_KEY
SecurityInfo = DACL_SECURITY_INFORMATION
ppSecurityDescriptor = pointer to buffer to store output info.

The calls of interface methods happens not inside explorer.exe but in COM Surrogate process DllHost.exe - running at High Integrity Level. When GetSecurity method called DllHost.exe calls RegQueryKeySecurity API.

After successful method call ppSecurityDescriptor buffer filled with

Code: Select all

D:AI(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)

Dropper/SE.exe saves this information for later use and calls server dll again with request SetSecurityDescriptor.

SeServerXX.dll receives parameters and uses it for ISecurityEditor->SetSecurity as shown below

Code: Select all

pObjectName = MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
ObjectType = SE_REGISTRY_KEY
SecurityInfo = DACL_SECURITY_INFORMATION
SecurityDescriptor = D:(A;;GA;;;WD)

Where DACL = (Allow access at level GENERIC_ALL for EVERYONE)

When ISecurityEditor->SetSecurity method called DllHost.exe calls RegSetKeySecurity API.

After successful call of this method Dropper/Se.exe calls usual RegOpenKeyExW for HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System with Read/Write access flags. Because key security replaced with new values this call is succesful. Next it overwrites the following values:

ConsentPromptBehaviorAdmin
ConsentPromptBehaviorUser
EnableLUA

with 0 and saves previous values to the following keys (they used if malware want to restore previous UAC state - Se.exe "ON" param, see above).

HKCU\Software\Microsoft\icp
HKCU\Software\Microsoft\lps
HKCU\Software\Microsoft\qmd

After this malware restores HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System key security with SetSecurityDescriptor(PreviouslySavedValues) call.

ISecurityEditor undocumented Microsoft backdoor interface. Quick C interface definition, ripped partially from Simda binary, unexpected MS symbols (forgotten to strip private info?) and debugging.

Code: Select all

EXTERN_C const IID IID_ISecurityEditor;

typedef interface ISecurityEditor ISecurityEditor;

typedef struct ISecurityEditorVtbl
{
	BEGIN_INTERFACE

		HRESULT(STDMETHODCALLTYPE *QueryInterface)(
		__RPC__in ISecurityEditor * This,
		/* [in] */ __RPC__in REFIID riid,
		/* [annotation][iid_is][out] */
		_COM_Outptr_  void **ppvObject);

		ULONG(STDMETHODCALLTYPE *AddRef)(
			__RPC__in ISecurityEditor * This);

		ULONG(STDMETHODCALLTYPE *Release)(
			__RPC__in ISecurityEditor * This);

		HRESULT(STDMETHODCALLTYPE *GetSecurity)(
			__RPC__in ISecurityEditor * This
			/* [in] */ LPWSTR pObjectName,
			/* [in] */ SE_OBJECT_TYPE ObjectType,
			/* [in] */ SECURITY_INFORMATION SecurityInfo,
			/* [in][out] */ PSECURITY_DESCRIPTOR *ppSecurityDescriptor
			);

		HRESULT(STDMETHODCALLTYPE *SetSecurity)(
			__RPC__in ISecurityEditor * This
			/* [in] */ LPWSTR pObjectName,
			/* [in] */ SE_OBJECT_TYPE ObjectType,
			/* [in] */ SECURITY_INFORMATION SecurityInfo,
			/* [in] */ PSECURITY_DESCRIPTOR SecurityDescriptor
			);

	END_INTERFACE
} ISecurityEditorVtbl;

interface ISecurityEditor
{
	CONST_VTBL struct ISecurityEditorVtbl *lpVtbl;
};

This Simda code is very old. It was created in the end of 2010 and for my big surprise I was unable to find any references to this anywhere.

Solution for UAC bypass - turn it on maximum and think twice before clicking OK, even if UAC window prompt you as Microsoft actions.
Global solution - use normal user instead of default admin.

P.S.
Maybe I will try to reimplement this and try with other objects as seems it can work with more of SE_OBJECT_TYPE.

[kmd]

is explorer.exe injection required to execute this code?
by the way this interface present also in win10 tp.

[EP_X0FF]

is explorer.exe injection required to execute this code?
by the way this interface present also in win10 tp.

Didn't tried reimplementing the Simda code, but I guess so, or at least it must be middle integrity Microsoft process. Furthermore there are also few reasons: why explorer.exe? Because it is always running to provide the Windows taskbar and desktop. Why dll and not whole malware inside explorer? Because they wanted small and universal functionality that can be used by different components in modular malware infection structure.

[r3shl4k1sh]

2 questions:

1. I didn't quite understand how the Access permissions of the ISecurityEditor (shown at the OLE Object viewer) implicates that you can use it to do high privileges stuff?
2. Where did you found the symbols for the ISecurityEditor? is it implemented in the shell32.dll? if so is there any easy way to find where is it in the binary?

Thanks.

BTW.
In the Simda dll (SeServer32) it uses a COM moniker in order to get the ISecurityEditor object like this:

Code: Select all

BIND_OPTS3 pBO;
	memset(&pBO, 0, sizeof pBO);

	pBO.hwnd = 0;
	pBO.cbStruct = 0x24;
	pBO.dwClassContext = CLSCTX_LOCAL_SERVER;

	void* ppv;
	
	hRes = CoGetObject(L"Elevation:Administrator!new:{4D111E08-CBF7-4f12-A926-2C7920AF52FC}",
		&pBO,
		IID_ISecurityEditor,
		&ppv);

When i have tried to run it from a regular executable with Medium integrity level it pops up the UAC window, so it seems that there is something in doing it from within explorer.exe.

[kmd]

@r3shl4k1sh
i found this describing com activation permissions http://msdn.microsoft.com/en-US/en-en/l ... 79714.aspx

When i have tried to run it from a regular executable with Medium integrity level it pops up the UAC window

are yours uac at max level?

[EP_X0FF]

2 questions:

1. I didn't quite understand how the Access permissions of the ISecurityEditor (shown at the OLE Object viewer) implicates that you can use it to do high privileges stuff?
2. Where did you found the symbols for the ISecurityEditor? is it implemented in the shell32.dll? if so is there any easy way to find where is it in the binary?

Thanks.

Security in COM, http://msdn.microsoft.com/en-us/library ... 85%29.aspx

ISecurityEditor (Shell Security Editor) has the same Elevation enabled and security permissions as IFileOperation (Copy/Move/Rename/Delete/Link Object). You can scan ole objects and I'm sure there will be more like this. Windows is full of things Microsoft want to use but do not want to document, resulting we have the ridiculous situation when this undocumented things are beginning to be used by malware (for years like this Simda from 2010 up to 2015) subverting this security-through-obscurity concept and we must spend hours on debugging to just understand wtf is happening here and why system accept this.

What about interface declaration, I know it sound strange but ISecurityEditor symbols can be found in the... MS symbols. But not in Shell32 TLB (as it might be), not in shell32.pdb. In case of Microsoft partially stripped symbols like this one the best working solution is to download everything from symbols to your OS and then do strings scan for a known name. Thats true not only for ISecurityEditor but for newest (win8+) nt kernel structures too (for example in certenroll.pdb some interesting stuff). This interface I found inside urlmon.pdb, twinapi.pdb, certenroll.pdb. Tool that can extract symbols is the PDBRipper -> http://ntinfo.biz/files/pdbripper.rar, it's a bit slow, but it is better than nothing.

Once you have declaration the only thing need to be recovered - parameter names. Here comes debugging and understanding what you looking for. For example when I had found this interface definition I already knew that it will be looking something like reduced version of GetNamedSecurityInfo, SetNamedSecurityInfo. I used Visual Studio on x64 debugging Se.exe, once Se.exe injects dll into explorer.exe I attached second instance of Visual Studio to the explorer.exe and installed breakpoints directly on all interface calls which are preliminarily determinated in the disassembler (hiew). Once breakpoint hit, inspect registers and stack, for x64 it will be rcx = 1 param (this pointer here because method is thiscall), rdx (2 param), r8 (3 param), r9 (4 param), next in stack (rsp + 0x20), compare what you see with what you expected and give method parameters proper names. Using the same approach you can find by yourself many other structures and definitions if you need them.

SeServerXX.dlls contains encrypted data (xor).

Here are important of them

"ole32.dll" name of dll to be loaded with LoadLibrary.
"CoGetObject" name of routine from ole32 for GetProcAddress to be used next.
"Elevation:Administrator!new:{4D111E08-CBF7-4f12-A926-2C7920AF52FC}" - name of interface to be used in CoGetObject call.

BTW.
In the Simda dll (SeServer32) it uses a COM moniker in order to get the ISecurityEditor object like this:
When i have tried to run it from a regular executable with Medium integrity level it pops up the UAC window, so it seems that there is something in doing it from within explorer.exe.

It must be Microsoft signed executable. For example if you alter explorer.exe with 1 byte modification it will become unknown to the system and this dll even inside explorer.exe memory will trigger UAC prompt on default UAC settings.