La residencia por proceso ha ido adquiriendo adeptos de manera paulatina (Win32.Maya, Win32.Niko...), y ha dado pie a la aparición de nuevas variantes, como la empleada en aquellos virus que enganchan APIs de la tabla de exportaciones de KERNEL32, con el fin de permanecer residentes en memoria de manera global. Probablemente la propia residencia por proceso y la variante que acabamos de explicar sean las dos vías más ortodoxas de permanecer en la memoria de Win32, así como las mejor adaptadas al sistema de multihilo de esta plataforma, además de ser las más estables.

Girigat es uno de los virus que se han subido al carro de la residencia por proceso, que consiste en enganchar ciertas APIs (las que el autor del virus decida) por medio de parcheos en la IT del programa huésped, de manera que cuando éste llame a una de las APIs enganchadas por el virus, el control pasará a un handler o rutina encargada de procesar ese tipo de llamadas, que se encargará de infectar las víctimas que haya al alcance y de saltar entonces a la dirección original de la API solicitada por el host del virus.

Como apuntamos con anterioridad, no todas las generaciones de Girigat tienen activada la capacidad de emplear API hooking (el nombre alternativo de la residencia por proceso, empleado por primera vez por Matt Pietrek), por lo que el virus comienza por comprobar si esta característica está disponible. Este tipo de chequeos los efectúa por medio de una serie de flags, que, mediante unos o ceros, le indican a Girigat la disponibilidad de la función que busca. En el caso de la residencia por proceso, si el flag correspondiente está activado, nuestro virus llama a una subrutina en la cual, mediante un bucle, procede iterativamente a buscar las APIs deseadas en la tabla de importaciones de su host, y, en caso de que estén presentes, a "engancharlas", sustituyendo su dirección original por la del handler vírico correspondiente en memoria.

Las APIs que el virus trata de enganchar son las correspondientes a la apertura y a la búsqueda de ficheros, en sus versiones ANSI y Unicode, para total compatibilidad con WindowsNT: CreateFileA, CreateFileW, FindFirstFileA, FindFirstFileW, FindNextFileA y FindNextFileW. El flujo de ejecución, tras haber completado la tarea de parcheo de la IT del host, alcanza el punto en el que Girigat determina si debe completar su proceso de ejecución añadiendo una búsqueda e infección de ficheros por medio de acción directa o runtime, o si simplemente bastará con devolver el control de ejecución al punto de entrada real del host, por medio de la instrucción ret, ya que, durante el proceso de inicialización, el virus había almacenado esta dirección (obtenida en forma de RVA previamente, durante la infección del fichero) en la pila.

En cualquiera de los dos casos, la actividad de los handlers de las APIs supuestamente enganchadas no entra en acción hasta el momento en el que el host, en plena ejecución, requiere el empleo de alguna de las APIs parcheadas. Es ahí cuando la instrucción call salta a un jmp que, en lugar de conducirnos hasta la API a la que se ha llamado, nos lleva hasta el handler que Girigat dispuso para dicha API. Aquí hay que decir que el virus dispone en realidad de tres handlers: uno para CreateFile (-A y -W), otro para FindFirstFile (-A y -W), y un último, para FindNextFile (también -A y -W). A diferencia de otros virus que, o bien no dan soporte a Unicode, o bien lo tratan de forma separada, Girigat procesa con un mismo handler ambos tipos de versiones, las cuales distingue por medio de la activación de un flag que le indica si debe proceder a convertir a ANSI los parámetros que emplea de cada una de las APIs, por medio de la función WideCharToMultiByte.

El funcionamiento de los handlers es estándar, y sigue en todos los casos la misma línea: obtención del nombre del fichero que el host pretende procesar por medio de la API en teórica actividad, chequeo del flag de Unicode y, en caso de estar activado, conversión del nombre del futuro fichero víctima a formato ANSI, comprobación del formato de dicho fichero (por medio de su extensión), salto a la runtina de setup de la infección (con el fin de efectuar otro tipo de chequeos), infección en caso de que no haya ningún problema, y finalmente devolución del control a la API original, para que el host funcione correctamente y no levante sospechas en el usuario.

A pesar de seguir unas mismas pautas, cada uno de los handlers tiene su peculiaridad, ya que, por ejemplo, el nombre del fichero a procesar cuando se trata de llamadas a las APIs CreateFile(A/W) y FindFirstFile(A/W) está almacenado en la dirección [esp+24h], mientras que cuando se llama a la API FindNextFile(A/W) éste se encuentra en [esp+28h]. Además existe el agravante de que, al estar las dos últimas APIs en estrecha relación (FindNextFileA sólo se puede llamar tras haber empleado con anterioridad a su "hermana", FindFirstFileA, y para el correcto funcionamiento de la primera es preciso especificar un handle -número único con el que el sistema identifica a cada fichero abierto- obtenido con la última), los handlers de cada una de ellas deben llevar a cabo una serie de acciones extra que implican cierta complejidad como para haber escrito un handler único para todas las APIs que engancha Girigat, lo cual habría sido algo así como rizar el rizo, aunque, eso sí, habría dificultado en cierta medida el análisis del virus, debido a lo intrincado de esta hipotética estructura.