An attacker steals a set of credentials. In a matter of seconds, and fully automated, they swap them for an access token, enter the cloud environment, enumerate, exfiltrate, and leave persistence behind. When the alert arrives, if it arrives, it's already too late. This isn't a hypothetical scenario: it's what Borja Merino sees, again and again, in the incidents he investigates.
The data backs him up: in 2025, the average time to identify a cloud breach was 219 days [CSA Lab Space]. Added to that is a detail that makes it even more uncomfortable: to the team defending, that activity looks a lot like legitimate access. That's the real problem with identity today: not so much detecting the attack, but telling it apart from normal.
Borja has spent some 16 years in the field, in reverse engineering, malware analysis, and, in recent years, threat hunting, with stops at organizations like ISDEFE, INTECO/INCIBE, Tarlogic, and One eSecurity. Today he leads the Threat Research team at Alpine Security, helping improve his clients' detection and response capabilities.
We asked him to look at identity risk from where he knows it best: from inside the attacker's head. What follows are his answers, unfiltered.
_
8Layers: Tell us a bit about yourself and your career.
Borja: I studied computer engineering at the Universidad Pontificia de Salamanca, where, during my undergraduate years, I worked at the university's own data center, taking part in various cybersecurity projects.
Since then, over roughly 16 years, I've built my career across different companies and organizations, among them ISDEFE, INTECO/INCIBE, Tarlogic, iHackLabs, and One eSecurity, working mainly in reverse engineering, malware analysis, and, in recent years, threat hunting.
I currently work at Alpine Security as head of the Threat Research team, helping improve threat detection and response capabilities for our clients.
8L: At Alpine Security, you "think as they act." In practice, what does thinking like an attacker let you see that a defender who's never been on the other side usually misses?
Borja: Mainly, it lets you connect the dots more quickly during an investigation and answer, more efficiently, the questions we tend to ask ourselves as we dissect the events of an incident. What is the attacker trying to achieve? What was the entry vector? Why did they write a particular file to disk? How and why did they carry out a certain lateral movement? How did they manage to escalate privileges? Why did they inject into this process? Etc.
The value a profile with an offensive background brings to a hunting team is quite distinctive, not only when it comes to forming hypotheses during an incident and contextualizing it based on the events analyzed, as I mentioned, but also for developing efficient proactive queries.
At Alpine we place a lot of value on profiles with solid knowledge not just in forensics or incident response, but also in malware and red teaming, precisely because we know that "adversarial mindset" improves early response.
8L: A good part of your research starts at the endpoint and in memory. At what point in the attack chain does identity (credentials, tokens, sessions) come into play?
Borja: To answer both questions precisely, I first need to unpack the premise.
It's true that in many scenarios the starting point of an investigation is a set of events or alerts, whether proactive or generated by the EDR solution itself, that take place on the endpoint. One of the main tasks, once the malicious activity has been contained (or is believed to have been contained), is to try to build a timeline of every action carried out by the threat actor or the corresponding malware.
This is a key phase in our work, for several reasons. It lets us, for example, identify artifacts or persistence techniques still active (undetected) on the affected endpoint or others. It lets us size and contextualize the incident. Also, it can help us improve our detection capabilities and our dwell time if we're able to create new proactive queries that identify the same threat at an earlier stage.
During the retrospective reconstruction of the timeline, it's essential to reach the initial access used, mainly to know whether the incident is reproducible, but also to know whether the threat is really still present in the organization.
Answering the questions posed, today a significant proportion of the entry vectors we observe is directly related to identity problems, stemming mainly from credential theft via infostealers, phishing attacks, and brute-force techniques. This trend confirms that identity protection remains neglected.
8L: Right, and to monitor identity, what specific challenges does that pose for a threat hunting team?
Borja: Mainly two. First, reaction time. We recurrently come across incidents where, in a matter of seconds, starting from an AiTM (Adversary-in-the-Middle), the attacker swaps credentials for a refresh/access token to access, enumerate, exfiltrate, and add persistence in a cloud environment. All of it automated, using open-source tools that are very easy to operate (see TokenTacticsV2, ROADtools, AADInternals, etc.).
Second, telling legitimate activity apart from malicious activity in the identity domain is quite complex in many scenarios. It takes a lot of effort to build effective use cases. These facts make identity a particularly challenging domain for detection.
8L: You specialize in evasion techniques and memory artifacts. Is there a parallel in the identity world, like ways an attacker stays under the radar using legitimate credentials and access that defenders still don't know how to hunt?
Borja: Calling myself a specialist is saying a lot. That said, it's something I've always enjoyed and dedicate a good deal of time to. There are certainly parallels to be drawn with identity. You only have to watch how offensive tools used for very specific identity-related actions are evolving. We're seeing, more and more often, new techniques emerge that speed up certain processes and bypass conditional policies: use of residential proxies to evade geofencing restrictions, registering new devices to obtain a PRT (Primary Refresh Token) and get around subsequent access restrictions, etc.
We're also seeing more and more sophisticated platforms for abusing OAuth flows, for example, to perform MFA downgrade, FOCI pivoting, etc. A few months ago the FBI warned about Kali365, a PhaaS competitor to EvilTokens that implements OAuth device-code flow abuse and AiTM techniques, and makes the extracted OAuth tokens available to other affiliates.
The proliferation of these increasingly specialized, automated, and accessible kits and platforms is lowering the complexity needed to compromise and access secrets, as well as making hunters' lives harder because of how difficult it is, as I noted earlier, to tell authorized access from malicious activity.
This fact, combined with the proliferation of affiliation models available to both threat actors and individual attackers for buying and selling credentials/sessions/tokens, and the high number of infostealers we've been observing in recent years, has forced threat hunting teams to treat threat intelligence as an essential component (and not a mere auxiliary element) within their operational strategy.
8L: Your recent talks deal with autonomous agents capable of identifying memory artifacts. Looking at the other side of the coin: as AI agents start acting inside organizations, with their own credentials and permissions, they become a new identity to watch. How do you see that new kind of "autonomous identity" from the perspective of someone who studies the attacker?
Borja: It's undoubtedly a new challenge, for the same reasons noted above. In most of our clients we already observe AI agents (Claude agent, OpenClaw, etc.), as well as all kinds of applications and scripts (run via Node, Python, etc.) that communicate with language models via API. This has forced us to implement very granular detection queries to try to identify suspicious activity.
Part of this difficulty is due to the legitimacy of those tools and the leniency of EDRs toward them (most precompiled binaries are signed, and the communications, generally via API, go to legitimate domains). It poses a challenge similar to the profiling we have to do when identifying malicious use of RMM tools or tunnels of various kinds.
Staying current and understanding very well, technically, how threat actors are using these agents as post-exploitation tools is essential to building effective detections. Back in mid-2025, a case was documented in which APT28 used an executable packaged with PyInstaller carrying a payload called LameHug, which connected to the Hugging Face API to use an LLM as a generator of post-exploitation commands. These kinds of threats aren't mere speculation or something for the future, they're a present reality and represent a new paradigm from a defensive standpoint.
8L: The industry loves to compete on the number of out-of-the-box detections, the quantity of prebuilt rules a product ships to fire alerts on suspicious behavior. From your seat as a detection engineer, what really separates a good detection from noise? Where's the line between quantity and quality, and at what point do more rules stop helping and start making the team's work worse?
Borja: In my view, the fundamental thing, first of all, is to understand technically how the technologies we work with function. I'm obviously not talking about doing reverse engineering, but it's true that the more low-level knowledge, the better. That already gives us certain clues about the possible detection gaps and shortcomings they may have, or the kind of attacks they may be subject to. For example, most EDR solutions feed on ETW, but others additionally do user-space hooking by injecting their own DLLs, on top of installing their corresponding drivers. Knowing the data sources these solutions feed on, as well as the type and quality of the telemetry generated, already gives us valuable information.
On the other hand, since vendors usually don't give you the detection logic they implement for their rules, it's advisable to have a lab and, as part of hunting operations, test many TTPs to assess whether or not it's necessary to create complementary queries to cover possible detection gaps.
When building those queries, what really separates a good detection from noise is its quality in being able to filter by rarity, context, and deviation from a certain baseline. Combining multiple correlated signals and moving away, as much as possible, from IOCs, to cover a greater number of scenarios and raise the adversary's operational cost. In theory this sounds good, but in practice it requires a lot of time and people with a great deal of experience and high technical knowledge.
Also, one last phase that's essential is testing, where we must try the detection on as many endpoints and diverse scenarios as possible to gauge the noise generated. In theory we often think a given detection could be very good, but in practice, when we apply it in real environments, we run into many false positives, where, despite tuning and profiling it, the noise generated makes it unviable. Factors like the tuning effort, the detection's coverage, and the number of false positives generated are what we ultimately weigh to determine whether or not we bring that detection into our hunting cycle.
8L: To close: from the perspective of someone who studies the attacker, which identity artifacts (service accounts, API keys, OAuth tokens) are the most valuable targets and, at the same time, the most ignored by teams today? And if you could give one piece of advice to a team facing identity attacks today, what would it be?
Borja: I'd say session tokens and authentication cookies, along with non-human identities, since they're more neglected (they're rarely rotated and lack the same scrutiny as real users).
First, I'd advise, whenever they have the option, choosing a professional identity-focused solution with the capability and flexibility to create detection rules. Day to day, I'd say build many rules based on a known baseline (a refresh token used from a region not seen before, the first time a user registers an application, an identity that starts using a different Client ID for the first time, etc.). I'd also advise counting on and correlating events with a third-party threat intel service that can report secrets stolen by infostealers and from underground markets.
_
If anything stays with you from this conversation with Borja, it's that the identity attack no longer gives warning. It happens in seconds, automated, and, most uncomfortably, disguised as perfectly normal activity. And that distinction can't be bought ready-made. It starts with understanding what sources your telemetry feeds on and what it's able to see; it continues by building a baseline of what's normal in your environment; and it culminates when you stop treating session tokens and non-human identities as second-class and start watching them with the same rigor as any user. Fewer out-of-the-box rules, more context. That, in the end, is the work.
Identity Attack, Unfiltered
Identity Attack, Unfiltered is 8Layers' biweekly series where we give security experts the floor to talk, unfiltered, about identity risk: how they see it from the field, what worries them, and what they'd do differently. Each conversation adds a different perspective, from governance to digital forensics, from the SOC to threat intelligence.
The series grows out of what we do at 8Layers: uniting in a single view of identity what normally lives apart: posture, detection, and compliance.
Do you work in identity security and feel you have something to contribute? We'd love to hear from you. Write to us at marketing@8layers.io and tell us your perspective; you could be the next voice in the series.