вводная: пейлоад - reverse_https\reverse_dns (кастомный) ав - eset nod32 internet security пейлоад используется стейджед, шеллкод криптуется и компилируется в ехе собственным криптором, имеет полный фуд на статик\рантайме. сабж: каким образом IDS может палить метерпретер?хоть и ехе является абсолютно фудовым, после успешного выполнения в течение 3-5 секунд (в случае с reverse_https) IDS нода абсолютно четко и ясно палит соединение вплоть до названия угрозы "win32/riskware.meterpreter". и это при всем том, что используется ssl сертификат + пиннинг + настройки в хендлере EnabelStageEncoding, что исключает возможность расшифровывания трафика и детекта по содержимому. в случае с reverse_dns, все еще интереснее. ботнет протекшн хоть и не палит конкретно наличие метера, однако все равно помечает трафик как подозрительный, совершенно невзирая на то, что запросы идут вообще на легитимный DNS сервер принадлежащий провайдеру и общение с сервером мсф напрямую даже не производится, а сами запросы кодируются в поддоменах через base32 и идут на проксирующий ns сервер, чего тоже вполне достаточно должно быть, чтобы обойти детект по сигнатурам. интересен сам принцип работы, какие механизмы используются для детекта и как можно обойти? из вариантов почему идет детект пришло в голву лишь: 1) self-signed сертификат 2) дефолтное поведение стейджера (тайминги отстука, длина пакета) 3) дефолтные настройки хендлера (а конкретно HttpUnknownRequestResponse HttpUserAgent HttpCookie)
пробовал reverse_https, reverse_winhttps, reverse_dns, reverse_tcp_rc4_dns везде одна ситуация (кроме реверс днс) - палят полностью вплоть до того, что стоит именно метерпретер. менял значения HttpUnknownRequestResponse HttpUserAgent HttpCookie - не помогло. также менял StagerRetryWait - никак не сказалось.
да тут дело же не в этом даже, он зашивается внутрь пейлоада и в любом случае трафик расшифровывать невозможно. однако это не мешает ав вполне точно палить метерпретер
А промежуточную прокладку запилить с перешифрованием на лету? Я так понимаю Метр палится по сигнатурам, я с ним конкретно дел не имел но принцип я так понимаю всё тот же. Если пакет идет по защищенному каналу и его нельзя расшифровать значит проблема не в содержимом а в поведении (ну по идее/ по логике) Смена стандартных портов итд, попляши вокруг костра, бубенци незабудь)
да вот я и плясал и чет вообще безрезультатно. да и исходящий коннект на 443 порт это помоему хуевый флаг чтобы детектить метер. видимо действительно либо палится конкретно содержимое пакетов, либо существуют какието паттерны поведения - длина пакета, тайминги и тд, что я и хочу узнать. ну не тайминги точно, т.к. это я уже тестил
к сожалению нет. с использованием валидного реального сертификата от летсенкрипт все равно палит. ни одному из этих критериев в статье он не удовлетворяет The certificate isn't signed by a trusted CA The domain names are random (i.e. don't really exist) Domain names end with .com, .gov or .net Validity period is stated to be exactly one month
