Decoding the Future with Cybersecurity’s Past: A Conversation with Morey J. Haber

Cybersecurity’s constant state of evolution, with new technologies and threats continuously emerging, leaves no room for complacency. But to truly understand where we’re going, we must first understand where we’ve been. What lessons from attack vectors past can we apply to today’s challenges and threats around AI, identity security, and more?

To explore these questions, we sat down with Morey J. Haber, Chief Security Advisor at BeyondTrust and author of the new book, Attack Vectors: The History of Cybersecurity. In this Q&A, Morey shares insights from his research, discussing the pivot from technological exploits to identity theft, the dangerous paradox of AI adoption, and why old security principles are more relevant than ever for tackling new threats.

I don’t believe that one attack vector has changed the course of what we’ve learned today. I sincerely believe attack vectors have shifted from assets and applications to identities and governance in the last 50 years, however. While there have been notable attacks against default credentials, simple passwords, and insecure secrets throughout the decades, the landscape has significantly changed in the last five years with a focus on identities, accounts, entitlements, and privileges that is reshaping how organizations must protect their assets and resources.

It you consider that the IT perimeter is no longer the castle-and-moat defense it once was; that concept died with the rise of remote work post-pandemic. Exploitation of organizations has pivoted from zero-day attacks and missing security patches to identity theft via social engineering and weak authentication and access management. After all, today it is much easier for a threat actor to log in than to hack in.

It’s important to note that attacks against assets and applications haven’t gone away and they are still very important to remediate. Threat actors today would rather steal your identity and login credentials over an exploit that could be patched. This change in trajectory from technology to people is one of the most notable outcomes from my research and the biggest change in the trajectory of cybersecurity.

I noticed a very interesting pattern for new technologies, how they are adopted, and how they can be exploited. If you are familiar with the analyst community, they reference almost all new technology disciplines in the form of a hype cycle. This hype cycle encompasses the rapid adoption of technology, its maturity, market consolidation, and eventual stability. Unfortunately, security is too often an afterthought, even though secure-by-design best practices recommend security should always be baked into a new technology solution from the start.

If you map out recent technology adoption—from mobile phones to cloud computing—you can clearly see that security best practices were often ignored in favor of building market presence and revenue. Common features like a PIN to protect your phone, biometrics for MFA, and least privilege for cloud entitlements were all added after initial adoption. This pattern holds true today with the adoption of generative AI and agentic AI. Adoption always seems to precede security, which creates an environment ripe for exploitation during the initial hype phase of almost every new technology.

Organizations today are enamored with artificial intelligence. Make no mistake; we are on the downside of the hype cycle before maturity sets in. For my fellow CISOs, AI is no different than any other middleware we’ve installed over the last 30 years. The old best practices are still valid, plus a few new ones. This includes enforcing least privilege, monitoring for vulnerabilities, providing just-in-time access to data sources and connectors, preventing model poisoning (data corruption), and most importantly, having a human-in-the-loop approach to correct AI hallucinations or inappropriate behavior (for example, implementing AI kill switches).

While we may marvel at the possibilities for AI, it also represents just another piece of technology susceptible to a wide variety of known attack vectors, which are now evolving with new names for old exploits. For instance, “sovereign AI” is a new architecture to protect against geolocation threats, much like we used air-gapped networks in the past.

Data poisoning is analogous to database corruption and requires input filtering, model backups, and detailed logs to ensure the output stays appropriate and can be corrected. These are old techniques with new names, but the overall strategy is still the same. Therefore, we should take the lessons we already know and map them to new technology, such as AI, to identify any gaps.

Agentic AI is being adopted faster than almost any technology in history. This begs a very interesting question: what happens when adoption outpaces secure-by-design practices, and the hype cycle is nearly flattened? The answer is a technology paradox. Obsolescence occurs before maturity, and this creates an environment with solutions that never prove their value before they should be deprecated.

In many ways, this can be looked at as a production experiment of new technology and a conflict for the joiner. mover, and leaver process of application development and adoption. This paradox of application adoption, in my opinion, hasn’t been seen before with other technologies, including the cloud and mobile devices. While both had early solutions, they matured into what we have in our pockets and through our browsers today.

Agentic AI is moving so fast that something deployed today may not prove any value and be obsolete tomorrow. This has left us with a big problem. Early implementations of “shadow AI” may never be reconciled for removal. It was never secure by design, placed in production before security and maturity were proven, and could be exploited in the future because of its rapid adoption and failure to meet best practices for security deployment, monitoring, and management. This is a new lesson we must be aware of as students of the history of cybersecurity. Moving too fast can create its own problems.

The confused deputy problem has existed for decades. It arises when a system is tricked into revealing privileged information or executing commands from a lower-privileged resource. When this is applied to various verticals, it can have detrimental effects. Consider these examples:

• Hospital: A care-coordination agent has read access to EHR and a delegated scope to call the pharmacy API. A simple discharge note instructs it to “refill medication as needed,” triggering the agent to use a back-office service account with broad rights to authorize multiple high-risk opioid refills because the pharmacy API trusts the hospital’s service principal, not the clinician’s intent of limited dosages. The abuse stems from the ambiguity of “as needed”, which may be common language for “take as needed”, but not “refill as needed". A simple mistake like this could cause long-term harm.

• Bank: A collections bot aggregates customer data and can initiate “goodwill fee reversals” via an internal API. A user requests a bulk reversal of “all fees” and the overprivileged bot misinterprets “all” to mean all fees for multiple clients instead of all fees for the single user’s account, and executes widespread refunds.

• Government: A records digitization agent normalizes documents and pushes to a public portal. A poorly crafted template causes it to treat an “internal draft” as “publishable”, enabling it to use a content management token with insufficient scoping to release internal information inappropriately.

In each case, the deputy (agent) is “trusted” with privileges that exceed the context of the user’s input. A simple mistake or a well-crafted attack can trick the LLM into processing information in an unintended way, causing the confused deputy problem. In each example, the undesirable outcome has the potential for serious, long-standing repercussions for the business and patrons.

Implement all connections and data sources using the principle of least privilege. This simple discipline ensures that agents do not have excessive privileges to a data source or automation by default. This minimizes the potential for a confused deputy problem and helps isolate a compromised system. While scoping least privilege for agentic AI may be a cumbersome task, it’s basic entitlement management for middleware and should be implemented during any testing and production rollout. The history of cybersecurity has proven that, any time privileged rights are obtained by a threat actor, a game over event can occur. Implementing AI with excessive privileges introduces the same risks and something we should manage from the start.

Account takeover uses stolen or compromised credentials or secrets. Account poisoning manipulates the context of trusted devices, tool configurations, and delegated consents to trick a system into behaving maliciously, even with a valid login.

Automation can accelerate both attack vectors, but poisoned AI agents can manipulate misconfigurations or integrations without tripping an indicator of compromise. Defending against automated account poisoning attacks requires posture monitoring, configuration drift detection, and just-in-time access. The threat is not the login itself; it’s the manipulation that occurs after a successful authentication that makes account poisoning so dangerous.

In the early days of phishing and ransomware, the attacker’s source information was relatively reliable. Today, that is a stark contrast to where we are now. Identifying the source of an attack is complex and requires detailed logs from almost every hop, step, and packet used. A threat actor’s source IP address alone rarely reveals who they are, thanks to bots and VPNs.

This is where we see a true cat-and-mouse game. Threat actors now use techniques to mask or fake their location—using Wi-Fi signals, DNS lookups, or GPS locations services—to implicate someone else, such as another country in a nation-state sponsored attack. Forensics teams once relied on this data to determine the source of the attack, but now it’s reasonable to assume this information is no longer credible. Some of it may be valid, some fabricated, and some intentionally obfuscated to redirect forensic investigations. In the early days of phishing and ransomware attacks, this information was relatively reliable to determine the source. Because IP/geolocation data can be obfuscated today, low-level logs and packet information are almost always required to determine the real culprit.

Organizations today are least prepared for supply-chain attacks and source code compromises. This includes compromised open source, malware embedded tools, AI prompt injection, and integration packs (SDKs) that propagate through marketplaces and internal catalogs.

The industry has built plenty of tools for code-signing compiled code, but when the source is compromised at the vendor or during open-source updates, we have no way of detecting or preventing it. To that end, most organizations cannot answer where the software bill of materials (SBOM) originates for the software they license. This leads to an auditing dead end when something is determined to be vulnerable or compromised.

If you need proof, look at how hard it was for companies to identify all the locations Log4J was installed within their environments in 2021, and the extensive planning required to remediate that simple vulnerability. Now, imagine if that vulnerability was malicious code instead. Until we treat our software supply chains with verification, attestation, and rapid rollback, we will remain a step behind what could potentially be the industry’s biggest attack vector.

I believe my prediction on “Reverse Identity Theft” would have aged the best. Almost everyone is aware of the concept of identity theft; entire businesses have been built around detecting it and protecting services and financials when an identity is compromised. However, like everything else in cybersecurity, there are attacks that are the explicit opposite of the initial attack vector.

Reverse identity theft is the concept of your identity being falsely associated with another identity that is not yours, without your knowledge. Simply put, reverse identity theft is not about your identity being stolen, but rather about you being implicated for something you simply did not do.

This is already happening when threat actors merge data from vast data breaches incorrectly, simply based on your name or other common fields. For people with common names, it can result in faulty collection claims or errant emails. For others, it can be a case of extreme mistaken identity or accusations of having a doppelganger, whether fictional or not. For example, you may be contacted or phished for a delinquent credit card associated with your name, but by using facts from some else who has the same name.

In this security professional’s opinion, I expect to see a rise in this phenomenon, where breached data creates faux personas for individuals based on improperly merged data and assumptions. Trying to address the problem will result in an exercise of serious futility.

In fairness, I do see echoes of past “failed” technologies coming back and having a stronger presence in today’s technology ecosystems. Remember thin clients? They “failed” and returned as cloud desktops and hosted VDI solutions we’ve used for decades. Expert systems died, but LLMs brought them back as a middleware component. Even PKI, which was once painful and difficult to manage, is now essential for device identity and privileged access.

AI today feels overhyped, but eventually, it will be a component we accept in almost every architecture: secure, invisible, and embedded. In fact, the initial AI hype bubble has burst, as we’re already seeing investors cool off and investing less in new startups. The current noise is around new use cases, not foundational changes. While I’m not certain what will come back from AI in the future, one thing is for certain: it will involve new forms of cybersecurity attack vectors, as threat actors always target new and maturing technologies.

These insights reveal a powerful, recurring theme: as technology creates new surfaces for attack, the underlying principles of defense remain consistent. The fundamental shift from targeting systems to targeting identities underscores that the human element is the new perimeter, making identity security a critical defense layer.

As organizations race to adopt agentic AI and other emerging technologies, the lessons from the past, from enforcing least privilege to eliminating the dangers of a “confused deputy”, are essential components of a modern defense.

By studying the historical patterns of how technology is adopted and exploited, we can better prepare for the threats of today and tomorrow, ensuring security is not an afterthought, but an integral part of innovation.

To dive deeper decoding how past attack vectors can inform your security approach today, get your copy of Attack Vectors: The History of Cybersecurity today, sign up for the live webinar, or learn more at https://www.beyondtrust.com/attack-vectors.