- Introduction
- Chapter 1 The Tiger Teams: Cold War Roots of Controlled Trespass
- Chapter 2 Phreaks, Modems, and the Underground BBS
- Chapter 3 The Legality Gap: The Computer Fraud and Abuse Act
- Chapter 4 From Anarchy to Audit: Early Network Assessments
- Chapter 5 SATAN Unleashed: The Automation of Vulnerability Discovery
- Chapter 6 The Rise of L0pht Heavy Industries: Hardware and Culture
- Chapter 7 Selling the Hack: The Birth of the Boutique Consultancy
- Chapter 8 The Commercial Frontier: WheelGroup and NetScan
- Chapter 9 Full Disclosure vs. Responsible Disclosure: The Mailing List Wars
- Chapter 10 L0pht Goes to Washington: Testifying Before the US Senate
- Chapter 11 Network Associates, Axent, and the First M&A Wave
- Chapter 12 @stake: Wall Street Money Enters Hacker Street
- Chapter 13 Scripting the Siege: The Emergence of Nessus and Nmap
- Chapter 14 Social Engineering: Weaponizing the Human Factor
- Chapter 15 Dot-Com Boom: Securing the Digital Gold Rush
- Chapter 16 The Exploit Economy: Zero-Days as Commodities
- Chapter 17 Methodology Matters: The Quest to Standardize Infiltration
- Chapter 18 From Hobbyist to Suit: Corporate Culture Shock
- Chapter 19 Post-9/11 and Critical Infrastructure: Homeland Defense Reframes Hacking
- Chapter 20 Metasploit and the Democratization of Exploitation
- Chapter 21 The Compliance Mandate: Sarbanes-Oxley, HIPAA, and Checkbox Security
- Chapter 22 Red Teams vs. Blue Teams: War Games in the Boardroom
- Chapter 23 The Big Four Move In: Professional Services Absorb the Rebel
- Chapter 24 Ethics, Certifications, and the CISSP Era
- Chapter 25 The Industrial Complex: The Legacy of the First Pen Testers
The First Pen Testers
Table of Contents
Introduction
In the autumn of 1998, seven young men in black T-shirts, leather jackets, and long hair filed into the Dirksen Senate Office Building in Washington, D.C. They carried no corporate dossiers and used pseudonyms like Mudge, Weld Pond, Kingpin, and Space Rogue. Seated beneath the mahogany paneling of the Senate Governmental Affairs Committee, the members of the Boston hacker collective known as L0pht Heavy Industries delivered an assessment that stunned the lawmakers before them: any one of them could take down the entire global Internet in under thirty minutes. More striking than their boast was the response from the senators. Rather than calling Capitol Police, the politicians leaned forward, scribbled notes, and asked what funding would be required to prevent such a catastrophe. In that single afternoon, the tectonic plates shifted. The digital trespasser—long portrayed in the media as a nocturnal saboteur or a cyber-anarchist—was invited inside the halls of power as an indispensable advisor.
Between 1990 and 2005, an unruly subculture of phone phreaks, hardware tinkerers, and bulletin-board system operators transformed into a multi-billion-dollar professional services industry. This book is the chronicle of that transformation: the history of penetration testing, or "pen testing," the practice of authorized digital intrusion designed to expose systemic vulnerabilities before an adversary can exploit them. Today, penetration testing is an established corporate fixture, mandated by federal regulations, managed by Big Four accounting firms, and performed by certified analysts adhering to rigid legal contracts. Yet thirty years ago, the entire enterprise was an improvisational gambit. It was an occupation invented on the fly by autodidacts who realized that the nascent World Wide Web was built upon foundations so structurally fragile that the only way to defend a network was to learn how to break it first.
To understand how breaking into computer systems became a billable service, one must appreciate the sheer velocity of the era. The decade of the 1990s saw society blindly bet its critical infrastructure on interconnected computing. Banks, hospitals, municipal power grids, and Fortune 500 enterprises rushed into cyberspace, prioritizing speed, market share, and uptime over basic security hygiene. The engineers who built these architectures were visionaries, but they were often dangerously naive; they designed protocols that trusted whoever knocked on the port. Operating in the shadows was an informal international community of curious explorers who quickly discovered that these corporate digital empires could be brought down by a single unverified string of user input or a poorly configured modem hanging off an executive's desk. The gulf between institutional ignorance and hacker capability was vast, and bridging it required an entirely new business model: paying the intruder to show you the hole in your wall.
Turning intrusion into a profession was fraught with moral and legal hazards. In the early 1990s, the Computer Fraud and Abuse Act hung over security researchers like a guillotine. Corporate legal departments reflexively viewed vulnerability reports as extortion, and network administrators treated outside scrutiny as an act of war. The pioneers documented in these pages had to forge an ethos out of raw chaos. They engaged in brutal mailing-list wars over the morality of "full disclosure," arguing whether publishing an exploit weaponized the Internet or was the only lever powerful enough to force software vendors to patch their code. They wrote the foundational tools—from Dan Farmer and Wietse Venema’s controversial SATAN scanner to Fyodor’s Nmap and H.D. Moore’s Metasploit—that automated the art of discovery and, in doing so, democratized the siege engine for an entire generation.
As the dot-com boom gathered steam, venture capital flooded the space. Hacker lofts gave way to boutique consultancies like WheelGroup, Secure Networks, and @stake, where countercultural talent suddenly grappled with corporate governance, non-disclosure agreements, and stock options. The clash of civilizations was profound. Veteran systems architects had to teach themselves the language of the boardroom, translating buffer overflows into risk management profiles, while executive suites were forced to swallow the bitter pill that the kids they had once wanted to incarcerate were now the only people capable of protecting their balance sheets. By the early 2000s, driven by post-9/11 national security anxieties and sweeping regulatory mandates like Sarbanes-Oxley and HIPAA, the transformation was complete. The rebel had been institutionalized. The tradecraft of underground infiltration had crystallized into an industry standard.
The First Pen Testers tells this human and technological saga through the stories of the practitioners who lived it. It is not merely a technical post-mortem, nor is it a romantic eulogy for the lost innocence of early computing. It is an examination of how society learns to govern its most dangerous innovations. By following the tinkerers who professionalized intrusion, this book reveals how the instincts of an underground counterculture became the immune system of the modern information age—and how the compromises made along the way continue to dictate the battle over digital security today.
CHAPTER ONE: The Tiger Teams: Cold War Roots of Controlled Trespass
In the spring of 1971, a small group of computer scientists at the RAND Corporation sat down in Santa Monica, California, to contemplate a problem that almost no one else on the planet took seriously. The United States Department of Defense was steadily connecting its primary research computers across long-distance telephone lines via a radical new experimental network called the ARPANET. The engineers who built the system were euphoric; they had discovered that large, room-sized mainframe computers built by different manufacturers could exchange packets of data reliably across thousands of miles. To the Pentagon’s logistical planners, it looked like magic. To Willis Ware, a veteran electrical engineer at RAND who had spent the previous two decades designing military data architectures, it looked like an open door swinging in a gale.
Ware understood a reality that the networking pioneers had largely brushed aside: if an authorized user on one coast could summon files from an operational mainframe on the other, an adversary might do the exact same thing without asking permission. Computer security, up to that point, had been largely physical. You protected a machine by posting armed guards at the entrance of a climate-controlled basement, issuing laminated badges, and bolting the raised floor tiles into solid concrete. If someone wanted to steal information, they had to walk past a sentry with a camera or smuggle a roll of magnetic tape out in a briefcase. Once those mainframes acquired modems and shared phone lines, physical perimeters evaporated. An intruder no longer needed to break a window or bribe a security officer; they only needed access to a wire.
Ware had already chaired a task force for the Defense Science Board that produced a seminal 1970 report warning that multi-user, time-shared systems were fundamentally incapable of protecting classified information from malicious insiders or clever remote operators. Yet theoretical white papers rarely changed bureaucratic behavior. Military commanders and corporate executives were paying millions of dollars for access control software that vendors promised was bulletproof. The vendors insisted that their operating systems maintained strict partitions between different users, ensuring that Top Secret files could safely coexist alongside unclassified code on the same spinning platters. Ware and his colleagues realized that no amount of mathematical analysis or vendor documentation would shatter this complacency. The only way to convince leadership that their defenses were fictional was to breach them openly, methodically, and by design. They needed practitioners who could play the role of the enemy.
The concept of using an internal adversary to test defenses was not entirely new, but its application to digital computing was unprecedented. For decades, the military had employed so-called red teams during physical field maneuvers to stress-test base defenses or mimic Soviet armor tactics. Similarly, specialized squads known colloquially as "tiger teams" had long been used by armed services to test the physical perimeter security of nuclear installations, naval bases, and weapons depots. These operatives slipped under barbed-wire fences in the middle of the night, picked padlocks on ammunition lockers, left chalk marks on sensitive hardware to prove they had been there, and then presented photographic evidence to mortified base commanders the next morning. The leap that occurred in the early 1970s was the realization that this exact same adversarial doctrine could be applied to lines of code.
Among the very first to operationalize this concept in the computing domain was a brilliant, eccentric systems engineer named James P. Anderson. Working out of a nondescript office in Pennsylvania, Anderson had served on the Defense Science Board task force with Ware and had grown frustrated by the military's blind faith in vendor software specifications. In 1972, Anderson authored a foundational report for the Electronic Systems Division of the United States Air Force titled Computer Security Technology Planning Study. In this dry, typewritten technical document, Anderson laid out the tactical blueprint for what would eventually become the penetration testing profession. He argued that system security could not simply be audited against an administrative checklist. Instead, the Air Force needed to systematically deploy what he explicitly termed "tiger teams"—small groups of elite systems programmers tasked with finding and exploiting the architectural weaknesses in operating systems before the Soviets could discover them.
Anderson realized that typical software testing and adversarial security testing were two entirely distinct mental disciplines. A standard quality assurance engineer tested a system to verify that it performed its documented functions correctly when fed typical inputs. A tiger team member, by contrast, looked at the system from an inverted perspective, asking what unintended actions the machine could be forced to take when fed broken, anomalous, or malicious data. Anderson noted that operating systems were far too complex for their design flaws to be predicted by linear review. A computer program did not fail gracefully like a steel beam under tension; a single misplaced instruction among millions could cause the entire logical framework of access control to collapse instantly. To find those fault lines, you needed people who thought like saboteurs.
The Air Force took Anderson’s advice and began commissioning controlled assaults against its flagship mainframes. One of the most significant early targets was the Multics operating system. Multics, short for Multiplexed Information and Computing Service, had been developed as a joint venture involving the Massachusetts Institute of Technology, Bell Labs, and General Electric. It was widely regarded by academics and military officials as the absolute pinnacle of secure computational architecture. Unlike the sprawling, chaotic mainframe software that preceded it, Multics had been built from the ground up with security as a primary design requirement. It featured sophisticated hardware rings of protection, strict privilege levels, and an access control matrix designed to mathematically enforce the principle of least privilege. In the eyes of the Pentagon, Multics was practically unsinkable.
In 1973, the Air Force sponsored an operational security evaluation of Multics running on a Honeywell 6180 mainframe. The team assembled to test it included an ambitious mathematician and computer scientist at the MITRE Corporation named Paul Karger, along with Air Force Captain Roger Schell, an energetic officer who held a doctorate in computer science from MIT. Karger and Schell were not outsiders attempting to cause damage; they were authorized researchers granted permission to examine the source code, inspect the hardware architecture, and execute arbitrary programs to determine whether the security boundaries could be breached. Their findings, later preserved in a legendary Air Force technical report titled Multics Security Evaluation: Vulnerability Analysis, shattered the industry's illusions about operating system security.
Karger and Schell did not look for simple operational mistakes like guessable passwords. Instead, they dissected the logical assumptions embedded within the system's software interfaces. They discovered that while the Multics kernel was theoretically impenetrable, the peripheral services that supported it were full of subtle logical oversights. One of the primary techniques they pioneered was the analysis of what they termed "argument validation" vulnerabilities. When a user program requested a service from the operating system—such as opening a file or requesting additional memory—the operating system kernel had to inspect the request to make sure the user had the right to make it. Karger and Schell noticed that a clever user could manipulate the timing of these requests, switching memory pointers between the moment the operating system verified them and the moment it acted upon them. Decades later, the industry would formalize this flaw as the time-of-check to time-of-use bug, a staple of modern vulnerability research.
Taking their exploration further, Karger and Schell conceived of attacks that anticipated modern malware by a generation. They demonstrated how a malicious compiler could be secretly modified to insert hidden trapdoors into the software it compiled, without leaving any trace in the human-readable source code. Years before Ken Thompson famously described this exact attack in his 1984 Turing Award lecture, Reflections on Trusting Trust, the MITRE and Air Force researchers had already drafted it as an operational tactic. The tiger team showed that once an adversary gained the ability to modify low-level system software, no audit of the surface-level applications could be trusted. Multics, the gold standard of defense-grade computing, was completely compromised from the inside out.
Crucially, the early tiger teams did not limit themselves to code. They understood that a computer system existed within a physical environment inhabited by human beings who possessed distinct behavioral habits and logistical vulnerabilities. During the same period that Karger and Schell were probing the internal architecture of military mainframes, a quiet pioneer named Marvin Schaefer was conducting security assessments for the System Development Corporation, a major defense contractor in Santa Monica. Schaefer, a brilliant logician who would later become the chief scientist at the National Computer Security Center, was tasked with auditing systems that handled classified material for military intelligence agencies.
Schaefer and his colleagues quickly realized that the easiest path to computational compromise rarely involved wrestling with complex algorithmic defenses. Instead, it involved physical audacity and an intuitive understanding of human nature. On one assignment, Schaefer arrived at an ostensibly secure military computing facility situated inside a windowless compound surrounded by fences and guard posts. Rather than spending weeks trying to break into the mainframe through a terminal, Schaefer and his team analyzed the facility's waste stream. They discovered that every evening, janitors wheeled giant bins of discarded magnetic printouts and punch cards out through an unmonitored loading dock. The tiger team retrieved stacks of high-speed printer ribbons from the trash, unspooled the ink-soaked fabric in a hotel room, and read the classified data that had been directly imprinted onto the material as it struck the paper.
On another occasion, Schaefer’s team demonstrated how easily social engineering could circumvent multimillion-dollar technical controls. Dressing in industrial overalls and carrying clipboards, members of the team walked confidently into a classified data center during a shift change. They announced themselves to the night operator as telecommunications maintenance engineers dispatched to service the communications lines. Without asking for identification or verifying their names with supervisors, the flattered operator ushered them in, offered them coffee, and left them alone in the terminal room for several hours. By the time they departed, they had installed physical monitor taps, gathered credentials written down on notepads beneath keyboards, and acquired enough raw system privileges to control the installation indefinitely.
The early tiger teams were establishing a fundamental truth that would govern computer security for the next half-century: absolute security in an isolated component meant nothing if the surrounding operational ecosystem was fragile. A cryptographic system could be mathematically flawless, but if an operator taped the encryption key to the monitor, the mathematics were completely irrelevant. Security was not a static feature that could be purchased and bolted on; it was an ongoing, fragile state determined by the weakest link across code, hardware, protocol, and human psychology.
While defense contractors and military research laboratories were developing these concepts for the Pentagon, a parallel evolution was occurring within the high-technology corporate sector. By the mid-1970s, commercial enterprises were beginning to migrate their financial ledgers, customer records, and proprietary formulas onto time-sharing mainframes. The dominant player in this space was International Business Machines. IBM was selling its System/370 architecture to virtually every Fortune 500 company, promising that its advanced operating systems, particularly OS/360 and its successor MVS, could safely isolate sensitive financial partitions.
Privately, IBM executives were deeply nervous. They had heard whispers of the Air Force tiger team successes and recognized that if customers realized how easy it was for one user on a mainframe to read another user's private data, the commercial time-sharing market might evaporate. In response, IBM quietly sanctioned internal tiger teams to assault their own operating systems before customers could uncover the problems.
One of the key figures in this commercial offensive was a software engineer named Robert Abbott. Abbott had worked on mainframe operating systems and possessed an intimate understanding of the complex supervisor calls that governed internal operating system behavior. Operating under strict non-disclosure arrangements within IBM and later through external consultancy work with Lawrence Livermore National Laboratory, Abbott and his peers systematically dismantled the access control systems of the era's primary commercial platforms. They did not rely on accidental bugs. Instead, they approached the software with systematic methodology, cataloging the classes of design errors that were inevitable when hundreds of disparate programmers contributed code to a single platform.
Abbott recognized that operating systems routinely suffered from a lack of boundary checking. If a user program told the supervisor to store eight characters of data in an eight-character buffer, the machine operated as expected. But if the user program sent sixteen characters, the operating system often failed to notice the surplus. The trailing eight characters would spill over into the neighboring memory address, overwriting critical administrative instructions and allowing the user program to execute arbitrary commands with total supervisor privilege. Abbott documented these patterns in research that directly foreshadowed the classic memory corruption and buffer overflow exploits that would define network intrusion in the late 1990s. The technical mechanics of memory corruption were fully documented by tiger teams in the mid-1970s, yet the software industry continued to ship code vulnerable to the exact same design flaws for the next thirty years.
The work of these early pioneers remained largely invisible to the public. Reports produced by the Air Force, the RAND Corporation, and MITRE were stamped with classified designations or marked as "For Official Use Only," circulating within a tightly knit fraternity of military researchers, intelligence specialists, and select academic institutions. The general public still viewed computers through the lens of science fiction: massive, omniscient mechanical brains operated by white-coated technicians in sterile cleanrooms. The idea that a teenager with a home telephone could alter a corporation’s financial balance sheet was simply not a concept within the public consciousness.
Yet within the cloistered defense and corporate circles where tiger teams operated, an unmistakable philosophical shift was underway. The early practitioners were writing the initial vocabulary of vulnerability research. Terms that are now foundational to cybersecurity—such as the concept of the "flaw hypothesis methodology"—were invented during these Cold War experiments.
The flaw hypothesis methodology was formulated during these early years as a systematic approach to breaking systems. Rather than randomly trying inputs and hoping for an error, the tiger team began with an exhaustive structural study of the target system's documented architecture. The team analyzed how the operating system handled inter-process communication, how it validated authorization, and how it recovered from unexpected hardware failures. Based on this structural analysis, the team drafted a list of theoretical hypotheses: if the programmers designed this subsystem according to standard practice, they likely assumed that input parameter X would always be positive; therefore, what happens if we force it to be negative? Once these hypotheses were documented, the team designed specific, minimal test cases to validate each one sequentially. If a hypothesis proved correct, the team exploited the vulnerability to prove its practical impact, analyzed why the architectural controls had failed, and presented the findings in an actionable remediation report.
This systematic process transformed intrusion from an undisciplined art into an empirical science. It separated the professional tester from the casual malicious saboteur. A vandal sought only to find one hole, smash through it, and cause damage or extract a single asset. A tiger team sought to understand the totality of the attack surface, mapping every potential avenue of failure so that the entire architecture could be fundamentally redesigned. The goal was never destruction; it was diagnostic clarity.
Despite their brilliance, these early practitioners operated under intense institutional friction. Military brass and corporate management often reacted to tiger team reports with defensive anger rather than gratitude. It was deeply humiliating for a senior general or an executive vice president to stand in front of a mainframe that had cost their organization millions of dollars, only to watch an engineer in short sleeves demonstrate that an unclassified account could take total command of the system in fewer than sixty seconds. The initial bureaucratic impulse was frequently to shoot the messenger: to classify the tiger team’s findings so deeply that nobody could read them, or to demand that the researchers be reprimanded for violating institutional protocol.
Roger Schell and Marvin Schaefer often found themselves having to patiently explain to furious administrators why breaking their systems had been an act of loyalty rather than insubordination. They had to teach the leadership that a vulnerability did not cease to exist simply because nobody talked about it. In fact, silence only guaranteed that an adversary would exploit the flaw under conditions where the victims would never know they had been compromised. By inviting the tiger team in, an organization seized control of its own exposure. They traded the catastrophic risk of an unexpected adversarial breach for the controlled discomfort of a scheduled, domestic intrusion.
By the late 1970s, the operational landscape began to shift again. The United States government, realizing that ad-hoc tiger team exercises were insufficient to guarantee the security of the hundreds of defense mainframes scattered across the globe, sought to formalize these lessons into unified national policy. This effort eventually culminated in 1983 with the publication of the Department of Defense’s Trusted Computer System Evaluation Criteria, universally known in the security community as the "Orange Book" due to its brightly colored cardstock cover.
The Orange Book was an ambitious, highly bureaucratic attempt to categorize operating systems into distinct hierarchical security classes, ranging from Division D (minimal protection) up to Division A (verified design with mathematical proofs of security). Systems were evaluated through exhaustive documentation and rigorous architectural review. In theory, the Orange Book was supposed to render tiger teams obsolete; if a vendor could mathematically prove that their operating system adhered to the formal security policies of Class A1, then no intruder could possibly violate its integrity.
In practice, the Orange Book created a dangerous disconnect between compliance and operational security. A mainframe could achieve a high security classification on paper by meeting dozens of detailed documentation requirements, yet still be utterly vulnerable to a practical attack executed through a misconfigured peripheral device, a forgotten debugging terminal, or an employee tricked into divulging credentials over the phone. The bureaucratic machinery of the Department of Defense prioritized formal verification over operational reality. The tiger team ethos—messy, irreverent, and intensely focused on finding the single practical crack in the real-world armor—was largely sidelined within the defense establishment in favor of rigid compliance checklists.
Yet the technical instincts that James Anderson, Paul Karger, Roger Schell, Robert Abbott, and Marvin Schaefer had pioneered could not be contained within classified military annexes. The underlying reality of computing was moving in the exact opposite direction of the Orange Book's orderly, top-down architecture. As the 1970s bled into the 1980s, the era of the isolated mainframe managed by a professional priesthood was coming to a rapid close.
In corporate offices, research universities, and suburban homes across the United States, computing was decentralizing at breakneck speed. Minicomputers like the DEC VAX were replacing mainframes, and small, inexpensive personal microcomputers were landing on the desks of engineers, students, and hobbyists. Most importantly, these machines were being tethered to acoustic-coupler modems and linked directly to the public switched telephone network. The ARPANET was quietly mutating into a broader internetwork of academic and commercial nodes.
The environments that the early tiger teams had probed were tightly controlled, highly specialized, and accessible only to individuals with high-level security clearances or corporate credentials. Now, an entire generation of young people was growing up with direct access to keyboards, phone lines, and free time. They possessed none of the institutional access of a MITRE engineer or a RAND researcher, but they shared the exact same psychological impulse: the compulsive need to poke at complex electronic systems to see where they would break.
The Cold War tiger teams had proven that every computer system was vulnerable to an adversary who understood its internal logic better than the people who built it. They had invented the philosophy of the controlled trespass, mapped the foundational categories of software vulnerability, and demonstrated that the only way to measure security was through direct, adversarial engagement. What they could not have foreseen was that in just a few short years, this dangerous, rarefied tradecraft would escape the sterile military cleanroom entirely, finding a new, unruly home among a legion of adolescent outsiders armed with nothing more than cheap Commodore 64s, pirate modems, and the telephone system's dial tone.
This is a sample preview. The complete book contains 27 sections.