Entrevista con el Desarrollador de Threat Bounty – PHYO PAING HTUN
Hoy, queremos presentar a la comunidad de SOC Prime a un miembro talentoso y dedicado del Programa Threat Bounty y autor de contenido de detección – Phyo Paing Htun, quien ha estado publicando detecciones en la plataforma SOC Prime desde diciembre de 2022.
- Cuéntanos sobre ti y por qué decidiste convertirte en un especialista en ciberseguridad.
Mi nombre es Phyo Paing Htun, y puedes llamarme Chi Lai. Nací en Myanmar y tengo ciudadanía birmana. Pero en estos días, me mudé a la ciudad de Bangkok, Tailandia, y actualmente estoy trabajando en Bangkok. Mi posición actual es Respondedor de Incidentes de Ciberseguridad L2 en uno de los proveedores de servicios de seguridad gestionada en Tailandia. Mi responsabilidad es responder a cada incidente y cada amenaza que es escalada por los analistas de SOC, así como investigar los comportamientos de ataque CVE. El punto principal de enfoque es cómo entender y mitigar potenciales comportamientos de ataque utilizando la Gestión de Información y Eventos de Seguridad (SIEM).
- ¿Cuáles son tus estudios y certificaciones profesionales, y cómo te desarrollaste profesionalmente?
Ya obtuve el BlueTeam Level 1 (BTL1) por el equipo Security Blue Team y también aprobé el examen de Threat Hunting Professional por INE Security en 2023.
- ¿Cómo te enteraste del Programa Threat Bounty? ¿Por qué decidiste unirte?
Me enteré por mis amigos mayores (Ko Kyaw Pyiyt Htet, Ko Zaw Min Htun, y Ko Aung Kyaw Min Naing) de Myanmar, quienes también son miembros del Programa. Contribuyeron con reglas Sigma a SOC Prime, y me apoyaron en cómo escribir una regla Sigma, cómo buscar noticias de ciberseguridad, y otras cosas por el estilo. Además, me gustaría escribir consultas de detección de amenazas en Splunk SPL, consultas de Kibana, KQL, etc., pero es difícil aprender y entender todos los lenguajes en detalle. Así que, he elegido el lenguaje Sigma para aprenderlo más a fondo. Sigma se puede convertir en cualquier regla SIEM o EDR con uncoder.io.
- ¿Te resulta difícil ahora escribir una regla?
Tengo experiencia como Desarrollador de Software y estoy familiarizado con múltiples lenguajes de consulta como YAML. No me resulta difícil ahora. Comencé a aprender a partir del artículo Regla Sigma para Principiantes por Adam Swan. Me dio un entendimiento de lo básico, como cómo escribir una condición, cómo identificar fuentes de registros, qué tipos de fuente de registro puede soportar Sigma, etc.
- Y cuando escribes reglas para Threat Bounty, ¿cuánto tiempo te lleva desde la idea hasta el momento de publicación?
Creo que probablemente tomará hasta dos horas. A partir de informes de amenazas, necesito entender qué tipo de tácticas y técnicas puedo escribir para propósitos de detección. Debo encontrar los artefactos críticos, leer el informe, y entenderlo claramente. Después de eso, escribo la regla Sigma.
- ¿Puedes describir tu proceso de creación de reglas usando el ejemplo de una de tus reglas publicadas recientemente? Desde la investigación hasta la publicación, incluido el proceso de revisión?
Esta es mi última regla hasta ahora – “Posibles Actividades de Evasión de Defensa del RAT BlotchyQuasar [también conocido como Troyano Bancario de Hive0129] Detectadas Por Valores de Registro Modificados. (vía Evento_Registro)”. Decidí escribir sobre la actividad de evasión de defensa. Comencé leyendo el informe. Este informe trata sobre el malware BlotchyQuasar, y la actividad ya está asociada con el grupo APT Hive0129. El informe me dio varias ideas para escribir la cadena de detección, como detección para acceso inicial, evasión de defensa, comunicación C2, y otros.
Elegí la técnica de evasión de defensa para el proceso de cambio de valor del registro, basado en una de las partes del informe. Pero antes de escribir la regla, necesito buscar la regla existente en la plataforma SOC Prime utilizando la búsqueda Lucene. Primero, necesito asegurarme de no escribir una regla duplicada. Como mi búsqueda con Lucene devolvió varias reglas para “TamperProtection”, decidí elegir otra y crear una regla.
Al principio, mi regla fue rechazada porque los detalles de las partes de valor estaban equivocados. Pero rápidamente hice los cambios necesarios, y la regla fue publicada.
Utilizo IBM X-Force Exchange Osint Advisory para buscar nuevos informes de amenazas.
- ¿Cuál es la razón más frecuente por la que personalmente recibes el rechazo de contenido?
Probablemente sea “reglas de baja resiliencia” porque a veces los informes tienen IOCs de comportamiento, y si escribo una regla basada en ellos, será rechazada. Necesitamos crear reglas de detección robustas para que sean aceptadas.
- Siendo parte de una gran comunidad profesional, ¿qué crees que es el mayor valor de las reglas que publicas en la Plataforma?
Cuando las organizaciones se refieren a SOC Prime para contenido de detección, pueden estar seguros de que las reglas de detección no son solo “cualquier” regla, o reglas de IOC, o reglas de comportamiento-IOC. Para las organizaciones, es muy importante tener detecciones robustas, como reglas de detección genéricas.
- ¿Cuál es tu recomendación para los nuevos miembros del programa Threat Bounty, nuevos desarrolladores de contenido que acaban de empezar su camino con el programa?
Definitivamente recomendaría a todos los nuevos miembros que verifiquen el plataforma SOC Prime para el contenido existente. Además, por favor, no escriban reglas de IOC de bajo nivel. Estas reglas no son eficientes después de un corto tiempo. También, SigmaHQ puede ser un buen recurso para aprender algunas bases generales sobre cómo crear una regla Sigma.
- ¿Cuál es tu motivación para participar en el Programa después de recibir muchas rechazos de publicación de contenido?
Si recibo demasiados mensajes de rechazo, generalmente voy a preguntar en el canal de Discord para el programa Threat Bounty. Por ejemplo, no podía entender por qué seguían rechazando mi regla, diciendo que era de baja resiliencia. En el canal de Discord, le pedí al equipo que me lo explicara. Todo se volvió muy claro para mí, y solo tuve que rehacer la regla. Envié la regla para revisión, ¡y fue rechazada de nuevo! ¡Fue un momento realmente difícil para mí, pero me tomé un tiempo para analizar la regla, hice algunos cambios de nuevo, y después de la revisión, mi regla finalmente fue publicada. Es muy útil cuando el equipo de verificación proporciona algunos detalles en casos en los que una regla puede ser modificada para mejorar su rendimiento.
- ¿Te parece útil cuando respondemos a otros autores en Discord? Por ejemplo, cuando otros autores tienen preguntas sobre por qué sus reglas son rechazadas.
Eso es muy útil para mí. En particular, aprendí por qué las reglas son rechazadas a partir de las conversaciones en Discord. Además, esas conversaciones me dieron un entendimiento de qué tipo de error (baja resiliencia) necesito evitar y qué tipo de reglas de detección robustas puedo crear.
- Mencionaste que comenzaste a participar en el Programa Threat Bounty con la ayuda de tus amigos, quienes primero comenzaron a publicar reglas. Es un gran ejemplo de una comunidad profesional local que apoya a los nuevos miembros en el crecimiento de su potencial de defensa cibernética. ¿Cómo conociste a los chicos? ¿Hay competencia entre ustedes?
Usábamos Discord y otros canales para charlar sobre ideas de detección de amenazas que eran interesantes para nosotros. Nosotros (Comunidad Birmana de Desarrolladores de Detección de Amenazas) no tenemos competencia dentro del grupo, nos ayudamos y apoyamos mutuamente, y eso es lo que ayuda a cada uno de nosotros a crecer.
¡Gracias por tu tiempo y una conversación tan perspicaz! ¡Deseamos a Phyo Paing Htun éxito con sus futuras publicaciones de contenido!
¿Quieres unirte al Programa Threat Bounty de SOC Prime? ¡No dudes en solicitar la participación ahora!