GuardBreaker: cómo un simple comentario de código puede confundir a la IA en el análisis de malware

Los crea­do­res de có­di­go ma­li­cio­so mo­di­fi­can cons­tan­te­men­te sus mé­to­dos para sor­tear los me­ca­nis­mos de de­fen­sa y evi­tar que sus he­rra­mien­tas re­ve­len sus ver­da­de­ras in­ten­cio­nes du­ran­te la ins­pec­ción. Con la in­cor­po­ra­ción de mo­de­los de len­gua­je de gran ta­ma­ño (LLM) en las ta­reas de aná­li­sis y cla­si­fi­ca­ción de có­di­go en se­gu­ri­dad, los ata­can­tes han co­men­za­do a bus­car ma­ne­ras de in­ter­fe­rir con estas tec­no­lo­gías uti­li­zan­do en­tra­das ad­ver­sa­ria­les que se mues­tran de forma abier­ta.

Un ejem­plo de esta tác­ti­ca fue de­tec­ta­do por in­ves­ti­ga­do­res en un script VBS­cript em­plea­do en las fases ini­cia­les de una agre­sión con­tra un ob­je­ti­vo en Ucra­nia, atri­bui­do a un grupo ali­nea­do con Rusia. En este caso, el ar­chi­vo in­cluía un co­men­ta­rio con una pe­ti­ción fic­ti­cia para fa­bri­car un arma nu­clear, idea­da para ac­ti­var los fil­tros de se­gu­ri­dad de los es­cá­ne­res ba­sa­dos en LLM y lo­grar que de­tu­vie­ran el aná­li­sis antes de re­vi­sar el resto del do­cu­men­to, cuyo pro­pó­si­to era ins­ta­lar un car­ga­dor des­ti­na­do a dis­tri­buir más ele­men­tos ma­li­cio­sos.

Esta téc­ni­ca, de­no­mi­na­da Guard­Brea­ker, fun­cio­na como un caso de in­yec­ción de prompts donde el con­te­ni­do ma­li­cio­so llega al mo­de­lo du­ran­te la in­fe­ren­cia a tra­vés del ar­chi­vo ana­li­za­do, apro­ve­chan­do una vul­ne­ra­bi­li­dad de di­se­ño en los LLM ac­tua­les al pro­ce­sar datos no con­fia­bles junto con ins­truc­cio­nes le­gí­ti­mas. In­ci­den­tes si­mi­la­res han ocu­rri­do en ata­ques a ca­de­nas de su­mi­nis­tro de soft­wa­re, donde se han in­ser­ta­do ins­truc­cio­nes fal­sas, ór­de­nes ex­plí­ci­tas para re­por­tar có­di­go pe­li­gro­so como se­gu­ro, o re­pe­ti­cio­nes ma­si­vas de fra­ses para ago­tar la ven­ta­na de con­tex­to del mo­de­lo.

Para mi­ti­gar estos ries­gos, se re­co­mien­da que nin­gún motor LLM posea la au­to­ri­dad ab­so­lu­ta para de­ter­mi­nar si un có­di­go es se­gu­ro, de­bien­do com­bi­nar­se la in­te­li­gen­cia ar­ti­fi­cial con va­li­da­cio­nes hu­ma­nas y en­fo­ques mul­ti­ca­pa, ade­más de con­tar con es­tra­te­gias cla­ras y ser­vi­cios de de­tec­ción y res­pues­ta ges­tio­na­das (MDR) para evi­tar pun­tos cie­gos en la se­gu­ri­dad.