Инцидентът с DigiCert поставя фокус върху риска при code-signing сертификати

Нова информация от Expel свързва subgroup от GoldenEyeDog екосистемата, наричан CylindricalCanine, с инцидент при DigiCert от април 2026 г. Според анализа атакуващите са използвали malware, за да компрометират устройство на служител от support екип и да получат достъп до code-signing certificates, предназначени за клиенти на DigiCert.

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

Когато атакуващите получат достъп до валиден code-signing сертификат, злонамерен файл може да изглежда по-достоверен. Това създава риск за software supply chain, endpoint protection и процесите за доверие към доставчици.

Какво се случва

Според Expel атакуващите са използвали social engineering срещу support процес. Злонамерени файлове са били представени като screenshots или customer evidence, изпратени чрез phishing имейли или support-ticket submissions. След отваряне на файла устройството на служител е било компрометирано.

Полученият достъп е позволил на атакуващите да достигнат до activation codes, свързани с подновяване или издаване на code-signing certificates. Такива кодове участват в процеса по активиране на hardware tokens, използвани за подписване на софтуер.

След това атакуващите са могли да използват откраднатите сертификати, за да подписват свои злонамерени файлове. Това не премахва нуждата malware да изпълни зловредно действие, но може да му помогне да изглежда по-легитимен в ранните етапи на изпълнение и анализ.

Защо code-signing сертификатите са чувствителни

Code-signing сертификатите се използват за потвърждение, че даден софтуер идва от конкретен издател и че кодът не е променян след подписването. Те са важни за:

• софтуерни доставчици;
• вътрешни development екипи;
• update механизми;
• enterprise deployment процеси;
• endpoint security решения;
• потребителско доверие;
• проверка на software integrity.

Ако сертификат бъде откраднат или злоупотребен, атакуващият може да подпише malware с валидна цифрова подпись. Това може да затрудни първоначалната оценка от потребители, IT екипи и част от защитните механизми.

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

Какъв malware е използван

Expel свързва активността с Golden Gh0st Loader и Golden Gh0st RAT. Това са инструменти, използвани в кампании, свързани с GoldenEyeDog активност.

Golden Gh0st RAT може да предостави възможности за:

• отдалечен достъп;
• изпълнение на команди;
• събиране на browser credentials;
• правене на screenshots;
• изброяване на процеси;
• поддържане на persistence;
• изтриване на следи от активност;
• създаване на допълнителен backdoor достъп.

Expel описва и употреба на DLL sideloading. При тази техника легитимно приложение се използва, за да зареди злонамерена DLL библиотека, поставена в подходяща директория. Това затруднява откриването, защото част от execution chain изглежда свързана с доверен executable.

Рискът при support и ticketing процеси

Инцидентът показва важна слабост в много организации: support екипите често получават файлове от външни потребители, клиенти или партньори. Тези файлове могат да бъдат screenshots, logs, документи, архиви или proof-of-issue материали.

Това създава специфичен риск:

• служителите очакват да отварят външни файлове;
• файловете често изглеждат част от нормален customer workflow;
• support системите може да не са напълно изолирани;
• attachment scanning може да пропусне нови payload-и;
• компрометираният support endpoint може да има достъп до чувствителни customer workflows.

Затова support процесите трябва да се разглеждат като част от attack surface, особено когато support екипите работят с certificates, credentials, activation codes, customer environments или sensitive operational data.

Какво трябва да се наблюдава

Организациите, които използват code-signing процеси или обработват customer-submitted files, трябва да наблюдават няколко типа активност:

• изпълнение на неочаквани .scr, .exe, .dll или архивирани файлове;
• DLL sideloading от легитимни приложения;
• нови scheduled tasks;
• нови локални administrator accounts;
• промени, позволяващи remote desktop достъп;
• необичайни outbound WebSocket връзки;
• достъп до certificate management системи;
• извличане или употреба на activation codes;
• необичайно подписване на файлове;
• подписани файлове, които не съответстват на нормален release процес;
• употреба на code-signing certificate извън очакваната build среда.

Тук контекстът е важен. Самото наличие на цифров подпис не трябва да бъде достатъчно, за да се приеме даден файл за безопасен. Подписът трябва да се проверява заедно с издателя, времето, мястото на подписване, release workflow и поведението на файла.

Препоръчителни действия

Организациите трябва да третират code-signing сертификатите като чувствителни security assets.

Приоритетни действия:

• ограничете достъпа до code-signing certificates и hardware tokens;
• използвайте multi-person approval за critical signing операции, когато е приложимо;
• изолирайте build и signing средите;
• следете кога, къде и от кого се подписват файлове;
• забранете подписване извън одобрени системи;
• наблюдавайте certificate usage logs;
• ротирайте или revoke-вайте сертификати при съмнение за компрометиране;
• проверявайте дали подписани файлове отговарят на нормален release процес;
• изолирайте support endpoints, които обработват външни файлове;
• използвайте sandbox среда за преглед на customer-submitted attachments;
• обучете support екипите да не стартират непроверени screenshots, installers или archives;
• следете за DLL sideloading и необичайни persistence механизми.

Ако има съмнение за злоупотреба с code-signing certificate, реакцията трябва да включва не само revoke на сертификата. Трябва да се провери кои файлове са били подписани, къде са били разпространени, дали са достигнали клиенти и дали има downstream impact.

DIAMATIX перспектива

Инцидентът показва, че доверието в софтуера трябва да се управлява като част от защитния модел. Code-signing сертификатите, build процесите, support каналите и endpoint контролите са свързани.

За организациите рискът не е само дали даден certificate provider е бил засегнат. Въпросът е дали вътрешните процеси могат да открият злоупотреба с подписан код, необичайно използване на сертификат или компрометирана support/workstation среда.

DIAMATIX разглежда подобни случаи като supply chain и trust infrastructure риск: сертификатът е доверен елемент, но поведението на файла, пътят на доставяне и контекстът на подписване трябва да се наблюдават заедно.

CISO анализ

За CISO основният въпрос е дали организацията знае как се управляват code-signing сертификатите и кой има достъп до тях.

Ключови въпроси за проверка:

• Кои code-signing сертификати използваме и къде се съхраняват?
• Кой има право да подписва софтуер?
• Има ли logging за всяка signing операция?
• Може ли сертификат да се използва извън одобрена build среда?
• Има ли процес за revoke и ротация при съмнение за компрометиране?
• Проверяваме ли подписани файлове според поведение, не само според валиден подпис?
• Изолирани ли са support endpoints, които обработват външни файлове?
• Имаме ли процес за проверка на customer-submitted attachments?

Практическият извод е, че code-signing сертификатите трябва да се управляват като привилегирован достъп. Ако бъдат злоупотребени, рискът може да се прехвърли към клиенти, партньори и downstream потребители на софтуера.

Какво означава това за вашата среда

• Този тип риск разчита на компрометирани support endpoints, злоупотреба с activation codes и използване на валидни code-signing certificates за подписване на malware.
• Откриването зависи от видимост върху certificate usage, signing workflows, support attachments, endpoint behavior, DLL sideloading и outbound command-and-control комуникации.
• Реакцията изисква revoke на засегнати сертификати, преглед на подписаните файлове, проверка на support endpoints, анализ на persistence механизми и оценка на downstream impact.

Ключови въпроси за проверка:

• Знаете ли всички code-signing сертификати, които организацията използва?
• Можете ли да видите кога и къде е използван всеки сертификат?
• Има ли контрол върху файловете, изпращани през support каналите?
• Може ли валидно подписан malware да заобиколи част от вашите процеси?
• Имате ли план за реакция при компрометиран code-signing certificate?

Проверете контрола върху code-signing сертификати и software supply chain риска

DIAMATIX може да помогне с преглед на:

• code-signing процеси и certificate usage;
• build и release workflow;
• support канали и обработка на външни файлове;
• endpoint telemetry за DLL sideloading и persistence;
• процедури за revoke и ротация на сертификати;
• готовност за реакция при компрометиран trusted software asset.

Заявете преглед на software trust и code-signing риска с DIAMATIX.
Trusted · Innovative · Vigilant

Източници

• Expel. Introducing CylindricalCanine: The GoldenEyeDog subgroup responsible for the April DigiCert incident.
• The Hacker News. GoldenEyeDog Subgroup Linked to DigiCert Breach and Code-Signing Certificate Theft.
• DigiCert. Microsoft and code-signing certificates: What to know.
• Expel IOC repository for Golden Gh0st indicators.

Статията е базирана на публично достъпна информация към юли 2026 г.