Кражбата на идентификационни данни (credential harvesting) от машините на разработчиците се разшири. По-ранните софтуери за кражба на информация (infostealers) работеха с кратък списък от известни цели, най-вече хранилища на браузъри и няколко пътя за идентификационни данни в облака.
Активните в момента семейства хвърлят много по-широка мрежа. Shai-Hulud, например, изпълни таен скенер върху цялата файлова система и потвърждаваше автентичността на всичко открито, вместо да проверява шепа очаквани места.
Тази ширина е това, което прави защитата чрез примамки (deception) практична, а скоростта е това, което я прави спешна. Модул за събиране, който потвърждава събраното, тества откраднатите идентификационни данни за секунди, а не за часове. Първоначалното компрометиране вече не е прозорец от време, в който да разследвате. До момента, в който някой обикновено би се сетил да провери, идентификационните данни вече са взети, проверени и използвани.
Атакуващ, който сканира целия диск за всичко с форма на идентификационни данни, ще прихване примамка, където и да се намира тя, и ще я тества заедно с всичко останало. Този първи опит за потвърждение е сигналът за тревога и той е единственият момент, който е достатъчно ранен, за да има значение.
Защо защитата чрез примамки не изпълни обещанието си
Поведенческото откриване работи въз основа на подсказки. То наблюдава процесорната активност, файловите операции и мрежовите извиквания, съпоставя ги с известни модели и оценява доколко е вероятно да се случва нещо злонамерено. Добрите продукти оценяват добре, но оценката все пак си остава просто продуктът.
Honeytoken премахва предположенията. Идентификационните данни съществуват без друга причина, освен да бъдат откраднати, така че нищо в нормалната инженерна работа няма причина да ги докосва. Тяхното използване не е доказателство за пробив; то е самият пробив. Тъй като няма какво да се претегля, няма какво и да се сгреши, откъдето идва и процентът на фалшиво положителни резултати, близък до нулата.
Предвид всичко това, очевидният въпрос е защо защитата чрез примамки все още не е навсякъде. Отговорът е по-скоро оперативен, отколкото концептуален. Ръчното поставяне на примамки не се мащабира извън шепа системи с висока стойност. Някой трябва да реши какво да постави, къде да го сложи и да го поддържа там, докато машините се преинсталират, а разработчиците идват и си отиват. Примамка, която тихо изчезва след три месеца, е по-лоша от липсата на примамка, защото екипът вярва, че е защитен.
GitGuardian въведе внедряване в цялата мрежа от устройства чрез управление на мобилни устройства (MDM), което отстрани проблема с ръчното поставяне: агент, който вече работи на всяка машина, може да постави примамка и да я върне обратно, ако някой я изтрие. Изследванията за това как всъщност се държат софтуерите за кражба на данни решиха другата половина от проблема, тъй като вече не трябва да гадаем какво един такъв софтуер би намерил за привлекателно, когато можем да проучим какво събира и да го възпроизведем.
Какво работи днес
Honeytokens са част от платформата GitGuardian от няколко години и това, което екипите могат да правят с тях днес, е по-широко, отколкото терминът „примамка за идентификационни данни“ подсказва.
Екипите създават honeytokens чрез контролния панел, API или командния ред. След това ги поставят навсякъде, където има вероятност атакуващ да търси: хранилища с изходен код, конфигурационни файлове, вътрешна документация, скриптове за внедряване и конвейери за непрекъсната интеграция (CI pipelines).
Поставена honeytoken примамка, свързана с машината, на която се намира, и файла с идентификационни данни, в който е записана. Таблицата със събития е празна, което показва как изглежда недокосната примамка.
От юни 2026 г. това разполагане се разпростира и върху лаптопите на разработчиците. Honeytokens се внедряват в целия парк от устройства чрез съществуващите MDM инструменти, което означава, че екипът по сигурността може да защити няколко хиляди машини, без да докосва нито една от тях индивидуално, а контролният панел отчита кои крайни точки действително съдържат примамка, вместо да оставя някого да предполага покритието. Примамките, които биват изтрити, се заменят при следващата синхронизация.
Защита с honeytoken на една крайна точка, показваща последната синхронизация, колко примамки са внедрени и от колко време машината е покрита. Токенът е активен и никога не е бил задействан.
От оперативна гледна точка предупрежденията са това, което има значение. Когато някой се опита да използва honeytoken, GitGuardian генерира инцидент, посочващ машината и файла, от който са дошли идентификационните данни, и след това го пренасочва през каквото екипът вече използва – било то имейл, Slack, Teams, ServiceNow или техен собствен webhook. Никой не трябва да следи нова конзола, което е по-важно, отколкото изглежда, когато повечето инструменти за откриване изискват от екипа да поеме повече сигнали от предишната седмица. Този инструмент ги кара да поемат сигнал, върху който винаги си струва да се противодейства.
Разширяване на стръвта извън ключовете за облачни услуги
Днешните honeytokens на GitGuardian са идентификационни данни за AWS, а примамката е реален ключ, издаден от AWS профил, който GitGuardian контролира. Всяко API извикване, направено към този ключ, се регистрира в профила, към който принадлежи, така че когато атакуващ тества идентификационните данни, ние виждаме опита, заедно с това кога се е случил и откъде е дошъл.
Повечето идентификационни данни на машината на разработчик не предлагат нищо сравнимо. Достъпът до Kubernetes клъстери, входните данни за регистри с пакети и други идентификационни данни за услуги следват различни формати и се насочват към различни места, като няколко от тях са сред първите неща, които червеите в регистрите за пакети търсят. Покриването им изисква повече от това да се запише убедително изглеждащ файл на диска, защото нещо трябва да чака от другата страна, когато атакуващият го опита, готово да распознае опита и да го проследи обратно до конкретен клиент и машина.
Това е работата, която се извършва в момента, и тя умишлено е изградена наведнъж, вместо да се изгражда наново за всеки тип идентификационни данни. Тъй като нищо след предупреждението не трябва да се променя, всеки нов вид примамка пристига в рамките на конфигурацията, която клиентът вече има: същият инцидент, същите маршрути за уведомяване и същият работен процес.
Проектиране на примамки, които издържат
Примамката е полезна само докато атакуващият не може да я различи от истински идентификационни данни и това ограничение оформя дизайна повече от всичко останало.
Форматите за идентификационни данни, които добавяме, не носят вътрешна структура, която би могла да издаде примамката. Идентификаторът във файла е случаен, без кодиран собственик или профил, който атакуващият да разкрие, така че откраднатата примамка не му казва нищо дори при внимателна проверка. Инфраструктурата зад тези примамки се държи отделно от всичко, което би я идентифицирало като наша, с предположението, че мотивиран атакуващ в даден момент ще започне да търси.
Освен тази базова линия обаче се оказва, че ефективното подвеждане (децепция) зависи значително по-малко от сложен камуфлаж, отколкото повечето модели на заплахи биха предположили, тъй като зловредният софтуер, който извършва събирането, далеч не е толкова придирчив, колкото противникът, около когото са изградени тези модели. Това, което има значение, е да се съответства на начина, по който идентификационните данни действително се събират в реална среда — което е по-ниска летва от проектирането срещу хипотетичен атакуващ и значително по-полезна такава.
Честно ограничение
Подвеждането открива използването, а не кражбата. Примамка, която е открадната и никога повече не е докосната, ще остане тиха, и никоя реализация не може да промени това, тъй като контролът се задейства само когато някой предприеме действие въз основа на онова, което е взел. Това е причината подвеждането да има своето място редом с откриването на идентификационни данни, а не вместо него. Откриването ви казва кои валидни идентификационни данни са изложени на дадена машина и ви връчва списък за отмяна, докато подвеждането ви уведомява в момента, в който някой посегне към дадени данни. Екип, който използва само първото, разполага с опис на риска без никой да го наблюдава, а екип, който използва само второто, чака предупреждение за излагане на риск, което никога не е измерил.
Накъде продължава това
Работата се развива в две посоки: повече места за поставяне и повече видове honeytoken за поставяне.
Относно разполагането, средите за непрекъсната интеграция (CI runners) и Kubernetes клъстерите са в обхвата, тъй като скорошни варианти на червеи бяха създадени да попадат в среди за разработка и билдване.
Относно покритието, конфигурационните файлове на Kubernetes и данните за вход в регистри за пакети са типовете идентификационни данни, към чието поддържане се стремим.
Идентификационните данни за Google Cloud и Azure са по-назад в списъка, тъй като прегледът ни на образци от инфостийлъри (зловреден софтуер за кражба на информация) показва, че днес те едва биват докосвани. Предпочитаме да добавим покритие там, където събирането действително се случва.
Къде се намират honeytoken-ите в платформата на GitGuardian
Honeytoken-ите са слоят за подвеждане в платформата за сигурност на тайни и нечовешки самоличности на GitGuardian. Developer Endpoint Protection е това, което ги внедрява и поддържа в цялата флотилия от устройства на разработчиците. Заедно с откриването на идентификационни данни, те отговарят на двата въпроса, които даден екип по сигурност има за всяка машина: какво е изложено на нея и посегнал ли е някой към него.
Повърхността от идентификационни данни на машината на разработчика продължава да нараства, а инструментите за кодиране с изкуствен интелект добавят нови пътища към нея всяко тримесечие. Екипите, които ще хванат кражбата рано, са тези, които имат нещо чакащо в тези пътища, преди да се случи събирането.
Вижте го да работи от край до край в демо на живо на платформата GitGuardian, от крайните точки на разработчиците до видимостта на самоличностите.