Откраднатите облачни идентификационни данни могат да превърнат обикновен инцидент в по-сериозен пробив в сигурността. Атакуващ, който се сдобие с валиден AWS ключ или сесия, може да влезе като одобрен потребител и да се насочи към чувствителни системи.

Всичко може да започне с непознат IP адрес, да премине през облачни проверки и да завърши с трансфер на данни или промени, които удължават достъпа на киберпрестъпника. Последните случаи, включващи активни AWS ключове за достъп, показват защо компрометирането им може да доведе до широк контрол над облачната инфраструктура.

Анализатори от AWS очертаха този път на атака в ръководство за свързване на различни сигнали за сигурност. Докато изолираните предупреждения могат да изпуснат цялата картина, свързаните събития могат да разкрият координирано проникване.

AWS посочва в доклад, споделен с Cyber Security News (CSN), че показва как компрометираната идентичност може да подпомогне разузнаването, ескалацията на привилегии, страничното движение и кражбата на данни. Индивидуалните действия могат да изглеждат легитимни, но техният момент на извършване и цел могат да разкрият атака.

AWS описва пет фази: първоначален достъп, разузнаване (откриване), ескалация на привилегии, странично движение и ексфилтрация на данни. CloudTrail записва API активността, VPC Flow Logs улавят мрежовите връзки, а Resolver логовете показват търсенията на домейни. Заедно те изграждат хронология на събитията.

Атакуващите могат да извикат GetCallerIdentity, GetSessionToken или AssumeRole от нов адрес, за да потвърдят, че откраднатите идентификационни данни работят. Обикновено те продължават с заявки от тип List, Describe и Get. Грешките от тип AccessDenied са важни, тъй като повтарящите се неуспешни опити могат да покажат, че злонамерен субект тества лимитите на акаунта.

Ескалацията на привилегии може да последва, ако атакуващият открие верига от роли или промяна в политиките, която дава повече права. AWS посочва PutRolePolicy, CreateAccessKey и AttachUserPolicy като сигнали, които трябва да се свържат помежду си.

Ето защо злоупотребата с CloudTrail логове от страна на атакуващите е критична: злонамерен субект с достатъчно права може да отслаби или изтрие доказателствата, на които разчитат защитниците.

Валидна роля може да извършва GetObject заявки към хранилището, преди да изпрати данни навън. AWS препоръчва свързването на голям брой четения от чувствителни контейнери (buckets) с изходящи трансфери и DNS заявки към нови домейни, особено когато съответният потребителски профил не би трябвало да има достъп до тези данни.

Изграждане на облачна детекция с отчитане на контекста

AWS препоръчва активирането и настройването на GuardDuty, CloudTrail, VPC Flow Logs и Route 53 Resolver query logging, преди да се създават потребителски правила. GuardDuty Extended Threat Detection може да обедини общи модели на поведение и да генерира критично предупреждение. То обаче не може да знае кой контейнер е чувствителен, кои роли са разрешени или кога трябва да се извършват промени.

Този локален контекст е от решаващо значение. Екипите трябва да опишат одобрените потребители за четене, разрешените вериги от роли, собствениците на ключове и времевите прозорци за промени. Роля за внедряване (deployment role), която приема няколко роли по график, може да е нещо нормално. Но потребителски профил на реален човек, който прави това в полунощ преди да създаде нов ключ, заслужава проверка.

За хранилищата AWS съветва да се активират CloudTrail data events. Събитията за управление (management events) сами по себе си не записват GetObject активност. Екипите трябва да определят базова линия на активност и да зададат прагове над 95-ия персентил за четене на обекти.

Компанията също така съветва свързването на събитията за идентичност с мрежовите записи да става по време на събитието, а не по време на заявката. Доставянето на CloudTrail логове може да се забави с 5 до 15 минути, така че търсене в диапазон от 30 до 60 минути може да подпомогне по-точна десетминутна корелация. Това потвърждава дали подозрителен потребител е извършил голям външен трансфер.

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

Организациите трябва да започнат с едно добре настроено правило, да го тестват спрямо реален трафик и да добавят нови модели едва след като то се докаже като полезно. Това е изключително актуално, тъй като фишинг комплектите крадат конзолни идентификационни данни, а кампаниите за компрометиране на облака, задвижвани от изкуствен интелект, скъсяват времето между кражбата и нейното въздействие.

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

Това може да направи откраднатите идентификационни данни по-малко полезни, преди тихото проникване да се превърне в мащабен пробив. На практика екипите трябва да преглеждат непознати идентичности, да анулират компрометирани сесии и ключове и да запазват логовете, преди атакуващият да успее да ги промени.

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