С чем связян детект wacatac.b!ml?Последний месяц - полтора, как то он совсем рандомно вешает на каждый второй билд этот детект. При том что софт абсолютный полиморф: код, ресурсы, рантайм (вызов winapi), даже rich header.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
wacatac.b!ml
- Автор темы secidiot
- Дата начала
Много мусора в коде, этот детект вешается когда дефендер считает что софт не несет полезной нагрузки. К примеру нет мало статических winapi, мало или мусорные вызовы статических winapi, слишком много mov, add, xor ну и т.д.
энтропия , апи карта
деф чуть по умнее чем энтропия, лол. Мы не в 2010. Уже тогда MSE (на базе которого деф в итоге выкатили) был с виртуалкой внутри и раскручивал крипты.
я теперь жажду услышать от тебя ответ что такое энтропия
Not sure why, but there is many reasons. Detection is based on machine learning so you have some patterns that are being detected. Also, low number of APIs in IAT can be reason. next, maybe you have bad behaviour in your app (like writing in registry as soon it starts, sending HTTP or socks request as soon it starts, etc...)
Try using some junk API calls and break for loops as much you can.
Чеки секций на энтропию это древний метод, который умер примерно тогда же когда умерла авира, которая чекала корректность PE файлов и чекала, чтобы пределы энторопии кодовой секции были 6.1-6.9, иначе детект. Сейчас используются более сложные алгоритмы и почти никто из аверов энтропию не чекает (кроме авиры и аваста, да).я теперь жажду услышать от тебя ответ что такое энтропия
Ты не в том положении, чтобы мне задавать вопросы в таком тоне. Что такое энтропия может загуглить любой школьник, я тебе отвечу почему и как её использовали: показатели энтропии, если её считать только по кодовой секции, на средних интеловских инструкциях из под компилятора стандартного давали значения около 6 и если значнеия сильно выбивались, то это говорило о наличии мусорного кода (если они сильно выше) из трешгена.
Соотношение энтропии общей по файлу, если она высокая, тоже говорило, что файл упакован или покриптован, если были отдельные секции > 8, то это говорило что вся секция покриптована и в целом кидало детекты кучей аверов.
Так вот вындеф не настолько туп, чтобы считать энтропию. Я тебе больше скажу. Все детекты, которые он кидает - это детекты не статически на файл, а после прогона его внутри аверского эмулятора, когда он запоминает cf и прогоняет его по внутренним движкам. Wacatak это детект внутреннего ML на поток исполнения. Карта API тоже учавствует, но не настолько топорно, как это было раньше, например, у езета.
Оно детектит в том числе длинные циклы на старте. В общем всё о чем сказал merdock.
окей отключаем интернет и смотрим как работает эмулятор а ни как wacatac, wacpe и прочие !ml отлетают совпадение ? не думаю, ещё больше ясности внесёт отладчик
Щас тренд писать малварь на высокоуровневых языках, потому что чем меньше абстракций между языком и функционалом тем больше детектов. Если просто калькулятор на C написать vt повесит 30 из 60 детектов, а стиллер на питухоне будет иметь 1 детект
Hello, I hope you are well.
Initially, I had the same problem. This detection or alarm seems to be a generic detection, which identifies an unsigned digital file as "different" from the usual, meaning:
1.- In my case, payloads without any type of shellcode byte array.
2.- Payloads without any type of Cobalt and similar C2 framework inside the payload. I retrive the shellcode from a encrypted file/internet/steganography so at the beginning, nothing suspicious was included in the initial loader (cobalt/havoc and similar c2 frameworks shellcodes). Even cobalt shellcode was behind a UDRL custom kit so... Nothing to be related with external shellcode.
3.- Payloads without signatures.
4.- DLL sideload payloads (chrome/java in my case)
Everything was random. As I said, in my case this was something exceptional. The same payload that received a Wacatac function was bypassed on 10 EDRs or more (I don't count them) in real environments, receiving callbacks on my testing server. (only alerted by gay bill gates AV system as wacatac but bypass EDRs as cutting butter)
To my surprise, nothing was flagged as Wacatac on a normal .exe with just 5 minutes of work, without pump functions, containing shellcode byte arrays, no AMSI bypass, no ETW, nothing. I only received these errors/issues on certain DLL sideloads, in my case with Java/Chrome, under the same evasion profile but with more sophisticated work behind it.
More people in my circle have the same view in the end: this happens because the AV didn't understand what was happening and flagged the work as Wacatac.
If you need more explanations, feel free to ask anything, but it is a weird alarm. I just came to the conclusion that it is a generic alert for an unknown payload/executable/file.
All my work comes with unsigned files. If I do any SmartScreen bypass or something similar, it comes with a DLL sideloading as we already know. But as I said, even a very simple exe did not receive this alert, but a well-crafted DLL sideload payload did receive a Wacatac alert when, in the end, it was bypassing 80% of scanner.to EDRs and giving a callback on the test server.
If you are interested I can further develop the situation and the cases in which I experienced this.
At first it was only in these sideload payload dlls (chrome/java). I used the same methods as other generations of payloads, but in these cases I have had these "alert".
secidiot
Initially, I had the same problem. This detection or alarm seems to be a generic detection, which identifies an unsigned digital file as "different" from the usual, meaning:
1.- In my case, payloads without any type of shellcode byte array.
2.- Payloads without any type of Cobalt and similar C2 framework inside the payload. I retrive the shellcode from a encrypted file/internet/steganography so at the beginning, nothing suspicious was included in the initial loader (cobalt/havoc and similar c2 frameworks shellcodes). Even cobalt shellcode was behind a UDRL custom kit so... Nothing to be related with external shellcode.
3.- Payloads without signatures.
4.- DLL sideload payloads (chrome/java in my case)
Everything was random. As I said, in my case this was something exceptional. The same payload that received a Wacatac function was bypassed on 10 EDRs or more (I don't count them) in real environments, receiving callbacks on my testing server. (only alerted by gay bill gates AV system as wacatac but bypass EDRs as cutting butter)
To my surprise, nothing was flagged as Wacatac on a normal .exe with just 5 minutes of work, without pump functions, containing shellcode byte arrays, no AMSI bypass, no ETW, nothing. I only received these errors/issues on certain DLL sideloads, in my case with Java/Chrome, under the same evasion profile but with more sophisticated work behind it.
More people in my circle have the same view in the end: this happens because the AV didn't understand what was happening and flagged the work as Wacatac.
If you need more explanations, feel free to ask anything, but it is a weird alarm. I just came to the conclusion that it is a generic alert for an unknown payload/executable/file.
All my work comes with unsigned files. If I do any SmartScreen bypass or something similar, it comes with a DLL sideloading as we already know. But as I said, even a very simple exe did not receive this alert, but a well-crafted DLL sideload payload did receive a Wacatac alert when, in the end, it was bypassing 80% of scanner.to EDRs and giving a callback on the test server.
If you are interested I can further develop the situation and the cases in which I experienced this.
At first it was only in these sideload payload dlls (chrome/java). I used the same methods as other generations of payloads, but in these cases I have had these "alert".
secidiot
Последнее редактирование:
Все верно сказано и развернуто. Я бы добавил что детект ставится исходя из объема и "полезности" кода, как считается полезность - секрет, но опытным путем выяснил и описал в начале. Иногда достаточно убрать xor шифрование (к примеру хешь апи когда считается), иногда достаточно сделать все апи вызовы - статическими или разбавить ими - НО они должны именно участвовать в работе софтины, иногда достаточно уменьшить объем мусорных инструкций add mov nop и т.д., встречались мне случае когда детект вешался на преждевременно прекращение программы или выход из программы по средства критической ошибки (ну к примеру антидетект и return/try except/crash). Если поставить сертификат на софтину то данный детект пропадает. Если включен оптимизатор кода то тоже помогает избавится от кода который не участвует в работе. Т.е. чтобы убрать данный детект софтина должна использовать все АПИ, иметь мало "мусора" (даже валидного рабочего мусорного кода), отрабатывать без ошибок с корректным завершением работы.
Вообще как мне показалось(нет достоверных данных) данный детект - общий и плавающий, такое ощущение что они обучают ИИ на рабочем софте в облаке и эмуляторе именно по поведению. Потом просто новые ехе скармливают этой системе и выдают - софт полезный или нет.
del
Последнее редактирование:
Прошу пояснить пост, а потерял суть - чему это?
del
Последнее редактирование:
++ What this guy says, about the code seeming foreign to the ML then it getting flagged as Wacatac. One method I've used to bypass it is hiding behind a GUI framework, an example would be QT or something like that, then having some GUI code that exits immediately, or displays a loading screen.
есть еще тайные инструкции для компилятора, чтоб не палиться у аверов?
Больше не работает на Visual Studio 2022.
warning LNK4044: unrecognized option '/emittoolversioninfo:no'; ignored
Дам вам ребята совет, за который меня скорее всего тут захейтят (форум то кулхакерский), не используйте msvc, есть нормальные компиляторы (gcc, clang). Поставьте себе кланг и юзайте его. Маздайный коноплятор не конформен стандарту, да он до сих пор даже C++ 11 полностью не поддерживает, причем даже базово, не говоря уже о шаблонах, на которых он нередко сыпится (msvc даже проекты с некоторыми хедер-онли либами буста собрать не в состоянии, лол), поддержка стандарта у msvc вообще похоже выборочная, а про strict aliasing и другие языковые концепции он не в курсе, из-за чего очень часто компилит невалидный плюсовой код, и при этом не компилит валидный, это просто нонсенс. Помимо прочего это худший компилятор в плане оптимизаций, а так же по скорости компиляции, ну и да, единственный компилятор, который генерит Rich хедер. =)