Dpsfnshr exe что это

Warm Snow Lab

Архив блога

Обо мне

Google Search

четверг, 3 апреля 2008 г.

В сети проскакивал диск К-систем (или что-то другое), но судя по отзывам это что-то отвратительное 🙂 Поэтому будем делать все своими руками.

Для создания диска нам также потребуется.

Рис 1 – начало работы с программой.

Выбираем русский (или любой другой из доступных ) языков и жмем далее (кнопка с символом > ). В платформе для инсталляции выбираем первый пункт (Диск).

Рис 2 – выбор платформы.

Жмем на кнопку Открыть и указываем папку с Дистрибутивом Win XP и нажимаем далее.

Рис 3 – выбор драверопакетов для интеграции.

И видим следующий скрин – Выбор пакетов драйверов. Я выбрал все возможные драйвера. Отмечу следующее, насколько я понял – если вы установите галку рядом DriverPack MassStorage Text Mode, то вначале установятся драйвера для жестких дисков. Или поправьте меня, если не прав.

Как выяснилось я был не прав

После этого выбираем метод для интеграции. Метод нужно выбрать второй – тогда в папке с дистрибутивом WinXP появиться папка ОЕМ, которая нужна там для дальнейшей работы.

Рис 4 – выбор метода для интеграции.

На следующем этапе Выбор Метода для старта Finisher – выбрал GUIRunOnce, на самом деле разницы тут никакой нет, так как мы с вами не интегрируем драйвера для установки их вместе с Виндоуз. Об этом мы, может быть, поговорим позже.

Рис 5 – выбор метода для старта Finisher.

Жмем далее раза 2 и перед нами вновь возникает выбор, но нас он в данном контексте также не интересует и поэтому выбираем Отключить KTD (отключить Keep The Drivers, по-русски Сохранить Драйвера На жестком диске).

Рис 6 – отключаем KTD.

Вот в принципе и все – на следующих скринах, можете выбрать Отключить Буфер Quick Stream и ATI Catalyst Control Panel, но можете просто нажать на кнопку Поехали! и идти за чаем.

Рис 7 – папка с «дровами» готова.

1. FINI.cmd – распаковывает пакеты с драйверами в Папку C:\WINDOWS\DriverPacks (или не С, а диск куда установлена система) и «прописывает» в системе драйвера. Таким образом при установке нового оборудования вам всего лишь нужно будет нажать Далее в мастере установки нового оборудования.

FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST «%%i:%TAGFILE%» SET CDDRIVE=%%i:

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\BIN\DP*.7z «%SystemDrive%\»

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\DP*.7z «%SystemRoot%\DriverPacks»

start %SystemDrive%\Mute.exe on

COPY /Y %CDDRIVE%\OEM\bin\DPsFnshr.ini %SystemDrive%\

xcopy %SystemRoot%\Driverpacks\*.* %SystemDrive%\ /y /i /e /h

taskkill /f /im DSPdsblr.exe

2. DO_PNF.cmd – аналогичен первому скрипту, но могут возникнуть сбои с установлением некоторых CPL аддонов. Поэтому рекомендую использовать первый скрипт.

FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST «%%i:%TAGFILE%» SET CDDRIVE=%%i:

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\BIN\DP*.7z «%SystemDrive%\dump»

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\DP*.7z «%SystemRoot%\DriverPacks»

start %SystemDrive%\dump\Mute.exe on

taskkill /f /im DSPdsblr.exe

RD /Q /S %SystemDrive%\dump

FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST «%%i:%TAGFILE%» SET CDDRIVE=%%i:

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\BIN\DP*.7z «%SystemDrive%\»

%CDDRIVE%\OEM\BIN\un7zip.exe %CDDRIVE%\OEM\DP*.7z «%SystemDrive%\»

COPY /Y %CDDRIVE%\OEM\bin\DPsFnshr.ini %SystemDrive%\

start %SystemDrive%\Mute.exe on

taskkill /f /im DSPdsblr.exe

Еще замечу что все это дело можно скопировать на флешку. Только запомните что папку ОЕМ должна быть помещена в корень флеш-диска, иными словами не должна быть вложена в другой каталог. Либо поправьте строку поиска в скрипте, только не используйте длинные имена папок. Вроде все.

За сим откланиваюсь. И тем кто дочитал до этого момента, предлагаю Лончер собственного производства. Работа с ним проста – выбираете метод установки и жмете Install Drivers.

Uploaded: 12/02/2008, 15:49:25

Рис 8 – Автоматизируем процесс.

Zaur Baghirov aka Теплый Снег

12-02-2008 Baku Azerbaijan

Источник

Борьба за производительность или кто отнимал процессорное время

Началось все с «Неваляшки». О том, что это такое и для чего это было надо описано тут: http://habrahabr.ru/company/oktell/blog/108726/. То есть, мы имели четыре работающих сервера call-центра, одинаково настроенных и с примерно одинаковой конфигурацией внешних и внутренних линий, пользователей и настройкой внутренней БД. На каждый из серверов со стороны оператора связи поступала равномерная звонковая нагрузка, но сервера реагировали на это по разному!

N Конфигурация сервера и операционная система
1 T1300 @ 1.66 1 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP1 32 bit
2 Intel Core Duo E8400 @ 3000 4 Гб ОЗУ, Windows 2003 Standard Ed.SP1 32 bit
3 Intel Pentium 4 3GHz 2 Гб ОЗУ, Windows 2003 Standard Ed. SP2 32 bit
4 E3400 @ 2.60 2 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP2 32 bit

Столкнулись с жалобами на качество связи. Причем, жаловались не на каждый звонок, а на «некоторые». Жаловались на «кваки», очень характерные для VoIP телефонии. Довольно оперативно было выяснено, что причиной появления «кваков» было непредсказуемый рост занятости процессора на одном (первом) из серверов call-центр при возрастании нагрузки. И это при всем притом, что другие сервера такой нагрузки вообще не замечали, и никакого роста нагрузки на процессор при таком же количестве вызовов не наблюдалось. Даже, несмотря на то, что первый сервер был значительно слабее всех остальных, такой картины — роста занятости процессора до 100% — наблюдаться не должно было.

Не стоит, наверное, говорить, что мы прошли стандартный путь «протирки фар», «пинания колес» и пр. В конечном итоге пришли к мнению, что ни настройки самого call-центр, ни его СУБД, на поведение сервера не влияет. Отправной точкой для понимания сущности проблемы послужил тот факт, что в диспетчере задач в списке процессов ни один из процессов не занимал процессорного времени, вместе с тем, на мониторинге быстродействия хронология загрузки процессора показывала непрерывную загрузку процессора ядра на уровне 20%.

Задались целью получить ответ на вопрос чем же занято ядро в том случае, когда нагрузки на все остальные сервисы отсутствуют. Process Explorer — штатная утилита от Microsoft — подсказала, что основным потребителем ресурсов является «Hardware Interrupts». Для дальнейшего анализа причин такого потребления была скачана другая штатная утилита от Microsoft — «Kernrate View». Как и было описано в рекомендациях по использованию, в командной строке выполнили «C:\Program Files\KrView\Kernrates\Kernrate_i386_XP.exe >> log.txt» и, спустя некоторое время, нажав Ctrl-C, остановили. Получили файл log.txt, содержащий информацию вида:

/==============================\
\==============================/
Date: 2010/12/08 Time: 1:09:14
Machine Name: RESERVCC
Number of Processors: 1
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: 6
PROCESSOR_REVISION: 0e08
Physical Memory: 1015 MB
Pagefile Total: 2450 MB
Virtual Total: 2047 MB
PageFile1: \??\C:\pagefile.sys, 1524MB
OS Version: 5.2 Build 3790 Service-Pack: 1.0
WinDir: C:\WINDOWS

Kernrate User-Specified Command Line:
Kernrate_i386_XP.exe

Kernel Profile (PID = 0): Source= Time,
Using Kernrate Default Rate of 25000 events/hit

P0 K 0:00:36.671 (28.5%) U 0:00:09.671 ( 7.5%) I 0:01:22.343 (64.0%) DPC 0:00:29.484 (22.9%) Interrupt 0:00:00.281 ( 0.2%)
Interrupts= 136809, Interrupt Rate= 1063/sec.

Total Profile Time = 128687 msec

Total Avg. Rate
Context Switches, 609407, 4736/sec.
System Calls, 5078088, 39461/sec.
Page Faults, 119817, 931/sec.
I/O Read Operations, 11671, 91/sec.
I/O Write Operations, 209479, 1628/sec.
I/O Other Operations, 229216, 1781/sec.
I/O Read Bytes, 39981700, 3426/ I/O
I/O Write Bytes, 19240135, 92/ I/O
I/O Other Bytes, 7130204725, 31107/ I/O

— Results for Kernel Mode:
— OutputResults: KernelModuleCount = 99
Percentage in the following table is based on the Total Hits for the Kernel

Time 44651 hits, 25000 events per hit — Module Hits msec %Total Events/Sec
intelppm 27457 128685 61 % 5334149
hal 12284 128685 27 % 2386447
ntkrnlpa 2868 128685 6 % 557174
win32k 525 128685 1 % 101993
alder9xp 427 128685 0 % 82954
tcpip 254 128685 0 % 49345
Ntfs 251 128685 0 % 48762
afd 120 128685 0 % 23312
RDPDD 109 128685 0 % 21175
e1e5132 109 128685 0 % 21175
iaStor 97 128685 0 % 18844
NDIS 39 128685 0 % 7576
RDPWD 31 128685 0 % 6022
fltMgr 26 128685 0 % 5051
amon 12 128685 0 % 2331
termdd 10 128685 0 % 1942
CLASSPNP 10 128685 0 % 1942
ftdisk 7 128685 0 % 1359
ipsec 3 128685 0 % 582
Npfs 2 128685 0 % 388
USBPORT 2 128685 0 % 388
volsnap 2 128685 0 % 388
TDTCP 1 128685 0 % 194
rdbss 1 128685 0 % 194
ws2ifsl 1 128685 0 % 194
netbt 1 128685 0 % 194
watchdog 1 128685 0 % 194
PartMgr 1 128685 0 % 194

Далее определяем какой именно драйвер загружает процесс «Hardware Interrupts». В списке лога «Kernrate View» он будет верхним, и рядом в процентах будет показана его доля занимания ядра. Тут стоит обратить внимание, что проценты показывают не общий процент от загрузки системы, а процент загрузки серверного ядра драйверами.
Определили, что этим драйвером является Intelppm (Intel processor power manager). Дальше — google нам в помощь. Интернет велик, могуч и безграничен. Довольно быстро поняли, что проблема с Intelppm возникает, не так уж и часто, вместе с тем, мы были не одни столкнувшиеся с такой бедой. Результат не замедлил себя обнаружить, нашлась статья, в которой не только описывается сама проблема, но и обозначается путь ее решения (Постоянный адрес оригинала статьи тут: http://www.osp.ru/text/print/302/5818429.html)
Далее следуя рекомендациям Стивена Догерти понимаем, что intelppm, является драйвером управления электропитанием процессора, который не нужен на сервере, где питание от аккумулятора и не используется вовсе. Вариантов решений было предложено несколько: переустановка, обновление или остановка неисправного драйвера. Какой варианты выберете вы — смотрите сами, вполне логично тут следовать оригинальным рекомендациям Догерти.
Мы полезли в реестр. Данные драйвера процессора Intel находятся в разделе реестра HKEY_LOCAL_MACHINE/SYSTEM/Current Control Set/Services/intelppm. Для отключения драевера intelppm изменили значение параметра Start с 1 на 4. Специалисты Microsoft, конечно, рекомендуют делать резервную копию реестра, но мы то с вами русские люди, да и что там один параметр поменять с 1 на 4.

Рестарт помог убедиться, что загрузка процессора в среднем находится в пределах 60-70% даже при полной(!) загрузке сервера call-центр звонками.
Очень интересно выглядит при этом диспетчер устройств:

Жалуется, ябедничает, плачет: «Драйвер для этого устройства был отключен. Возможно, необходимые функции исполняет другой драйвер. (Код 32), Нажмите кнопку „Диагностика“, чтобы запустить мастер диагностики для данного устройства.» Но на безопасность полетов это уже не влияет 😉

Источник

Пока расследование не разлучит нас: малварь, которая может сидеть в сети компании годами

Недавно мы расследовали АРТ-атаку на одну российскую компанию и нашли много занятного софта. Сначала мы обнаружили продвинутый бэкдор PlugX, популярный у китайских группировок, АРТ-атаки которых обычно нацелены на похищение конфиденциальной информации, а не денег. Затем из скомпрометированной сети удалось вытащить несколько других схожих между собой бэкдоров (nccTrojan, dnsTrojan, dloTrojan) и даже общедоступных утилит.

Программы, используемые в этой преступной кампании, не отличаются сложностью, за исключением, может быть, PlugX. К тому же три из четырех вредоносов использовали при запуске давно известную технику DLL hijacking. Тем не менее, как показало наше исследование, даже при таких условиях злоумышленники могут годами оставаться в скомпрометированных сетях.

Мы решили изучить обнаруженный софт и поделиться своими наблюдениями.

PlugX

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

Запуск PlugX

PlugX, как правило, распространяется в виде самораспаковывающихся архивов, содержащих:

Такой набор характерен для техники DLL hijacking, при которой злоумышленник заменяет легитимную DLL на вредоносную. При этом малварь получает возможность работать от имени легитимного процесса и обходить таким образом средства защиты (рис. 1).

Рис. 1. Наглядное представление техники DLL hijacking

Рассмотрим в качестве примера один из экземпляров PlugX, характеристики которого приведены в табл. 1.

Вот что происходит при запуске невредоносного исполняемого файла (EXE) из пакета.

Сначала одна из импортируемых им библиотек (отдельная DLL) заменяется вредоносной. После загрузки в память процесса DLL открывает третий файл из пакета PlugX, который обходит средства защиты за счет отсутствия видимого исполняемого кода. Тем не менее он содержит шелл-код, после исполнения которого в памяти расшифровывается еще один дополнительный шелл-код. Он с помощью функции RtlDecompressBuffer() распаковывает PlugX (DLL). При открытии мы видим, что сигнатуры MZ и PE в исполняемом файле PlugX заменены на XV (рис. 2) — скорее всего, это тоже нужно, чтобы скрыть модуль от средств защиты.

Рис. 2. Исполняемый файл PlugX в распакованном виде с измененными сигнатурами MZ и PE

Наконец, запускается распакованная вредоносная библиотека, и управление передается ей.

В другом экземпляре PlugX мы обнаружили интересную особенность: малварь пыталась скрыть некоторые библиотечные вызовы от песочниц. При восстановлении импортов вместо адреса импортируемой функции сохранялся адрес тремя байтами ранее. Результат для функции SetFileAttributesW() виден на рис. 3.

Рис. 3. При получении адреса функции SetFileAttributesW() сохраняется адрес 0x7577D4F4

В табл. 2 приведены характеристики этого экземпляра.

б)
Рис. 4. Фрагмент декомпилированного кода (а) и соответствующий ему фрагмент листинга перехваченных инструкций (б), где встречается вызов функции SetFileAttributesW()

Основная нагрузка PlugX не сохраняется в расшифрованном виде на диске.

Работа PlugX

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

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

То, как вредонос будет вести себя дальше, во многом определяет его конфигурация.

В зависимости от значения check_flag в конфигурации PlugX вредоносная программа может начать поиск в зараженной системе сетевого адаптера, MAC-адрес которого совпадает с адресом, заданным в самой малвари. В случае совпадения вредоносная программа завершит свое исполнение. Вероятно, таким образом она пытается обнаружить виртуальную среду.

Если значение mode_flag равно 0, вредоносная программа закрепляется в системе (подробнее в разделе «Закрепление в системе»). Затем она переходит к инициализации плагинов и взаимодействию с сервером управления (подробнее в разделе «Функциональность плагинов и исполнение команд»).

Если значение mode_flag равно 2, вредоносная программа сразу переходит к инициализации плагинов и взаимодействию с сервером управления.

Если значение mode_flag равно 3, вредоносная программа внедряет шелл-код в Internet Explorer. Передача управления вредоносному коду осуществляется с помощью функции CreateRemoteThread(). Также производится инициализация плагинов, и создается именованный пайп, через который вредоносная программа получает команды, предназначенные для исполнения плагинами.

Закрепление в системе

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

Анализируемый образец выбирает одну из следующих директорий в зависимости от разрядности малвари:

В зависимости от persistence_flag PlugX может закрепляться:

Помним, что малварь может и не закрепляться вовсе.

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

Функциональность плагинов PlugX и исполняемые команды

Основная функциональность бэкдора реализована с помощью так называемых плагинов. Фрагмент функции, в которой производится инициализация плагинов, приведен на рис. 5.

Рис. 5. Фрагмент инициализации плагинов PlugX

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

Полный перечень функций вредоносной программы, доступной через плагины, приведен в табл. 3.

Табл. 3. Функциональность PlugX, доступная через плагины

Фрагмент функции обработки команд, полученных от сервера управления приведена на рис. 6.

Рис. 6. Команды сервера управления, которые получает PlugX

Описание команд приведено в табл. 4.

Табл. 4. Команды сервера управления, которые получает PlugX

nccTrojan

Один из обнаруженных нами бэкдоров найден в отчете VIRUS BULLETIN и назван авторами nccTrojan по константному значению в коде основного пейлоада. Характеристики попавшегося нам образца малвари приведены в табл. 5.

Запуск nccTrojan

Работа nccTrojan

nccTrojan расшифровывает конфигурацию, хранящуюся по определенному смещению в оверлее. Конфигурация зашифрована с помощью алгоритма AES-CFB-256, он же используется для шифрования взаимодействия с сервером управления. Пары «ключ шифрования + вектор инициализации» захардкоржены и различны для шифрования конфигурации и взаимодействия с сервером управления.

Расшифрованная конфигурация содержит информацию о сервере управления и выглядит следующим образом:

Если соединение установлено, то на сервер управления отправляется следующая информация:

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

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

Табл. 6. Команды, исполняемые nccTrojan

dnsTrojan

Следующий бэкдор мы обнаружили впервые: на момент расследования мы не нашли упоминаний о нем в отчетах других экспертов. Его отличительная особенность — общение с сервером управления через DNS. В остальном по своей функциональности вредоносная программа схожа с бэкдором nccTrojan. Чтобы сохранить единообразие в названиях найденной малвари, назвали ее dnsTrojan.

Запуск dnsTrojan

После запуска вредоносная программа извлекает из ресурсов, распаковывает и сохраняет в рабочей директории два файла:

Работа dnsTrojan

Все свои действия вредоносная программа логирует в файл %ProgramData%\logD.dat, при этом записанные данные похожи на отладочную информацию для злоумышленников (рис. 7).

Рис. 7. Фрагмент файла logD.dat

Взаимодействие с сервером управления осуществляется с использованием DNS-туннелирования. Данные передаются серверу управления в виде DNS-запроса TXT-записи в зашифрованном виде.

Сразу после запуска на сервер управления отправляются следующие данные:

Из них формируется сообщение вида 8SDXCAXRZDJ;O0V2m0SImxhY;6.1.1;1;00-13-d2-e3-d6-2e;2020113052831619.

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

При формировании домена, для которого запрашивается TXT-запись, после каждого 64-го символа ставится точка. Запросы, отправляемые вредоносной программой, можно увидеть на рис. 8.

В ответ на запрос, отправленный на предыдущем шаге из TXT-записей, dnsTrojan получает команды сервера и может исполнить их (табл. 8).

dloTrojan

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

Характеристики файлов исследуемого нами образца приведены в табл. 9.

Запуск dloTrojan

На сцену опять выходит DLL hijacking.

Итак, вредоносная программа dloTrojan состоит из двух компонентов:

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

Далее библиотека расшифровывает вредоносный исполняемый файл, код которого внедряется в еще один запущенный процесс ChromeFrameHelperSrv.exe с использованием техники Process Hollowing.

Работа dloTrojan

Вредоносная программа пытается получить данные значения с именем TID из одного из двух ключей реестра (это зависит от имеющихся привилегий в системе):

Если же значение в реестре отсутствует, создается один из указанных ключей реестра. В параметре TID прописывается строка из 16 произвольных символов, которую в дальнейшем можно рассматривать как ID зараженной системы.

Строки во вредоносной программе зашифрованы методом простого сложения по модулю двух с одним байтом (отличается для различных строк).

Затем малварь расшифровывает адрес сервера управления. В зависимости от конфигурации вредоносная программа может иметь несколько адресов, в текущей конфигурации адрес сервера управления один.

Теперь dloTrojan устанавливает соединение с сервером управления. Если подключиться к серверу не удалось, малварь пытается найти настроенные прокси-серверы одним из способов:

Далее на сервер управления отправляется следующая информация о зараженной системе:

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

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

Перечень возможных команд приведен в табл. 10.

Табл. 10. Команды, исполняемые dloTrojan

И еще несколько программ, которые мы раскопали в ходе расследования

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

GetPassword

GetPassword предназначена для получения паролей из зараженной системы. Раньше исходный код утилиты лежал в репозитории MimikatzLite, но сейчас его почему-то удалили. Можем только поделиться скриншотом на рис. 9.

Рис. 9. Скриншот работы утилиты GetPassword

Quarks PwDump

Еще одна утилита для извлечения паролей из ОС Windows.

Исходный код можно найти в репозитории 0daytool-quarkspwdump. Скриншот утилиты приведен на рис. 10.

Рис. 10. Скриншот работы утилиты Quarks PwDump

wpmd v 2.3 (beta)

wpmd (windows password and masterkey decrypt) также предназначена для получения паролей в ОС Windows. Увы, источник мы не нашли, поэтому можем только показать скриншот (рис. 11).

Рис. 11. Скриншот работы утилиты wpmd v 2.3 (beta)

os.exe

os.exe позволяет определить версию ОС Windows (рис. 12). Источник тоже не найден 🙁

Рис. 12. Скриншот работы утилиты os.exe

nbtscan 1.0.35

nbtscan — утилита командной строки, предназначенная для сканирования открытых серверов имен NETBIOS в локальной или удаленной TCP/IP-сети. Она обеспечивает поиск открытых общих ресурсов (рис. 13). Доступна на ресурсе Unixwiz.net.

Рис. 13. Скриншот работы утилиты nbtscan

Это расследование в очередной раз убедило нас, что даже заезженные и понятные техники способны доставить жертвам много неприятностей. Злоумышленники могут годами копаться в IT-инфраструктуре жертвы, которая и подозревать ничего не будет. Думаем, выводы вы сделаете сами 🙂

PlugX (SHA256: EXE, DLL, Shell-code)

PlugX-executor: (SHA256: EXE)

nccTrojan (SHA256: EXE, DLL)

dnsTrojan (SHA256: EXE)

dloTrojan (SHA256: EXE, DLL)

Источник