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/ What's the origin story?
I don’t really use a handle. I go by my full name and ask people to call me Jennie, so no one has to break their tongue or fingers trying to pronounce or type it. By the time handles were considered common and the "norm", I was already known in the community by my real name, so there was no reason to invent one. Besides, my last name is so unique that if you Google it, you’ll only find me, so it already does the job of standing out better than any handle could.
What got you into cybersecurity? How did you get into pentesting specifically?
When I studied mathematics at university, one of the applied math tracks was information security - mostly cryptography and encoding. What really hooked me was how abstract mathematical concepts could be used to protect data in a practical way. That combination made the choice easy, and I never looked back.
Around the same time, I was also curious about hacking, but early on, I ran into a couple of ethical hacking forums that said, “You must start with assembly, and you cannot be a good hacker without it." So I tried it. I bought a couple of assembly books, wrote multi-line programs just to print “Hello, world” using syscalls, and ended up confused about how any of that related to hacking. At that point, I decided it probably was not for me.
Several years later, while working at an IT security consulting company, integrating security solutions, I discovered that penetration testing services existed. That completely changed my perspective. I realized that pentesting spans many layers and disciplines, has strong community knowledge, and allows you to start from different backgrounds as long as you keep learning. I spent the next few years writing pentest reports, doing labs, and managing an analytics department for security assessment services, before eventually transitioning into fully hands-on pentesting as an expert.
What exploit or clever attack are you most proud of and why?
I have reported vulnerabilities that required deeper research and stronger technical skills, but I really like the following simpler one: partly because it was a bit funny, and partly because of its impact.
During an internal penetration test, I found credentials for a database. I logged in and pulled a small set of records containing encrypted passwords from a custom application's table just to grab a clean PoC screenshot. I was going to come back to it later while enumerating other systems. Shortly after that, we lost connectivity to the customer’s internal network and had to wait for it to be restored. With nothing to do online, I started looking more closely at the data I already had. I noticed that several encrypted passwords looked suspiciously similar. Long story short, when the connection came back, I was able to recover any plaintext user password from that database, since the application simply XORed passwords with the same static key.
To make matters worse, that database turned out to be used by their in-house SSO system. Once cracked, it effectively gave us access to almost everything in the internal network. It was a great example of how a seemingly small cryptographic mistake can completely undermine a large environment.
What is your go-to brag when talking about your pentesting skills?
I’m not big on bragging, but if I had to pick one thing, it would be how comfortable I am working in large, complex environments. Before moving into hands-on pentesting, I spent a lot of time learning how enterprise networks are built and protected, and reviewed a large number of pentest reports from my colleagues. At the same time, I became very familiar with rules of engagement and with why certain attack paths should be avoided or handled with extra care in production environments.
Because of that background, I know how to approach complex systems methodically: how to move through them, choose realistic and responsible attack paths, and still achieve meaningful business-specific impact without putting critical assets at unnecessary risk.
Share a time something went wrong in the course of a pentest? What happened and what did you do?
During a complex internal penetration test that I was leading, one of the client’s web applications stopped working. We had not performed any risky actions against it, but I informed the client and we moved on to other parts of the assessment.
Shortly after, the client asked whether we had attempted a privilege escalation exploit on one of the servers used by that application. That immediately raised red flags for me: exploits of that kind were explicitly forbidden under the rules of engagement due to the risk of DoS, and we already had privileged access to that server by that time, so there would have been no reason to run such an exploit in the first place. I paused all pentesting activity, verified with the team that no such action had been taken, communicated that to the client, and provided initial guidance on how to proceed with incident response.
A couple of hours later, the customer said that we could continue pentesting. When I asked about the incident, they said the following. The application developer, who did not have root access to the server, had accidentally crashed their own service, and out of fear of admitting the mistake, attempted a local privilege escalation exploit in hopes of quietly restoring the application.
That situation reinforced for me how important clear rules of engagement, strong logging, and a responsive team are, especially when something goes wrong, and assumptions can be made quickly.
What are your favorite tools or TTPs when conducting pentests? Why do you find them effective?
There are a lot of great tools tailored each for their own purpose, so it’s hard to compare or pick favorites, but in terms of impact per tool, a few consistently stand out for me. For web applications, I rely heavily on Burp Suite, and for Active Directory assessments, Impacket and BloodHound are hard to beat.
What makes these tools especially effective is how flexible they are and how well they support real-world attack paths. I also put a lot of value on customizing tools rather than using them strictly out of the box. Sometimes, to bypass EDR, you don’t need to dig deeply into system internals. A small, targeted modification to ready tools like Impacket or NanoDump could be enough to evade detection while keeping the approach simple and reliable.
That combination of solid tooling and lightweight customization lets me stay effective without introducing unnecessary risk or complexity.
What are your favorite asset types (web applications, APIs, network, etc.) to pentest and why?
My favorite area to pentest is the entire network infrastructure, mainly because it brings together a bit of everything. You’re dealing with multiple layers at once: web, operating systems, directory services, network devices, legacy systems, and modern platforms, all integrated into a single environment. I really enjoy that variety; it makes the work both challenging and rewarding, and it’s where I feel most engaged and effective.
What certifications do you have? Why did you go for those specifically?
I hold OSCP, OSCE, OSEP, and OSWE, as well as CISSP and CISA. I earned CISSP and CISA earlier in my career because they were relevant for the consulting company I was working with at the time, but they also turned out to be valuable for me personally as a solid basis. They gave me a structured, high-level understanding of the broader information security landscape, including governance, risk, and processes.
On the technical side, most of my certifications come from Offensive Security. I’m a big fan of their courses and exams, not just because they’re well respected in the industry, but because they’re deeply technical, hands-on, and force you to develop real problem-solving skills. Their “Try Harder” mindset strongly resonates with me, and it’s something I actively apply in practice during every engagement.
What advice do you wish someone had given you when you first started pentesting?
Don’t feel like you have to start with assembly if it does not click for you, ha-ha!
Beyond that, my advice for anyone starting is to enjoy the learning journey and always think about the real, business-specific impact behind a technical vulnerability. Also, be cautious when running attacks in production, as they’re very different from a lab. Ask yourself: What can happen if I try that "' OR '1'='1" SQL Injection here? Or if I attempt ARP spoofing of an entire subnet from my laptop?
And finally, if you have more experienced people around, don’t hesitate to ask questions. Learning from others can save a lot of time and prevent unnecessary mistakes.
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 adapt my communication to the audience. When working with Cobalt, for example, there’s ongoing communication with the client throughout the engagement via the pentest chat, which makes it easy to gauge whether they prefer high-level explanations or deeper technical detail. Regardless, my reports are always structured to include both clear, executive-friendly summaries as well as detailed technical findings.
More generally, I focus on setting expectations early. I take time to understand the client’s business context and goals, clearly communicate any access issues or testing limitations, and discuss potentially risky checks in advance. That way, there are no surprises, and the client feels informed and involved throughout the process.
This approach helps ensure not just accurate findings, but a smooth, transparent, and high-quality experience for the customer.
Why do you like pentesting with Cobalt?
I enjoy pentesting with Cobalt for both personal and professional reasons. On a personal level, as a mom of two young kids, I really appreciate the flexibility that the Cobalt model provides. It allows me to balance work and family throughout the day.
Professionally, I love the variety of environments and teams I get to work with. One day it might be an internal pentest for a large enterprise in a team of three, and another day it could be a solo web application security assessment of an AWS Cognito application, or something entirely different. That variety keeps the work engaging and constantly challenges me to learn new things.
How do you see pentesting changing in 2026 and over the next few years?
AI is reshaping nearly every area of IT, and penetration testing is no exception. On the positive side, it’s incredible: tasks that used to take hours can now be completed in minutes, and I use AI myself to streamline certain parts of assessments.
At the same time, I’m cautious about over-reliance. I have seen examples where developers or system owners treated complex systems as “magical black boxes,” assuming built-in security is enough and neglecting basic measures like network segmentation or access control. The usability of AI can also tempt people to give it broad access without fully considering security implications.
I think the future of pentesting will involve combining AI’s efficiency with human judgment: leveraging AI to speed up analysis and discovery, but always applying critical thinking, understanding the context, and carefully evaluating the real-world security impact.
