Víctor José González Arcos

AI is accelerating cyberattacks. For those of us who investigate them, the challenge is no longer just to understand what happened, but to buy time to stop the attacker escalating further. ______ At 03:12, the team considers the response complete. It has isolated a compromised server, preserved the available evidence and restored a backup taken before the attack. The system is working again. At 03:47, another alert fires: the same vulnerability is rapidly exploited again and a suspicious connection is established from the same server. Again. The scene, although anonymised, illustrates a very familiar problem. The restore has returned the system to its previous state, including the vulnerability that allowed the initial compromise, before there has been time to patch it. Everything suggests that, outside the organisation, an automated operation is still running and can try again without fear of, or even awareness of, having been discovered, with the sole purpose of continuing towards the objective it has been given. In the past, an attacker might have left with their loot after being discovered, or tried new methods to return to a stealthier mode of operation. Our new adversaries do not “feel” either shame or fear, emotions reserved for people. This leads to a basic distinction that is often overlooked: restoring the service is not the same as evicting the attacker. Before closing the incident, we need to know how they got in, which credentials were exposed and identify every possible persistence mechanism or alternative route back in before any of them are used. And we must preserve the evidence needed to reconstruct what happened. Otherwise, we have only helped fix the symptom, not the problem. Restoring the service does not mean the attacker has been evicted. The attack may begin long before the first alert In the latter months of 2026, while analysing leaked material, we examined target-reconnaissance projects based entirely on Artificial Intelligence. Whoever wrote these scripts was clearly not focused on a single company. The material brought together data from a large number of organisations, mainly in Spain, Germany and England, some in retail but many in healthcare. What were they inventorying? Internet-facing services, usernames associated with those organisations, potentially known passwords, complete lists of prospective customers, among other things. To do this, we observed hundreds of scripts, some sourced from GitHub and others custom-built, designed to extract each type of data, together with scripts intended to abuse the technologies exposed by each organisation. Part of the material we analysed was written in Cyrillic characters, once again. That is an indicator, but not an attribution, as this writing system is used by several languages and does not in itself identify either a country or the people responsible for the activity. Those inventories combined data from open sources with information obtained from leaks. It is important to separate the two: they are not the same thing. What was new was seeing them brought together, correlated and organised to study many targets at once. AI is undoubtedly accelerating this work at scale, and across every stage of the process. The question therefore changes. When someone gets into a network and appears to move through it with great stealth and confidence, how much research had they done beforehand? The answer would probably vary depending on when the question was asked. At first, I would have said several months; a year ago, that had fallen to just a few weeks; today, we are seeing that period shrink to only a few hours. AI accelerates the collection and correlation of information needed to study many targets at once. Seven minutes, hundreds of actions In this final quarter of 2026, while responding to an incident, we analysed how an attacker compromised all of the organisation's credentials within seven minutes of the initial intrusion. This is not a statistical average, nor does that fact alone prove that AI was carrying out every action. But it does reflect the direction in which attacks are moving and the resulting concern over how little time these rapid and highly effective attacks leave organisations to detect and contain them. Public figures help put this into context. According to CrowdStrike, during 2025 cybercriminals took an average of 29 minutes to move from the first compromised system to a successful first lateral move; the fastest observed case was 27 seconds. The time between initial compromise and the first successful lateral movement is known as breakout time. This does not, by itself, prove the use of AI either. What it shows is that defensive action may come only after the attack has already progressed. That speed is compounded by the volume of new data that has to be analysed. In another incident, we faced investigations that required reviewing hundreds of scripts per machine! And they differed from those found on other machines involved in the same incident, which suggests that the attacker was adapting rapidly to the services encountered on each system. With such a large volume of scripts, analysing each one in isolation is not enough: you need to correlate them, establish which were executed, with what permissions and what outcome they produced. And you have to do that while the incident is still active and the attacker is erasing their tracks. The speed of the attack and the volume of actions reduce the time available to detect, investigate and contain it. That is without even mentioning suspicions that the attack may have originated from a neighbouring corporate network, and confirmed evidence that the attacker had moved into another network connected to the one involved in our incident. This ability to adapt, move between environments and generate new tools at what appears to be remarkable speed is probably one of the most significant characteristics of the incidents we will face in the coming years. Another trend, also relatively unusual until this year, is finding multiple exfiltration methods available in parallel on the same machine, one attempted after another. If one fails, that does not mean the operation has stopped. What matters is achieving the objective. From that behaviour alone, we cannot know whether several AI agents were involved, a single AI system or conventional automation. What matters is the effect: multiple avenues open simultaneously, hundreds of scripts to analyse and barely any time to react. Our forensic tools remain effective, but they were designed for a different scale of work and, in a sense, for a less voracious era. What has already been documented Public research shows just how far this kind of automation can go. In November 2025, Anthropic described an espionage campaign in which, by its own estimate, Claude Code carried out between 80% and 90% of the operational tasks. The attackers presented part of the work as a legitimate security audit and broke the instructions into smaller steps. The system ultimately helped carry out offensive activity it should not have performed, leaving significant damage in its wake. This closely resembles what we also observed in the leaked material I mentioned earlier: many scripts, many targets, and a command history in which the “claude” command was the common denominator across all the actions carried out. In addition, in August 2025, ESET disclosed PromptLock, a ransomware program capable of generating scripts through an AI model at runtime. It was later confirmed to be an academic prototype from New York University, rather than a real campaign with victims. More recently, on 7 October 2026, CrowdStrike documented attacks against South Korean financial institutions in which a threat actor used ARTEX, an AI agent-based penetration-testing tool, together with large language models (LLMs). Data exfiltration was investigated, although the activity was not attributed to a known group. In our own investigation, we found evidence that, from the compromised machine, the attacker was using a jump server with multiple ports, with each of those ports corresponding to a different identity on the internet, clearly intended to make detection and tracking more difficult. Even if AI can carry out the actions, there is still a human being who needs to be protected. We are therefore dealing with different situations: an operation investigated by the provider of a well-known AI system, findings from our analysis of different incidents in our own laboratory, and attacks against real organisations investigated through leaked information. It would be a mistake to conflate them. It would also be a mistake to imagine AI as an infallible attacker. It can fail, invent results or take useless paths that we may never even know about. In fact, in our analysis of the leak we observed one OSINT field (data collected from open sources) where, when it could not find the real value, “claude”, in this particular case, let its imagination run wild to complete that stage of the objective it had been given and satisfy the attacker. Without losing sight of the main point, the risk here is that it can try many alternatives so quickly that it multiplies first the effort required for defence and then the effort required for investigation. Even if the information is not entirely reliable, there is so much of it, across so many organisations, that the importance of data quality can be diluted by the sheer increase in the number of targets. AI can make mistakes and still multiply the attack options and the effort required to defend against them. The response needs technology, but it also needs judgement The first requirement for any organisation is visibility into everything that is happening. Not just during office hours. Organisations need to pay close attention to everything exposed to the internet and use network segmentation, with demilitarised zones (DMZs) separated from the rest of the environment for the most exposed servers, helping to prevent possible lateral movement. They should also use frequent rotation of strong passwords and a second authentication factor, together with a Zero Trust approach based on least privilege for all users, with administrator privileges reserved only for specific, auditable and exceptional needs. It is also necessary to patch any vulnerability on the same day . The time we used to have to test an update first in a staging environment and only then in production has become precious. Teams also need to detect anomalous access, unusual account behaviour, connections to uncommon destinations, suspicious correlations, those familiar use cases, impossible travel, such as a login in Spain and another in the US at the same time without allowing for six to eight hours of flight time, unusual data transfers, and anomalous CPU, memory or network usage. All of this, and any other deviation from normal behaviour, deserves attention. There also needs to be capacity to act without waiting for the problem to pass through a long chain of approvals. There is no longer a grace period for the so-called zero-day exploits. We are seeing vulnerabilities probed twice in the time it takes to read the vendor advisory after disclosure. Those of us working in incident response and digital forensics also need to review our methods. If hundreds of scripts appear, we may need to group them by behaviour and reconstruct the sequence without reviewing every one individually and in detail as we once did. Either we analyse them in bulk or we risk not seeing the wood for the trees. The focus has to remain on what matters: containment, eradication, recovery and lessons learned. If an account has been compromised, we need to consider revoking sessions and credentials and analysing its connections. If immediate containment is required, we will not always be able to perform a full forensic acquisition first. We will have to decide which evidence can be preserved without worsening the impact and document every action taken. Understanding what happened remains essential, but stopping the attack cannot wait until every detail is understood. Defensive automation can be a major help, but it must not become a black box. A tool may detect patterns or recommend an action; someone still needs to understand the organisation, assess the consequences and take responsibility for the decision. Not everything that looks unusual is an attack. Not every fast action is a good response, because it can affect the business, and under these new conditions those decisions increasingly have to be made almost in real time. For me, this is one of the most interesting challenges this field has faced in many years. It forces us to improve, to share knowledge and build teams capable of investigating large-scale, sophisticated or particularly intense attacks while protecting the business. But this is not about competing with the machine. It is about identifying, amid all the noise now generated during an attack, the actions we need to interrupt in time to stop an adversary effectively when that adversary appears, at least initially, to know everything and always be one step ahead. For years, much of our effort has gone into reconstructing every step an attacker had taken. Now, without abandoning that work, we also need to stop the next steps while they are happening. Understanding every detail remains important, but it can no longer always come first. It is a change in strategy, and it will not be the only one we have to adapt to. Perhaps our techniques are still valid. What has also changed is how we need to apply them to these new incidents, and the amount of time available to analyse, understand and make decisions. On any given day, once again at 03:47, another alert fires. The incident is escalated to us. We go in. We're on our own, but this time we know what we are facing: something pursuing an objective that does not stop at the obstacles we put in its way, does not care about being seen even when repeating the same patterns, and wants only to continue until it reaches its objective. ______ Final note: Observations from our own investigations are presented in anonymised form; they do not imply public attribution or a proven relationship between the cases. Even so, many of them show what appears to be a common trend: more actions, greater speed and less time to react. Cybersecurity AI-Native SecOps: framework for assessing the maturity of an Artificial Intelligence enabled SOC September 21, 2026

As we saw in the first post of the series, the IR (incident response) process in case of attacks using ransomware is fundamental, relying on the work of several groups that, providing different roles, form a single working team to help the affected company recover in the shortest possible time. Our NextDefense services include a specific branch in their proposal to cover these types of services. In this second post of the series, we are going to review the role played by the members of Telefónica Tech's DFIR (Digital Forensics and Incident Response) services team within the global IR process. DFIR team composition The team is made up of a group of multidisciplinary professionals, mostly senior profiles, whose professional career has always been linked to security in any of its specialities. This diversity of roles makes it possible to be prepared for any evolution in attackers' techniques, tactics, offensive procedures and anti-forensic methods, regardless of the specific characteristics of the actor and the attack. In the case at hand, security incidents using ransomware, it is necessary to combine resources from different groups: DFIR Threat Hunting (occasionally combined with EDR monitoring services) Threat Intel (Threat intelligence) Within these disciplines, DFIR has three distinct roles that are involved in very specific ways within the IR process: Incident Handler (IH): He/she coordinates the security incident, liaising between the client and the different teams to keep track and facilitate communication, assigning tasks to the different parties and ensuring that the whole IR process evolves in the right way. Forensic Analyst: This is the specialist with the capacity to carry out investigations (local and remote) on any system or support with information, and whose purpose is to obtain evidence that allows progress to be made during the investigation. Malware Analyst: The specialist who performs static and dynamic analysis on viruses and other malicious artefacts that may be found on the computers processed by the forensic analyst, the role threat-hunter or by the customer himself. Preparing the IR process When a new incident response process is initiated, the DFIR services team organises the work and prepares to perform the first tasks. Cloud spaces are created (to be used for evidence sharing) and also used to analyse the ransom note itself, the extension of the encrypted files and even which corporate domain the affected company has. Waiting for the initial meeting with the client, the assigned people internally review the available information and prepare all the content for these first steps with the client. This first working meeting will be one of the most important. All this preparation before the first meeting is used to review the knowledge one might have about the specific actor: whether he usually exfiltrates data, which entry route he usually uses, which tools he deploys and even if the company has exfiltrated credentials in black markets. The first day of the process and, in particular, the first meeting, are crucial. Start of response Once the first meeting takes place and the actual response process begins, initial work streams are created for all groups (including the client and third parties), tested at each incident and improved at the end of each incident. Some examples are: The Incident Handler will take control of the process and start organising all the working groups, activities, meeting plan, etc. The Threat Intel team will request a series of data from the customer to produce actionable cyber security intelligence (to be discussed in the next post). The forensic analyst will collect all events/objects that may harbour information from the attacker. This will produce the first IOCs (Indicators of Compromise) that will allow e.g., blocking to start the containment and eradication phases of the threat. If malware elements are present, a malware analyst will be added to the team to perform the corresponding tasks. The Threat Hunting group (often in combination with other Telefónica TECH monitoring services) will support the deployment (when necessary) of an EDR platform, carrying out alert analysis and threat research on this platform. Specifically, in the last post of the series we will see the work of this team. Performance during the IR process The incident response process follows a routine of meetings (more executive) or checkpoints (more technical) throughout the work period (a couple of weeks, on average). In these meetings, the joint working team (customer, Telefónica TECH team and possible third parties) will review the work in progress, sharing knowledge and assigning new tasks to everyone (being reviewed at each checkpoint). The forensic profiles of the DFIR team will work intensively in this iterative process and throughout the agreed work period: they will carry out their investigations with the different types of evidence available, they will rely on malware analysts (if necessary) and they will gradually create the incident narrative that will be explained to the client at the next checkpoint. They will identify and communicate the IOCs found to the different groups to support containment and eradication, while tracing the timeline that will be reflected in the report that will be delivered to the client together with the identification of the first system found to be compromised (becoming "patient 0"), the entry vectors used to enrich the recommendations that will serve as points of improvement of the affected infrastructure and everything relevant to the network (and the attacker) that must be communicated to the client. Subsequently, and only in cases where there might be a publication of information (not all ransomware attacks involve data exfiltration), threat intelligence analysts will try to monitor their Hall of Shame (usually public boards where exfiltrated information is disclosed) in order to assist customers in the most important aspects concerning data privacy and GDPR, among other actions. This block of activity will be explained in the next post in the series. In short: the work of the DFIR group within a ransomware incident, as we understand it at Telefónica TECH, is a constant process of investigation and exchange of knowledge of forensic and malware analysts with other groups (threat intelligence and Threat Hunting, above all). In each action, the client and the other roles and groups will learn about the progress achieved in DFIR thanks to the intermediation of the Incident Handler (perhaps a new IOC or the identification of patient 0) and in turn, these groups will be able to extend the information to the DFIR specialists to refine the next steps of their investigation. Completion of forensic and malware analysis work When the investigation work in an IR process is completed, a final investigation report is generated and follows a structure that is regularly revised to ensure maximum usefulness to the client. Regardless of the country/region of the incident or the language used, the report always has the same format and structure. In some cases, clients request an advance version of the report to share with law enforcement, insurance companies, auditors, partners, suppliers or customers. To provide peace of mind, once the final investigation report has been shared with the client, the IR process usually continues with an agreed 24x7 monitoring of the EDR where the entire team may be reactivated. In these final stages of the IR process, a final meeting will be held with the client where the report delivered will be reviewed in detail, resolving any doubts that may have arisen and explaining the most important aspects of the narrative of both the incident and the recommendations. As we have seen, the incident response process of Telefónica TECH's DFIR team works in a fast and organised way, following a specific methodology followed by all the groups, to cover all the phases of the IR process. These roles and their methodology are key to resolving this type of incidents. Download our new guide created in partnership with Palo Alto to help you prepare, plan, and respond to Ransomware attacks