• XSS.stack #1 – первый литературный журнал от юзеров форума

Как пишут вирусы в Word,Excel???

Отслеживать
patrick12 сказал(а):
а где написать код?

Можно начать вот с этого: *тык*
Сначала научись использовать язык по его прямому назначению, без этого просто никак, а потом уже что-то нетипичное делай.
 
Если хочешь именно писать вирусы для ворда то нужно изучать vb, а так для заражения хоста есть известные уязвимости ворда например

CVE-2017-857,​

CVE-2017-11882. К которым уже есть готовые решения на гидхаб. Их плюс в том что они не требуют от пользователя включить макросы, которые по умолчанию выключены​

 
В офисных продуктах мелкомягких встроен ЯП VBA. Это практически полноценный язык программирования. Он поддерживает внешиние библиотеки, ну и как следтвие библиотеки сисстемных функций WinApi32. Сам язык уже давно мёртвый, в том симысле что не развивается. Смысл его изучать только ради малвари, такое себе. В бизнесе его еще используют, но всё реже, так как очень медленный и опять таки не развивается.
В принципе сам язык не сложный и много в сети форумов (ещё живых) где обсуждали лет 10 назад тот или иной проблемный вопрос.
Помимо VBA можно в VS написать надстройку для офисного документа, и реализовать там уже средствами .Net технологий свою идею.
Суть запуска зловредов из офисных приложений это запуск внешней программы, ну что бы она продолжила работу после закрытия офисного приложения. Для этого в коде VBA (часто называют макросом) или в надстройке должна быть процедура скачивающая и запускающая внешнюю программу. Внешняя программа может быть и в самом теле документа, то есть в этом случае её не надо скачивать, а надо сохранить её на диск, если предпологается запуск с диска, к примеру такие нагрузки это exe, dll, cpl, vbs, js, ps1 файлы. Есть возможность загрузить непосредственно shell код в память и для этого не потребуется сохранять файл на диск или же запустить внешнюю нагрузку запуском powershell.exe с передачей скрипта в виде Base64Unicode. Проблемы запуска из VBA в том что спобов запуска не много и все они вполне являются тригерами для АВ. То есть придётся поизгаляться в поисках решения которое АВ воспримет как безопасное.
 
Silvio_Manuel сказал(а):
В офисных продуктах мелкомягких встроен ЯП VBA. Это практически полноценный язык программирования. Он поддерживает внешиние библиотеки, ну и как следтвие библиотеки сисстемных функций WinApi32. Сам язык уже давно мёртвый, в том симысле что не развивается. Смысл его изучать только ради малвари, такое себе. В бизнесе его еще используют, но всё реже, так как очень медленный и опять таки не развивается.
В принципе сам язык не сложный и много в сети форумов (ещё живых) где обсуждали лет 10 назад тот или иной проблемный вопрос.
Помимо VBA можно в VS написать надстройку для офисного документа, и реализовать там уже средствами .Net технологий свою идею.
Суть запуска зловредов из офисных приложений это запуск внешней программы, ну что бы она продолжила работу после закрытия офисного приложения. Для этого в коде VBA (часто называют макросом) или в надстройке должна быть процедура скачивающая и запускающая внешнюю программу. Внешняя программа может быть и в самом теле документа, то есть в этом случае её не надо скачивать, а надо сохранить её на диск, если предпологается запуск с диска, к примеру такие нагрузки это exe, dll, cpl, vbs, js, ps1 файлы. Есть возможность загрузить непосредственно shell код в память и для этого не потребуется сохранять файл на диск или же запустить внешнюю нагрузку запуском powershell.exe с передачей скрипта в виде Base64Unicode. Проблемы запуска из VBA в том что спобов запуска не много и все они вполне являются тригерами для АВ. То есть придётся поизгаляться в поисках решения которое АВ воспримет как безопасное.
У меня возникло пару вопросов.
1. Почему в самом макросе нельзя сразу через API получить и отправить нам все необходимые данные с жертвы?
2. В чем главный плюс тянуть из макроса внешний бинарь который будет выполнять эту задачу?
3. Сразу после скачки(даже если его запускать из RAM не сохраняя на HDD) нашего бинарника из кода макроса как я понимаю AV его будет чекать
т.е нужно периодически криптовать этого зверя, следовательно всякое старье AV спалит и сразу заблочит?
 
1) Можно сразу. Но важно учесть насколько быстро это отработает и отправит и не успеет ли пользователь за это время закрыть документ. То есть если закрыть до отправки собраной информации то и отправки не будет.
2) Плюс для постэксплуатации. То есть даже если пользователь закроет документ, полезная нагрузка продолжит взаимодействие с админкой. К тому же как я писал выше можно и не загружать внешний бинарь, а держать его в теле самого документа.
3) Да бинарь нужно чистить от детектов АВ. Все попытки запустить что либо внешнее из VBA расцениваются AV весьма параноидально, поэтому там будет AV пытаться понять что загрузилось опасное или нет.
Варианты загрузки внешних исполняемых файлов:
1) ShellExecute - функция из библиотеки shell32, вызывает командный процессор и из неё запускает программу по указанному пути и поддерживает загрузку в скрытом режиме.
2) Shell аналогичная функции выше но встроенная в VBA функция запуска командного процессора с указанием пути к исполняемому файлу и режимом окна в том числе скрытом
3) Методы WScript.Shell, тоже поддерживают скрытый запуск (Run поддерживает Exec не поддерживает).
4) ну и для загрузки шеллкода функции CreateRemoteThread, VirtualAllocEx, WriteProcessMemory, CreateProcessA, RunStuff из библиотеки kernel32
Все эти способы очень привлекают внимание AV к сожалению мои знания на этих способах пока ограничены, если кто-то знает другие варианты, напишите пожалуйста, я их протестирую и отпишусь насколько тригерны они для AV.
 
Последнее редактирование:
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх