Приветствую, Хабр!

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

В качестве меры предотвращения такой утечки компании, как правило, используют DLP системы (Data Loss Prevention) и другие способы мониторинга переписки. Одним из самых популярных мессенджеров, используемых в России и СНГ, является Telegram. Как показывает практика компаний, работающих с DLP, алгоритм определения клиента Telegram в системе несовершенен и обойти механизмы контроля, используя портативную версию, достаточно просто.

Оценивая стоимость внедрения механизмов контроля и простоту их обхода, давайте попробуем ответить на вопрос: "По каким признакам можно понять, что используется Portable клиент Telegram?".

Для анализа мы возьмем штатные средства мониторинга системы, а также журналы Sysmon. События журналов будем рассматривать в R-Vision SIEM, так как продукт позволяет обрабатывать все события в одном месте с удобными фильтрами и высокой производительностью.

Telegram в корпоративной среде

Официальные приложения клиента Telegram доступны в различных исполнениях:

• мобильные приложения: Telegram для Android, Telegram Messenger on the App Store;

• классические Desktop приложения: Telegram для Windows/Mac/Linux;

• веб-приложение Telegram.

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

Мониторинг использования Telegram на Windows можно осуществлять на разных уровнях взаимодействия с системой. Условно разделим их на:

• Процессы

• Файловая система

• Сетевой

• Реестр

• Именованные каналы

• Windows API

Начнем поиск индикаторов с запуска приложения.

Поиск артефактов

Создание процесса

Для начала давайте рассмотрим события создания процесса Telegram на рабочей станции с ОС Windows. Для удобства представления логов будем использовать функционал сравнения событий в R-Vision SIEM.

Событие запуска процесса записывается в журнал Security c EventID 4688 (Process Creation). В событии фиксируется полный путь к исполняемому файлу. Инсталлируемая версия, как правило, располагается по пути %USERPROFILE%/AppData/Roaming/Telegram Desktop/Telegram.exe. В то время как портативная версия по умолчанию имеет путь %USERPROFILE%/{PATH}/tportable-x, но как видно на рисунке ниже, этот путь можно легко заменить. Так же в событии можно увидеть родительский процесс, который при запуске пользователем из графического интерфейса всегда будет explorer.exe, и пользователя, который запустил клиент мессенджера.

К сожалению, при переименовании исполняемого файла клиента или его пути, данное событие нам не поможет. Тогда на помощь может прийти событие с EventID 1 (Process creation) из журнала Sysmon/Operational. Данное событие, кроме рассматриваемой ранее информации, также содержит контрольные суммы исполняемого файла и информацию об издателе приложения. Данные значения пользователю изменить сложнее, чем переименовать файл. Одним из способов изменения данных значений является использование утилиты Resource Hacker.
Отметим, что контрольные суммы исполняемого файла будут отличаться в зависимости от используемой версии клиента, что потребует их постоянный пересмотр и поддержку. Если в компании организована централизованная установка и обновление программного обеспечения, то "нелегальную" версию клиента можно отличить с помощью логической операции исключения. Например : fileHash not like "%легитимный hash%".

События запуска процесса можно использовать для обнаружения портативной версии клиента, однако, при наличии у пользователя специальных навыков этот способ детектирования можно обойти. Для того, чтобы отличить инсталлируемую версию от портативной следует обращать внимание на путь к исполняемому файлу. Инсталлируемая версия клиента по умолчанию размещается по пути %USERPROFILE%/AppData/Roaming/Telegram Desktop/Telegram.exe.

В следующем разделе рассмотрим изменения на уровне файловой подсистемы.

Изменение файловой системы

В директории запуска Portable клиента Telegram создается папка tdata в которую помещаются данные приложения. При настроенном логировании создания файлов в папках пользователя можно зафиксировать изменения в событии c EventID 11 (FileCreate) журнала Sysmon/Operational.

Стоит учитывать, что каталог с наименованием tdata могут использовать другие приложения, поэтому для минимизации ложного детектирования, можно коррелировать данное событие с событием c EventID 1 (Process creation) Sysmon/Operational по идентификатору процесса (поле spid нормализованного события). А так же исключить события с вхождением подстроки Program Files, Windows, ProgramData в пути до каталога /tdata/ или наоборот ограничится каталогом пользователей :\Users\.* и папкой Temp.

Для отслеживания события изменений файловой системы требуется настройка аудита изменения соответствующих директорий, что может повлечь генерацию большого количества не важных для службы ИБ событий. Данный факт может снизить производительность системы обработки событий и увеличить ее стоимость, поэтому делаем вывод, что отслеживать использование клиента Telegram можно на основании создания файлов в директории tdata, но требуется осознано подойти к настройке соответствующего уровня логирования. При этом исключить инсталлируемую версию можно по пути C:/Users/{{User}}/AppData/Roaming/Telegram Desktop/tdata, оставшиеся события будут сигнализировать об использовании портативной версии.

Следующим методом детектирования использования клиента Telegram является мониторинг сетевой активности.

Маркеры в сети

Приложение при синхронизации обращается к api серверов Telegram. Список сетевых соединений при запуске приложения представлен на изображении. Данное поведение аналогичное как для Portable клиента, так и для инсталлируемого, но для Web версии клиента оно отличается.

Такие обращения можно детектировать на уровне анализа журналов прокси сервера, сетевых соединений или на основе события c EventID 22 (DNSEvent) журнала Sysmon/Operational.

Клиент Telegram запрашивает адреса у следующих DNS имен:

• td.telegram.org

• telegram.org

• desktop.telegram.org

• tdesktop.telega.one

• api.telegram.org

На основании рассмотренного выше события можно сделать вывод об использовании Telegram клиента, при этом инсталлируемую версию от портативной можно отличить по указанному в событии пути к исполняемому файлу (поле dproc нормализованного события).

Дополнительно рассмотрим события сетевых соединений зафиксированных в событиях c EventID 3 (Network connection detected) в журнале Sysmon/Operational. На рисунке приведена статистика соединений Telegram Client к серверам за 5 минут, в столбец count выведено количество событий подключения к конкретным серверам.

При использовании proxy-сервера, в качестве ip-адреса подключения в событии установки сетевого соединения в журнале Sysmon/Operational будет указан его адрес. В этом случае детектирование сетевых подключений к серверам Telegram на основе события c EventID 3 (Network connection detected) невозможно.

Для синхронизации с сервером Telegram использует несколько публичных подсетей. Информация об используемых подсетях по данным сайта ipinfo.io на изображении.

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

Отслеживание сетевых соединений и DNS запросов к серверам Telegram также может помочь в детектировании атак использующих его, как инструмент для управления скомпрометированными узлами и обмена данными. В представленных разборах атак злоумышленники используют кастомные реализации клиентов (что делает невозможным детектирование на основе иных рассматриваемых событий), но такие клиенты обращаются к api легитимных серверов Telegram. Эти обращения будут зафиксированы в событиях, рассмотренных в данном разделе.

Далее разберемся, какие изменения при запуске клиента происходят в системе. Для начала рассмотрим изменения зафиксированные в реестре.

Реестр скажет обо всем

При первом запуске приложения, происходят изменения ветки реестра /HKEY_USERS/{{UUID}}_Classes. В данной ветке создаются два раздела tg и tdesktop.tg.
Разделы в реестре сохраняется после завершения работы как инсталлируемой, так и портативной версии, при этом их наполнение аналогичное.

Изменение данных веток можно отслеживать в событии EventID 4657 (A registry value was modified) журнала Security. Для регистрации события требуется настройка расширенного аудита и SACL на изменяемую ветку реестра.

А так же в событиях c EventID 12 (RegistryEvent (Object create and delete)) и EventID 13 (RegistryEvent (Value Set)) из журнала Sysmon/Operational об изменение аналогичных веток:

Портативную версию от инсталлируемой можно отличить по пути к исполняемому файлу в значении измененного ключа .../tg/shell/open/command/(Default) указанном в поле cs4 нормализованного события.

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

Разобрав изменения на уровне реестра, давайте перейдем к событиям создания именованного пайпа, которое обеспечивает межпроцессорное взаимодействие.

Создание именованного канала

При запуске приложения создается именованный канал (Named Pipe). Именованный канал служит для взаимодействия между процессами в операционных системах Windows. Различные процессы в системе могут записывать в него и считывать данные обеспечивая необходимое взаимодействие.
Имя именного канала генерируется функцией SingleInstanceLocalServerName и состоит из слова Global\\ + значение hash в формате md5 + "-" + Уникальный GUID.
Ниже представлен пример сгенерированного имени:

\\Global\\86dc7d25b16c5a67f82ffcb5c00ac31e-{87A94AB0-E370-4cde-98D3-ACC110C5967D}

Создание именованных каналов регистрируются в событии c EventID 17 (Pipe created) журнала Sysmon/Operational.

Событие с EventID 17 журнала Sysmon о создании именованного канала

Имя созданного канала клиентом Telegram можно проверить с использованием регулярного выражения:

\\Global\\[0-9a-f]{32}-\{[0-9A-f]{8}-[0-9A-f]{4}-[0-9A-f]{4}-[0-9A-f]{4}-[0-9A-f]{12}\}

Именованный канал создается как при использовании инсталлируемого приложения, так и портативного, поэтому отличия можно зафиксировать только по пути к исполняемому файлу, который создал именованный канал.
На основе событий создания именованного канала можно достаточно эффективно детектировать использование клиента Telegram, даже после модификации исполняемого файла рассмотренного в разделе "Создание процесса". При этом инсталлируемую версию от портативной можно отличить только по пути к исполняемому файлу.

Далее рассмотрим характерные для клиента Telegram API вызовы при помощи утилиты API Monitor.

Мониторинг на уровне Windows API

При запуске Telegram клиента, вне зависимости от директории запуска и наименования исполняемого файла, характерен API вызов CreateFileW создания файла конфигурации Qt с указанием пути C:/Telegram/Libraries/...:

Для инсталлируемой версии клиента характерен вызов API GetFullPathNameW для проверки наличия файлов и директорий с указанием пути C:/Users/{{User}}/AppData/Roaming/Telegram Desktop/ в качестве параметра и CreateDirectoryW с аналогичным параметром для последующего создания это директории:

Для Portable версии характерны аналогичные вызовы GetFullPathNameW и CreateDirectoryW, только с указанием в аргументах пути соответствующему директории запуска:

При первом запуске Portable версии (или запуска в новой директории), для хранения данных приложения создается директории tdata, c использованием api вызова CreateDirectoryW. В результате выполнения операции получаем значение True:

При повторном запуске, а также при запуске инсталлируемой версии, в результате вызова API для создания директории получаем ошибку, что директория уже создана.

Дополнительно для запуска Telegram клиента, вне зависимости от версии, характерно создание и подключение к именованному каналу с использованием системных вызовов CreateNamedPipeW и ConnectNamedPipe:

Вывод

В статье мы разобрали возможные артефакты в событиях Windows, которые оставляет портативная версия Telegram клиента. Каждый из маркеров имеет свои достоинства и недостатки:

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

• Методы, основанные на изменениях файловой системы и реестра, также оповестят об его использовании, но для регистрации таких событий, как правило, требуется дополнительная настройка аудита.

• События сетевых подключений и DNS запросов могут сигнализировать об использовании Telegram Client, в том числе при использовании собственной сборки клиента, но для этого требуется поддерживать актуальный список подсетей и DNS имен используемых Telegram. Данные события не регистрируются при использовании Proxy.

• События создания именованных каналов, имя которых соответствует рассмотренной маске, может сообщить нам об использовании Telegram клиента, но нет 100 процентной гарантии, что иное программное обеспечение не использует аналогичный формат имени.

Рассмотренные методы детектируют использование официального клиента Telegram вне зависимости от его версии. Отличить портативную версию от инсталлируемой можно только по пути к исполняемому файлу и его хэшу.

Отсюда мы делаем вывод, что детектирование использования Telegram клиента - задача достаточно сложная, но выполнимая. На примере R-Vision SIEM мы показали, как решить эту задачу с помощью решения класса SIEM.

Автор: Нестеров Борис (@dino_cn), аналитик-исследователь угроз кибербезопасности R-Vision.