Security Researchers: Digital Fighters Series
A Security: “An attack against closed commercial software used to take a government, a team of experts, and months of work”
Alex Mor, Security Research Manager at A Security, explores the impact of AI and autonomous agents on cyber threats, as part of CTech’s Security Researchers series.
“Building an attack like that against closed commercial software used to take a government, a team of experts, and months of work,” says Alex Mor, Security Research Manager at A Security, describing a zero-day flaw his team uncovered in Zoom. “This took one researcher one day, using AI models anyone can pay for.”
Within Israel’s cyber companies are small, highly specialized teams trained to think like attackers, find vulnerabilities and stay ahead of a threat landscape increasingly accelerated by AI. In this series, we meet the individuals and teams who make up this frontline of cyber: the digital fighters.
Mor started hacking at 16, later serving in the IDF, pursuing a Bachelor's degree in physics, and spending nearly eight years at EY Hacktics followed by six years building security testing at AB InBev. Today, he leads a 10-person research team at cyber startup A Security. “We operate more like a small squad than a group of specialists, even though everyone has areas they know particularly well,” he explains
You can read the entire interview below.
ID Card
Company name: A Security
Founders: Yossi Torati, Yuval Itzchakov, Omer Gull
Year of founding: 2025
Current number of employees: 66
Company Description:
A Security is building an autonomous offensive security platform. It continuously maps environments, discovers vulnerabilities, chains them into real-world attack paths, validates what can actually be exploited, and helps close it before a real attacker gets there.
About A Security’s Security Research Team:
The research team has 10 people. We operate more like a small squad than a group of specialists, even though everyone has areas they know particularly well.
Each researcher owns one or more areas from start to finish: understanding the technique, writing the spec, reviewing relevant docs and past decisions, testing against hard and intentionally misleading environments, trying it on real targets, and working with engineering to make sure the implementation does what we intended. But ownership isn’t solo work. In any given week you’re as likely to be validating someone else’s project as driving your own.
Spreading the work around matters because we don’t want knowledge trapped in one person’s head.
What is your background in cyber, and what led you to specialize in security research?
I started hacking when I was 16. I learned mostly through CTFs and by probing systems on my own. When I found vulnerabilities, I reported them to the companies, and back then my reward was usually a “premium” account on their platform. That was enough to keep me going.
After that I served in the infantry and then did my Bachelor’s degree in Physics. When I was looking for my first job, I came across an opening at EY for penetration testers. EY had acquired Hacktics, an Israeli company with a pretty legendary team of hackers, and I remember thinking: why does an accounting firm need a team of elite hackers? I joined, and that became the start of my professional career in cybersecurity.
I stayed almost eight years. The first couple I spent testing: hundreds of assessments across web, thick-client, mainframe, VDI and internal networks, for major banks, insurers, telecoms and hospitals. Then I started leading teams, and the work shifted from finding bugs to running full red team simulations, from reconnaissance through phishing to the trophy hunt. Later, working under EY Hacktics’ CTO, I was responsible for our playbook, the tactics, techniques and procedures the team followed on every engagement, as well as building our tooling and training the new generation of hackers.
I left as Senior Manager, running our software security services and working as product security architect for EY’s clients. Then six years at AB InBev, the world’s largest brewer, where I got another version of the same question: why does a beer company need a cybersecurity team? I built the security testing capability from scratch and scaled it across hundreds of applications and thousands of developers.
Joining A Security brought me back to where I started. And in a strange way it brought me back to that playbook work, too. I spend my days trying to make an operator’s instinct explicit enough to be repeated. The difference is that this time the operator is an agent, and it will do exactly what I wrote down, including the parts I got wrong.
What does your security research team look like in action?
Research is planned in cycles, and each cycle usually falls into three buckets: teaching the agent a new skill, sharpening one it already has, and building a new capability with a proof of concept attached.
Two things drive what we work on: what the platform missed on a real engagement, and where our benchmarks say we’re weak.
The teaching itself is the interesting part, and it’s harder than it sounds. You can’t tell an agent to be thorough. You have to decide what thorough means: what evidence is enough, what to try when the obvious thing fails, when a result is worth doubting, when to stop. Every one of those is a judgment a good pentester makes without noticing.
This is also where we’ve learned that agents aren’t perfect. They can find things that would take a human researcher significant time to discover, but they also fabricate findings, lose context as the story unfolds, and sometimes pursue the wrong hypothesis for too long. When an agent fails, we want to understand why. Then we turn that lesson into the next research cycle.
What I’d tell someone considering this work: the loop is short. You figure something out on a Tuesday, and within a couple of weeks the agent is doing it against real environments, on every engagement, forever.
How does the research team influence your company at large?
Research gives us a lot of our product direction. When researchers work on real targets, review what happened in a customer’s environment, or investigate a new vulnerability class, they get a direct view of where the platform works and where it still falls short. That feeds into what the agent needs to understand better, which checks are missing, where the workflow is too shallow, and what infrastructure we need to improve. Something we learn from a real target or a failed run can become a benchmark, prompt or product requirement, and eventually code.
A big part of the job is taking things a good human researcher does almost instinctively and making them explicit enough for an agent to repeat. What evidence should it collect? When should it question its own result?
Day-to-day, researchers are involved in project and design reviews, reviewing agent runs against customer environments, content review, and prompt engineering. We look at where the agent succeeded, where it hallucinated, where it gave up too early, where it missed the real issue, and where we simply didn’t give it the right tools or context.
What has been your team’s most significant security discovery to date?
The highest-impact finding was in Zoom. We found a way for anyone sitting in a meeting to take over anyone else’s computer in that meeting. The victim doesn’t click anything, doesn’t download anything, doesn’t see anything. They just have to be on the call. It worked on Windows, Mac, iPhone and Android, because all those apps are built from the same code.
The bug itself is simple. Zoom’s annotation feature, the one that lets you draw on a shared screen, believed whatever another person on the call told it about how much data they were sending. Send more than it expects and you can take over their machine. We reported it privately, and Zoom shipped a fix before we published.
But the bug isn’t really the story. The story is that this took one researcher one day, using AI models anyone can pay for. Building an attack like that against closed commercial software used to take a government, a team of experts, and months of work.
Who or what is your 'Moby Dick'?
A single finding, on its own, is rarely the interesting part. If I get code execution on an isolated machine and there’s nowhere useful to go from there, it doesn’t mean much.
What I really want is a rabbit hole.
You find a way to escalate privileges. You start looking around and find a misconfiguration. That exposes a secret. From there, you get into a production database and find unencrypted PII. None of the individual findings has to be spectacular. What matters is that they connect.
So my Moby Dick isn’t a target. It’s a behavior. I want an agent that chains the way a person does.
That turns out to be one of the hardest things to teach. A good pentester finds something and immediately asks, “OK, what can I do with this?” Agents are less reliable at this. They’ll find a vulnerability, write it up, and stop.
So most of our work isn’t really about finding vulnerabilities. It’s about teaching the agent to see what a finding gives it, and to judge whether that’s worth chasing.
How would you characterize the competition between research teams today?
The local security community is strong. There are many good researchers in offensive security companies, boutique firms, and startups. It’s a small community too, so people know each other and ideas spread fast. That keeps us honest.
Globally, the field is still young. Plenty of capable teams are experimenting with autonomous offensive security, but nobody has settled on a formula yet. Different companies are taking different approaches and learning from what works outside of controlled demonstrations.
AI changes the nature of the competition. Finding a new bug class is only the first step. The harder part is teaching an agent to recognize it, investigate it, test whether it’s exploitable, and reach a decision you can trust.
What is your take on the future of the human security researcher?
I don’t think human researchers are going away. I think the job will change. Researchers will spend less time running every test by hand and more time managing and evaluating agents. That pulls in a few different skills.
Firstly, teaching. You take something you know how to do and describe it clearly enough that an agent can repeat it on a target it has never seen. Then, evaluation. You have to know how well your agents perform and where they fall apart, and be specific about it. Finally, a judgment. Business logic, trust boundaries, the way small issues combine into a real attack: that still takes experience. So does spotting an agent that’s confidently wrong.
The best researchers will use AI to cover far more ground, and spend their own time on the questions that need creativity and context.
