Microsoft windows rpc что это

Уровень сложности
Средний

Время на прочтение
19 мин

Количество просмотров 13K

Всем привет!

Мы — команда исследователей‑аналитиков киберугроз в компании R‑Vision. Одной из наших задач является исследование возможных альтернативных и дополнительных источников событий для более точного детектирования атак.

И сегодня мы рассмотрим тему мониторинга RPC (Remote Procedure Call, удаленный вызов процедур), а также разберем возможные варианты логирования Microsoft Remote Procedure Call (MS‑RPC), связанного с актуальными и популярными на сегодняшний день атаками.

Но преждем чем приступить, предлагаем ознакомиться с базовой работой RPC и с тем, на каких механизмах она основывается. В дальнейшем это поможет нам понять, какую информацию необходимо собирать и отслеживать при детектировании атак с использованием удаленного вызова процедур.

Что такое RPC?

Remote Procedure Call или «удаленный вызов процедур» представляет собой технологию межпроцессного взаимодействия IPC. Она позволяет программам вызывать функции и процедуры удаленно таким образом, как‑будто они представлены локально. В среде Windows используется проприетарный протокол от Microsoft — MS‑RPC, который является производным от технологии DCE/RPC (Distributed Computing Environment/ Remote Procedure Calls). Для упрощения понимания мы будем называть MS‑RPC просто RPC.

Службы RPC используются во множестве процессов в операционных системах Windows. Например, с их помощью можно удалённо изменять значения в реестре, создавать новые задачи и сервисы. На вызовах RPC построена значимая часть работы Active Directory: функции аутентификации в домене, репликация данных и многие другие вещи — список грандиозно большой.

В виду того, что RPC используется в Windows практически во всех процессах, по понятным причинам она является предметом особого интереса для атакующих. В тоже время RPC фигурирует в большом количестве популярных и опасных атак. К ним относится PetitPotam, с чьей помощью можно произвести атаку типа Relay на машинный аккаунт контроллера домена. Еще одна атака — DCSync, позволяющая скомпрометировать всех пользователей в домене при наличии учетной записи с высокими привилегиями. Кроме того, в арсенале атакующих есть еще и фреймворк Impacket, который может задействовать RPC для отправки вредоносных команд на удаленный сервер.

Все это говорит нам о важности понимания механизмов работы RPC, а также о необходимости её мониторинга.

Механизмы работы RPC

Изучение механизмов работы RPC мы начнем с краткого разбора сетевого трафика, поскольку протокол RPC в первую очередь является сетевым. На рисунке 1 мы видим подключение к удалённой машине: оно начинается с Bind запроса (выделен красным), после которого фигурирует второй Bind запрос (выделен синим). Первый используется для подключения к службе Endpoint Mapper (EPM), про него мы поговорим дальше. Второй инициирует подключение к самому RPC интерфейсу. После прохождения аутентификации устанавливается сессия, а уже дальше осуществляется вызов нужной функции и возвращение результата.

Эволюция, конечно, могла бы остановиться здесь, если бы для RPC применялись только протоколы TCP и UDP, но в Microsoft пошли немного дальше и применяют так называемую последовательность из протоколов. К ней мы вернемся позднее, а сейчас рассмотрим, что такое EPM.

Endpoint Mapper

Одним из важных механизмов взаимодействия с RPC сервисами является служба Endpoint Mapper (EPM), расположенная на стороне сервера. Её главная задача помочь определить параметры дальнейшего подключения к нужному сервису для клиента. Сам EPM, как это ни странно, является таким же RPC сервисом, использующим для транспорта порты TCP/135 или TCP/593 (RPC over HTTP).

EPM‑cервис расположен на каждой Windows машине и содержит базу зарегистрированных RPC интерфейсов. За каждый из интерфейсов чаще всего отвечает свой исполняемый файл или динамически подгружаемая библиотека (DLL). Посмотреть список всех доступных интерфейсов можно с помощью утилиты rcpdump.py из упомянутого нами ранее фреймворка Impacket.

На рисунке 3 приведен пример вывода по одному из доступных интерфейсов.

Здесь мы можем увидеть:

• Название интерфейса: Netlogon Remote Protocol;

• Библиотеку провайдера, отвечающего за нужные нам функции: netlogon.dll;

• Уникальный идентификатор интерфейса: UUID;

• Список точек подключения к данному интерфейсу, которые записываются в формате:

"значение, отражающее последовательность протоколов":хост[порт]

Отметим в приведенном выше интерфейсе два протокола:

• ncalrpc — отражает локальное использование по протоколу LRPC;

• ncacn_np — отражает подключение по именованному каналу Named Pipes (NPs). В связи с этим у него вместо порта указан путь.

Может возникнуть вполне резонный вопрос: всегда ли нужно обращаться к EPM? Нет, не всегда, так как существуют статические точки подключения, остающиеся неизменными. К ним, например, относится NPs \pipe\lsass.

Можно также посмотреть на RPC интерфейсы процессов не только снаружи, но и «изнутри». Они выглядят примерно так.

Что дальше?

После того как клиент определил куда он будет дальше подключаться, в процесс вступает сериализация данных. Если клиентом является Windows система, то эту работу будет выполнять компонент NDR (Network Data Representation). Он также отвечает за десериализацию данных со стороны RPC сервера. После чего данные попадают в качестве аргументов функции и другой информации для вызова этой самой функции в DLL библиотеку, ответственную за определённый RPC функционал. На финальном этапе функция выполняется, а её вывод передаётся обратно в RPC для отправки клиенту.

Протоколы в RPC

Разобравшись как работает RPC, подробнее изучим протоколы, которые активно эксплуатируются в интерфейсах RPC и, следовательно, доступны атакующему. И первым мы рассмотрим протокол Named Pipes (NPs).

Named Pipes

Данный протокол следует принципам передачи данных через чтение и запись: используя NPs можно записывать, а также сразу читать наименование и аргументы функций. Более того, это даже можно делать одновременно. NPs проще всего представлять в виде файлов: в Windows взаимодействие с ними происходит с помощью функций CreateFile, ReadFile, WriteFile, что в некоторой степени намекает нам на схожесть этих технологий. NPs выполняет роль интеграционного слоя между RPC и другими служебными компонентами.

Со стороны клиента NPs можно представить как точки подключения для выполнения какого‑то конкретного функционала. Например, точка подключения \pipe\svcctl направлена на управление службами на конечном устройстве. Однако Microsoft не всегда следует такому разделению. Так, при подключении к \pipe\lsass можно вызвать функции EFS сервиса, если передать корректный UUID при выполнении bind запроса.
На стороне сервера, на который происходит обращение, выполняется импорт библиотеки, отвечающий за EFS (C:\Windows\System32\efslsaext.dll) в процесс lsass. Стоит отметить, что у EFS существует свой собственный интерфейс \pipe\efsr.
Также EFS функционал может быть вызван с помощью других точек, например через samr или lsarpc, за каждым из которых стоит процесс lsass. Это в свою очередь наталкивает на мысль о некоторой «универсальности» процессов — интерфейсов, так как каждый процесс может импортировать нужную библиотеку и существует возможность вызывать функции любых других сервисов.

Перейдем к следующему протоколу — SMB.

SMB

Если отойти немного от протокола RPC и посмотреть на NPs отдельно, мы обнаружим, что NPs может вполне заменить RPC, так как первый исполняет функции удаленно даже без второго. Для этих целей он использует протокол SMB (Server Message Block). При этом фактически SMB нужен только для доступа к служебной директории IPC$, аббревиатура которой расшифровывается как Interprocess Communication. Через эту «папку» можно читать, записывать, но только NPs, что вполне в духе SMB, и вызывать таким образом удаленные функции.

LRPC

До этого мы говорили про протоколы, которые используются в удаленным вызове, но есть и локальный вариант RPC — протокол LRPC, у которого существует две трактовки: Local RPC или Lightweight RPC. Этот протокол предназначен только для локальных вызовов. Конечно, при использовании подключений по NPs или RPC на адрес localhost эффект будет тот же. Более того, некоторые программы так и делают, но для локальных вызовов LRPC работает куда быстрее и он удобнее в использовании. В выводе rpcdump.py мы его видели «зашифрованным» под ncalrpc. При этом LRPC работает поверх ALPC — еще одного протокола, о котором будет сказано чуть позже.
Но сначала про LPC.

LPC

LPC (Local Procedure Call) — также отвечает за механизм общения процессов в одной и той же системе. Данный протокол является недокументированным и используется (использовался) только внутри самой Microsoft. БОльшую часть информации об этом протоколе мы можем узнать исходя из работ реверс специалистов. Сторонний софт использует его не напрямую, а взаимодействует через документированный LRPC.

А теперь вернемся к ALPC.

ALPC

LPC — это все же устаревшая технология и в явном виде уже не используется. На смену ей пришел ALPC (Advanced Local Procedure Call), являющийся асинхронным и также недокументированным протоколом. Работает он по принципу клиент‑серверной модели. В качестве сервера выступает процесс, принимающий соединения на определённый порт. Порт для подключения открывается с помощью функции NtAlpcCreatePort. Любой процесс имеет возможность подключиться к этому порту в качестве клиента, используя функцию NtAlpcConnectPort. Один «процесс‑сервер» может взаимодействовать сразу с несколькими клиентами одновременно.

DCOM

Рассмотрим последний протокол, который фигурирует в RPC — DCOM, чья аббревиатура расшифровывается как Distributed COM. Фактически эта технология вызова COM‑интерфейсов удалённо. Тут нет больших отличий со стороны трафика, но есть различия в механизме вызова удаленных функций. DCOM не вызывает функции напрямую, а сначала инициализирует COM‑объект, функционал которого будет использовать. Концептуально это похоже на NPs с их разделением функционала на отдельные именованные каналы. Если рассматривать алгоритм общения клиента и сервера, то здесь не так много отличий от «чистого» RPC, но есть два исключения — вызов функций ISystemActivator и IDispatch.

Для вызова функции определённого COM объекта, такой объект сначала нужно вызвать, чтобы затем он «запустился»: загрузился в оперативную память и был доступен для работы. В локальном мире этим занимается COM интерфейс IUnknown. Он позволяет также узнать функции неизвестных COM интерфейсов для работы с ними.

При работе с DCOM ту же функцию выполняет ISystemActivator, позволяя обратиться к неизвестным DCOM интерфейсам, являющимися по сути теми же COM объектам, и работать с ними. ISystemActivator вызывается каждый раз при новом DCOM подключении.

Также IUnknown интерфейс дает возможность вызывать и другие функции COM объекта напрямую, фактически сводя всю работу с COM объектами до одной лишь функции IUnknown интерфейса. Тоже самое выполняет и интерфейс IDispatch для DCOM, позволяя выполнять любую функцию в мире DCOM через него. Поэтому, если мы взглянем на трафик, то увидим сначала вызов ISystemActivator, а потом только лишь обращения к IDispatch, вне зависимости от того какую DCOM функцию использует клиент.

Рассказывая про ALPC, мы упомянули, что эта технология используется только локально. Но это, конечно, не совсем правда, так как ALPC задействован чуть ли не во всех компонентах Windows. Поэтому, так или иначе, любое действие, в том числе и удалённое, будет прямо или косвенно применять ALPC. Это особенно интересно в контексте DCOM, потому что он напрямую использует ALPC на локальной машине, при этом будучи вызванным удалённым пользователем.

Схема вариантов RPC-подключений

Подведем итог вышесказаного в виде схемы вариантов подключения к удалённой машине, отражающей возможные пути со стороны клиента, которые в том числе доступны и для атакующего. Как видим из рисунка 5, все не так просто.

Способы мониторинга

Разобравшись с вариантами RPC‑подключений, и, как следствие, с потенциально возможными действиями со стороны атакующего, рассмотрим, варианты мониторинга, которые нам может предоставить сама операционная система: ETW, журналы безопасности, SACL, RPC Filtering, RPC Firewall и сетевой трафик.

И начнем с технологии, на базе которой строится функционал для логирования событий в операционной системе Windows — Event Tracing for Windows (ETW).

Event Tracing for Windows

Event Tracing for Windows или сокращено ETW имеет множество, так называемых, провайдеров, которых в ОС более нескольких тысяч. Они позволяют отслеживать через события как отдельные технологии, так и конкретные процессы. Часть провайдеров формируют вполне понятные для обыденного пользователя события, другая же, бОльшая часть, используется исключительно только самой Microsoft для отладки.

ETW предоставляет возможность смотреть события вызовов RPC функций через стандартную оснастку Event Viewer. ETW провайдеры, связанные с RPC, представлены в таблице ниже.

Провайдеры, связанные с RPC

Саму настройку событий можно посмотреть здесь.

Настройка просмотра событий

Разбор событий

Теперь проведем разбор события на одном из примеров, показанных на рисунке 7.

В данном событии мы видим информацию об RPC запросе к именованному каналу \pipe\lsass по интерфейсу UUID 12 345 778–1234-abcd‑ef00–0 123 456 789ac и с номером процедуры (ProcNum / OpCode) — 34.

Переведем это событие с «машинного» языка: здесь мы фиксируем обращение к интерфейсу SAMR (Security Account Manager Remote). Атрибут Endpoint имеет значение \pipe\lsass, потому что SAMR интерфейс содержит в поле Named Pipe значение \pipe\lsass и конечное подключение производится к нему. Также виден протокол номер 2, что трактуется как NPs.

Стоит отметить, что некоторые NPs, такие как srvsvc и wkssvc динамически меняют свои GUID номера и, как следствие, их нельзя идентифицировать по одному общеизвестному GUID, но это можно сделать через поле Endpoint, которое четко указывает на соответствующий интерфейс.

Рассмотрим другой пример: при выполнении атаки DCShadow, мы можем увидеть следующее событие в журнале (рисунок 9).

На этом рисунке можно увидеть подключение к интерфейсу DRSUAPI, который имеет GUID e3 514 235–4b06–11d1-ab04–00c04fc2dcd2, протокол (Protocol) 1 или его человеко‑читаемое имя ‑TCP, а также IP‑адрес, с которого было совершено подключение. Как и в предыдущем примере здесь отображен номер процедуры (ProcNum) — 3, который трактуется как репликация обновления из NC реплики.

Журнал безопасности

Политики аудита позволяют нам настроить сбор событий, которые относятся в Windows к событиям безопасности. Они фиксируют обращения к NPs через SMB и «папку» IPC$. Сразу отметим минус такого подхода: если, к примеру, клиент будет обращаться к NPs через RPC, а не IPC$, то в событиях мы этого не увидим.

IPC$ — это системная папка общего доступа, с ее помощью мы можем логировать события подключения через политику Detailed File Share. Пример возможного события указан на рисунке 10 ниже.

События безопасности будут сформированы, если подключиться к NPs с именем srvsvc, как нам и показывает второй лог в разделе Сведение об общем ресурсе (Share Information) → Относительное имя конечного объекта (Relative Target Name). Как вы могли заметить, в данном событии не фиксируется номер процедуры (ProcNum), по которому можно было бы отследить что происходит.

System Access Control List

Для NPs также можно включить SACL (System Access Control List), чтобы фиксировать любые действия с ними. Пример события указан на рисунке 12.

Эти события практически идентичны тем, что мы получаем от политики аудита Detailed File Share. Поэтому гораздо проще включить политику, чем выставлять SACL повсеместно. Но включение SACL может помочь отслеживать подключение там, где оно происходит напрямую по RPC, при этом совершенно минуя SMB.

Выставлять SACL на NPs — не самая тривиальная задача, так как она не переживает перезагрузку машины и требует написания собственного кода, тем не менее является одним из вариантов проведения мониторинга.

Мы подготовили небольшой код, который может менять SACL на NPs.

Код C++ для выставления SACL

#include <aclapi.h>
#include <iostream>

BOOL SetPrivilege(
    HANDLE hToken,          // access token handle
    LPCTSTR lpszPrivilege,  // name of privilege to enable/disable
    BOOL bEnablePrivilege   // to enable or disable privilege
)
{
    TOKEN_PRIVILEGES tp;
    LUID luid;

    if (!LookupPrivilegeValue(
        NULL,            // lookup privilege on local system
        lpszPrivilege,   // privilege to lookup 
        &luid))        // receives LUID of privilege
    {
        printf("LookupPrivilegeValue error: %u\n", GetLastError());
        return FALSE;
    }

    tp.PrivilegeCount = 1;
    tp.Privileges[0].Luid = luid;
    if (bEnablePrivilege)
        tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
    else
        tp.Privileges[0].Attributes = 0;

    // Enable the privilege or disable all privileges.

    if (!AdjustTokenPrivileges(
        hToken,
        FALSE,
        &tp,
        sizeof(TOKEN_PRIVILEGES),
        (PTOKEN_PRIVILEGES)NULL,
        (PDWORD)NULL))
    {
        printf("AdjustTokenPrivileges error: %u\n", GetLastError());
        return FALSE;
    }

    if (GetLastError() == ERROR_NOT_ALL_ASSIGNED)

    {
        printf("The token does not have the specified privilege. \n");
        return FALSE;
    }

    return TRUE;
};

BOOL SetSecurityPrivilage(BOOL bEnablePrivilege) {
    LPCTSTR lpszPrivilege = L"SeSecurityPrivilege";
    HANDLE hToken;
    // Open a handle to the access token for the calling process. That is this running program
    if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hToken)) {
        printf("OpenProcessToken() error %u\n", GetLastError());
        return FALSE;
    }
    // Call the user defined SetPrivilege() function to enable and set the needed privilege
    if (!SetPrivilege(hToken, lpszPrivilege, bEnablePrivilege)) {
        printf("Failed to adjust Privilege\n");
        return FALSE;
    }
    return TRUE;
};

wchar_t *convertCharArrayToLPCWSTR(const char* charArray)
{
    wchar_t* wString=new wchar_t[4096];
    MultiByteToWideChar(CP_ACP, 0, charArray, -1, wString, 4096);
    return wString;
}

int main(int argc, char* argv[])
{

    LPCWSTR pipeName = NULL;
    LPWCH groupName = NULL;
    BOOL clrSACL = FALSE;

    if (argc <= 1)
    {
        printf("%s\n", "Help page, do it like this:\nprog.exe -path \\\\.\\pipe\\lsass -name Everyone\nOr to clear the SACL use -clr\nIt sets both success and failure audit, by now it works only with pipes");
        return 0;
    }

    // Argument parsing
    for (int i = 0; i < argc; ++i)
    {
        if (strcmp(argv[i], "-path") == 0)
        {
            pipeName = convertCharArrayToLPCWSTR(argv[i + 1]);
        }
        if (strcmp(argv[i], "-name") == 0)
        {
            groupName = convertCharArrayToLPCWSTR(argv[i + 1]);
        }
        if (strcmp(argv[i], "-clr") == 0)
        {
            clrSACL = TRUE;
        }
    }

    // Get Priv
    if (!SetSecurityPrivilage(TRUE)) {
        printf("Try to launch with Admin rights\n");
        return 1;
    }

    // Open the pipe with ACCESS_SYSTEM_SECURITY, the only right which allows to edit SACL
    HANDLE hPipe = CreateFile(pipeName, ACCESS_SYSTEM_SECURITY, 0, NULL, OPEN_EXISTING, NULL, NULL);

    if (hPipe == INVALID_HANDLE_VALUE)
    {
        printf("%s\n%d\n", "Incorrect handle", GetLastError());
        return 1;
    }

    // Just clear SACL and get out
    if (clrSACL)
    {
        if (SetSecurityInfo(hPipe, SE_KERNEL_OBJECT, SACL_SECURITY_INFORMATION, NULL, NULL, NULL, NULL) != ERROR_SUCCESS)
        {
            printf("%s\n%d\n", "SetSecurityInfo", GetLastError());
            return 1;
        }
        printf("%s\n", "[+] Successufully cleared SACL");
        return 0;
    }

    PACL pOldSACL = NULL;
    PSECURITY_DESCRIPTOR pPipeSD = NULL;
	
	// Just need an already existing SACL to be able to edit it
    if (GetSecurityInfo(hPipe, SE_KERNEL_OBJECT, SACL_SECURITY_INFORMATION, NULL, NULL, NULL, &pOldSACL, &pPipeSD) != ERROR_SUCCESS)
    {
        printf("%s\n%d\n", "GetSecurityInfo", GetLastError());
        return 1;
    }

    // Init TRUSTEE, which is basically SACL stucture
    TRUSTEE trusteeSACL[1];
    trusteeSACL[0].TrusteeForm = TRUSTEE_IS_NAME;
    trusteeSACL[0].TrusteeType = TRUSTEE_IS_GROUP;
    trusteeSACL[0].ptstrName = groupName;
    trusteeSACL[0].MultipleTrusteeOperation = NO_MULTIPLE_TRUSTEE;
    trusteeSACL[0].pMultipleTrustee = NULL;

    EXPLICIT_ACCESS explicit_access_listSACL[1];
    ZeroMemory(&explicit_access_listSACL[0], sizeof(EXPLICIT_ACCESS));

    // Here I buit SACL
    explicit_access_listSACL[0].grfAccessMode = SET_AUDIT_SUCCESS;
	// I wasn't able to made two right at the same time.
    //explicit_access_listSACL[0].grfAccessMode = SET_AUDIT_FAILURE;

	// If your change GENERIC_ALL, to something else, like ACCESS_SECURITY, then SACL will audit only handles with ACCESS_SECURITY rights.
    explicit_access_listSACL[0].grfAccessPermissions = GENERIC_ALL;
    
    explicit_access_listSACL[0].grfInheritance = NO_INHERITANCE;
    explicit_access_listSACL[0].Trustee = trusteeSACL[0];

    PACL pNewSACL = NULL;
    PACL pNewSACLFal = NULL;

    // This is not ideal, but I dont know how to unite SET_AUDIT_SUCCESS and SET_AUDIT_FAILURE and I dont want to waste much time on it.

    if (SetEntriesInAcl(1, explicit_access_listSACL, pOldSACL, &pNewSACL) != ERROR_SUCCESS)
    {
        printf("%s\n%d\n", "SetEntriesInAcl", GetLastError());
		return 1;
    }
    
    explicit_access_listSACL[0].grfAccessMode = SET_AUDIT_FAILURE;

    if (SetEntriesInAcl(1, explicit_access_listSACL, pNewSACL, &pNewSACLFal) != ERROR_SUCCESS)
    {
        printf("%s\n%d\n", "SetEntriesInAcl", GetLastError());
        return 1;
    }

    if (SetSecurityInfo(hPipe, SE_KERNEL_OBJECT, SACL_SECURITY_INFORMATION, NULL, NULL, NULL, pNewSACLFal) != ERROR_SUCCESS)
    {
        printf("%s\n%d\n", "SetSecurityInfo", GetLastError());
        return 1;
    }

    printf("%s\n", "[+] Successufully set SACL");

    LocalFree(pNewSACL);
    LocalFree(pNewSACLFal);
    LocalFree(pOldSACL);
    CloseHandle(hPipe);
}

Также для работы SACL должны быть включены следующие политики аудита:

Доступ к объектам | Object Access
--> Объект-задание (Успех и сбой)  | Kernel Object Success and Failure (Success and Failure)
--> Работа с дескриптором (Успех и сбой) | Handle Manipulation Success and Failure () (Success and Failure)

// Дополнительная информация, не работает без Объект-задание

RPC Filtering

Интересной альтернативой событиям, поставляемым через ETW провайдеры, может быть RPC Filtering. Решение устанавливается на конечное устройство и основано на возможностях межсетевого экрана самой ОС. Из плюсов — мы имеем возможность просмотра события в привычном нам Event Viewer. Но как и в случае с SACL, требуется предварительное выполнение настройки. Можно воспользоваться двумя способами:

• Утилитой netsh.exe;

• Использовать WinAPI.

В качестве примера возьмем RPC‑интерфейс, который связан с ранее упомянутой атакой PetitPotam — EFS.

rpc filter
add rule layer=um actiontype=permit audit=enable
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter

Установить правило можно с помощью утилиты netsh:

netsh -f rpcauditrule.txt

При выполнении обращения был получен следующий лог:

<REDACTED>
LogName=Security
EventCode=5712
EventType=0
ComputerName=<REDACTED>
SourceName=Microsoft Windows security auditing.
Type=Information
RecordNumber=39145598
Keywords=Audit Success
TaskCategory=RPC Events
OpCode=Info
Message=A Remote Procedure Call (RPC) was attempted.

Subject:
	SID:			S-1-5-7
	Name:			ANONYMOUS LOGON
	Account Domain:		NT AUTHORITY
	LogonId:		0x95FDD924

Process Information:
	PID:			716
	Name:			lsass.exe

Network Information:
	Remote IP Address:	0.0.0.0
	Remote Port:		0

RPC Attributes:
	Interface UUID:		{c681d488-d850-11d0-8c52-00c04fd90f7e}
	Protocol Sequence:	ncacn_np
	Authentication Service:	0
	Authentication Level:	0

Этот метод является прекрасной альтернативой ETW. Он не только генерирует удобный лог, но и имеет бОльшую информативность (например, наличие поля Subject). Также у такого метода нет каких‑либо технических ограничений по сбору событий, это все тот же EventLog.

RPC Firewall

Коллеги из Zero Networks предлагают идти дальше. С помощью решения RPC‑firewall, которое устанавливается на конечное устройство, они рассматривают возможность не только мониторинга, но блокировки конкретных RPC методов, чего нельзя сделать через стандартный Windows Firewall. Дополнительным бонусом предлагается заметно улучшенный журнал событий, так как в нем будет присутствовать информация о номере процедуры (ProcNum/ OpNum).

Закончив с уровнем операционной системы, перейдем к сетевому.

Сетевой уровень

Сетевой трафик весьма информативен. При его мониторинге мы можем увидеть не только подключение к IPC$ ресурсу, но и сразу номер процедуры (ProcNum/ OpNum). Это очень полезно, так как у нас появляется вся нужная информация о клиенте, а именно:

1. Кто именно клиент (так как мы видим Bind подключение);

2. Куда клиент подключается;

3. Какие именно функции выполняет клиент;

4. Как на них реагирует сервер (Ошибка или Успех).

Интереснее всего это получать информацию о выполняемых клиентом функциях, поскольку такие данные могут предоставить только ETW, RPC Firewall и трафик.

На рисунке 14 приведен пример NPs ориентированного подключения, где виден номер операции, в нашем случае это 64, в атрибуте SAMR → Operation.

Таким же образом можно просматривать и поведение TCP‑ориентированных подключений. В примере была запущена репликация домен‑контроллера, где мы можем увидеть RPC запрос вместе с номером процедуры (в примере на рисунке 15 он равен 5) и интерфейсом подключения (в примере это DRSUAPI).

Шифрование

Тема шифрования RPC‑трафика до этого в статье не затрагивалась, тем не менее оно есть. Шифрование может добавить проблем при мониторинге трафика в сети, так как расшифровывать его сложно, да и никто не любит это делать.

Трафик можно разделить на 2 вида:

• на инкапсулированный в TCP/ UDP/ HTTP и не предполагающий никакого шифрования кроме того, что реализовано в самом RPC протоколе;

• на использование NPs через SMB протокол.

Посмотрим как это выглядит в Wireshark (рисунок 16). В RPC трафике видно NPs, к которому обращается клиент, а также вызываемую функцию, поскольку эти данные не зашифрованы, а зашифрованы только аргументы к функции. Напомним, что любая функция RPC имеет свой OpNum, статически закреплённый за каждой из них. Так функции можно точно идентифицировать.

С SMB так не получится. Если используется SMB версии 3, то весь трафик целиком будет зашифрован и ничего нельзя будет увидеть. SMB3 поддерживается всеми современными версиями Windows и злоумышленник без проблем может использовать его, чтобы скрыть свои действия.

Поэтому если есть необходимость мониторить RPC взаимодействие, то можно это сделать через протокол SMB, либо если нужно выбрать один источник для мониторинга всего и сразу, то трафик лучше не использовать.

Заключение

В этой статье мы разобрали механизмы работы RPC, протоколы его интерфейсов и основные способы мониторинга удаленного вызова функций. Определенно, при сравнении всех трёх подходов логирования для мониторинга фаворитом будет являться ETW. Но в частных случаях, когда, например, точно известно об ограниченных возможностях злоумышленника и его неспособности использовать TCP‑ориентированное подключение, существует вариант применения политик аудита. В случае, если можно провести мониторинг трафика, такой способ имеет шанс стать альтернативой ETW и другим средствам логирования. Но здесь важно помнить о возможности его шифрования, если атакующий использует SMB.

Схема источников логов

Ниже представлена схема, показывающая возможности атакующего при подключении к сервису RPC и каким образом можно cобирать события по каждому из вариантов подключения.

Если у вас остались вопросы, пишите в комментариях. Надеемся, статья оказалась вам полезной!

Авторы:
— Черных Кирилл (@Ruucker), аналитик-исследователь киберугроз;
— Мавлютова Валерия (@Iceflipper), младший аналитик-исследователь киберугроз.

From Wikipedia, the free encyclopedia

Microsoft RPC (Microsoft Remote Procedure Call) is a modified version of DCE/RPC. Additions include partial support for UCS-2 (but not Unicode) strings, implicit handles, and complex calculations in the variable-length string and structure paradigms already present in DCE/RPC.

Example[edit]

The DCE 1.0 reference implementation only allows such constructs as size_is(len), or possibly size_is(len-1). MSRPC allows much more complex constructs such as size_is(len / 2 - 1) and even length_is ((max & ~0x7) + 0x7), a common expression in DCOM IDL files.

Use[edit]

MSRPC was used by Microsoft to seamlessly create a client/server model in Windows NT, with very little effort. For example, the Windows Server domains protocols are entirely MSRPC based, as is Microsoft’s DNS administrative tool. Microsoft Exchange Server 5.5’s administrative front-ends are all MSRPC client/server applications, and its MAPI was made more secure by «proxying» MAPI over a set of simple MSRPC functions that enable encryption at the MSRPC layer without involving the MAPI protocol.

History[edit]

MSRPC is derived from the Distributed Computing Environment 1.2 reference implementation from the Open Software Foundation, but has been copyrighted by Microsoft. DCE/RPC was originally commissioned by the Open Software Foundation, an industry consortium to set vendor- and technology-neutral open standards for computing infrastructure. None of the Unix vendors (now represented by the Open Group), wanted to use the complex DCE or such components as DCE/RPC at the time.

Microsoft’s Component Object Model is based heavily on MSRPC, adding interfaces and inheritance. The marshalling semantics of DCE/RPC are used to serialize method calls and results between processes with separate address spaces, albeit COM did not initially allow network calls between different machines.

With Distributed Component Object Model (DCOM), COM was extended to software components distributed across several networked computers. DCOM, which originally was called «Network OLE», extends Microsoft’s COM, and provides the communication substrate under Microsoft’s COM+ application server infrastructure.

References[edit]

• Shirley, John; Rosenberry, Ward (1995). Microsoft RPC programming guide. O’Reilly & Associates, Inc. Open Book. ISBN 1-56592-070-8.
• Luke Kenneth Casson Leighton (1999). DCE/RPC over SMB: Samba and Windows NT Domain Internals. Sams. ISBN 1-57870-150-3.

External links[edit]

• MSRPC at MSDN
• [1], a chapter on MSRPC from a technical article by Jean-Baptiste Marchand.

Microsoft Windows RPC (Remote Procedure Call) — это механизм в операционной системе Windows, который позволяет программам взаимодействовать между собой на удаленных компьютерах. RPC является ключевым компонентом для обмена данными, вызова удаленных процедур и выполнения запросов к удаленным сервисам.

Протокол RPC используется для передачи информации между клиентскими и серверными приложениями, работающими на разных машинах. Он позволяет программам работать с данными и функциями, расположенными на удаленном сервере, таким образом, будто они находятся непосредственно на клиентском компьютере.

Процедуры, которые могут быть вызваны удаленно, описываются в Interface Definition Language (IDL) и компилируются в код, который может быть использован клиентской программой для вызова этих процедур. Клиент отправляет запрос на вызов удаленной процедуры, а сервер принимает этот запрос, выполняет требуемую операцию и возвращает результат обратно клиенту.

Протокол RPC предоставляет надежный и эффективный способ взаимодействия между приложениями на удаленных машинах в сети Windows. Он широко применяется в различных сферах, включая разработку распределенных систем, клиент-серверные приложения и компоненты операционной системы Windows.

Переход на RPC-модель взаимодействия программ повышает производительность, обеспечивает безопасность и упрощает разработку и поддержку приложений, позволяя программистам использовать удаленные ресурсы, не вникая в детали их реализации на удаленной машине.

RPC — Что это такое?

RPC использует клиент-серверную архитектуру, где клиент отправляет запросы на удаленное выполнение операций, а сервер принимает запросы, выполняет задачи и отправляет результаты обратно клиенту.

В Windows операционных системах Microsoft RPC является одним из наиболее распространенных механизмов для удаленного вызова процедур. Он обеспечивает удобные и эффективные возможности для создания распределенных приложений.

Одним из ключевых компонентов Microsoft RPC является стаб — это набор определений функций и структур данных, которые служат основой для генерации клиентского и серверного кода. Стаб позволяет клиенту вызывать удаленные процедуры и передавать параметры, а серверу — получать и обрабатывать эти вызовы.

RPC использует различные протоколы передачи данных, такие как TCP/IP, HTTP и другие. Он обеспечивает прозрачность для клиентского кода, скрывая детали взаимодействия между процессами и детали сетевой коммуникации.

Важно отметить, что безопасность является важным аспектом RPC. Microsoft предоставляет набор инструментов и механизмов для обеспечения безопасности RPC вызовов, таких как аутентификация и шифрование данных.

Архитектура RPC в Microsoft Windows

Передача данных между клиентом и сервером происходит через сеть, посредством различных транспортных протоколов, таких как TCP/IP или HTTP. RPC обеспечивает прозрачную передачу данных, скрывая детали взаимодействия на низком уровне.

В архитектуре RPC в Windows используется следующая схема работы:

1. Клиент вызывает процедуру (procedure) на удаленном сервере, как если бы она была локальной.
2. Клиентская сторона RPC формирует вызов процедуры и упаковывает параметры в формат, понятный для удаленного сервера.
3. Вызов процедуры передается по сети серверу, который распаковывает параметры и вызывает соответствующую процедуру.
4. Результат выполнения процедуры упаковывается в формат, понятный для клиента, и возвращается обратно клиенту.

При использовании RPC в Microsoft Windows программистам необходимо описать интерфейс удаленной процедуры, включающий имена процедур и их параметры. Для этого используется язык описания интерфейсов (Interface Definition Language, IDL).

Одной из ключевых особенностей архитектуры RPC в Windows является возможность обращения к удаленным процедурам, как будто они являются локальными. Это делает программирование в сетевой среде более удобным и позволяет создавать распределенные приложения.

RPC в Windows также поддерживает надежность и безопасность передачи данных. Для обеспечения надежности могут использоваться повторы запросов и механизмы обнаружения ошибок. Безопасность передачи данных может быть обеспечена с помощью аутентификации и шифрования.

В целом, архитектура RPC в Microsoft Windows обеспечивает простоту и эффективность взаимодействия между программами на удаленных компьютерах, позволяя создавать распределенные системы с высокой надежностью и безопасностью.

Протоколы взаимодействия в RPC

Основными протоколами взаимодействия в RPC являются TCP/IP и UDP. TCP/IP используется для надежного и устойчивого обмена данными, когда важна точность и полнота передачи. UDP используется в случаях, когда требуется быстрая передача данных, но точность и полнота не являются критическими.

Также для взаимодействия между клиентом и сервером в RPC могут использоваться протоколы HTTP и SOAP. Протокол HTTP является стандартным протоколом передачи данных в сети интернет, поэтому его применение в RPC позволяет взаимодействовать со сторонними серверами через сеть. Протокол SOAP обеспечивает структурированное и формализованное взаимодействие по модели клиент-сервер, позволяя передавать данные в формате XML.

В зависимости от используемого протокола, клиент и сервер в RPC могут взаимодействовать между собой, обмениваясь вызовами удаленных процедур и передавая данные. Правильный выбор протокола взаимодействия в RPC важен для обеспечения надежности, скорости и безопасности передачи данных.

Функциональность RPC в Windows

Реализация RPC в Windows предоставляет широкий набор функциональных возможностей, которые упрощают и улучшают разработку и взаимодействие между приложениями.

Ниже перечислены основные функции RPC в Windows:

• Удаленный вызов процедур — основная функция RPC. Она позволяет приложениям выполнять процедуры в удаленном адресном пространстве без необходимости написания сложного сетевого кода.
• Стабилизация и сериализация данных — RPC в Windows автоматически выполняет процессы стабилизации и сериализации данных, что позволяет безопасно передавать данные между удаленными процессами.
• Автоматическое управление протоколом — RPC в Windows автоматически выбирает и управляет протоколами передачи данных, включая TCP/IP, named pipes и NetBIOS.
• Поддержка различных программных интерфейсов — RPC поддерживает несколько протоколов и API, что обеспечивает возможность взаимодействия между различными программными интерфейсами и языками программирования.
• Обнаружение и обмен данными между удаленными процессами — RPC в Windows позволяет обнаруживать удаленные процессы и обмениваться данными с ними, в том числе с использованием межкомпьютерной коммуникационной инфраструктуры (DCOM).

Примеры использования RPC в Windows

1. Удаленный вызов процедуры (Remote Procedure Call):

RPC позволяет вызывать процедуры, которые находятся на удаленных компьютерах через сеть. Это позволяет программистам разрабатывать распределенные приложения, которые могут взаимодействовать с удаленными серверами и клиентами.

2. RPC для управления службами:

Windows использует RPC для управления службами на удаленных компьютерах. Например, администратор может использовать RPC для удаленного управления службой на сервере без необходимости физического присутствия на нем.

3. Работа с удаленным реестром:

RPC позволяет программам работать с удаленным реестром Windows. Например, администратор может удаленно изменять настройки компьютера, изменяя значения в удаленном реестре.

4. RPC для обмена данными между приложениями:

RPC может использоваться для обмена данными между приложениями, работающими на разных компьютерах. Например, клиентское приложение может использовать RPC для отправки данных на сервер, который обрабатывает эти данные и отправляет результаты обратно на клиентский компьютер.

5. Реализация удаленного вызова процедур:

RPC в Windows позволяет разработчикам реализовывать свои собственные удаленные вызовы процедур. Это полезно, когда требуется создать распределенные приложения, для которых необходимо вызывать процедуры на удаленных компьютерах.

Все эти примеры показывают, как важна и полезна технология RPC в Windows для создания распределенных приложений и обмена данными между компьютерами в сети.

Some users have been asking what RPC or Remote Procedure Call is on Windows and whether they can disable it completely. Other users have also faced an error saying ‘RPC server is unavailable’ making them question if they can get rid of the service altogether. We will explain what RPC is, can you disable it, should you disable it, and what is it used for.

Let’s begin.

What Is Remote Procedure Call or RPC

RPC is a core Windows system technology that is used for creating distributed client/server programs. It contains libraries that help Windows run and manage key network and communication protocols.

Where Is Remote Procedure Call Used

RPC was primarily designed to help computers on the same network communicate with one another. This involved making requests and passing data packets. However, in modern operating systems like Windows 10 and 11, RPC is also used by applications running on the same machine to communicate with one another and pass instructions, for example. In other words, it has evolved to be an interprocess communication method that is used by client-server-based apps. This is because multitasking has become the norm and apps are constantly communicating with one another to perform different but complex tasks. So RPC acts as a backbone and is a core Windows system process.

Here is a workflow for nerds on how client process and server process interact with one another:

In the above diagram, a client process is making a request to the server process and it shows their back and forth replies.

Some examples where RPC is constantly being used are MMC consoles, certain Control Panels apps like Device Manager, and even some core internal Windows components. It is also used to manage devices on the same network like computers, printers, and scanners.

Here is a real-world example of how that would look and function.

When you open Microsoft Word on a Windows computer and give the print command, the instructions are communicated using RPC from the Word app to the printer which then prints the document in real-time. For this to happen, both the devices must be connected to the same network.

Microsoft has guidelines for creating inbound rules to support RPC.

Should You Disable Remote Procedure Call

The short answer is no. We noted how some critical system apps depend on RPC rails to communicate and execute actions. You must not disable it because doing so will lead to all sorts of critical functionality errors. Your Windows computer depends on RPC to communicate instructions and perform functions even when you are not using the computer or when it is in an idle state.

You can check just how many services are dependent on the RPC service by using the command terminal.

1. Press Windows+S to open Windows Search and type CMD. Under Command Prompt, select Run as administrator. Click Yes in the pop-up if asked.

2. Type the command below and hit Enter to execute it.

sc enumdepend rpcss 12500

3. You will see a long list of lines. Look at the first line and you would see the number of services that depend on RPC on your Windows computer. For me, it is 93.

This means all these services will be affected if I disable RPC on my Windows 11 computer. So, yes, we can disable it but must not do so at all costs.

Why are RPC Service Options Grayed Out

In fact, Microsoft has grayed out several options in the RPC services menu.

1. Press the Windows+S to open Windows Search and type Services. Click to open the same.

2. Under the Name column, find Remote Procedure Call (RPC). Double click to open it.

Here you will notice that several options are grayed out under tabs like Log On, Recovery, etc. Microsoft is trying to avoid accidental changes to RPC here.

What About ‘The RPC Server is unavailable’ Error

Some of you are seeing this error thinking disabling RPC will solve it once and for all. We already saw what RPC does and how critical it is for the functioning of your Windows computer. Also, in most cases, you can’t disable it even if you wanted to. Fortunately, there are ways to fix RPC server errors quickly.

1. Open Services app using Windows Search as we did before.

2. The Remote Procedure Call (RPC) Status should be Running and Startup Type should be Automatic.

3. If it is not set to the said status, contact your admin or if you have root access, double-click to open and change the Status and Startup Type values as discussed in step 2. If you can click on the Start button (not grayed out) under the General tab, do so and then click on Apply to save changes.

Another solution could be flushing DNS cache on your Windows computer.

Remote Procedure Call

This is a high-level overview of RPC and its role in the larger Windows ecosystem. When you begin to dig deeper, you will find it has many layers and a complex system that was designed decades ago but is still relevant.