The Cobalt Pentester Spotlight highlights the fascinating journey of our Core members. Through an interview style, we share their experiences, background, and insights into the world of an accomplished pentester.
What's your handle? Do you use more than one? Where did it come from?
My handle is monr4. It partly comes from writing my name backwards. Still, by coincidence, it also ended up sounding (in Spanish) similar to a character I really liked as a kid, Mumm-Ra from Thundercats. It was more of a series of coincidences that just clicked.
What got you into cybersecurity? How did you get into pentesting specifically?
I’ve always been interested in security, but at the time, it was very difficult to find pentesting-related jobs. After graduating, I started a security diploma program and focused heavily on Linux.
Because there were very few job opportunities in security back then, I ended up working 100% with Linux and Unix for several years, specializing in system hardening and secure operations in production environments.
Over time, I decided to take the leap and pursue security-focused certifications to explore opportunities in the field. I was fortunate enough to meet a pentester who shared a job opening at a consultancy, where I was allowed to enter the world of pentesting, an opportunity I’m still grateful for today.
Since then, I’ve been able to perform pentesting on a continuous basis across many interesting projects, working with a wide range of technologies that not everyone gets access to, which has been key to my professional growth.
What exploit or clever attack are you most proud of and why?
There are several attacks I’m proud of, but one in particular involved performing a bypass of security controls during the remote onboarding of payment devices.
The main challenge was understanding a highly restricted system designed to operate in a tightly controlled environment. The process required gaining access to the communication channel used by the devices, capturing and deeply analyzing the exchanged frames, identifying weaknesses in the protocol design, and then manipulating specific fields during the device installation process.
More than the attack itself, what I value most about this case was the journey—from having little knowledge of the system’s architecture and workflows to understanding it well enough to identify a real weakness and demonstrate impact in a controlled manner.
What is your go-to brag when talking about your pentesting skills?
I worked on a very interesting project involving payment devices. At the time, I didn’t have deep knowledge of how they worked—their architecture or the protocols used to communicate and process payments.
I had to do a lot of reading, analyze communication frames, and identify behavioral patterns in the systems. Through that process, I was able to identify critical vulnerabilities, which led me to specialize in payment systems during that period of my career. As for the vulnerability itself, I can’t share details.
Share a time something went wrong in the course of a pentest? What happened and what did you do?
It was the first banking web application I ever tested. It belonged to a small bank, and the application was not transactional but rather informational. However, the website’s content management system was developed in-house, which meant it had many weaknesses.
I found an authentication bypass that allowed me to make changes directly to the website, and during testing, I ended up modifying a large portion of the site—it came very close to becoming a full defacement. Fortunately, I still had the original content cached in my browser, which allowed me to restore the website without any issues.
Since then, I’ve been extremely careful when validating impact and performing tests that could directly affect production environments. It was an important lesson that shaped how I approach pentesting.
What are your favorite tools or TTPs when conducting pentests? Why do you find them effective?
It really depends on the type of pentest, but in general, my favorite TTPs are more about really understanding the system than breaking things quickly.
For web, I like intercepting flows, playing with business logic, and testing authorization controls slowly, watching how the application responds, and looking for inconsistencies. A lot of the time, the real issues are not obvious bugs but how different pieces fit together.
For internal pentesting, especially in Windows domain-based environments, I really enjoy the enumeration phase, understanding the domain, seeing how identities and permissions relate to each other, and then chaining small weaknesses into something with real impact.
Tools definitely help, but for me, the mindset and the process behind each test matter the most.
What are your favorite asset types (web applications, APIs, network, etc.) to pentest and why?
First and foremost, my favorite type of work is internal pentesting. Having worked as a sysadmin for many years, it’s an environment where I feel very comfortable and where I really enjoy understanding how systems work from the inside.
Second would be web pentesting, which I enjoy a lot because of the variety of scenarios and the constant challenge of analyzing application logic, flows, and security controls.
What certifications do you have? Why did you go for those specifically?
I have several certifications, and I’ve never seen them as something to collect, but rather as a way to structure and validate knowledge I was already using in real work. Certifications like OSCP, OSCE, CPTE, and OPST helped me strengthen my pentesting mindset and methodology, beyond just the technical side.
I also have a strong Linux and systems background with certifications like LPIC-1, RHCSA, RHCE, and SUSE CLA. Even though they’re expired, I have a special appreciation for them since they come from my sysadmin years and shaped how I approach internal pentests. Over the last couple of years, I haven’t pursued new certifications due to time constraints, but this year I’m planning to get back on track and pursue more security certifications as personal challenges.
What advice do you wish someone had given you when you first started pentesting?
I wish someone had told me to practice Python more and to code a lot earlier. It makes a huge difference in the long run and gives you much more freedom when it comes to analyzing, automating, and validating findings.
How do you approach explaining findings to customers during a pentest? Is there a way you discuss your findings with customers? How do you ensure they have a quality experience?
I always try to explain findings in a simple way, focusing first on the business impact. My goal is to translate the technical details so they can be understood in the most clear and executive-friendly way possible.
If the customer is more technical, I go much deeper and explain how things work, the attack vector, and the technical implications. For me, adapting to the audience is key to making sure the customer has a good experience and really understands the value of the pentest.
What is your favorite part of working with a pentesting team? What about working on your own?
Definitely, what I enjoy the most about working in a team is learning from others. I’ve had the chance to work alongside excellent pentesters who are very creative and sharp, and I’ve learned a lot from them. Sharing different approaches and seeing how others think about problems adds a huge amount of value.
Why do you like pentesting with Cobalt?
Honestly, there are many reasons. The first one is the ability to work from anywhere, which I really value. I also really enjoy the opportunity to collaborate and learn from other highly skilled pentesters, as well as the overall work dynamic, which makes projects both interesting and well-organized.
Would you recommend Cobalt to someone looking for a pentest? Why or why not?
Definitely yes. Because of the organization, the quality of the pentesters, and how the whole process is designed. Cobalt connects customers with highly skilled professionals and makes engagements run smoothly from start to finish, which is noticeable both for clients and for pentesters.
What do customers or the media often misunderstand about pentesters?
I think one of the biggest misunderstandings is the idea that a pentest is just running an automated tool. For a long time, many customers have associated pentesting with scanning and reporting, partly due to how some commercial solutions have been marketed.
In reality, a good pentest goes much further. It’s about understanding context, architecture, and the business itself, and having a human actively analyze the system with judgment and creativity. It’s also true that some negative past experiences with poorly structured tests have contributed to that perception. In the end, it’s a cultural shift: showing that pentesting isn’t something negative, but a collaborative effort to identify real risks that automated tools simply won’t catch.
How do you see pentesting changing in 2026 and over the next few years?
I believe pentesting will become less about automation and much more context-driven, even with all the AI integration we’re seeing today. AI is already very good at enumeration, pattern matching, and finding known vulnerabilities at scale, which will raise the baseline across the industry. However, its real value will be in reducing noise and accelerating analysis, not in replacing human judgment.
Professional pentesting will increasingly focus on design flaws, logic issues, and misconfigurations, and on understanding entire systems rather than isolated vulnerabilities. At the same time, AI is changing how applications are built, which introduces new attack surfaces around models, integrations, and automated workflows. In that context, the pentester’s role evolves into making judgment calls under real-world constraints, knowing how far to go without breaking things, and clearly explaining risk and impact. AI removes repetitive work, but the real differentiator will remain critical thinking, creativity, and the ability to build trust.
What’s one non-technical skill (e.g., writing, communication, project management) that you believe is becoming critically important for a successful pentester, and how do you cultivate it?
Without a doubt, communication. Knowing how to talk to customers, how to translate a technical vulnerability into something that makes sense from a business perspective, and how to explain risk without creating unnecessary fear is critical. A strong finding loses value if it’s not communicated properly.
It’s a skill I’m always working to improve. Sometimes it goes better, sometimes not so much, but it’s something I consistently work on. Listening to the customer and adapting the message depending on whether you’re speaking to technical or business stakeholders makes a big difference.
What's your p(Doom)?
I’d say my p(Doom) is moderate to high, not because of the technology itself, but because of the human factor. There are too many people doing things in the most comfortable or “lazy” way possible, and that shows in the overall quality of how security is implemented and tested.
That said, I don’t think it’s inevitable. When professionals take the work seriously, understand the context, and go beyond the bare minimum, risk drops significantly. The real problem isn’t a lack of tools, but a lack of judgment and commitment.
