Malleable C2. Создаем профиль для скрытой передачи данных Cobalt Strike

В этой статье мы рас­смот­рим про­цесс соз­дания и нас­трой­ки про­филя Malleable C2, который будет ими­тиро­вать легитим­ные зап­росы к извес­тным сай­там. Мы деталь­но раз­берем струк­туру про­филя и пос­мотрим, как замас­кировать его под вза­имо­дей­ствие с реаль­ными сер­висами.

Что такое профиль Malleable C2

Про­филь Malleable C2 поз­воля­ет гиб­ко нас­тро­ить поведе­ние маяч­ка (beacon) Cobalt Strike при вза­имо­дей­ствии с сер­вером управле­ния (Team Server). Основное наз­начение про­филя Malleable C2 — изме­нять сетевые зап­росы и отве­ты таким обра­зом, что­бы они выг­лядели как обыч­ный тра­фик, который не будет вызывать воп­росов у сис­тем IDS/IPS. К тому же это усложня­ет ана­лиз тра­фика спе­циалис­тами. Дос­тига­ется же мас­киров­ка путем нас­трой­ки раз­личных парамет­ров HTTP-зап­росов и отве­тов: URI, заголов­ков, парамет­ров и содер­жимого зап­роса.

Как происходит взаимодействие

Ког­да маячок запус­кает­ся на целевой машине, он ини­циирует тран­закцию HTTP-GET к Team Server (зап­рос при этом может быть как GET, так и POST). В зап­росе переда­ются метадан­ные о ском­про­мети­рован­ной сис­теме. Сер­вер в ответ отправ­ляет задачи, которые дол­жен выпол­нить маячок. Пос­ле завер­шения задач маячок про­веря­ет наличие дан­ных для отправ­ки и ини­циирует тран­закцию HTTP-POST, содер­жащую иден­тифика­тор сеан­са. Сер­вер исполь­зует эту информа­цию для при­вяз­ки дан­ных к соот­ветс­тву­юще­му сеан­су.

Те­перь, ког­да мы разоб­рались с осно­вами вза­имо­дей­ствия маяч­ка и сер­вера, перей­дем к нас­трой­ке про­филя Malleable C2.

Структура профиля

Для запус­ка Team Server с кас­томным про­филем необ­ходимо выпол­нить коман­ду

Про­филь опи­сыва­ет, как маячок обща­ется с сер­вером и как про­исхо­дит пос­тэкс­плу­ата­ция. Выше я говорил, что маячок исполь­зует два вида тран­закций для обме­на дан­ными (HTTP-GET и HTTP-POST). Даль­ше мы пос­мотрим, как реали­зовать это в про­филе.

http-get

В про­филе параметр http-get отве­чает за переда­чу метадан­ных на Team Server и получе­ние задач от него. Он обя­зан содер­жать клю­чи:

• client — опи­сыва­ет, как будет выг­лядеть HTTP-зап­рос от маяч­ка к сер­веру;
• server — опи­сыва­ет ответ сер­вера на зап­рос.

Ключ client дол­жен иметь параметр metadata, в котором опре­деля­ются спо­собы обра­бот­ки отправ­ляемой маяч­ком мета­информа­ции, а ключ server — параметр output, в котором опи­сыва­ется порядок обра­бот­ки отве­та кли­енту.

В парамет­рах client и server еще опре­деля­ются:

• uri — опи­сыва­ет URL;
• header — добав­ляет HTTP-заголов­ки к зап­росу;
• parameter — добав­ляет парамет­ры к uri.

В перечис­ленных парамет­рах могут исполь­зовать­ся под­ста­новоч­ные зна­ки или перечис­ление зна­чений.

Из­менять метадан­ные (metadata) и выводи­мую информа­цию (output) помогут сле­дующие выраже­ния:

• append — добав­ляет стро­ку в кон­це дан­ных;
• base64 — кодиру­ет дан­ные в Base64;
• base64url — кодиру­ет дан­ные в Base64 для исполь­зования в URL;
• mask — выпол­няет опе­рацию XOR со слу­чай­ным клю­чом;
• netbios — кодиру­ет дан­ные в NetBIOS;
• netbiosu — кодиру­ет дан­ные в NetBIOS;
• prepend — добав­ляет стро­ку перед дан­ными.

Пре­обра­зова­ние дан­ных дол­жно закан­чивать­ся одним из сле­дующих опе­рато­ров, ука­зыва­ющих на мес­то раз­мещения переда­ваемой информа­ции в HTTP-зап­росе:

• header "Cookie" — запишет отправ­ляемые дан­ные в HTTP-заголо­вок Cookie (может исполь­зовать­ся любой заголо­вок);
• parameter "view" — запишет отправ­ляемые дан­ные в параметр view (нап­ример, http://sadfadsf.com/asdfsadf?view=<передаваемые_данные>);
• print — запишет дан­ные в тело HTTP (обя­зате­лен для бло­ков http-get.server.output, http-post.server.output и http-stager.server.output);
• uri-append — добавит дан­ные в URI.

Струк­тура про­филя HTTP-GET будет сле­дующая:

http-post

Этот параметр отве­чает за отправ­ку дан­ных, получен­ных в резуль­тате выпол­нения задач маяч­ка.