Пишување Reverse socks5 proxy во powershell.Дел 1

Приказна за истражување и развој во 3 дела. Дел 1 е истражувачки.
Има многу букови дрвја - уште повеќе придобивки.

Проблем изјава

За време на пентести и кампањи на RedTeam, не е секогаш можно да се користат стандардните алатки на клиентот, како што се VPN, RDP, Citrix итн. како сидро за влез во внатрешната мрежа. На некои места, стандарден VPN работи со помош на MFA, а хардверски токен се користи како втор фактор, во други брутално се следи и нашето најавување на VPN веднаш станува видливо, како што велат, со сето она што го подразбира, но во други има едноставно нема такви средства.

Во такви случаи, постојано мораме да правиме таканаречени „обратни тунели“ - врски од внатрешната мрежа до надворешен ресурс или сервер што го контролираме. Внатре во таков тунел, веќе можеме да работиме со внатрешните ресурси на клиентите.

Постојат неколку варијанти на овие повратни тунели. Најпознатиот од нив е, се разбира, Meterpreter. SSH тунелите со пренасочување на обратна порта се исто така во голема побарувачка кај хакерските маси. Има доста средства за спроведување на обратно тунелирање и многу од нив се добро проучени и опишани.
Се разбира, од своја страна, развивачите на безбедносни решенија не стојат настрана и активно ги откриваат таквите акции.
На пример, сесиите на MSF се успешно откриени со модерен IPS од Cisco или Positive Tech, а обратен SSH тунел може да се открие од речиси секој нормален заштитен ѕид.

Затоа, за да останеме незабележани во добра кампања на RedTeam, треба да изградиме обратен тунел користејќи нестандардни средства и да се прилагодиме што е можно поблиску до реалниот режим на работа на мрежата.

Ајде да се обидеме да најдеме или измислиме нешто слично.

Пред да измислиме нешто, треба да разбереме каков резултат сакаме да постигнеме, кои функции треба да ги извршува нашиот развој. Кои ќе бидат барањата за тунелот за да можеме да работиме во максимален скришум режим?

Јасно е дека за секој случај таквите барања може многу да се разликуваат, но врз основа на работното искуство, може да се идентификуваат главните:

• работи на Windows-7-10 OS. Бидејќи повеќето корпоративни мрежи користат Windows;
• клиентот се поврзува со серверот преку SSL за да избегне глупаво слушање користејќи IP;
• При поврзување, клиентот мора да поддржува работа преку прокси-сервер со овластување, бидејќи Во многу компании, пристапот до Интернет се случува преку прокси. Всушност, клиентската машина можеби дури и не знае ништо за тоа, а проксито се користи во транспарентен режим. Но, ние мора да обезбедиме таква функционалност;
• клиентскиот дел треба да биде концизен и пренослив;
  Јасно е дека за да работите во мрежата на клиентот, можете да инсталирате OpenVPN на клиентската машина и да креирате целосен тунел до вашиот сервер (за среќа, клиентите на openvpn можат да работат преку прокси). Но, прво, ова нема секогаш да функционира, бидејќи можеби нема да бидеме локални администратори таму, и второ, ќе направи толку многу врева што пристојниот SIEM или HIPS веднаш ќе нè „коцне“. Идеално, нашиот клиент треба да биде таканаречена инлајн команда, како што на пример се имплементираат многу баш школки и се активираат преку командната линија, на пример, кога се извршуваат команди од макро со збор.
• нашиот тунел мора да биде со повеќе нишки и да поддржува многу врски истовремено;
• врската клиент-сервер мора да има некаква овластување за тунелот да биде воспоставен само за нашиот клиент, а не за секој што доаѓа на нашиот сервер на наведената адреса и порта. Идеално, целна страница со мачки или професионални теми поврзани со оригиналниот домен треба да се отвори за „трети лица“.
  На пример, ако Клиентот е медицинска организација, тогаш за администратор за безбедност на информации кој одлучува да го провери ресурсот до кој пристапил вработен во клиниката, страница со фармацевтски производи, Википедија со опис на дијагнозата или блог на д-р Комаровски итн. треба да се отвори.

Анализа на постоечки алатки

Пред повторно да го измислите вашиот сопствен велосипед, треба да направите анализа на постоечките велосипеди и да разберете дали навистина ни треба и, веројатно, не сме единствените кои размислувале за потребата од таков функционален велосипед.

Гуглирањето на Интернет (изгледа гугламе нормално), како и пребарувањето на Github со помош на клучните зборови „обратни чорапи“ не даде многу резултати. Во основа, сè се сведува на изградба на ssh тунели со обратно пренасочување на портите и се што е поврзано со него. Покрај SSH тунелите, постојат неколку решенија:

github.com/klsecservices/rpivot
Долгогодишна имплементација на обратен тунел од момците во Kaspersky Lab. Името јасно покажува за што е наменета оваа скрипта. Имплементиран во Python 2.7, тунелот работи во режим на јасен текст (како што е модерно да се каже сега - здраво RKN)

github.com/tonyseek/rsocks
Уште една имплементација во Python, исто така во јасен текст, но со повеќе можности. Напишан е како модул и има API за интегрирање на решението во вашите проекти.

github.com/llkat/rsocstun
github.com/mis-team/rsocstun
Првата врска е оригиналната верзија на имплементацијата на обратна сокс во Golang (не е поддржана од развивачот).
Втората врска е нашата ревизија со дополнителни функции, исто така во Голанг. Во нашата верзија, имплементиравме SSL, работиме преку прокси со овластување NTLM, овластување на клиентот, целна страница во случај на неточна лозинка (или подобро, пренасочување кон целната страница), режим со повеќе нишки (т.е. неколку луѓе може да работи со тунелот во исто време), систем на ping на клиентот за да се утврди дали е жив или не.

github.com/jun7th/tsocks
Имплементација на обратен сокс од нашите „кинески пријатели“ во Пајтон. Таму, за мрзливите и „бесмртните“, има готов бинарен (exe), склопен од Кинезите и подготвен за употреба. Овде, само кинескиот Бог знае што друго може да содржи овој бинар освен главната функционалност, затоа користете го на ваш сопствен ризик и ризик.

github.com/securesocketfunneling/ssf
Доста интересен проект во C++ за имплементација на реверс сокс и многу повеќе. Покрај обратниот тунел, може да врши пренасочување на порта, да креира командна школка итн.

Мерач на MSF
Овде, како што велат, нема коментари. Сите дури и помалку или повеќе образовани хакери се многу запознаени со оваа работа и разбираат колку лесно може да се открие со безбедносни алатки.

Сите алатки опишани погоре работат со слична технологија: претходно подготвен извршен бинарен модул се лансира на машина во мрежата, која воспоставува врска со надворешен сервер. Серверот работи сервер SOCKS4/5 кој прифаќа врски и ги пренесува на клиентот.

Недостаток на сите горенаведени алатки е тоа што или Python или Golang мора да се инсталираат на машината на клиентот (дали често сте виделе Python инсталиран на машините на, на пример, директор на компанија или канцелариски работници?), или претходно склопен бинарното (всушност питон) мора да се влече на оваа машина и скрипта во едно шише) и да го извршите овој бинарен веќе таму. И преземањето exe и потоа неговото лансирање е исто така потпис за локален антивирус или HIPS.

Во принцип, заклучокот се сугерира - ни треба решение за powershell. Сега ќе ни летаат домати - велат дека powershell е веќе целосно пробиен, надгледуван, блокиран итн. и така натаму. Всушност, не секаде. Изјавуваме одговорно. Патем, има многу начини да се заобиколи блокирањето (тука повторно има модерна фраза за здраво RKN 🙂), почнувајќи од глупаво преименување на powershell.exe -> cmdd.exe и завршувајќи со powerdll, итн.

Да почнеме да измислуваме

Јасно е дека прво ќе погледнеме на Google и... нема да најдеме ништо на оваа тема (ако некој го нашол, објави линкови во коментарите). Има само имплементација Socks5 на powershell, но ова е обичен „директен“ sox, кој има голем број на свои недостатоци (ние ќе зборуваме за нив подоцна). Можете, се разбира, со мало движење на раката да ја претворите во обратна, но ова ќе биде само сокс со една нишка, што не е баш она што ни треба.

Значи, не најдовме ништо готово, па сепак ќе треба повторно да го измислиме нашето тркало. Ќе го земеме како основа за нашиот велосипед нашиот развој обратен сокс во Голанг, и ние имплементираме клиент за него во Powershell.

RSocksTun
Па, како функционира rsocstun?

Работата на RsocksTun (во натамошниот текст rs) се заснова на две софтверски компоненти - серверот Yamux и Socks5. Socks5 серверот е редовен локален socks5, работи на клиентот. И мултиплексирањето на врските со него (се сеќавате на повеќенишки?) се обезбедува со користење на yamux (уште еден мултиплексер). Оваа шема ви овозможува да стартувате неколку сервери за клиент socks5 и да дистрибуирате надворешни врски до нив, препраќајќи ги преку една единствена TCP конекција (речиси како во метар преведувач) од клиент до сервер, со што ќе имплементирате режим со повеќе нишки, без кој едноставно нема да бидеме способни целосно да работат во внатрешните мрежи.

Суштината на тоа како работи yamux е тоа што воведува дополнителен мрежен слој на струи, имплементирајќи го во форма на заглавие од 12 бајти за секој пакет. (Тука намерно го користиме зборот „поток“ наместо нишка, за да не го збуниме читателот со програмски поток „нишка“ - овој концепт ќе го користиме и во оваа статија). Заглавието на yamux го содржи бројот на преносот, знаменцата за инсталирање/завршување на преносот, бројот на префрлени бајти и големината на прозорецот за пренос.

Покрај инсталирањето/завршувањето на стрим, yamux имплементира механизам keepalive кој ви овозможува да ја следите работата на воспоставениот канал за комуникација. Работата на механизмот за пораки keeplive е конфигурирана при креирање на Yamux сесија. Всушност, од поставките има само два параметри: овозможи/оневозможи и фреквенција на испраќање пакети во секунди. Пораките Keepalive може да се испраќаат од сервер yamux или yamux клиент. Кога примате порака за задржување, оддалечената страна мора да одговори на неа со испраќање на истиот идентификатор на пораката (всушност број) што го примил. Во принцип, keepalive е истиот пинг, само за yamux.

Целата техника на работа на мултиплексерот: типови на пакети, ознаки за поставување и завршување на конекцијата и механизмот за пренос на податоци се детално опишани во спецификации на јамукс.

Заклучок за првиот дел

Така, во првиот дел од статијата, се запознавме со некои алатки за организирање на обратни тунели, ги разгледавме нивните предности и недостатоци, го проучувавме механизмот на работа на мултиплексерот Yamux и ги опишавме основните барања за новосоздадениот модул powershell. Во следниот дел ќе го развиеме самиот модул, практично од нула. Продолжува. Не менувај :)

Извор: www.habr.com