Author: bronxi
In 2019, I was a computer science student. That same year, I attended my first Ekoparty after encouragement from a friend when I told him I wanted to be more involved in the world of cybersecurity. I arrived at Ekoparty, not knowing anything about the world of hacking and cybersecurity, but I left with a new network of friends and a better understanding of bug bounty hunting. The concept of bug bounty was totally new to me and I assumed that anyone who reported vulnerabilities were likely famous hackers with highly specialized skills. Surely they only communicate in binary? Three years later, as I started involving myself more in the community, I realized that you don’t need to be highly experienced or speak in binary to start hacking. What you do need is to know at least one vulnerability type really well, specifically how to find it across different environments, and how to write a good report. From there, the rewards will come. That’s the story I want to share with you today.
If you’re a student, someone passionate about cybersecurity, or just someone who wants to gain experience while studying and earn some money, this article is for you.
When it comes to hacking, I find it easier to work backwards. I want to understand what not to do, in order to understand what I should do. When I started in bug bounty, I used to do reconnaissance that would take me days. I collected all the subdomains I could, both from open sources and directly probing the targets. Then I fed that into a script that automatically searched for known vulnerabilities. Did I find bugs? Yes, but the same ones other hunters had already found, aka duplicates. What did I learn from this methodology? That it worked. Although sometimes I didn’t understand the vulnerabilities that the script returned, I learned the process. I gained some knowledge and new skills. Was this methodology effective for bug bounty? No, not for earning rewards. There are thousands of people using the same method, so you have a 99% chance of finding a duplicate.
I recommend you focus on a manual-driven approach. You need to really understand a vulnerability in depth and then search for it manually. How does one do this? Practice using PortSwigger labs, HackTheBox, and other platforms. Read every post or article you can find on that vulnerability, such as writeups, public reports from other hunters, and papers. Watch every video you can find on YouTube and—most importantly—take notes on all of it. Keep a log (Obsidian is great for note taking). When you solve a lab on that vulnerability, write down the steps you took. Your notes and experience become the foundation of your bug bounty hunting. Now, combine your practice with hunting on real bug bounty programs.
Go to Bugcrowd, create an account, and pick a program that uses a technology or system that may have that vulnerability. For example, if you’re looking for a web app vulnerability, filter for web apps; if it’s mobile, filter for programs with mobile in scope; if it’s code review, filter for code review programs, and so on. Take the time to pick one, two, or at most three programs and look for that vulnerability in each of them.
While you study with labs, articles, and video tutorials, keep checking the programs. Understand how the vulnerability works and think about how to look for that vulnerability in the context of a real program. Work it through. Dedicate a block of hours, at least on weekends, to practice. When you can’t find answers to your questions, use a security-oriented LLM to ask. For me personally, I think the best place to turn when you have questions is a bug bounty Telegram community in your native language. You’ll find mentors, friends, and collaborators.
To give you a practical and illustrative example, I’ll tell you how I understood, found, reported, and received my first $200 reward on Bugcrowd. It was an HTML Email Injection. If you know HTML, it’ll be straightforward. If not, you just need to understand what HTML tags are and how they render—here’s a resource.
My methodology regarding user inputs consisted of injecting HTML tags both in registration fields and any other field possible. To my surprise, the tags appeared in my profile data—they weren’t rendered. I kept searching and testing every possible action. I noticed it was possible to send invitations to different people to join the team, and I wondered if the emails included my data, which already contained HTML tags.
I had only used the <u> tag to underline my first name and the <i> tag to italicize my last name. To my surprise, when I sent the invitation email, my name appeared underlined and my last name in italics. My name and surname weren’t rendered on the webpage, but they were in the invitation emails! Immediately, I crafted a convincing HTML injection:
<u>Before starting</u> in “First name” and <a href="https://attacker-site.com">Click here</a> in “Last name.”
<u>Before starting</u>
<a href="https://attacker-site.com">Click here</a>
To get to the point that I could quickly see a vulnerability possibility, I had already read many writeups about HTML injection and how to turn them into Cross-Site Scripting. However, I didn’t specifically know I could take this HTML injection and turn it into cross-site scripting with the emails that victims received. The mindset is this: think about how an attacker could trick a victim. In this case, I could control what was rendered in the emails sent by the company to invite other users (victims) to a workspace. So, I could give false instructions and redirect them to a malicious site. HTML Injection is a LOW impact vulnerability, but it’s not hard to find. If you focus, you’ll find plenty.
To get started, you need a Bugcrowd account, some time, willingness to learn, a web browser, and a proxy. That’s it.
You learn by practicing. You’re hacking real organizations in production and gaining real experience. You gain verifiable experience because your profile on the platform is public, and if the program you reported to is public as well, that’s double the exposure for your work. You’ll earn some money while practicing and gaining experience, but think of that as a bonus, not the main goal—it’s a monetary reward as you gain new skills. If you use social media to build your professional profile, share your findings. The best posts focus on how you found a vulnerability, (to the extent you can disclose—sometimes there’s confidential information), not how much you earned. This adds a lot to the community and is more professional.
Happy hunting!
For hackers who want to stay in the know about the Bugcrowd community and get involved, follow us on X, Instagram and sign up!
For security teams who want to work with hackers like bronxi, contact us and we’ll help you set up your first bug bounty program, pen test, or red teaming engagement. Check out our new guide, Get to know the Crowd, to learn about more of the experts who work on our Platform.
En 2019 era estudiante de informática y fui a mi primera Ekoparty, aconsejado por un amigo cuando le conté que quería involucrarme en el mundo de la ciberseguridad. Llegué a esa Eko y no entendía nada. Pero me llevé un montón de cosas. Entre ellas la idea de lo que era Bug Bounty Hunting. Algo totalmente nuevo para mí. Tampoco entendía muy bien de qué se trataba y me imaginaba que todas las personas que reportaban vulnerabilidades en bug bounty eran hackers con habilidades tan especiales que prácticamente podían comunicarse en binario. Tres años después me empecé a meter más en ese mundo y me di cuenta de que para empezar no necesitas ser un hacker sumamente experimentado ni mucho menos hablar en binario. Sí debías conocer, al menos, una vulnerabilidad y muy bien para encontrarla en diferentes compañías, escribir un buen reporte y recibir una recompensa. Esa historia es la que quiero compartir hoy con vos.
Si sos estudiante, te apasiona la ciberseguridad, querés ir adquiriendo experiencia mientras estudias -sin tener un trabajo a tiempo completo- y, por qué no, también ganar algo de dinero, este artículo es para vos.
Siempre es más sencillo darnos cuenta de lo que NO hacer, para entender qué sí hacer. Cuando empecé en bug bounty, hacía un reconocimiento que me llevaba días: recolectaba todos los subdominios que podía, tanto de fuentes abiertas como pegándole directamente a los objetivos. Eso lo pasaba directamente a un script que buscaba vulnerabilidades conocidas de forma automática. ¿Encontraba bugs? Sí, pero los mismos que ya habían encontrado otros hunters y eran duplicados. ¿Qué aprendí de esto? Que esa metodología funcionaba, aunque a veces no entendía las vulns que me devolvía el script. Aprendí a hacerlo y es un conocimiento que todavía me es útil, al que se suman nuevas habilidades. ¿Era efectivo para bug bounty? Para ganar recompensas NO porque había -y aún hay- miles de personas haciendo lo mismo, entonces tenés un 99% de posibilidades de recibir un duplicado -alguien más ya lo reportó y se llevó la recompensa.
Enfocarte en una búsqueda orientada a lo manual. A entender esa vulnerabilidad en profundidad y buscarla manualmente. ¿Cómo hacerlo? Hacé labs de portswigger, HackTheBox y otras plataformas. Leé todas las publicaciones que encuentres sobre esa vulnerabilidad: writeups, reportes públicos de otros hunters, papers. Mirate todos los videos que encuentres en YouTube y, lo más importante, tomá notas sobre todo eso. Llevá tu bitácora -Obsidian es muy bueno para ello. Y cuando resuelvas un lab de esa vuln, escribí los pasos que llevaste a cabo. Son la base de tu búsqueda en bug bounty. Porque mientras hacés esto, también buscá esa vulnerabilidad en programas de Bug Bounty.
Entrá a Bugcrowd, crea un usuario y elegí un programa que use la tecnología o sistema que pueda tener esa vuln. Si buscas una vuln de web app, filtrá por web app, si buscás una vuln mobile filtrá por programas que tengan mobile en scope, si buscás code review filtrá por code review y así. Tomate un tiempo para elegir uno, dos o a lo sumo tres programas para tu lista y buscá esa vuln en cada uno de ellos.
Mientras estudiás, revisá ese programa. Entendé cómo funciona y pensá cómo deberías buscar esa vulnerabilidad en ese contexto. Dale vueltas. Tené un bloque de horas, al menos el fin de semana, donde hagas esto. Cuando no encuentres respuesta a tus dudas, usá algún LLM especializado en seguridad ofensiva para preguntarle, pero lo mejor es entrar en un grupo de Telegram de la comunidad de bug bounty que hable en tu lengua nativa y preguntar ahí. Vas a encontrar mentores, amigos y aliados para hacer collab.
Para dar un ejemplo práctico e ilustrativo, les voy a contar cómo entendí, busqué, reporté y recibí mi primer recompensa de 200USD en Bugcrowd. Fue un HTML email Injection. Si sabés de html, va a ser algo sencillo para vos. Sinó solo tenés que entender qué son los tags html y cómo se renderizan, aquí te dejo un recurso AQUÍ.
https://www.w3schools.com/tags/tag_html.asp
Mi metodología respecto a los inputs de usuario consistía en inyectar etiquetas HTML tanto en los campos de registro como en cualquier otro campo donde fuera posible. Para mi sorpresa, las etiquetas se mostraban en los datos de mi perfil, no se renderizaban. Seguí buscando y probando cada acción posible. Noté que era posible enviar invitaciones a distintas personas para unirse al equipo y me pregunté si los correos incluían mis datos, que ya contenían etiquetas HTML.
Solo había usado la etiqueta <u> para subrayar mi nombre y la etiqueta <i> para poner en cursiva mi apellido. Para mi sorpresa, cuando envié el correo de invitación, mi nombre aparecía subrayado y mi apellido en cursiva. ¡Mi nombre y apellido no se renderizaban en la página web, pero sí en los correos de invitación! Inmediatamente, forjé una inyección HTML convincente:
<u>Before starting</u> en “First name” y <a href="https://attacker-site.com">Click here</a> en “Last name”.
Para llegar a esto, ya había leído muchas writeups sobre HTML injection y cómo convertirlos en Cross Site Scripting. Pero específicamente no sabía que lo podía hacer en los emails que recibía una víctima. El mindset es el siguiente: pensá cómo podría un atacante engañar a una víctima. En este caso podía controlar lo que se renderizaba en los emails enviados por la compañía para invitar a otros usuarios (víctimas) a un espacio de trabajo. Entonces podía dar indicaciones falsas y llevarlos a una web maliciosa. El html injection es una vulnerabilidad LOW, pero no es difícil de encontrar y si te concentrás en ella vas a encontrar muchísimas.
En resumen, ¿qué necesitás? Un usuario en Bugcrowd, algo de tiempo, ganas de aprender, un navegador web y un proxy.
Aprendés en la práctica porque estás hackeando organizaciones reales en producción. Ganas experiencia comprobable porque tu perfil en la plataforma es público y si el programa en que reportaste también es público va a aparecer en tu perfil. Mientras hacés esto podés ganar algunos dólares, pero pensalo cómo beneficio extra, que el dinero no sea un objetivo sinó una recompensa mientras adquirís nuevas habilidades. Si usás redes sociales para ir dando visibilidad a tu perfil profesional, publicá tus hallazgos: lo mejor es contar qué encontraste, en medida de lo que se pueda contar, a veces hay info confidencial. Contar qué encontraste y cómo aporta mucho a la comunidad y es más profesional para tu perfil que solo decir el monto de lo que te pagaron.