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

Статья ? как я делал Удаленное Управление, реверсшелл и многое другое на WinAPI в моем RAT

shkolnick1337

(L3) cache
Пользователь
Регистрация
04.05.2020
Сообщения
158
Реакции
106
Депозит
0.16
Это история в картинках и видео, в исходниках и переписках о моем ратнике, в котором я постепенно реализовываю нужный мне функционал, за его прогрессом вы можете следить на гитхабе, а так же просто интересуясь у меня в комментариях этой темы, начнем статью...

?Часть первая: "Рождение"

Всё началось когда я выклянчал у своего друга (голова, товарищ, братишка) аккаунт от кору, не всегда же мне реверсшеллы на питоне делать, да? Моей мыслью было найти какой нибудь проект наподобие ратника, что бы можно было опереться на плечо тех, кто что либо писал до меня. Но к сожалению такого проекта не было, кроме тининайка, который итак лежал на гитхабе, но с кору я вытащил код который опубликовал один юзер, исходник был реверсшеллом на си, и тут зародилась идея, о написании собственного проекта, который я бы мог развить во что нибудь стоящее, это был пресловутый хакатон, на котором программист реализует что то подобное чему то. Я решил без малого сделать клон Quasar, на основе хотя бы чего то, и что бы принципиально разобраться самому как это работает!

?Часть вторая: "Протокол"

Первой мыслью было конечно писать что то подобное как у шара и джевса, но давайте представим себе, если бы я хотел бы добавить "Управление рабочим столом" как в Quasar? Что бы получилось в итоге? А если бы я посылал все это еще в виде json? Это как мне нужно было бы сервер накодить, что бы он это дело все обрабатывал? А это не лоадер без функционала, а полноценная система управлением компьютером должна быть, вы же все пользовались РМС или Тимвьювером, они что ль по http работают!?

По этому я принял решение получать команды от сервера в таких вот структурах, чем использовать обычный json или xml:
C:
typedef struct BIGSCREEN
{
    int DO;
    int w;
    int h;
    int RealW;
    int RealH;
    int ClickX;
    int ClickY;
    DWORD ZipSize;
    DWORD Size;
} BIGSCREEN;

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

3a10e646c9c661108ecd7203094e4d99.jpg


? Часть третья: "Не побоялся и обосрался"

Второго числа этого месяца я начал проект по созданию ратника и написал небольшую статью о нем и выложил на гитхаб исходники.
Вот статья
: https://xss.pro/threads/37990/
Вот ссылка на проект: https://github.com/techkote/RAT_WINAPI
В статье я подробно выговорил всё об его устройстве, протоколе по которому взаимодействует ратник и панель, разобрал все до мельчайших деталек, в принципе это был готовый конструктор лего, из которого можно было собрать всё что угодно. Но планы на него у меня были и я продолжил разработку далее. Замечу, что это хоть и не готовый проект, но на форуме статей и подробных разборов аналогичных не было, и я продолжу эту славную традицию...
Затем последовало много критики, ведь я не претендую на звания лучшего кодера планеты, но к некоторым людям я прислушался и оно того стоило:


Screenshot_8.png


1) Как правильно заметил Haunt - разработка на сокетах была обусловлена тем, что я хотел бы в дальнейшем расширять этот функционал в сторону аналогов "quasar" или "tinynuke" и выбрал его потому, что другой альтернативы не видел для себя, если я пишу на си c винапи в клиенте, то нужно быть максимально разборчивым в том, чем ты будешь пользоваться в дальнейшем, например я в тот момент не мог ответить на этот вопрос - ведь если я бы не выполнил или не смог сделать как я бы хотел - я бы был п#даболом.

2) Это был прототип, и я плавно съехал с консольного варианта сервера, на популярный в С++ кругах фреймворк Qt, хотя движок полностью остался прежним как и был. Движок не изменился, так как для моих целей он был важен.

3) Я написал код для себя в первую очередь, во вторую для людей, ведь люди после меня будут что то делать свое и возможно - я им пригожусь, вспомнят добрым словом нелепого меня, который пытался реализовать недостижимое и заложил фундамент для будущих ребят которые захотят создавать что то на базе пары моих статей, ведь я включаю подробную документацию о том как готовить этот ратник, ведь слишком много откровенно скамерских и глупых тем HVNC и ратников в продаже:? Сами же были свидетелями, того что люди хоть и пытаются скопировать тининьюк или что то подобное, но у них ничего не выходит из за проблем в самом тининьюке, или из за нехватки знаний, или из за того что тини это единственное что у них скомпилировалось и они пошли пытаться его впарить кому то...

Часть четвертая: "Приделываю реверсшелл и получение скриншотов"

Ни один уважающий себя RAT не может быть полнофункциональным если он не имеет доступа к командой строке, о том для чего она важна вы можете почитать в предыдущей моей статье про распространение с помощью неё ваших вирусов: https://xss.pro/threads/38293/, можно запускать, короче говоря, полноценные программы, от лоадеров до стиллеров написанных хоть на пауршелле, пайтоне или батче, или любом другом скриптовом языке программирования который установлен на компьютере жертвы аттаки. Можно например скачать стиллер из этой моей же статьи и попробовать его запустить https://xss.pro/threads/38304/ таким вот методом распространения... Вообщем был нужен доступ, и я его как говорилось выше нашел самым первым, переписал под себя, и мог полноценно вставить в ратник:


Реверсшелл это прекрасно, но что было со скриншотами это конечно атас, требовалось их получать не сохраняя на диск, а конвертируя HBITMAP в набор байтов и отправлять их по сокетам на сервер где бы мне пришлось конвертировать обратно байты в HBITMAP и вставлять это дело в мой кастомный класс QLabel. Но дело спорилось, и все что было мне нужно это гугл, тот же тини, пара часов на понимание как делать скрин, как его маштабировать под разрешение QLabel; как построить структуры для их передачи между клиентом и сервером, и в итоге я получил нормально работающую систему, которую доработать до стриминга изображения рабочего стола не составило труда, на ваших глазах вы увидете как у автора появилось простое решение этой насущной задачи:


? Часть пятая: "Удаленное управление"

Многим может показаться, что кликать мышкой по импровизированному экрану это было бы очень просто, ведь сколько игр, сколько программ написано про это, но я сталкиваюсь с новой для меня задачей, в которой требуется передавать нажатия мышкой из одной программы в другую операционную систему, и тут я пошел по непроторенной дорожке, в которой пришлось изучать Qt.
А именно получать разрешение Лейбла пересылать его жертве, получать разрешение экрана у жертвы, на стороне жертвы скейлить (подгонять одно разрешение под другое) и пересылать серверу готовый таким образом скриншот, который уже оптимизирован и прекрасен... А ранее я скейлил все на строне сервера, это было просто... Но разрешение экрана жертвы мне еще пригодилось я смог с помощью него и размеров QLabel рассчитывать координаты тычков (кликов) мышей по QLabel и подгонять их под разрешения экрана, по формуле которая была взята из тини:

C:
int x = GET_X_LPARAM(lParam);
int y = GET_Y_LPARAM(lParam);

float ratioX = (float)client->screenWidth / client->pixelsWidth;
float ratioY = (float)client->screenHeight / client->pixelsHeight;

x = (int)(x * ratioX);
y = (int)(y * ratioY);

в более мне подходящую:

C++:
void DisplayLabel::mousePressEvent(QMouseEvent *ev)
{
    float ratioX = (float)ClientW / this->width();
    float ratioY = (float)ClientH / this->height();
    int x = (int)(ev->pos().x() * ratioX);
    int y = (int)(ev->pos().y() * ratioY);

На этом код позаимствованный из серверной части тининьюка для моего ратника начинается и заканчивается...

Далее идет код отработки событий нажатия клавиш, он получился простым и максимально содержательным:

C++:
    CMDiDATA indata; \\ создаю структуры из первой части:)
    memset(&indata, 0, sizeof(CMDiDATA));
    indata.CMD = CMD_SCREEN; \\ говорю ей что это будет команда связанная со скриншотами

    BIGSCREEN inBIGSCREEN; \\ создаю структуру для инфромации по скриншотам
    memset(&inBIGSCREEN, 0, sizeof(BIGSCREEN));

    switch (ev->type())
    {
        case QEvent::MouseButtonDblClick: { \\ тут регистрируется двойное нажатие 
            inBIGSCREEN.DO = DO_DCLICK;  \\ этой структуре говорю что это будет операция связанная с "двойными кликами мышкой"
            break;
        }
        case QEvent::MouseButtonPress: {
            if (ev->buttons() == Qt::LeftButton){
                inBIGSCREEN.DO = DO_LCLICK;  \\ этой структуре говорю что это будет операция связанная с "левым кликом мыши"
            }else{
                inBIGSCREEN.DO = DO_RCLICK; \\ а тут с правым
            }
            break;
        }
        default:
            break;
    }

    inBIGSCREEN.ClickX = x; \\записываю координаты клика
    inBIGSCREEN.ClickY = y;

    memcpy(indata.DATA, &inBIGSCREEN, sizeof(BIGSCREEN)); \\копирую одну структуру в другую
    send(MSOCKETS[NOMER], (char*)&indata, sizeof(CMDiDATA), 0); \\ и отправляю ее на сервер
    memset(&indata, 0, sizeof(CMDiDATA));
    memset(&inBIGSCREEN, 0, sizeof(BIGSCREEN));
}

А на клиентской части был бедлам, я закопался в коде на добрых два дня, пытаясь разобраться с исходниками чужого проекта, разобраться со всеми делами - что бы получить результаты которые граничили с катастрофой:


А все объяснялось очень просто - я не знал как работает WinApi в окнах, ведь по сути на них писал лишь консольные приложения, которые по большей части и есть все вирусы... «Ученье - свет, а неученье - тьма! (Суворов)» Так я перешел на мдсн и начал разбираться ползая по сети, и ища ответы, и в итоге у меня получилось! Не без страданий, но проект ожил, начал приносить осязаемый отклик, что меня не могло ни радовать.


Исходя из этого проекта я вынес для себя две важных вещи - любой софт рано или поздно устаревает, под десяткой работа с хвнц типа тини уже не комильфо, у нее появилась альтернатива, с которой не справляется winapi, майки говорят выпустили новый фреймворк, который совместит программирование под winapi и программирование под win10 приложения, что бы сделать актуальный ратник, под актуальные операционные системы нужно прочно и надолго закопаться в разработке.

Но давайте прямо скажем - мой проект принципиально решает задачи, хоть его допиливать и допиливать, до состояния аналогичных, но если хватит сил и постараться выйти из яслей, то возможно создать полноценные альтернативы многим софтам, например таким классным как этот:


Screenshot_1.png


Никого не смутило что там в окне у него написано - Online (80), а клиентов нету? В принципе чего и стоило ожидать:

Screenshot_2.png


Зачастую мы не видим как люди кодят долго и упорно классные софты, а иногда просто создают концепты, без функционала, в моем же случае я создал целую лабораторию по изучению и отладке работы ратников - так что если вы так же мечтаете написать что то такое - присоединяйтесь к разработке, это на самом деле весело!
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Для сжатия данных на клиенте лучше отказаться от RtlDecompressBuffer/RtlCompressBuffer в пользу статической библиотеки на чистом си.
Таких библиотек много. Kaimi описывал у себя в блоге работу с LZO. Лично мне LZ4 нравится.

мой проект принципиально решает задачи
До production еще очень далеко. На локалхосте пинг между клиентом и сервером неадекватный. Что будет, если его запустить через VPN + Tor, когда цель в USA а ты в RU?

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

Bitcoin кошелек скинь в ПМ.
 
Для сжатия данных на клиенте лучше отказаться от RtlDecompressBuffer/RtlCompressBuffer в пользу статической библиотеки на чистом си.
Таких библиотек много. Kaimi описывал у себя в блоге работу с LZO. Лично мне LZ4 нравится.


До production еще очень далеко. На локалхосте пинг между клиентом и сервером неадекватный. Что будет, если его запустить через VPN + Tor, когда цель в USA а ты в RU?

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

Bitcoin кошелек скинь в ПМ.
Я приму всё к сведению и уже переделываю, как раз занят именно этим. В нынешней сборке конечно ужасненько, нужно переделывать, но я не буду останавливаться, мне очень понравилось.
 
Удачи в начинаниях :)
Глянул одним глазом что там по коду, могу подсказать по WinAPI - лучше пробовать использовать не обычные TCP/UDP сокеты из WinSock2, а выстраивать общение клиент/сервер по http, на 80/443 порт через WinInet методы, c keep-alive соединением, либо хотя бы просто запросами, т.к. так проще (а ещё лучше если будет какое-нибудь шифрование трафика, хотя бы xor'ом).

Дело в том, что в корп. сетях очень часто все машинки пробрасываются через WLAN прокси с авторизацией + настраивается фаервол. Называется такая штука NTLM, см:
Получается по итогу что-то типо Socks5 прокси для WLAN сети и чтобы отстучать на сервак рату нужно открывать туннель через этот прокси.
У WinInet'а можно выставить нужные флаги и авторизация пройдет автоматически.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Спасибо за библиотеки обязательно переделаю. Судя по бенчмаркам лучше выбрать lz4 ?
особого толку от этого не будет, самое важное в удалённом управлении - передавать только нужные данные, т.е. минимальные изменённые квадратики экрана, иначе на реальных тестах (уебанский микс траф) - софт будет отзывчив только на хороших корейских пк и всё
 
особого толку от этого не будет, самое важное в удалённом управлении - передавать только нужные данные, т.е. минимальные изменённые квадратики экрана, иначе на реальных тестах (уебанский микс траф) - софт будет отзывчив только на хороших корейских пк и всё
+
Рекомендую также погуглить принцип RFB (Remote Frame Buffer) протокола, который лежит в основе многих VNC. Реализовать самому что-то похожее на том же WinGDI не сложно.
 
+
Рекомендую также погуглить принцип RFB (Remote Frame Buffer) протокола, который лежит в основе многих VNC. Реализовать самому что-то похожее на том же WinGDI не сложно.
спасибо!
 
особого толку от этого не будет, самое важное в удалённом управлении - передавать только нужные данные, т.е. минимальные изменённые квадратики экрана, иначе на реальных тестах (уебанский микс траф) - софт будет отзывчив только на хороших корейских пк и всё
Не понимаю сути видео вообще, скринов вполне должно хватать.
Сплю и вижу как недокардер смотрит видео в надежде поймать момент когда жертва
будет вводить данные карты когда есть кейлоггеры и тп.
 
по протоколу чекни protobuf
учитывай, что если продукт пойдет в реальное боевое использование то довольно быстро появится в IDS (snort/suricat/...) и будут выпиливать и абузить по протоколу. Рекомендую закладываться с шифрованием изначально, хотя бы при проектировании заложить возможность.
И шифровать протокол нужно так, что бы не было возможности строить сигнатуры.
На пример с https (если это просто протокол общения клиент-сервер) достаточно периодических смен сертефикатов (по тому же крону), что бы не вносили серты в блек листы.
По "vnc" функционалу клева получилось, хотя реализация скрытого рабочего стола - это задача совершенно другого порядка.
Рендеринг всего в ручную - еще то развлечение.

Продолжай! Тебя ждет успех!
 
Наврядли это чудо пойдет в бой когда-либо в обозримом будущем. Но тем не менее, спустя N попыток у автора все может получится. Рим не за один день построили, так сказать. Тут также, только процесс обучения и написания конечного софта можно сказать объединены.
HVNC автор осилит ещё совсем не скоро, но если возьмется, будет любопытно глянуть что получится))
По hvnc советую глянуть zeus hvnc, ifsb, tunynuke (как самый простой вариант). А также мою статью с зимнего конкурса. Там расписал можно сказать игрушечную технологию, но тем не менее рабочую, на момент написания статьи под хром, фф, оперу, ie и т.п.
 
Наврядли это чудо пойдет в бой когда-либо в обозримом будущем. Но тем не менее, спустя N попыток у автора все может получится. Рим не за один день построили, так сказать. Тут также, только процесс обучения и написания конечного софта можно сказать объединены.
HVNC автор осилит ещё совсем не скоро, но если возьмется, будет любопытно глянуть что получится))
По hvnc советую глянуть zeus hvnc, ifsb, tunynuke (как самый простой вариант). А также мою статью с зимнего конкурса. Там расписал можно сказать игрушечную технологию, но тем не менее рабочую, на момент написания статьи под хром, фф, оперу, ie и т.п.
я более чем уверен что это чудо в бой не пойдет никогда:) я просто тыкаю потому что мне интересно ? так сказать ради фана
 
Наврядли это чудо пойдет в бой когда-либо в обозримом будущем. Но тем не менее, спустя N попыток у автора все может получится. Рим не за один день построили, так сказать. Тут также, только процесс обучения и написания конечного софта можно сказать объединены.
HVNC автор осилит ещё совсем не скоро, но если возьмется, будет любопытно глянуть что получится))
По hvnc советую глянуть zeus hvnc, ifsb, tunynuke (как самый простой вариант). А также мою статью с зимнего конкурса. Там расписал можно сказать игрушечную технологию, но тем не менее рабочую, на момент написания статьи под хром, фф, оперу, ie и т.п.
я переписываю считай тот же тининайк, но упор делаю на построение аналога цезаря. мне просто было очень интересно повторить. как говорится учимся на клонах.
 
Немного математики. Что происходит, если ты делаешь все без сжатия. 1 фрейм твоего видеопотока размерности 1920x1080 при условии, что у нас 4 байта на пиксель имеет вес 8294400 байт. Представим, что херачишь ты 30 фреймов в секунду (30 fps).
Так вот 1 секунда твоего видеопотока будет весить ~249 MB. Минута твоего видеопотока - 14.93 GB. 30 минут - 447.9 GB
2 часа - 1.79 TB.
Это 1 твой бот. Естественно ты столкнёшься с проблемой на стадии когда захочешь переслать хотя бы 1 секунду видеопотока. Представим, что ты каждую секунду хочешь синхронизировать чанки между ботом и твоей клиент прогой. Бот уже отрисовал следующую секунду., а у тебя старый набор чанков с предыдущей секунды(249мб) ещё не дошёл, они же у нас последовательно передаются. Раз, и забил канал юзера. А если у юзера норм инет, то забьешь изи канал своего сервера. Посчитай, какая пропускная способность должна быть у твоего сервера, чтобы одновременно работать с 2-3 ботами..
Никогда не задумывался, что значит в ютубе 240р, 360р, 720р? 240р если верить вики, это 400 кбит/сек или 50кб/сек. Чувствуется разница с твоими 250мб, да?) И ютуб сам умеет определять какой битрейт тебе надо поставить. И тебе так тоже надо уметь, адаптировать битрейт под скорость коннекта, у всех ботов он разный. То есть качество зависит от пропускного канала, бота, твоего. А по поводу вычисления разности кадров и передачи только разницы, то, о чем выше говорили.... это самая базовая фича, на самом деле, с помощью алгоритмов компенсации движения можно ещё больше сжать последовательность кадров. А например с помощью конвертации в 8 битный цвет можно представить все твои цвета rgba(4 байта) как 1 байт. Например по такой палетке.
5928D700-E741-41B7-A4A3-BAE045B7E61E.png

Таким образом будет потеря в цвете, но в видео трансляции экрана это не столь важно. С другой стороны ты реализуешь 1 пиксель не 4 байтами, а 1 байтом. Дели вес кадра на 4. И так дальше по списку. Все это в совокупности реализовано в кодеках. И либо ты сам будешь возиться с этим матаном(а его там много) и его реализацией, либо используешь отлаженное и готовое. Худшим вариантом, но самым простым, считается сжатие с потерей качества(quality 20% норм). То есть, когда ты передаёшь каждый кадр как сжатый jpeg. Как временное решение это может использоваться. И учти, что сильное jpeg сжатие очень херит графики и подобный контент. А в целом, то, что ты показал в статье, вообще оторвано от реальности. Без обид:)
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
А например с помощью конвертации в 8 битный цвет можно представить все твои цвета rgba(4 байта) как 1 байт
А не проще ли использовать png сжатие? С моего скрина, в формате bmp, который весит 3мб, я сжал png алгоритмом и получил кадр в размере 150кб. В твоем же случае будет вместо 3мб - 1 мб
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Потому что в "нормальных" хвнц передаются данные только измененных секторов экрана, типа там экран делят на сектора и всё такое.
RDP клиент тоже так делает, там у него блоки по 64х64 пикселя, которые кешируются (можно погуглить на тему BMCache и RDP, забавно, что эти закэшированные картинки можно вытащить).
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Потому что в "нормальных" хвнц передаются данные только измененных секторов экрана, типа там экран делят на сектора и всё такое.
Так а эти изменённые сектора как то сжимаются же?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Так а эти изменённые сектора как то сжимаются же?
https://catchchallenger.first-world...rk:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO - вот тебе таблицы алгоритмов сжатия для сравнения. В общем случае тебе нужен компромис между степенью сжатия и скоротью работы алгоритма. Возьми несколько и проверь, что тебе подходит. Но отправлять все равно надо только те блоки, что изменились, а то трафика будет много, как ты его не пакуй. В твоем любимом PNG вроде Deflate используется, что по сути один хер с алгоритмом GZIP.
 


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