Intervista con lo Sviluppatore di Threat Bounty – PHYO PAING HTUN

Oggi vogliamo presentare alla comunità di SOC Prime un membro talentuoso e devoto del Threat Bounty Program e autore di contenuti di rilevamento – Phyo Paing Htun, che ha pubblicato rilevamenti sulla piattaforma SOC Prime dal dicembre 2022.

Regole di Phyo Paing Htun

• Raccontaci di te e del perché hai deciso di diventare uno specialista di cybersecurity.

Mi chiamo Phyo Paing Htun, ma puoi chiamarmi Chi Lai. Sono nato in Myanmar e possiedo la cittadinanza birmana. Tuttavia, attualmente mi sono trasferito nella città di Bangkok, Thailandia, e sto lavorando a Bangkok. La mia posizione attuale è Cybersecurity Incident Responder L2 presso uno dei fornitori di servizi di sicurezza gestita in Thailandia. La mia responsabilità è rispondere a ogni incidente e minaccia escalation da parte degli analisti SOC, oltre a ricercare i comportamenti di attacco CVE. Il punto focale principale è come comprendere e mitigare i potenziali comportamenti di attacco utilizzando la Gestione delle informazioni e degli eventi di sicurezza (SIEM).

• Qual è la tua formazione professionale e quali certificazioni hai ottenuto, e come ti sei sviluppato professionalmente?

Ho già conseguito il BlueTeam Level 1 (BTL1) dalla Security Blue Team e ho anche superato l’esame Threat Hunting Professional presso INE Security nel 2023.

• Come hai saputo del Threat Bounty Program? Perché hai deciso di iscriverti?

L’ho saputo dai miei amici più anziani (Ko Kyaw Pyiyt Htet, Ko Zaw Min Htun, e Ko Aung Kyaw Min Naing) in Myanmar, che sono anche membri del Programma. Hanno contribuito con regole Sigma a SOC Prime e mi hanno supportato su come scrivere una regola Sigma, come cercare notizie di cybersecurity e cose simili. Vorrei anche scrivere query di rilevamento delle minacce in Splunk SPL, query Kibana, KQL, ecc., ma è difficile imparare e capire tutte le lingue nel dettaglio. Quindi, ho scelto il linguaggio Sigma per approfondirlo. Sigma può essere convertito in qualsiasi regola SIEM o EDR con uncoder.io.

• È difficile per te ora scrivere una regola?

Ho un background come Sviluppatore di Software e sono familiare con diversi linguaggi di interrogazione come YAML. Ora non è difficile per me. Ho iniziato a imparare dall’articolo Sigma Rule for Beginners di Adam Swan. Mi ha dato una comprensione delle basi, come scrivere una condizione, come identificare le fonti di log, quali tipi di logsource Sigma può supportare, ecc.

• E quando scrivi regole per il Threat Bounty, quanto tempo ti ci vuole dall’idea al momento della pubblicazione?

Penso che ci vorranno probabilmente fino a due ore. Dai report sulle minacce, devo capire che tipo di tattiche e tecniche posso scrivere a fini di rilevamento. Devo trovare gli artefatti critici, leggere il report e capirlo chiaramente. Dopo di che, scrivo la regola Sigma.

• Puoi descrivere il tuo processo di creazione delle regole usando l’esempio di una delle tue regole recentemente pubblicate? Dalla ricerca alla pubblicazione, incluso il processo di revisione?

Questa è la mia ultima regola per ora – “Attività di elusione della difesa possibili di BlotchyQuasar RAT [alias Trojan bancario di Hive0129] rilevate da valori del registro modificati. (via Registry_Event)”. Ho deciso di scrivere sull’attività di elusione della difesa. Ho iniziato leggendo il report. Questo report riguarda il malware BlotchyQuasar e l’attività è già associata al gruppo APT Hive0129. Il report mi ha dato diverse idee per scrivere la catena di rilevamento, come il rilevamento per accesso iniziale, elusione della difesa, comunicazione C2 e altri.

Ho scelto la tecnica di elusione della difesa per il processo di modifica dei valori del registro, basandomi su una delle parti del report. Ma prima di scrivere la regola, devo cercare la regola esistente sulla piattaforma SOC Prime usando la ricerca Lucene. Prima di tutto, devo assicurarmi di non scrivere una regola duplicata. Dato che la mia ricerca con Lucene ha restituito diverse regole per “TamperProtection”, ho deciso di sceglierne un’altra e creare una regola.

All’inizio, la mia regola è stata rifiutata perché i dettagli delle parti del valore erano sbagliati. Ma ho rapidamente apportato le modifiche necessarie e la regola è stata pubblicata.

Utilizzo IBM X-Force Exchange Osint Advisory per cercare nuovi report sulle minacce.

• Qual è il motivo più frequente di rigetto dei contenuti che ricevi personalmente?

Probabilmente è “regole a bassa resilienza” perché a volte i report contengono IOC comportamentali, e se scrivo una regola basata su di essi, verrà rifiutata. Dobbiamo creare regole di rilevamento robuste per farle accettare.

• Essendo parte di una grande comunità professionale, quale pensi sia il valore più grande delle regole che pubblichi sulla Piattaforma?

Quando le organizzazioni si riferiscono a SOC Prime per i contenuti di rilevamento, possono essere sicure che le regole di rilevamento non sono solo “qualunque” regola, o regole IOC, o regole di comportamento-IOC. Per le organizzazioni, è molto importante avere un rilevamento robusto, come regole di rilevamento generico.

• Qual è la tua raccomandazione per i nuovi membri del programma Threat Bounty, i nuovi sviluppatori di contenuti che hanno appena iniziato il loro percorso con il programma?

Consiglierei sicuramente a tutti i nuovi membri di controllare la piattaforma SOC Prime per i contenuti esistenti. Inoltre, per favore, non scrivete regole di basso livello IOC. Queste regole non sono efficienti dopo un breve periodo. Anche SigmaHQ potrebbe essere una buona risorsa per imparare alcune basi generali su come creare una regola Sigma.

• Qual è la tua motivazione per partecipare al Programma dopo aver ricevuto molte rigetti di pubblicazione di contenuti?

Se ricevo troppi messaggi di rigetto, solitamente chiedo sul canale Discord per il programma Threat Bounty. Ad esempio, non riuscivo a capire perché continuassero a rifiutare la mia regola, dicendo che era a bassa resilienza. Sul canale Discord, ho chiesto al team di spiegarmelo. Tutto è diventato molto chiaro per me, e dovevo solo rifare la regola. Ho inviato la regola per la revisione, e è stata di nuovo rifiutata! È stato un periodo davvero difficile per me, ma ho preso un po’ di tempo per analizzare la regola, ho apportato nuovamente alcune modifiche, e dopo la revisione, la mia regola è stata finalmente pubblicata. È molto utile quando il team di verifica fornisce alcuni dettagli nei casi in cui una regola può essere modificata per avere prestazioni migliori.

• Trovi utile quando rispondiamo ad altri autori su Discord? Ad esempio, quando altri autori hanno domande sui loro rigetti di regole?

Questo è molto utile per me. In particolare, ho imparato perché le regole vengono rifiutate dalle conversazioni su Discord. Inoltre, quelle conversazioni mi hanno dato una comprensione di quale tipo di errore (bassa resilienza) devo evitare e quale tipo di regole di rilevamento robuste posso creare.

• Hai menzionato che hai iniziato a partecipare al Threat Bounty Program con l’aiuto dei tuoi amici, che hanno inizialmente pubblicato regole. È un grande esempio di una comunità professionale locale che supporta i nuovi membri nel far crescere il loro potenziale di difesa informatica. Come hai incontrato i ragazzi? C’è competizione tra voi?

Abbiamo usato Discord e altri canali per chattare sulle idee di rilevamento delle minacce che ci interessavano. Noi (Comunità degli sviluppatori di rilevamento delle minacce del Myanmar) non abbiamo competizione all’interno del gruppo, ci aiutiamo e supportiamo a vicenda, e questo è ciò che ci aiuta a crescere.

Grazie per il tuo tempo e per questa conversazione così perspicace! Auguriamo a Phyo Paing Htun successo con le sue ulteriori pubblicazioni di contenuti!

Vuoi unirti al SOC Prime Threat Bounty Program? Non esitare a fare domanda per partecipare ora!