ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Milovski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Наши коллеги-исследователи из ESET опубликовали статью о ранее незадокументированных инструментах, проникающих в крупные компании и местные органы власти в Азии. Инструменты, действующие как минимум с 2020 года, предназначены для кражи данных.ESET назвала их Workok ESET зафиксировала значительный перерыв в активности с 5 мая 2021 г. по начало 2022 г. Тем не менее, когда Worok снова стал активным, новые целевые жертвы, в том числе энергетические компании в Центральной Азии и организации государственного сектора в Юго-Восточной Азии, были заражены для кражи данных на основе о типах атакуемых компаний. Исследователи из ESET описали две цепочки выполнения и способы компрометации компьютеров жертв. Первоначальный компромисс неизвестен, но следующие этапы подробно описаны, в том числе описание того, как конечная полезная нагрузка загружается и извлекается с помощью стеганографии из файлов PNG. Однако окончательная полезная нагрузка еще не восстановлена. Подробную информацию о Worok, цепочках и командах бэкдора можно найти в статье ESET Workok: The big picture.
Наш анализ направлен на расширение текущих знаний об исследованиях ESET.Мы захватили дополнительные артефакты, связанные с Вороком, в конце цепочки выполнения. Файлы PNG, захваченные нашей телеметрией, подтверждают, что целью конечной полезной нагрузки, встроенной в них, является кража данных. Что примечательно, так это сбор данных с машин жертв с помощью репозитория DropBox, а также злоумышленников с помощью DropBox API для связи с финальной стадией.
Вся цепочка
Мы намерены придерживаться терминологии, установленной в исследовании ESET. Наше исследование также не выявило всей первоначальной компрометации вредоносного ПО. Однако у нас есть несколько новых наблюдений, которые могут быть частью процесса проникновения.
На рис. 1 показана исходная цепочка компрометации, описанная ESET. В некоторых случаях вредоносное ПО предположительно внедряется злоумышленниками через ProxyShell уязвимости. В некоторых крайних случаях эксплойты против уязвимости ProxyShell использовались для персистентности в сети жертвы. Затем злоумышленники использовали общедоступные инструменты эксплойтов для развертывания своих пользовательских вредоносов. Итак, финальная цепочка проста: первый этап CLRLoader, который реализует простой код, загружающий следующий этап ( PNGLoader).
Как начать
Конкретный вектор начальной атаки пока неизвестен, но мы обнаружили на взломанных машинах четыре библиотеки DLL, содержащие код CLRLoader. Наши обнаружения зафиксировали дерево процессов, показанное на рисунке 2.
Это дерево процессов наблюдалось для WLBSCTRL.DLL, TSMSISrv.DLL и TSVIPSrv.DLL. Взаимный процесс, выполняющий DLL, - svchost -k netsvcs. Таким образом, начальным процессом является SvcHost, представляющий службу Windows. DLL файлы помогают нам определить две службы Windows, а именно IKE и AuthIP IPsec Keying Modules (IKEEXT) и Remote Desktop Configuration (SessionEnv). Обе службы известны тем, что по умолчанию захватывают DLL-файлы, отсутствующие в папке System32, SCM и DLL Hijacking Primer.
Боковое перемещение
Перехват DLL в папке System32 сам по себе не является уязвимостью, поскольку для записи в нее злоумышленникам необходимы привилегии администратора. Однако мы предполагаем наличие реализованной обратной оболочки с привилегиями администратора как следствие первоначальной компрометации. В этом случае злоумышленник может эффективно выполнить латеральное перемещение через диспетчер управления службами (SVCCTL).
Короче говоря, злоумышленники помещают перехваченные DLL-файлы в %SYSTEMROOT%\System32, а затем удаленно запускают соответствующую службу.
Список взломанных служб Windows и их DLL-файлов:
Модули ключей IPsec IKE и AuthIP:
C:\Windows\System32\WLBSCTRL.dll
Конфигурация удаленного рабочего стола:
C:\Windows\System32\TSMSISrv.dll
C:\Windows\System32\TSVIPSrv.dll
Второй замеченный захват DLL связан с машинами VMware. Злоумышленники могут злоупотреблять захватом vmGuestLib.dll, которая используется службой WMI Performance Adapter (WmiApSrv) для предоставления информации о производительности. При запуске системы WmiApSrv загружает vmStatsProvider.dll, который пытается вызвать vmGuestLib.dll из %ProgramFiles%\VMware\VMware Tools\vmStatsProvider\win32 в качестве первого. Однако оригинальная библиотека находится в %SYSTEMROOT%\System32. Следовательно, если злоумышленники поместят vmGuestLib.dll в папку %ProgramFiles%, это также приведет к перехвату DLL. Эти два подхода являются вероятными сценариями того, как может быть выполнен CLRLoader, и запущена цепочка компрометации, показанная на рисунке 1. Элегантность этого подхода заключается в том, что злоумышленникам не нужно создавать новую службу, которая может выявить подозрительную деятельность. Злоумышленники злоупотребляют только экспортными функциями взломанных DLL, пустая перереализация которых не вызывает ошибки или какого-либо другого признака компрометации. Более того, постоянство CLRLoader обеспечивается легитимными службами Windows.
CLRLoader
CLRLoader - это DLL-файл, написанный на Microsoft Visual C++. Он реализует метод DllMain, который отвечает за загрузку следующего этапа (.NET вариант PNGLoader). Остальные экспортируемые функции соответствуют интерфейсам взломанных DLL, но реализация экспортируемых функций пуста. Поэтому вызов этой функции не вызывает сбоя в вызывающих процессах. Для полноты картины, взломанные файлы также содержат цифровые подписи оригинальных DLL-файлов; естественно, подпись недействительна. CLRLoader активируется вызовом LoadLibraryExW из нарушенного процесса/службы. LoadLibraryExW вызывается с нулевыми параметрами dwFlags, поэтому при загрузке вредоносной DLL в виртуальное адресное пространство вызывается DllMain. Пример кода CLRLoader показан на рисунке 3.
CLRLoader проверяет наличие DLL-файла .NET, содержащего PNGLoader, создает мьютекс и, наконец, выполняет PNGLoader через API CorBindToRuntimeEx.
Мы распознали два варианта PNGLoader со следующими точками входа:
PNGLoader
Второй этап (PNGLoader) загружается CLRLoader или, как сообщает ESET, PowHeartBeat. Мы пока не видим кода, развертывающего PNGLoader на инфильтрированных системах, но ожидаем увидеть его аналогично боковому перемещению. PNGLoader - это загрузчик, который извлекает байты из файлов PNG и реконструирует их в исполняемый код. PNGLoader - это DLL-файл .NET, обфусцированный с помощью .NET Reactor; описание файла содержит информацию, имитирующую легитимное программное обеспечение, такое как Jscript Profiler или Transfer Service Proxy. Деобфусцированный код PNGLoader включает точку входа (Setfilter), вызываемую CLRLoader. Имеется жестко закодированный путь loader_path, по которому рекурсивно ищутся все PNG-файлы. Каждый файл .png проверяется на наличие определенных атрибутов растрового изображения (высота, ширина) и стеганографически внедренного содержимого (DecodePng). Метод Setfilter показан на рисунке 4.
Стеганографическое внедрение основано на одном из наиболее распространенных стеганографических методов, называемом кодированием наименее значимых битов (LSB). Как правило, этот метод встраивает данные в младшие биты каждого пикселя. В этой конкретной реализации один пиксель кодирует полубайт (по одному биту на каждый альфа-, красный, зеленый и синий канал), т.е. два пикселя содержат байт скрытой информации, как показано на рис.5. Хотя этот метод очень легко обнаружить с помощью простого статистического анализа, такое изменение значения пикселя едва заметно невооруженным глазом.
Затем стеганографически внедренное содержимое извлекается в четыре этапа следующим образом.
Результатом этих шагов является окончательная полезная нагрузка, стеганографически встроенная в файл PNG.
Если PNGLoaderуспешно обрабатывает ( извлекает → декодирует → распаковывает ) финальную полезную нагрузку, она компилируется во время выполнения и немедленно выполняется. Наша телеметрия зафиксировала два варианта PNGLoaderработа с магическими числами, записанными на рисунке 6 .
Первой реализацией полезной нагрузки является сценарий PowerShell, как показано в фрагменте кода PNGLoade rна рисунке 7 . Как и у наших коллег из ESET, у нас пока нет образца этой полезной нагрузки, но мы ожидаем аналогичную функцию, как и вторая реализация полезной нагрузки, описанная ниже.
Вторая реализация полезной нагрузки — это .NET C#, скомпилированный и выполненный через CompileAssemblyFromSourceметод CSharpCodeProviderкласс, см. рис. 8
.
Полезная нагрузка .NET C# имеет пространство имен Mydropbox, класс Programи метод Main. Пространство имен указывает, что полезная нагрузка работает с DropBox. Наше оборудование зафиксировало несколько файлов PNG, включая стеганографически встроенную полезную нагрузку C#.
На первый взгляд картинки PNG выглядят невинно, как пушистое облачко; см. рис. 9 . Наша телеметрия захватила три изображения PNG со следующими атрибутами:
Рис. 9. Вредоносный PNG-файл со стеганографически внедренной полезной нагрузкой C#
Как мы упоминали ранее, авторы вредоносных программ полагаются на кодирование LSB, чтобы скрыть вредоносную полезную нагрузку в пиксельных данных PNG, в частности, в LSB каждого цветового канала (красного, зеленого, синего и альфа-канала). Давайте посмотрим на их бит-планы. На рис. 10 показана одна из старших битовых плоскостей для каждого цветового канала; обратите внимание, что каждое из этих изображений выглядит далеким от случайного шума. Если бы мы посмотрели на изображение без данных, встроенных в его младший бит, мы бы увидели похожие закономерности.
Рисунок 10. Одна из битовых плоскостей RGB без скрытых данных
Теперь, для контраста, давайте взглянем на битовые плоскости LSB. На рисунке 11 показаны битовые плоскости LSB для каждого канала изображения PNG со встроенной зашифрованной (и сжатой) полезной нагрузкой. Напомним, что и шифрование, и сжатие обычно должны увеличивать энтропию изображения.Поэтому неудивительно, что битовые плоскости LSB такого изображения выглядят как случайный шум. Видно, что не используется все полотно битовых плоскостей LSB.
Полезная нагрузка занимает только пиксели, представляющие размер полезной нагрузки, а остальные остаются нетронутыми; см. алгоритм ниже.
В этом конкретном случае файлы PNG расположены в C:\Program Files\Internet Explorer, поэтому изображение не привлекает внимания, поскольку Internet Explorer имеет тему, аналогичную рисунку 12.
Рисунок 12. Пример графической темы Internet Explorer
DropBoxControl
Можем расширить цепочку компрометации с помощью полезной нагрузки .NET C#, которую мы называем DropBoxControl– третий этап, см. рисунок 13
Рисунок 13. Расширенная цепочка компрометации
DropBoxControl представляет собой бэкдор, который общается с злоумышленниками через сервис DropBox. Примечательно, что C&C-сервер — это учетная запись DropBox, и все коммуникации, такие как команды, загрузки и загрузки, выполняются с использованием обычных файлов в определенных папках. Поэтому команды бэкдора представлены в виде файлов с определенным расширением. DropBoxControlпериодически проверяет папку DropBox и выполняет команды на основе файлов запроса. Ответ на каждую команду также загружается в папку DropBox в виде файла результата.
Ниже описание компонентов DropBoxControl и весь рабочий процесс бэкдора.
API DropBox
DropBoxControl реализует связь DropBox, применяя стандартный API через HTTP/POST. Есть специальный класс, DropBoxOperation, обернув API методом, представленным в Таблице 1. Ключ API DropBox, отправленный в заголовке HTTP, жестко запрограммирован в DropBoxControl образец, он может быть изменен удаленно.
Злоумышленники управляют бэкдором с помощью десяти команд, записанных в Таблице 2 .
Команда Info отправляет основную информацию о зараженной системе следующим образом:
ClientId, жестко закодированный в каждом образце DropBoxControl
Версия образца DropBoxControl (видел 1.1.2.0001)
Имя хоста машины жертвы
Список всех IP-адресов жертвы
Версия и размер файла explorer.exe
Архитектура Windows
Список жестких дисков, включая общий размер, доступное свободное пространство и тип диска
Текущее время на машине жертвы
Конфигурация
DropBoxControl, объект данного исследования, использует три файла, расположенные в C:\Program Files\Internet Explorer. Имена файлов стараются выглядеть легитимно с точки зрения папки Internet Explorer.
ieproxy.dat
Этот файл содержит конфигурацию DropBoxControl, которая зашифрована. Он настраивает четыре переменные следующим образом:
DropboxId: API-ключ, используемый для авторизации
Interval: как часто проверяется диск DropBox
UpTime/DownTime: определяет временной интервал, когда бэкдор активен (см. 7 - 23).
Смотрите пример содержимого конфигурационного файла:
Bearer WGG0iGT****AAGkOdrimId9***QfzuwM-nJm***R8nNhy,300,7,23
iexplore.log
Файл iexplore.log - это файл журнала DropBoxControl, который записывает большинство действий, таких как обращение к DropBox, загрузка/выгрузка файлов, загрузка конфигурации и т.д. Сущности журнала записываются только в том случае, если существует файл sqmapi.dat. Механизм входа реализован любопытно, поскольку лог-файл не зашифрован и содержит расшифрованные данные файла ieproxy.dat.
Шифрование
DropBoxControl шифрует конфигурационный файл (фактически без эффекта), а также осуществляет связь с DropBox. Конфигурационный файл шифруется с помощью многобайтового XOR с жестко закодированным ключом (owe01zU4). Хотя API-коммуникация шифруется через HTTPS, данные, хранящиеся на DropBox, шифруются собственным алгоритмом.
Данные шифруются с помощью другого жестко закодированного массива байтов (hexEnc), TaskId и ClientId. Более того, TaskId используется в качестве индекса для массива hexEnc, и этот индекс солят с ClientId на каждой итерации; см. рисунок 14. Это похоже на алгоритм, используемый PowHeartBeat.
Рисунок 14. Алгоритм шифрования, используемый для файлов DropBox
Как мы упоминали выше, связь между бэкдорами и злоумышленниками осуществляется с помощью файлов DropBox. Как правило, файлы DropBox, содержащие ценную информацию, зашифрованы. Каждый файл, помимо самих данных, также включает в себя флаги, тип задачи ( команда ) и другие метаданные, как показано на рис. 15 и в табл. 3.
Рисунок 15. Файловая структура файлов DropBox
Возвращаясь к файлам DropBox, мы исследуем файловую структуру DropBox учетной записи DropBox. Корневая папка включает в себя папки, названные в соответствии с ClientId который жестко запрограммирован в DropBoxControl; точнее, в файле PNG.
Каждая папка клиента содержит time.txt файл, который включает в себя число, которое является счетчиком итераций бэкдора. Одна итерация означает обращение к соответствующей клиентской папке в репозитории DropBox и ее обработку.
Злоумышленники указывают тип задачи и возможные параметры. Затем тип и параметры задачи упаковываются с использованием заголовка файла и загружаются в соответствующую папку клиента в виде файла запроса ( .req). Дальнейший анализ показал, что бэкдор обрабатывает .reqфайлы и создает файл результата ( .res) в качестве ответа для каждого файла запроса. Файл результатов имеет ту же файловую структуру, что и показанная на рис. 15, но данные, длина данных и тип задачи имеют разные значения, поскольку возвращаемые данные содержат запрошенную (украденную) информацию. Сравнив все папки DropBox ( рисунок 16 ), мы определили имя файла запроса и результата в таком виде: [0-9]+-[0-9]+. Имя файла используется для идентификации запроса/ответа, а также для шифрования данных. Например, давайте использовать имя файла запроса 31-1233.req. IDMessageявляется 31-1233а также TaskIdявляется 1233. Таким образом, данные шифруются с помощью ClientIdа также TaskId, а также жестко закодированные hexEnc.
Рисунок 16. Список файлов DropBox
Рабочий процесс DropBoxControl
Мы определили и описали основные функциональные возможности DropBoxControl в разделах выше. Поэтому мы можем обобщить все эти знания в виде рабочего процесса бэкдора и описать весь процесс сбора данных, загрузки, скачивания и взаимодействия с хранилищем DropBox.
В начале PNGLoader извлекает стенографически внедренный DropBoxControl и вызывает метод Main класса C# Mydropbox.Program. Затем DropBoxControl расшифровывает и загружает конфигурационный файл, содержащий API-ключ DropBox. Большинство действий записывается в файл журнала.
Если текущее время находится между интервалом UpTime и DownTime, DropBoxControl становится активным и запускает основную функциональность. Он связывается с хранилищем DropBox и загружает файл time.txt в папку клиента. Если загрузка файла time.txt прошла успешно, бэкдор загружает список всех файлов, хранящихся в папке клиента. Список файлов итерируется, и каждый файл запроса (.req) загружается и обрабатывается в зависимости от типа задания (команды). DropBoxControl выполняет команду и создает файл результата (.res) с запрошенной информацией. Полученный зашифрованный файл загружается обратно в папку клиента. Наконец, обработанный файл запроса (.req) удаляется.
Анализ жертв
Жертвы, на которых была нацелена эта кампания, похожи на тех, кого видела компания ESET. Жертвами этой кампании стали компании и государственные учреждения в Азии и Северной Америке, а именно в Мексике. Вьетнам и Камбоджа - другие страны, пострадавшие от DropBoxControl. Одно из соединений DropBoxControl отслеживалось с IP, связанного с Министерством экономического развития России.
Обсуждение
Третий этап цепочки компрометации представлен C#-реализацией DropBoxControl. Функциональность DropBoxControl позволяет злоумышленникам контролировать и шпионить за машинами жертв. Более того, бэкдор имеет доступ к папке Program Files, поэтому мы ожидаем, что он будет запущен под правами администратора. Наиболее распространенной командой, наблюдаемой в лог-файлах, является получение информации о файлах жертв, а затем сбор данных.
Типичной командой для сбора данных является команда cmd; см. пример ниже:
Атаки направлены на сбор всех интересующих файлов, таких как Word, Excel, PowerPoint, PDF и т.д. Они рекурсивно перебирают файлы на диске C:\\ и упаковывают их в зашифрованный архив rar, разбитый на несколько файлов. Другая команда, расшифрованная из файла запроса, запускает программу Ettercap, которая прослушивает сетевые соединения в реальном времени, используя атаку "человек посередине"; см. команду ниже:
Злоумышленники могут прослушивать сетевые коммуникации и перехватывать учетные данные пользователей, отправленные, например, через веб-страницы.
Одним словом, DropBoxControl - это вредоносное ПО с функциями бэкдора и шпиона.
Аккаунт DropBox
Мы зафиксировали эти три API DropBox:
Два ключа зарегистрированы на имя "Veronika Shabelyanova" (vershabelyanova1@gmail[.]com) с китайской локализацией. Электронная почта все еще активна, как и хранилище DropBox. Пользователь электронной почты - это славянская транскрипция "Вероника Шабелянова".
Третий репозиторий DropBox связан с гонконгским пользователем "Hartshorne Yaeko" (yaekohartshornekrq11@gmai[l].com).
Файлы DropBox
Мы следим за хранилищами DropBox и уже получили некоторую примечательную информацию. Аккаунты DropBox были созданы 11 июля 2019 года, судя по файлам README, созданным при создании аккаунта.
На данный момент только один репозиторий DropBox кажется активным. Оно содержит семь папок с семью файлами time.txt, поэтому существует семь активных экземпляров DropBoxControl, поскольку файлы time.txt содержат целые числа, которые периодически увеличиваются; см. раздел Файлы DropBox. Более того, целочисленные значения указывают на то, что бэкдоры работают непрерывно в течение десятков дней. Что касается команд бэкдора, мы предполагаем, что последняя активность, отправлявшая файлы запроса, была 1 июня 2022 года, также для семи бэкдоров. Наконец, общее количество папок, представляющих зараженные машины, равно двадцати одной жертве.
В апреле 2022 года злоумышленники загрузили сценарий на языке Lua, реализующий shortport библиотеки nmap для поиска служб Telnet, использующих s3270 для управления мэйнфреймами IBM; см. сценарий ниже.
Хотя обычно мы воздерживаемся от комментариев по поводу качества кода, в данном случае оно заслуживает упоминания, так как качество кода в лучшем случае спорно, и не каждое возражение можно списать на обфускацию. Код содержит много избыточного кода; как повторяющийся код, так и код, который не выполняет никакой функции. Признаком незнания C# является использование собственной реализации методов сериализации/десериализации вместо использования встроенных функций C#. Код многопоточности не опирается на обычные примитивы синхронизации, такие как семафоры, мьютексы и т. д., а использует логические флаги с периодическими проверками состояний потоков.Код также содержит части, предположительно скопированные из документации по API. Например, реализация DropBox_FileDownload содержит тот же комментарий, что и в документации DropBox; см. иллюстрацию ниже.
Еще одна странная особенность — метод шифрования файла конфигурации. DropBoxControlавтор попытался запутать конфигурацию в ieproxy.datфайл, потому что ключ API является конфиденциальной информацией. Однако, когда файл конфигурации расшифровывается и применяется, содержимое конфигурации регистрируется в iexplore.logфайл в виде простого текста.
Другими словами, весь проект DropBoxControl выглядит как школьный проект. Авторы не придерживаются обычных методов кодирования, полагаются на собственную реализацию общих примитивов и повторно используют код из примеров документации. Это приводит нас к оценке, что DropBoxControlавторы отличаются от авторов CLRLoaderа также PNGLoaderиз-за значительно отличающегося качества кода этих полезных нагрузок.
Вывод
Целью данного исследования было подтверждение предположений наших коллег-исследователей из ESET, опубликованных в статье о кибершпионской группе Worok. Нашему исследованию удалось расширить их компрометирующую цепочку, поскольку нам удалось найти артефакты, соответствующие цепочке, сопровождающей рассматриваемые образцы. Мы описали вероятные сценарии того, как первоначальная компрометация может быть запущена путем злоупотребления перехватом DLL служб Windows, в том числе боковым перемещением. Остальная часть цепочки компрометации очень похожа на описание ESET. Ключевым результатом этого исследования является перехват файлов PNG, как и предсказывала ESET. Стенографически встроенная полезная нагрузка C# (DropBoxControl) подтверждает, что Worok является группой кибершпионажа. Они крадут данные через учетную запись DropBox, зарегистрированную на активную электронную почту Google.
Распространенность инструментов Worok в дикой природе невелика, поэтому это может указывать на то, что набор инструментов представляет собой проект APT, ориентированный на известных организаций в частном и государственном секторах в Азии, Африке и Северной Америке.
Приложение
Значения типа задачи
PNG-файл со стеганографически встроенными полезными данными C#
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Milovski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Наши коллеги-исследователи из ESET опубликовали статью о ранее незадокументированных инструментах, проникающих в крупные компании и местные органы власти в Азии. Инструменты, действующие как минимум с 2020 года, предназначены для кражи данных.ESET назвала их Workok ESET зафиксировала значительный перерыв в активности с 5 мая 2021 г. по начало 2022 г. Тем не менее, когда Worok снова стал активным, новые целевые жертвы, в том числе энергетические компании в Центральной Азии и организации государственного сектора в Юго-Восточной Азии, были заражены для кражи данных на основе о типах атакуемых компаний. Исследователи из ESET описали две цепочки выполнения и способы компрометации компьютеров жертв. Первоначальный компромисс неизвестен, но следующие этапы подробно описаны, в том числе описание того, как конечная полезная нагрузка загружается и извлекается с помощью стеганографии из файлов PNG. Однако окончательная полезная нагрузка еще не восстановлена. Подробную информацию о Worok, цепочках и командах бэкдора можно найти в статье ESET Workok: The big picture.
Наш анализ направлен на расширение текущих знаний об исследованиях ESET.Мы захватили дополнительные артефакты, связанные с Вороком, в конце цепочки выполнения. Файлы PNG, захваченные нашей телеметрией, подтверждают, что целью конечной полезной нагрузки, встроенной в них, является кража данных. Что примечательно, так это сбор данных с машин жертв с помощью репозитория DropBox, а также злоумышленников с помощью DropBox API для связи с финальной стадией.
Вся цепочка
Мы намерены придерживаться терминологии, установленной в исследовании ESET. Наше исследование также не выявило всей первоначальной компрометации вредоносного ПО. Однако у нас есть несколько новых наблюдений, которые могут быть частью процесса проникновения.
На рис. 1 показана исходная цепочка компрометации, описанная ESET. В некоторых случаях вредоносное ПО предположительно внедряется злоумышленниками через ProxyShell уязвимости. В некоторых крайних случаях эксплойты против уязвимости ProxyShell использовались для персистентности в сети жертвы. Затем злоумышленники использовали общедоступные инструменты эксплойтов для развертывания своих пользовательских вредоносов. Итак, финальная цепочка проста: первый этап CLRLoader, который реализует простой код, загружающий следующий этап ( PNGLoader).
Как начать
Конкретный вектор начальной атаки пока неизвестен, но мы обнаружили на взломанных машинах четыре библиотеки DLL, содержащие код CLRLoader. Наши обнаружения зафиксировали дерево процессов, показанное на рисунке 2.
Это дерево процессов наблюдалось для WLBSCTRL.DLL, TSMSISrv.DLL и TSVIPSrv.DLL. Взаимный процесс, выполняющий DLL, - svchost -k netsvcs. Таким образом, начальным процессом является SvcHost, представляющий службу Windows. DLL файлы помогают нам определить две службы Windows, а именно IKE и AuthIP IPsec Keying Modules (IKEEXT) и Remote Desktop Configuration (SessionEnv). Обе службы известны тем, что по умолчанию захватывают DLL-файлы, отсутствующие в папке System32, SCM и DLL Hijacking Primer.
Боковое перемещение
Перехват DLL в папке System32 сам по себе не является уязвимостью, поскольку для записи в нее злоумышленникам необходимы привилегии администратора. Однако мы предполагаем наличие реализованной обратной оболочки с привилегиями администратора как следствие первоначальной компрометации. В этом случае злоумышленник может эффективно выполнить латеральное перемещение через диспетчер управления службами (SVCCTL).
Короче говоря, злоумышленники помещают перехваченные DLL-файлы в %SYSTEMROOT%\System32, а затем удаленно запускают соответствующую службу.
Список взломанных служб Windows и их DLL-файлов:
Модули ключей IPsec IKE и AuthIP:
C:\Windows\System32\WLBSCTRL.dll
Конфигурация удаленного рабочего стола:
C:\Windows\System32\TSMSISrv.dll
C:\Windows\System32\TSVIPSrv.dll
Второй замеченный захват DLL связан с машинами VMware. Злоумышленники могут злоупотреблять захватом vmGuestLib.dll, которая используется службой WMI Performance Adapter (WmiApSrv) для предоставления информации о производительности. При запуске системы WmiApSrv загружает vmStatsProvider.dll, который пытается вызвать vmGuestLib.dll из %ProgramFiles%\VMware\VMware Tools\vmStatsProvider\win32 в качестве первого. Однако оригинальная библиотека находится в %SYSTEMROOT%\System32. Следовательно, если злоумышленники поместят vmGuestLib.dll в папку %ProgramFiles%, это также приведет к перехвату DLL. Эти два подхода являются вероятными сценариями того, как может быть выполнен CLRLoader, и запущена цепочка компрометации, показанная на рисунке 1. Элегантность этого подхода заключается в том, что злоумышленникам не нужно создавать новую службу, которая может выявить подозрительную деятельность. Злоумышленники злоупотребляют только экспортными функциями взломанных DLL, пустая перереализация которых не вызывает ошибки или какого-либо другого признака компрометации. Более того, постоянство CLRLoader обеспечивается легитимными службами Windows.
CLRLoader
CLRLoader - это DLL-файл, написанный на Microsoft Visual C++. Он реализует метод DllMain, который отвечает за загрузку следующего этапа (.NET вариант PNGLoader). Остальные экспортируемые функции соответствуют интерфейсам взломанных DLL, но реализация экспортируемых функций пуста. Поэтому вызов этой функции не вызывает сбоя в вызывающих процессах. Для полноты картины, взломанные файлы также содержат цифровые подписи оригинальных DLL-файлов; естественно, подпись недействительна. CLRLoader активируется вызовом LoadLibraryExW из нарушенного процесса/службы. LoadLibraryExW вызывается с нулевыми параметрами dwFlags, поэтому при загрузке вредоносной DLL в виртуальное адресное пространство вызывается DllMain. Пример кода CLRLoader показан на рисунке 3.
CLRLoader проверяет наличие DLL-файла .NET, содержащего PNGLoader, создает мьютекс и, наконец, выполняет PNGLoader через API CorBindToRuntimeEx.
Мы распознали два варианта PNGLoader со следующими точками входа:
Код:
Jsprofile.Jspfilter (Setfilter)
pngpcd.ImageCoder (PngCoder)PNGLoader
Второй этап (PNGLoader) загружается CLRLoader или, как сообщает ESET, PowHeartBeat. Мы пока не видим кода, развертывающего PNGLoader на инфильтрированных системах, но ожидаем увидеть его аналогично боковому перемещению. PNGLoader - это загрузчик, который извлекает байты из файлов PNG и реконструирует их в исполняемый код. PNGLoader - это DLL-файл .NET, обфусцированный с помощью .NET Reactor; описание файла содержит информацию, имитирующую легитимное программное обеспечение, такое как Jscript Profiler или Transfer Service Proxy. Деобфусцированный код PNGLoader включает точку входа (Setfilter), вызываемую CLRLoader. Имеется жестко закодированный путь loader_path, по которому рекурсивно ищутся все PNG-файлы. Каждый файл .png проверяется на наличие определенных атрибутов растрового изображения (высота, ширина) и стеганографически внедренного содержимого (DecodePng). Метод Setfilter показан на рисунке 4.
Стеганографическое внедрение основано на одном из наиболее распространенных стеганографических методов, называемом кодированием наименее значимых битов (LSB). Как правило, этот метод встраивает данные в младшие биты каждого пикселя. В этой конкретной реализации один пиксель кодирует полубайт (по одному биту на каждый альфа-, красный, зеленый и синий канал), т.е. два пикселя содержат байт скрытой информации, как показано на рис.5. Хотя этот метод очень легко обнаружить с помощью простого статистического анализа, такое изменение значения пикселя едва заметно невооруженным глазом.
Затем стеганографически внедренное содержимое извлекается в четыре этапа следующим образом.
- Извлекаются первые 16 байтов (32 пикселя) файла PNG, а первые 8 байтов должны соответствовать магическому числу. Эта проверка выполняется из-за вычислительной сложности, необходимой для извлечения остальных пикселей (примерно сотни тысяч пикселей). Следующие 8 байтов представляют собой длину встроенной полезной нагрузки.
- Следующие извлеченные данные представляют собой зашифрованную полезную нагрузку в формате Gzip.
- Извлеченная полезная нагрузка расшифровывается с помощью многобайтового XOR, жестко запрограммированного в PNGLoader.
- Результатом операции XOR являются разархивированные данные Gzip.
Результатом этих шагов является окончательная полезная нагрузка, стеганографически встроенная в файл PNG.
Стеганографически встроенная полезная нагрузка
Если PNGLoaderуспешно обрабатывает ( извлекает → декодирует → распаковывает ) финальную полезную нагрузку, она компилируется во время выполнения и немедленно выполняется. Наша телеметрия зафиксировала два варианта PNGLoaderработа с магическими числами, записанными на рисунке 6 .
Первой реализацией полезной нагрузки является сценарий PowerShell, как показано в фрагменте кода PNGLoade rна рисунке 7 . Как и у наших коллег из ESET, у нас пока нет образца этой полезной нагрузки, но мы ожидаем аналогичную функцию, как и вторая реализация полезной нагрузки, описанная ниже.
Вторая реализация полезной нагрузки — это .NET C#, скомпилированный и выполненный через CompileAssemblyFromSourceметод CSharpCodeProviderкласс, см. рис. 8
.
Полезная нагрузка .NET C# имеет пространство имен Mydropbox, класс Programи метод Main. Пространство имен указывает, что полезная нагрузка работает с DropBox. Наше оборудование зафиксировало несколько файлов PNG, включая стеганографически встроенную полезную нагрузку C#.
PNG-файлы
На первый взгляд картинки PNG выглядят невинно, как пушистое облачко; см. рис. 9 . Наша телеметрия захватила три изображения PNG со следующими атрибутами:
- Размер: 1213 x 270 (пикс.)
- Разрядность: 8, тип цвета: 6 (RGB + Alpha)
Рис. 9. Вредоносный PNG-файл со стеганографически внедренной полезной нагрузкой C#
Как мы упоминали ранее, авторы вредоносных программ полагаются на кодирование LSB, чтобы скрыть вредоносную полезную нагрузку в пиксельных данных PNG, в частности, в LSB каждого цветового канала (красного, зеленого, синего и альфа-канала). Давайте посмотрим на их бит-планы. На рис. 10 показана одна из старших битовых плоскостей для каждого цветового канала; обратите внимание, что каждое из этих изображений выглядит далеким от случайного шума. Если бы мы посмотрели на изображение без данных, встроенных в его младший бит, мы бы увидели похожие закономерности.
Рисунок 10. Одна из битовых плоскостей RGB без скрытых данных
Теперь, для контраста, давайте взглянем на битовые плоскости LSB. На рисунке 11 показаны битовые плоскости LSB для каждого канала изображения PNG со встроенной зашифрованной (и сжатой) полезной нагрузкой. Напомним, что и шифрование, и сжатие обычно должны увеличивать энтропию изображения.Поэтому неудивительно, что битовые плоскости LSB такого изображения выглядят как случайный шум. Видно, что не используется все полотно битовых плоскостей LSB.
Полезная нагрузка занимает только пиксели, представляющие размер полезной нагрузки, а остальные остаются нетронутыми; см. алгоритм ниже.
В этом конкретном случае файлы PNG расположены в C:\Program Files\Internet Explorer, поэтому изображение не привлекает внимания, поскольку Internet Explorer имеет тему, аналогичную рисунку 12.
Рисунок 12. Пример графической темы Internet Explorer
DropBoxControl
Можем расширить цепочку компрометации с помощью полезной нагрузки .NET C#, которую мы называем DropBoxControl– третий этап, см. рисунок 13
Рисунок 13. Расширенная цепочка компрометации
DropBoxControl представляет собой бэкдор, который общается с злоумышленниками через сервис DropBox. Примечательно, что C&C-сервер — это учетная запись DropBox, и все коммуникации, такие как команды, загрузки и загрузки, выполняются с использованием обычных файлов в определенных папках. Поэтому команды бэкдора представлены в виде файлов с определенным расширением. DropBoxControlпериодически проверяет папку DropBox и выполняет команды на основе файлов запроса. Ответ на каждую команду также загружается в папку DropBox в виде файла результата.
Ниже описание компонентов DropBoxControl и весь рабочий процесс бэкдора.
API DropBox
DropBoxControl реализует связь DropBox, применяя стандартный API через HTTP/POST. Есть специальный класс, DropBoxOperation, обернув API методом, представленным в Таблице 1. Ключ API DropBox, отправленный в заголовке HTTP, жестко запрограммирован в DropBoxControl образец, он может быть изменен удаленно.
Команды
Злоумышленники управляют бэкдором с помощью десяти команд, записанных в Таблице 2 .
Команда Info отправляет основную информацию о зараженной системе следующим образом:
ClientId, жестко закодированный в каждом образце DropBoxControl
Версия образца DropBoxControl (видел 1.1.2.0001)
Имя хоста машины жертвы
Список всех IP-адресов жертвы
Версия и размер файла explorer.exe
Архитектура Windows
Список жестких дисков, включая общий размер, доступное свободное пространство и тип диска
Текущее время на машине жертвы
Конфигурация
DropBoxControl, объект данного исследования, использует три файла, расположенные в C:\Program Files\Internet Explorer. Имена файлов стараются выглядеть легитимно с точки зрения папки Internet Explorer.
ieproxy.dat
Этот файл содержит конфигурацию DropBoxControl, которая зашифрована. Он настраивает четыре переменные следующим образом:
DropboxId: API-ключ, используемый для авторизации
Interval: как часто проверяется диск DropBox
UpTime/DownTime: определяет временной интервал, когда бэкдор активен (см. 7 - 23).
Смотрите пример содержимого конфигурационного файла:
Bearer WGG0iGT****AAGkOdrimId9***QfzuwM-nJm***R8nNhy,300,7,23
iexplore.log
Файл iexplore.log - это файл журнала DropBoxControl, который записывает большинство действий, таких как обращение к DropBox, загрузка/выгрузка файлов, загрузка конфигурации и т.д. Сущности журнала записываются только в том случае, если существует файл sqmapi.dat. Механизм входа реализован любопытно, поскольку лог-файл не зашифрован и содержит расшифрованные данные файла ieproxy.dat.
Шифрование
DropBoxControl шифрует конфигурационный файл (фактически без эффекта), а также осуществляет связь с DropBox. Конфигурационный файл шифруется с помощью многобайтового XOR с жестко закодированным ключом (owe01zU4). Хотя API-коммуникация шифруется через HTTPS, данные, хранящиеся на DropBox, шифруются собственным алгоритмом.
Данные шифруются с помощью другого жестко закодированного массива байтов (hexEnc), TaskId и ClientId. Более того, TaskId используется в качестве индекса для массива hexEnc, и этот индекс солят с ClientId на каждой итерации; см. рисунок 14. Это похоже на алгоритм, используемый PowHeartBeat.
Рисунок 14. Алгоритм шифрования, используемый для файлов DropBox
Файлы DropBox
Как мы упоминали выше, связь между бэкдорами и злоумышленниками осуществляется с помощью файлов DropBox. Как правило, файлы DropBox, содержащие ценную информацию, зашифрованы. Каждый файл, помимо самих данных, также включает в себя флаги, тип задачи ( команда ) и другие метаданные, как показано на рис. 15 и в табл. 3.
Рисунок 15. Файловая структура файлов DropBox
Возвращаясь к файлам DropBox, мы исследуем файловую структуру DropBox учетной записи DropBox. Корневая папка включает в себя папки, названные в соответствии с ClientId который жестко запрограммирован в DropBoxControl; точнее, в файле PNG.
Каждая папка клиента содержит time.txt файл, который включает в себя число, которое является счетчиком итераций бэкдора. Одна итерация означает обращение к соответствующей клиентской папке в репозитории DropBox и ее обработку.
Злоумышленники указывают тип задачи и возможные параметры. Затем тип и параметры задачи упаковываются с использованием заголовка файла и загружаются в соответствующую папку клиента в виде файла запроса ( .req). Дальнейший анализ показал, что бэкдор обрабатывает .reqфайлы и создает файл результата ( .res) в качестве ответа для каждого файла запроса. Файл результатов имеет ту же файловую структуру, что и показанная на рис. 15, но данные, длина данных и тип задачи имеют разные значения, поскольку возвращаемые данные содержат запрошенную (украденную) информацию. Сравнив все папки DropBox ( рисунок 16 ), мы определили имя файла запроса и результата в таком виде: [0-9]+-[0-9]+. Имя файла используется для идентификации запроса/ответа, а также для шифрования данных. Например, давайте использовать имя файла запроса 31-1233.req. IDMessageявляется 31-1233а также TaskIdявляется 1233. Таким образом, данные шифруются с помощью ClientIdа также TaskId, а также жестко закодированные hexEnc.
Рисунок 16. Список файлов DropBox
Рабочий процесс DropBoxControl
Мы определили и описали основные функциональные возможности DropBoxControl в разделах выше. Поэтому мы можем обобщить все эти знания в виде рабочего процесса бэкдора и описать весь процесс сбора данных, загрузки, скачивания и взаимодействия с хранилищем DropBox.
В начале PNGLoader извлекает стенографически внедренный DropBoxControl и вызывает метод Main класса C# Mydropbox.Program. Затем DropBoxControl расшифровывает и загружает конфигурационный файл, содержащий API-ключ DropBox. Большинство действий записывается в файл журнала.
Если текущее время находится между интервалом UpTime и DownTime, DropBoxControl становится активным и запускает основную функциональность. Он связывается с хранилищем DropBox и загружает файл time.txt в папку клиента. Если загрузка файла time.txt прошла успешно, бэкдор загружает список всех файлов, хранящихся в папке клиента. Список файлов итерируется, и каждый файл запроса (.req) загружается и обрабатывается в зависимости от типа задания (команды). DropBoxControl выполняет команду и создает файл результата (.res) с запрошенной информацией. Полученный зашифрованный файл загружается обратно в папку клиента. Наконец, обработанный файл запроса (.req) удаляется.
Анализ жертв
Жертвы, на которых была нацелена эта кампания, похожи на тех, кого видела компания ESET. Жертвами этой кампании стали компании и государственные учреждения в Азии и Северной Америке, а именно в Мексике. Вьетнам и Камбоджа - другие страны, пострадавшие от DropBoxControl. Одно из соединений DropBoxControl отслеживалось с IP, связанного с Министерством экономического развития России.
Обсуждение
Третий этап цепочки компрометации представлен C#-реализацией DropBoxControl. Функциональность DropBoxControl позволяет злоумышленникам контролировать и шпионить за машинами жертв. Более того, бэкдор имеет доступ к папке Program Files, поэтому мы ожидаем, что он будет запущен под правами администратора. Наиболее распространенной командой, наблюдаемой в лог-файлах, является получение информации о файлах жертв, а затем сбор данных.
Типичной командой для сбора данных является команда cmd; см. пример ниже:
Код:
rar.exe a -m5 -r -y -ta20210204000000 -hp1qazxcde32ws -v2560k Asia1Dpt-PC-c.rar c:\\\*.doc c:\\\*.docx c:\\\*.xls c:\\\*.xlsx c:\\\*.pdf c:\\\*.ppt c:\\\*.pptx c:\\\*.jpg c:\\\*.txt >nulАтаки направлены на сбор всех интересующих файлов, таких как Word, Excel, PowerPoint, PDF и т.д. Они рекурсивно перебирают файлы на диске C:\\ и упаковывают их в зашифрованный архив rar, разбитый на несколько файлов. Другая команда, расшифрованная из файла запроса, запускает программу Ettercap, которая прослушивает сетевые соединения в реальном времени, используя атаку "человек посередине"; см. команду ниже:
Код:
ettercap.exe -Tq -w a.cap -M ARP /192.168.100.99/ //.Злоумышленники могут прослушивать сетевые коммуникации и перехватывать учетные данные пользователей, отправленные, например, через веб-страницы.
Одним словом, DropBoxControl - это вредоносное ПО с функциями бэкдора и шпиона.
Аккаунт DropBox
Мы зафиксировали эти три API DropBox:
Код:
Bearer gg706X***************Ru_43QAg**********1JU1DL***********ej1_xH7e
Bearer ARmUaL***************Qg02vynP**********ASEyQa***********deRLu9Gx
Bearer WGG0iG***************kOdrimId**********ZQfzuw***********6RR8nNhyДва ключа зарегистрированы на имя "Veronika Shabelyanova" (vershabelyanova1@gmail[.]com) с китайской локализацией. Электронная почта все еще активна, как и хранилище DropBox. Пользователь электронной почты - это славянская транскрипция "Вероника Шабелянова".
Третий репозиторий DropBox связан с гонконгским пользователем "Hartshorne Yaeko" (yaekohartshornekrq11@gmai[l].com).
Файлы DropBox
Мы следим за хранилищами DropBox и уже получили некоторую примечательную информацию. Аккаунты DropBox были созданы 11 июля 2019 года, судя по файлам README, созданным при создании аккаунта.
На данный момент только один репозиторий DropBox кажется активным. Оно содержит семь папок с семью файлами time.txt, поэтому существует семь активных экземпляров DropBoxControl, поскольку файлы time.txt содержат целые числа, которые периодически увеличиваются; см. раздел Файлы DropBox. Более того, целочисленные значения указывают на то, что бэкдоры работают непрерывно в течение десятков дней. Что касается команд бэкдора, мы предполагаем, что последняя активность, отправлявшая файлы запроса, была 1 июня 2022 года, также для семи бэкдоров. Наконец, общее количество папок, представляющих зараженные машины, равно двадцати одной жертве.
В апреле 2022 года злоумышленники загрузили сценарий на языке Lua, реализующий shortport библиотеки nmap для поиска служб Telnet, использующих s3270 для управления мэйнфреймами IBM; см. сценарий ниже.
Качество кода DropBoxControl
Хотя обычно мы воздерживаемся от комментариев по поводу качества кода, в данном случае оно заслуживает упоминания, так как качество кода в лучшем случае спорно, и не каждое возражение можно списать на обфускацию. Код содержит много избыточного кода; как повторяющийся код, так и код, который не выполняет никакой функции. Признаком незнания C# является использование собственной реализации методов сериализации/десериализации вместо использования встроенных функций C#. Код многопоточности не опирается на обычные примитивы синхронизации, такие как семафоры, мьютексы и т. д., а использует логические флаги с периодическими проверками состояний потоков.Код также содержит части, предположительно скопированные из документации по API. Например, реализация DropBox_FileDownload содержит тот же комментарий, что и в документации DropBox; см. иллюстрацию ниже.
Еще одна странная особенность — метод шифрования файла конфигурации. DropBoxControlавтор попытался запутать конфигурацию в ieproxy.datфайл, потому что ключ API является конфиденциальной информацией. Однако, когда файл конфигурации расшифровывается и применяется, содержимое конфигурации регистрируется в iexplore.logфайл в виде простого текста.
Другими словами, весь проект DropBoxControl выглядит как школьный проект. Авторы не придерживаются обычных методов кодирования, полагаются на собственную реализацию общих примитивов и повторно используют код из примеров документации. Это приводит нас к оценке, что DropBoxControlавторы отличаются от авторов CLRLoaderа также PNGLoaderиз-за значительно отличающегося качества кода этих полезных нагрузок.
Вывод
Целью данного исследования было подтверждение предположений наших коллег-исследователей из ESET, опубликованных в статье о кибершпионской группе Worok. Нашему исследованию удалось расширить их компрометирующую цепочку, поскольку нам удалось найти артефакты, соответствующие цепочке, сопровождающей рассматриваемые образцы. Мы описали вероятные сценарии того, как первоначальная компрометация может быть запущена путем злоупотребления перехватом DLL служб Windows, в том числе боковым перемещением. Остальная часть цепочки компрометации очень похожа на описание ESET. Ключевым результатом этого исследования является перехват файлов PNG, как и предсказывала ESET. Стенографически встроенная полезная нагрузка C# (DropBoxControl) подтверждает, что Worok является группой кибершпионажа. Они крадут данные через учетную запись DropBox, зарегистрированную на активную электронную почту Google.
Распространенность инструментов Worok в дикой природе невелика, поэтому это может указывать на то, что набор инструментов представляет собой проект APT, ориентированный на известных организаций в частном и государственном секторах в Азии, Африке и Северной Америке.
Приложение
[02:00:50]:[+]Main starts.
[02:00:50]:[+]Config exists.
[02:00:50]:[__]DecryptContent is 1,Bearer gg706Xqxhy4*****************gQ8L4OmOLdI1JU1DL**********1ej1_xH7e#,300,7,23
[10:39:40]:[+]In work time.
[10:39:42]:[UPD] UploadData /data/2019/time.txt Starts!
[10:40:08]:[UPD] UploadData /data/2019/time.txt Success!
[10:40:10]:[UPD] UploadData Ends!
[10:40:10]:[+]Get Time.txt success.
[10:40:11]:[+] DropBox_GetFileList Success!
[10:40:11]:[DOWN] DownloadData /data/2019/31-3.req Starts!
[10:40:13]:[DOWN] DownloadData /data/2019/31-3.req Success!
[10:40:13]:[DOWN] DownloadData Ends!
[10:40:26]:[UPD] UploadData /data/2019/31-3.res Starts!
[10:40:27]:[UPD] UploadData /data/2019/31-3.res Success!
[10:40:27]:[UPD] UploadData Ends!
[10:40:27]:[DEL] Delete /data/2019/31-3.req Starts!
[10:40:28]:[DEL] Delete /data/2019/31-3.req Success!
[10:40:28]:[DEL] Delete Ends!
[10:40:28]:[DOWN] DownloadData /data/2019/31-4.req Starts!
[10:40:29]:[DOWN] DownloadData /data/2019/31-4.req Success!
[10:40:29]:[DOWN] DownloadData Ends!
[10:40:34]:[UPD] UploadData /data/2019/31-4.res Starts!
[10:40:36]:[UPD] UploadData /data/2019/31-4.res Success!
[10:40:36]:[UPD] UploadData Ends!
[10:40:36]:[DEL] Delete /data/2019/31-4.req Starts!
[10:40:36]:[DEL] Delete /data/2019/31-4.req Success!
[10:40:36]:[DEL] Delete Ends!
[10:40:36]:[DOWN] DownloadData /data/2019/31-5.req Starts!
[10:40:37]:[DOWN] DownloadData /data/2019/31-5.req Success!
[10:40:37]:[DOWN] DownloadData Ends!
[10:40:42]:[UPD] UploadData /data/2019/31-5.res Starts!
[10:40:43]:[UPD] UploadData /data/2019/31-5.res Success!
[10:40:43]:[UPD] UploadData Ends!
[10:40:43]:[DEL] Delete /data/2019/31-5.req Starts!
[10:40:44]:[DEL] Delete /data/2019/31-5.req Success!
[10:40:44]:[DEL] Delete Ends!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Starts!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Success!
[10:40:44]:[DOWN] DownloadData Ends!
[10:40:49]:[UPD] UploadData /data/2019/31-7.res Starts!
[10:40:50]:[UPD] UploadData /data/2019/31-7.res Success!
[10:40:50]:[UPD] UploadData Ends!
[10:40:50]:[DEL] Delete /data/2019/31-7.req Starts!
[10:40:52]:[DEL] Delete /data/2019/31-7.req Success!
[10:40:52]:[DEL] Delete Ends!
[02:00:50]:[+]Config exists.
[02:00:50]:[__]DecryptContent is 1,Bearer gg706Xqxhy4*****************gQ8L4OmOLdI1JU1DL**********1ej1_xH7e#,300,7,23
[10:39:40]:[+]In work time.
[10:39:42]:[UPD] UploadData /data/2019/time.txt Starts!
[10:40:08]:[UPD] UploadData /data/2019/time.txt Success!
[10:40:10]:[UPD] UploadData Ends!
[10:40:10]:[+]Get Time.txt success.
[10:40:11]:[+] DropBox_GetFileList Success!
[10:40:11]:[DOWN] DownloadData /data/2019/31-3.req Starts!
[10:40:13]:[DOWN] DownloadData /data/2019/31-3.req Success!
[10:40:13]:[DOWN] DownloadData Ends!
[10:40:26]:[UPD] UploadData /data/2019/31-3.res Starts!
[10:40:27]:[UPD] UploadData /data/2019/31-3.res Success!
[10:40:27]:[UPD] UploadData Ends!
[10:40:27]:[DEL] Delete /data/2019/31-3.req Starts!
[10:40:28]:[DEL] Delete /data/2019/31-3.req Success!
[10:40:28]:[DEL] Delete Ends!
[10:40:28]:[DOWN] DownloadData /data/2019/31-4.req Starts!
[10:40:29]:[DOWN] DownloadData /data/2019/31-4.req Success!
[10:40:29]:[DOWN] DownloadData Ends!
[10:40:34]:[UPD] UploadData /data/2019/31-4.res Starts!
[10:40:36]:[UPD] UploadData /data/2019/31-4.res Success!
[10:40:36]:[UPD] UploadData Ends!
[10:40:36]:[DEL] Delete /data/2019/31-4.req Starts!
[10:40:36]:[DEL] Delete /data/2019/31-4.req Success!
[10:40:36]:[DEL] Delete Ends!
[10:40:36]:[DOWN] DownloadData /data/2019/31-5.req Starts!
[10:40:37]:[DOWN] DownloadData /data/2019/31-5.req Success!
[10:40:37]:[DOWN] DownloadData Ends!
[10:40:42]:[UPD] UploadData /data/2019/31-5.res Starts!
[10:40:43]:[UPD] UploadData /data/2019/31-5.res Success!
[10:40:43]:[UPD] UploadData Ends!
[10:40:43]:[DEL] Delete /data/2019/31-5.req Starts!
[10:40:44]:[DEL] Delete /data/2019/31-5.req Success!
[10:40:44]:[DEL] Delete Ends!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Starts!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Success!
[10:40:44]:[DOWN] DownloadData Ends!
[10:40:49]:[UPD] UploadData /data/2019/31-7.res Starts!
[10:40:50]:[UPD] UploadData /data/2019/31-7.res Success!
[10:40:50]:[UPD] UploadData Ends!
[10:40:50]:[DEL] Delete /data/2019/31-7.req Starts!
[10:40:52]:[DEL] Delete /data/2019/31-7.req Success!
[10:40:52]:[DEL] Delete Ends!
Значения типа задачи
PNG-файл со стеганографически встроенными полезными данными C#
Код:
29A195C5FF1759C010F697DC8F8876541651A77A7B5867F4E160FD8620415977
9E1C5FF23CD1B192235F79990D54E6F72ADBFE29D20797BA7A44A12C72D33B86
AF2907FC02028AC84B1AF8E65367502B5D9AF665AE32405C3311E5597C9C2774
