- Автор темы
- Добавить закладку
- #21
В общем то актуально, у кого какие идеи ещё есть?
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Avast Password Protection
- Автор темы Jeffs
- Дата начала
Аваст внедряет в процессы свой перехватчик API функций. Смапь ntdll заново и твоя проблема будет решена.
- Автор темы
- Добавить закладку
- #23
Можно в принципе просто файл каким-либо сопособом скопировать в другую папку и работать уже с ним. Но что-то идей нет
aswhook.dll, у avg возможно тоже такая шляпа есть. помнится раньше отрубалась обычным dll_process_detach, называлась ещё тогда по-другому кажись. на данный момент есть одно решение, о котором позабыли разрабы, оно очень простое и лежит на поверхности, но и фиксится легко. а по поводу фундаментального - поищите анхук в карберпе, должно помочь либо инжект
У вас должно быть более 100 реакций для просмотра скрытого контента.
Я хз кому пригодится, но для комьюнити.
Если в настройках хрома не установлен полный путь к папке загрузки, то у хрома высвечивается окошко куда установить.
как вариант - запускать хром с x,y координатами за пределами видимой части рабочего стола и эмуляция клика SendMessage().
You've triggered the AV's heuristic analysis engine e.g. it is unusual behavior for an application to attempt to get a HANDLE on Chrome files. You're going to have to find an alternative methodology to get your hand on the file. Some users have given some suggestions.
Method 1: Unhook from the AV (possible?)
If the AVs hooks are detecting the behavior, stripping yourself of the hooks (dynamically retrieving the syscalls, or for a proof-of-concept hardcoding them) may unveil a potential attack vector. However, it is possible the AV minifilter has detected this with a pre-operation callback routine
See: https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes
FS Filter 388401, 383190, 383190
With these minifilters in place, they may be detecting operational attempts on the binary
Method 2: Abusing logic bugs, symbolic links
Many AVs ignore symbolic links. You may be able to create a symbolic link and get a HANDLE on the file this way. This is fairly common application logic abuse. I do not believe AVs hook APIs for symbolic link creation.
Method 3: Binary execution proxying / LOLBINs.
For example, invoking cmd.exe with the COPY command may evade the AV. You'll have to explore different applications that allow this sort of behavior over here: https://lolbas-project.github.io/
Method 1: Unhook from the AV (possible?)
If the AVs hooks are detecting the behavior, stripping yourself of the hooks (dynamically retrieving the syscalls, or for a proof-of-concept hardcoding them) may unveil a potential attack vector. However, it is possible the AV minifilter has detected this with a pre-operation callback routine
See: https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes
FS Filter 388401, 383190, 383190
With these minifilters in place, they may be detecting operational attempts on the binary
Method 2: Abusing logic bugs, symbolic links
Many AVs ignore symbolic links. You may be able to create a symbolic link and get a HANDLE on the file this way. This is fairly common application logic abuse. I do not believe AVs hook APIs for symbolic link creation.
Method 3: Binary execution proxying / LOLBINs.
For example, invoking cmd.exe with the COPY command may evade the AV. You'll have to explore different applications that allow this sort of behavior over here: https://lolbas-project.github.io/
Идея тухлая, большинство АВ начинают орать если ты трогаешь файл ntdll на диске, хоть вручную размапишь, хоть через MmapViewOfFile, лучше уж тогда дергать системные вызовы напрямую по номерам, но тут мы снова упираемся в проблему, допустим надо дернуть NtCreateFile, но она перехвачена, тогда в прологе мы не найдем нужный номер системного вызова, тут нужен простейший дизасм, определяем куда ведет перехват, заходим во все ответвления в перехвате и сканируем там память на наличие стандартного пролога (его части), это будет трамплин, так как сисколы короткие то скорее всего занесение номера будет именно в трамплине, а не в оригинальном продолжении функции, там будет mov eax, syscall_number и чуть ниже sysenter\syscall
При этом ты не читаешь с диска ntdll и тем самым не вызываешь лишнюю тревогу у АВ
Имхо, сложно закодить универсальное решение под все перехваты.
Сложно не значит нереализуемо, я не думаю что какой-то из АВ будет заморачиваться и делать какой-то сверхзапутанный\заморфленый переходник, обычно это либо push + ret, либо jmp[+5 байт от rip] и следующие байты = адрес, либо mov reg, addr + jmp reg, это 3 самых популярных, а так всего их штук 10 незамороченых, если их все охватить это дасть 100 % профит от перехватов со стороны АВ, а так конечно если учитывать всякие экзотические перехваты вроде аппаратных точек останова - это будет заморочено, но я уверен что ав их не использует, так как экзотические решения либо нестабильны, либо как в случае с HBP можно поставить всего 4 перехвата на каждый поток, а ав используют более стандартные решения, которые будут стабильны