Ние пишем Reverse socks5 прокси на powershell. Част 1

Разказ за изследване и развитие в 3 части. Част 1 - изследване.
Има много буки - още повече ползи.

Проблем изявление

По време на пентестове и кампании на RedTeam не винаги е възможно да се използват стандартните инструменти на Клиентите, като VPN, RDP, Citrix и др. като щифт за влизане във вътрешната мрежа. Някъде обикновен VPN работи на MFA и железен токен се използва като втори фактор, някъде се наблюдава брутално и нашият VPN вход веднага става видим, както се казва - с всички последствия, но някъде просто няма такива средства.

В такива случаи непрекъснато се налага да правим така наречените „обратни тунели“ – връзки от вътрешната мрежа към външен ресурс или сървър, контролиран от нас. Вътре в такъв тунел вече можем да работим с вътрешните ресурси на Клиентите.

Има няколко разновидности на такива обратни тунели. Най-известният от тях е, разбира се, Meterpreter. SSH тунелите с обратно пренасочване на портове също са много търсени сред хакерските маси. Има доста средства за реализиране на обратно тунелиране и много от тях са добре проучени и описани.
Разбира се, от своя страна разработчиците на решения за сигурност не стоят настрана и активно откриват подобни действия.
Например, MSF сесиите се откриват успешно от модерни IPS от Cisco или Positive Tech, а обратен SSH тунел може да бъде открит от почти всяка повече или по-малко нормална защитна стена.

Следователно, за да останем незабелязани в една добра кампания на RedTeam, трябва да изградим обратен тунел с нестандартни средства и да се адаптираме възможно най-близо до действителния режим на работа на мрежата.

Нека се опитаме да намерим или измислим нещо подобно.

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

Ясно е, че за всеки случай такива изисквания могат да бъдат много различни, но според трудовия опит могат да се разграничат основните:

• работа на OS Windows-7-10. Тъй като повечето корпоративни мрежи използват Windows;
• клиентът се свързва със сървъра чрез SSL, за да елиминира глупавото слушане с помощта на ips;
• когато се свързва, клиентът трябва да поддържа работа чрез прокси сървър с разрешение, т.к В много компании достъпът до интернет се осъществява чрез прокси. Всъщност клиентската машина може дори да не знае нищо за него и проксито се използва в прозрачен режим. Но ние трябва да предоставим такава функционалност;
• клиентската част трябва да бъде стегната и преносима;
  Ясно е, че за да работите в мрежата на клиента, можете да инсталирате OpenVPN на клиентската машина и да издигнете пълноценен тунел към вашия сървър (за щастие клиентите на openvpn могат да работят чрез прокси). Но, първо, това не винаги ще работи, тъй като може да не сме местни администратори там, и второ, ще вдигне толкова много шум, че приличен SIEM или HIPS веднага ще ни "потупне", където е необходимо. В идеалния случай нашият клиент трябва да бъде така наречената вградена команда, като например много bash черупки са внедрени, и да се изпълнява през командния ред, например, когато изпълнява команди от макрос на дума.
• нашият тунел трябва да е многонишков и да поддържа много връзки едновременно;
• връзката клиент-сървър трябва да има някакъв вид оторизация, така че тунелът да бъде установен само за нашия клиент, а не за всеки, който идва на нашия сървър на посочения адрес и порт. В идеалния случай за „потребители на трети страни“ трябва да се отвори целева страница с котки или професионални теми, свързани с оригиналния домейн.
  Например, ако клиентът е медицинска организация, тогава администраторът на информационната сигурност, който реши да провери ресурса, достъпен от служител на клиника, трябва да отвори страница с фармацевтични продукти, Wikipedia с описание на диагнозата или блог на д-р Комаровски, и т.н.

Анализ на съществуващи инструменти

Преди да изобретите свой собствен велосипед, е необходимо да анализирате съществуващите велосипеди и да разберете дали наистина имаме нужда от него и вероятно не само ние сме мислили за необходимостта от такъв функционален велосипед.

Гугъл в интернет (изглежда, че гугълът е наред), както и търсене в github по ключовите думи „обратни чорапи“ не дадоха много резултати. По принцип всичко се свежда до изграждане на ssh тунели с обратно пренасочване на портове и всичко свързано с него. В допълнение към SSH тунелите има няколко решения:

github.com/klsecservices/rpivot
Стара реализация на обратен тунел от момчетата от Kaspersky Lab. От името става ясно за какво е предназначен този скрипт. Реализиран в Python 2.7, тунелът работи в режим чист текст (както е модерно да се казва сега - здравей RKN)

github.com/tonyseek/rsocks
Друга реализация в Python, също в чист текст, но има повече възможности. Написано като модул и има API за интегриране на решението във вашите проекти.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Първата връзка е оригиналната версия на изпълнението на обратните чорапи в golang (не се поддържа от разработчика).
Втората връзка вече е наша ревизия с допълнителни функции, също на golang. В нашата версия внедрихме SSL, работейки чрез прокси с NTLM оторизация, оторизация на клиента, целева страница с неправилна парола (или по-скоро пренасочване към целевата страница), многонишков режим (т.е. няколко души могат да работят с тунела едновременно) , система от клиентски пингове, за да се определи дали е жив или не.

github.com/jun7th/tsocks
Внедряване на обратни чорапи от нашите "китайски приятели" в python. На същото място, за мързеливите и "безсмъртните", има готов двоичен файл (exe), сглобен от китайците и готов за употреба. Тук само китайският бог знае какво друго може да има в този двоичен файл освен основната функционалност, така че го използвайте на свой собствен риск и риск.

github.com/securesocketfunneling/ssf
Доста интересен проект в C++ за внедряване на обратен запас и други. В допълнение към обратния тунел, той може да извършва препращане на портове, да създава командна обвивка и т.н.

MSF meterpreter
Тук, както се казва, без коментар. Всички повече или по-малко образовани хакери са добре запознати с това нещо и разбират колко лесно е да се открият инструменти за сигурност.

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

Недостатъкът на всички горепосочени инструменти е, че или имате нужда от Python или Golang, инсталирани на клиентската машина (често ли сте виждали Python инсталиран на машини, например директори на компании или офис служители?), Или трябва да плъзнете предварително създаде двоичен файл към тази машина (всъщност python и скрипт в една бутилка) и стартира този двоичен файл вече там. И зареждането на exe с последващото му стартиране е друг подпис за локална антивирусна програма или HIPS.

Като цяло заключението се налага само по себе си - имаме нужда от решение на powershell. Сега домати ще летят при нас - казват powershell - всичко това е разбито, наблюдава се, блокира се и т.н. и така нататък. Всъщност не навсякъде. Декларираме отговорно. Между другото, има много начини за заобикаляне на ключалките (тук отново модерна фраза за здравей RKN 🙂), започвайки от глупаво преименуване на powershell.exe -> cmdd.exe и завършвайки с powerdll и т.н.

Започва да изобретява

Ясно е, че първо ще търсим в Google и ... няма да намерим абсолютно нищо по тази тема (ако някой го е намерил, хвърлете връзки в коментарите). Има само изпълнение Socks5 на powershell, но това е нормален "прав" чорап, който има редица недостатъци (ще говорим за тях по-късно). Можете, разбира се, да го превърнете в обратен с леко движение на ръката си, но това ще бъде само Sox с една нишка, което не е точно това, от което се нуждаем.

И така, не сме намерили нищо готово, така че все още трябва да изобретяваме собственото си колело. Ще вземем за основа на нашия мотор нашето развитие backsock на golang, а клиентът към него е внедрен на powershell.

RSocksTun
И така, как работи rsockstun?

RsocksTun (по-нататък - rs) се базира на два софтуерни компонента - Yamux и Socks5 сървър. Socks5 сървърът е обикновен локален socks5, работи на клиента. И мултиплексирането на връзки към него (помните ли многопоточността?) се предоставя с помощта на yamux (още един мултиплексор). Тази схема ви позволява да стартирате няколко клиентски socks5 сървъра и да разпространявате външни връзки към тях, препращайки ги през една TCP връзка (почти като в meterpreter) от клиента към сървъра, като по този начин реализирате многонишков режим, без който просто не можем пълноценна работа във вътрешните мрежи.

Същността на работата на yamux е, че той въвежда допълнителен мрежов слой за потоци, реализирайки го като 12-байтов хедър за всеки пакет. (Тук съзнателно използваме думата "поток", а не нишката, за да не объркаме читателя с програмната нишка "нишка" - ние също ще използваме това понятие в тази статия). Заглавието на yamux съдържа номера на потока, флагове за настройка/завършване на потока, броя байтове за прехвърляне и размера на прозореца за прехвърляне.

В допълнение към настройването/спирането на поток, yamux прилага механизъм за поддържане на активността, който ви позволява да наблюдавате изправността на установения комуникационен канал. Работата на механизма за поддържане на съобщения се конфигурира при създаване на Yamux сесия. Всъщност от настройките има само два параметъра: активиране / деактивиране и честотата на изпращане на пакети в секунди. Съобщенията Keepalive могат да се изпращат от сървъра на yamux, както и от клиента на yamux. Когато се получи съобщение за поддържане на активността, отдалечената страна трябва да отговори на него, като изпрати точно същия идентификатор на съобщението (всъщност номер), който е получила. Като цяло, keepalive е същият пинг, само за yamux.

Подробно, цялата техника на мултиплексора: типове пакети, флагове за настройка и прекратяване на връзки, механизмът за пренос на данни е описан в специализация към yamux.

Заключение към първата част

И така, в първата част на статията се запознахме с някои инструменти за организиране на обратни тунели, разгледахме техните предимства и недостатъци, проучихме механизма на мултиплексора Yamux и описахме основните изисквания към новосъздадения модул powershell. В следващата част ще разработим самия модул, практически от нулата. Следва продължение. Не сменяйте 🙂

Източник: www.habr.com