Password spraying against research labs: an old attack on a new target

The week

On May 5, 2020, two agencies issued a joint advisory. One was the US Cybersecurity and Infrastructure Security Agency (CISA), the federal government’s lead civilian cyber defense agency. The other was the UK National Cyber Security Centre (NCSC), its British counterpart. It warned that advanced persistent threat groups were targeting organizations involved in the COVID-19 response. “Advanced persistent threat,” usually shortened to APT, is the term for well-resourced hacking teams, typically linked to a nation’s government, that pursue specific targets patiently over long periods, more like spies than burglars.

What the advisory said

The targets included health care bodies, pharmaceutical companies, academia, medical research organizations and local governments. The advisory said the groups were likely seeking information on national and international health policy and COVID-19 research. More broadly, it said such groups aimed to collect bulk personal information, intellectual property and intelligence aligned with national priorities. It also noted that both agencies were investigating incidents at pharmaceutical, research and university organizations.

That spring, some of the most valuable information in the world was held in university labs, hospital research offices and drug company servers. It included early findings about a new virus, plans for vaccines and treatments, and governments’ thinking about how to respond. It should not have been surprising that foreign intelligence services wanted it. What was striking was how ordinary their methods were.

The technique it highlighted was large-scale password spraying. Instead of trying thousands of passwords against one account, which quickly triggers a lockout, the attacker tries a handful of commonly used passwords against many accounts. The advisory described how attackers gathered names from online sources to build lists of likely accounts. It noted that common passwords often used the month, the season or the organization’s name. In past incidents, it said, attackers who broke into an email account had downloaded the organization’s global address list to find more targets.

The advisory also named the doors the attackers liked to use. It pointed to a vulnerability in Citrix remote access products, catalogued as CVE-2019-19781, and to flaws in VPN products from Pulse Secure, Fortinet and Palo Alto. All had been disclosed months earlier, and patches existed. Attackers were scanning for organizations that had not applied them.

The research the advisory had in mind was moving quickly. On May 1, the US Food and Drug Administration had issued an emergency use authorization for remdesivir, the first treatment authorized for COVID-19. Clinical trials of several vaccine candidates had begun in the United States and the United Kingdom since mid-March. Each trial generated data, manufacturing plans and regulatory filings that rivals and foreign governments had reason to want early.

The defenses it recommended

The recommended defenses were familiar. The advisory urged multi-factor authentication, which requires a second proof of identity, such as a code or a prompt on a phone, in addition to a password. It urged prompt patching of VPNs and other internet-facing services. A VPN, or virtual private network, is the secure tunnel that lets staff working from home connect to their organization’s internal systems, and patching means installing the fixes vendors release for security flaws.

It also recommended protecting the management interfaces of critical systems, collecting the monitoring data needed to investigate intrusions, and refreshing incident response plans. It pointed to guidance on choosing passwords and on blocking common ones through deny lists. And it recommended user awareness.

What came before and after

The advisory built on earlier warnings. On April 8, the same two agencies had published a joint alert on criminals and state groups exploiting the pandemic, mostly through phishing and fake COVID-19 lures. In mid-April, CISA had warned that attackers were still using credentials stolen from Pulse Secure VPNs before those devices were patched. Fixing the device had not removed the access already gained.

The joint authorship was itself a signal. Allied agencies publishing together, with shared technical detail, indicated that the activity was widespread and that both governments wanted defenders to act quickly.

The following week, on May 13, the FBI and CISA issued a separate warning about China-linked targeting of COVID-19 research. It said organizations researching vaccines, treatments and testing should expect to be targeted and should act accordingly.

For boards of hospitals, universities and life sciences companies, the message was uncomfortable. Their organizations were now intelligence targets, and the attackers were walking in through doors that basic hygiene could have closed.

Health systems usually plan for criminal attackers who want to encrypt systems or sell patient records. The May 2020 advisory described a different adversary with a different goal: state-backed groups after research and policy information. Password spraying is an old technique, and its defenses are well known. Academic medical centers, research hospitals and life sciences organizations found them hard to apply for structural reasons. The advisory pointed to three exposures, each shaped by how these institutions are organized: credentials spread across several identity systems, research data spread across collaboration tools, and remote access infrastructure stretched by the move home.

The technical fixes fit on a single page. What made them hard was structure. A bank or a manufacturer is one organization; an academic medical center is usually several, sharing people, buildings and a name, each with its own computer systems and its own leadership. Attackers do not care about those boundaries. Defenders have to.

The analysis starts with how a spray works, then takes the three exposures in turn. It follows one hypothetical institution through an intrusion and sets out how to turn an advisory into action. It closes with what the board stands to lose and how one owner can hold a federated risk together.

How a spray slips under the lockout

Every time someone signs in to email, a research portal or a remote access system, the system checks their credentials against a directory: the master list of accounts, passwords and permissions. Most large organizations run at least one, and the systems that rely on it are said to authenticate against it.

The arithmetic of guessing

Many systems protect themselves against guessing by locking an account after several wrong passwords in a row. Password spraying is designed to slip under that rule. The attacker takes a long list of usernames, often easy to work out from a public staff directory or email format. Then they try one common password against each, such as a season and a year. Then they wait, and try a second password. Each account sees only one or two failures, nothing that looks alarming. Across tens of thousands of accounts, a small percentage will use one of those passwords. A small percentage of a very large number is plenty.

Patient attackers make the pattern harder to see. They space attempts over hours or days so that failures fall outside the window a lockout rule counts. They send attempts from many internet addresses, so no single source looks busy. Some sign-in pages also reveal whether a username exists, which lets the attacker clean the list before guessing. Each of these is a design detail on the defender’s side, and each can be changed.

Why lockout is a blunt tool

Lockout rules carry their own trade-off. A strict rule, such as locking after three failures, stops slow guessing against a single account. It also lets an attacker lock out real users on purpose, which in a hospital can mean a clinician unable to reach records during a shift. Many identity platforms now offer adaptive lockout, which blocks attempts from suspicious sources while letting the real user in from a familiar device. Lockout still has a place. Spraying shows why it cannot be the main defense.

After the first account

Once inside one account, an attacker can read email, search shared drives, and look for ways to reach more sensitive systems. Because the access uses a real person’s real password, it can look like normal activity for a long time. The advisory’s note about global address lists shows the next step. A single mailbox yields a complete, accurate list of every colleague, which makes the next spray more efficient and makes phishing messages more convincing.

The second factor, and where it is missing

Multi-factor authentication breaks this chain. A guessed password is no longer enough; the attacker also needs the person’s phone or security key. For that reason it appears at the top of almost every advisory. The catch is that it only protects the doors where it is switched on. Some older systems use what are called legacy authentication protocols, older methods of signing in that were designed before multi-factor existed and simply skip the second check. A building with a guard at the front door and an unlocked loading dock is only as secure as the loading dock.

The legacy doors are often mundane. Older email clients and protocols that fetch mail with a username and password, scanners that send email, instrument computers in labs and scripts written years ago all tend to use them. Each was set up to make something work. Each also lets a sprayed password succeed without a prompt.

Not all second factors are equal either. Text-message codes can be intercepted or redirected. Push prompts can be approved by a tired user who did not start the sign-in. App-generated codes are better. Hardware security keys and similar methods, described as phishing-resistant, are strongest because they cannot be relayed by a fake sign-in page. For most institutions in 2020, the urgent step was to have any second factor on every door. The stronger methods were the next step, starting with administrators and remote access.

Credentials spread across several identity systems

Spraying works because some accounts in any large population use weak or common passwords, and because some services still accept a password alone. Academic medicine multiplies the targets. A physician-researcher may hold a hospital account, a university account and a research computing account, each with its own directory and password policy. Students, visiting scholars and affiliates add thousands more accounts with frequent turnover. Older applications often keep legacy authentication protocols enabled, and those protocols bypass multi-factor prompts.

The defenses that follow from structure

The defenses follow from that structure. Multi-factor authentication needs to cover every internet-facing entry point in every directory, including the ones set up for convenience. Legacy protocols that cannot support it should be disabled, with exceptions tracked and time-limited. Where directories cannot be merged, a common authentication policy across them removes the weakest link that attackers look for. Accounts of people who have left should be disabled promptly. Nobody notices when a dormant account is compromised.

Federation is one way to apply a common policy without merging everything. In a federated setup, one directory handles the sign-in and vouches for the user to other systems, using standards such as SAML. Many US universities already used federation to let researchers sign in to partner institutions’ services, often through the InCommon federation for research and education. Extending the same approach inside the institution, so that research systems trust the university or hospital sign-in, puts one multi-factor policy in front of many doors.

The account lifecycle

Turnover is the second structural problem. Employees leave through human resources, students through the registrar, and visiting scholars and affiliates often through no formal process at all. A sponsored account, created by a faculty member for a collaborator, may outlive the collaboration by years. Tying every account to an authoritative source, with an end date for any account that has no such source, closes the gap. A useful measure is the number of active accounts with no owner of record. In many institutions that number was large, and few knew it.

Shared and service accounts deserve their own list. Labs often run instruments through shared logins, and automated jobs use service accounts that cannot respond to a multi-factor prompt. Those accounts should be blocked from signing in from the internet, given long random passwords and reviewed by a named owner. They are exactly the accounts a spray will find if they use a simple password.

Rolling out the second factor

Turning on multi-factor for tens of thousands of people is a project in its own right. Students, affiliates and part-time clinicians need a way to enroll, and help desks need capacity for lost phones and locked-out users. Some staff cannot or will not use a personal phone, so hardware tokens or other options must be ready. The rollout usually starts with remote access and administrators, then email, then everything else facing the internet.

Enrollment itself is a weak point. If an account without multi-factor can register a new device simply by signing in with its password, an attacker who sprayed that password can register their own device first. The defender has then locked the attacker in rather than out. Enrollment should require a check beyond the password, such as a one-time code delivered through a verified channel, or an in-person or video identity check for high-risk roles. Accounts that have not enrolled by a deadline should be blocked from signing in from the internet, not left waiting.

Detection across directories

Detection needs a cross-directory view too. Spraying shows up as many failed sign-ins spread across many accounts from the same sources, each account failing only once or twice. A security team watching one directory at a time may miss the pattern entirely. Sending sign-in logs from all directories to one place, with an alert for that signature, closes the gap. A log here is just the system’s record of each attempt to sign in: who, when, from where and whether it worked.

The most important alert is the success that follows a spray. Hundreds of failures matter less than the one account that then signed in successfully from the same source. That account should be disabled, its password reset and its recent activity reviewed at once. Other useful signals include sign-ins from hosting providers rather than homes or offices, and a single account signing in from two distant places in a short time.

Passwords and people

Users are part of the control. Spraying succeeds against passwords like a season and a year, or the institution’s name with a number. Banning common and organization-specific passwords at the directory level removes most of them without relying on training. NIST’s digital identity guidelines, published in 2017, already recommended screening new passwords against lists of common and compromised ones. Where multi-factor prompts are pushed to phones, users also need to know to reject a prompt they did not start, and how to report it. A reported unexpected prompt is often the first sign that a password has already been guessed.

How it differs by type of organization

The scale of the identity problem tracks the structure. A standalone community hospital usually has one directory and a modest number of affiliates, so a common policy is largely a configuration task. An academic medical center may have three or more directories under separate leadership, which makes it a governance task. A biotech company has one directory but many contractors and partners with guest access. A contract research organization holds sponsors’ data under strict agreements, with sponsors auditing its controls. A public university hospital may also be bound by state security standards. The defenses are the same in each case; the effort lies in different places.

Research data spread across collaboration tools

COVID research in 2020 moved fast and involved many partners. Data moved through cloud storage, collaboration platforms and email, often outside systems the security team monitored. Unlike patient data, research data is rarely classified or inventoried. It is hard to protect what an institution does not know it holds.

Hospitals have spent years learning where patient records live, because federal health privacy law demands it. Research data has no equivalent habit. A laboratory may hold the most commercially and strategically sensitive information in the institution in a shared folder created by a postdoctoral researcher. That folder may be shared with collaborators at three other universities, with no record anywhere of what is in it.

Classification that covers research

The control starts with classification that covers research assets: unpublished results, assay data, trial designs and sponsor materials. Classification just means labeling information by how sensitive it is, the way a government marks documents “confidential” or “secret,” so that everyone knows how to handle it. Clear rules should say where each class may be stored and how it may be shared. Principal investigators need approved tools that are easier to use than the alternatives, or they will choose the alternatives.

Many universities already used a tiered scheme, often three or four levels, for institutional data. Extending it to research usually means adding examples researchers recognize, such as “unpublished sequence data” or “sponsor’s manufacturing process,” to the definitions. A label is only useful if it changes something. The highest tier should map to a specific storage location, a specific sharing method and a named data steward.

Obligations that come with the money

Research agreements with sponsors and government funders often carry their own security terms. A research administration office that records those terms against each project lets the security team know which data carries extra obligations. The obligations vary widely. Industry sponsors write confidentiality and incident notification clauses into contracts. Some defense-funded work involves controlled unclassified information, which carries specific federal safeguarding requirements. Export control rules can restrict who may access certain technical data. Clinical research data held by a hospital may also be protected health information under HIPAA.

Universities with academic medical centers often operate as HIPAA hybrid entities. Only the parts that perform covered health care functions are bound by HIPAA, so the same data can carry different obligations depending on where it is held. A research dataset copied from the hospital into a university lab can change its legal treatment along the way. Institutions should check with counsel how these rules apply to particular projects.

Secure enclaves and the openness trade-off

For the most sensitive projects, some institutions built secure research environments, often called enclaves. These are controlled computing spaces where data stays inside, access requires strong sign-in, and exports are reviewed. They work well for defined datasets. They also slow collaboration, which cuts against a research culture built on openness and speed.

The trade-off was sharp in 2020. Much COVID-19 research was posted rapidly as preprints, so one could argue there was little secret to steal. That argument misses what was not published: assay methods, manufacturing processes, trial designs, negotiating positions and early data before peer review. The value of stealing those lay in timing and in insight into rivals’ plans. Enclaves suit that material, while openly shared data can stay in ordinary tools.

Who owns research data

Ownership of research data is often unclear. Investigators tend to regard it as theirs, institutions usually claim it in their policies, and sponsors may own some of it by contract. Security decisions need a working answer. A practical model makes the principal investigator the data steward for each project, the research office the keeper of obligations, and the security team the provider of approved tools and monitoring. Each knows what it is accountable for, and none has to guess.

Access reviews matter here as well. Research collaborations end, but shared folders and guest accounts often persist. A quarterly review of external sharing on sensitive projects, owned by the project lead, shrinks the exposure without slowing active work.

Remote access infrastructure under load

The advisory also highlighted vulnerable VPN appliances. An appliance in this sense is a dedicated piece of equipment, often a box in a data center, that operates at the edge of the network and lets authorized people in from outside. Because it faces the internet, it is the first thing an attacker sees.

Old flaws, new load

By May 2020, many health and research organizations had expanded VPN capacity quickly, sometimes by deploying new devices or reviving old ones. Several VPN products had serious vulnerabilities disclosed in 2019 that were still being exploited. Patching an appliance that the whole remote workforce depended on was operationally hard, because downtime hit everyone, clinicians included.

The flaws named in the advisory were particularly damaging because of where they lived. A vulnerability in a remote access gateway can let an attacker read files on the device, including stored credentials or session information, without signing in. The attacker then holds working passwords that no spray was needed to obtain. Some of these flaws were also used to plant hidden programs, called web shells, that survived the patch.

Patching without stopping care

The response is to treat remote access appliances as high-priority assets. That means planned maintenance windows, redundancy that allows patching one device while another carries the load, and monitoring for signs of compromise. In a hospital, remote access may carry radiologists reading images from home, on-call physicians reaching the EHR and billing staff working offsite. Maintenance windows should be agreed with clinical leaders in advance, so a critical patch is not delayed while someone negotiates downtime.

Credentials harvested from a vulnerable appliance remain useful to an attacker after the appliance is patched. Patching should therefore be followed by password resets for affected accounts, review of sessions and accounts created while the device was exposed, and a check for unfamiliar administrative changes. That last point is often missed. Patching fixes the hole; it does not evict anyone who already came through it.

Beyond the VPN

Some institutions used the 2020 experience to start moving away from network-level VPNs toward access that is granted application by application. Under that model, a user signs in through the central identity system and reaches only the specific applications they need, rather than the whole internal network. It reduces what one compromised account can reach. It is also a multi-year change, touching every application, and in 2020 it was no substitute for patching the appliances already in place. The sound sequence was to patch and harden first, then plan the move.

Knowing what faces the internet

None of this works without an accurate list of what is exposed. Federated institutions often discover devices they did not know they had: a research group’s own VPN, an old remote desktop server, a vendor’s support gateway. Regular external scanning of the institution’s own internet addresses, compared with the asset inventory, finds them. Each discovered device needs an owner, a patch plan or a shutdown date.

One institution, three organizations

Consider a hypothetical academic medical center made up of a teaching hospital, a medical school within a university, and a research institute funded largely by grants and industry sponsors. Each has its own IT department. The hospital has strong multi-factor authentication, because it has been through several audits. The university has multi-factor for staff email but not for an older library system that still accepts passwords alone. The research institute runs its own directory for computing clusters, set up years ago by a scientist who has since moved on.

The intrusion

A senior virologist holds accounts in all three. Her university password, a season and a year, is guessed in a spray that tries one password against forty thousand accounts. The university’s security team sees nothing unusual; the failures are spread too thinly. Through the library system, the attacker confirms the password works. Because she reused it on the research directory, which does not require multi-factor, the attacker reaches a shared folder of unpublished data from a sponsor-funded study.

What would have stopped it

Now consider what would have stopped this. A common authentication policy across all three directories would have required multi-factor everywhere. Disabling the legacy protocol on the library system would have removed the unguarded test door. A password ban list would have rejected a season-and-year password. A combined view of sign-in logs would have shown one source failing once against tens of thousands of accounts. And a classification of sponsor data, recorded by the research office, would have told the security team where the most sensitive material was held. No single control is exotic. The gap was that no one person was accountable for all three organizations at once.

The aftermath

The aftermath is where the cost becomes visible. The research institute must now work out what was taken, a task made harder because nobody had recorded what was in the folder. The sponsor’s agreement requires notification of security incidents. The university must reset the virologist’s passwords everywhere and look for other accounts reached the same way. Each unit’s IT team, used to working alone, has to coordinate an investigation across boundaries it has never crossed before, under time pressure, with the board asking questions.

Several clocks start at once. If any patient information was in reach, the hospital’s privacy officer must assess whether HIPAA breach notification applies. The sponsor’s contract may set its own notification deadline. A federal funder may expect to be told. With a state-backed actor involved, the institution will likely work with the FBI, which affects what it can say publicly and when. Without an agreed incident plan across the three units, each of these decisions waits for someone to decide who decides.

Turning an advisory into action

Joint advisories like the May 2020 one arrive regularly, and they are written for technical staff. They typically contain a description of the threat and a set of recommended defenses. Most also list indicators of compromise, the fingerprints an attack leaves behind, such as particular internet addresses or file names. Their value depends entirely on what an organization does in the days after they land.

A four-step routine

A practical routine has four steps. First, someone is responsible for reading each relevant advisory as it arrives and deciding, quickly, whether it applies. For a research hospital in May 2020, this one plainly did. Second, the security team searches its own logs for the listed indicators, to see whether the attackers have already been there. Third, the team compares the recommended defenses with its current state, entry point by entry point and directory by directory, and lists the gaps. Fourth, the gaps are fixed or formally accepted by someone with authority, and the result is written down.

The routine needs a clock. Many security teams open a tracked work item for each applicable advisory, with a target of days for the log search and weeks for closing gaps. Each gap gets an owner and a due date. A gap that cannot be closed goes to a risk acceptance, signed by an executive, with a review date.

Sharing communities

Advisories are not the only source. Health-ISAC, the information sharing community for the health sector, and REN-ISAC, its counterpart for research and education networks, circulate warnings and indicators among members, often faster than formal advisories. An academic medical center may belong to both through different units. Making sure each warning reaches the security team of every unit, including those without their own membership, is a small step with a large effect.

The written record

That written record matters more than it might seem. A sponsor, an auditor or a board committee may later ask what the institution did in response to a warning about attacks on its sector. A dated note listing what was checked and changed is a far better answer than a recollection. It also shows, over time, whether the same gaps keep appearing in advisory after advisory, which is a sign that the problem is structural rather than technical.

Rehearsing it

The routine can be rehearsed before it is needed. A short tabletop exercise, using a past advisory such as the May 2020 one, asks each unit to say what it would search, what it would change and who would sign off. Gaps show up quickly: a unit that cannot search its own sign-in logs, or one with no one authorized to accept a risk. Fixing those in an uneventful month is far cheaper than discovering them during an intrusion.

In a federated institution, the routine has to run across every unit. If the hospital checks its logs and the university does not, the institution has checked half its doors. One coordinating owner, with the authority to ask each unit for its results, keeps the routine whole.

What the board stands to lose

For a hospital or university board, research theft can feel like a security team’s problem, but the consequences land on the institution’s most important relationships. Sponsors and government funders often write security obligations into research agreements, and a breach can put current and future funding at risk. Unpublished results can lose their value if they leak. Regulators and the public expect institutions entrusted with sensitive research to protect it. And an attacker who gets in to steal research may find a path to clinical systems too, where the cost is measured in disrupted care.

The evidence the board should see

A board does not need technical detail. It needs a few facts it can test. One is whether every internet-facing entry point in every unit requires multi-factor, with any exceptions named and dated. Another is whether the institution can see sign-in activity across all its directories in one place. A third is the date of the last response to a sector advisory, and what changed as a result. Sponsors and auditors increasingly ask for the same evidence, so preparing it for the board also prepares it for them.

The objections boards hear

Boards will hear objections, and some have weight. Clinicians object that multi-factor prompts slow them down at shared workstations and in procedure rooms. The answer is to design for the setting: tap-badge sign-in on shared clinical devices, longer sessions inside the building, and strong checks at the internet edge where spraying happens. Researchers object that controls slow collaboration. The answer is to put the strictest controls on a small set of classified projects and keep ordinary work in easy, approved tools.

A third objection is that a well-resourced state actor will get in regardless. Sometimes it will. But the May 2020 advisory described attackers choosing cheap methods first. Closing password-only doors forces them to spend more, use riskier techniques and leave more traces, which gives defenders time to notice.

A governance point beyond research

There is also a governance point that reaches beyond research. Wherever an organization is really a federation, with separate units sharing staff and systems, its security is set by the weakest unit. Fixing that takes the executive with authority over all of them, rather than the chief information security officer of any one unit.

One owner for a federated risk

All three exposures cross organizational lines. The hospital, the medical school and the research enterprise often run separate IT teams under separate governance, while attackers move freely between them. A shared inventory of external entry points and sensitive research assets, with one executive accountable for the combined risk, is the precondition for applying any of these defenses consistently. A routine for acting on joint advisories helps too: check the indicators, apply the recommendations, record what was done, within days.

How the ownership can work

The ownership can take several forms. Some institutions appoint a single chief information security officer for the whole enterprise, with authority over every unit. Others keep separate security teams but bind them with a written agreement: common minimum standards, shared logging, a joint incident plan and a single executive who reports combined risk to both boards. The second model is slower but often the only one the governance allows. Either works if one person can answer, with evidence, for the state of every door.

A short set of measures makes that answerable. They cover the share of internet-facing entry points requiring multi-factor in each directory, the number of legacy protocol exceptions and their age, and the number of accounts with no owner of record. They also cover the time to disable accounts of people who leave, and the time from advisory to completed log search. Reported quarterly to the combined risk committee, they show progress or its absence.

In practice, that means:

• Multi-factor authentication on every internet-facing entry point, in every directory, with phishing-resistant methods for administrators and remote access.
• Legacy sign-in methods switched off, with any exceptions listed and given an end date.
• Common and organization-specific passwords banned at the directory level.
• Sign-in logs from all directories in one place, with alerts tuned to spraying and to the success that follows it.
• Every account tied to an owner of record, with sponsored and service accounts reviewed.
• Research data classified, with sponsor and funder obligations recorded per project.
• Remote access appliances patched on a plan, followed by credential resets and a review of what happened while they were exposed.

The failures that recur:

• Declaring multi-factor “done” because email has it, while older systems still accept a password alone.
• Watching each directory separately and missing a pattern spread across all of them.
• Leaving guest accounts and external shares open long after a collaboration ends.
• Patching a vulnerable appliance and assuming the problem is over.
• Treating each joint advisory as news rather than as a checklist to act on and record.

Checking every door

1. How many separate directories do we run across the hospital, the school and research, and does every one require multi-factor authentication from outside?
2. Which systems still accept a password alone, and when will each one stop?
3. Can we see failed sign-ins across all our directories in one place, and would we notice a spray?
4. Where is our most sensitive research data, and which projects carry security terms from sponsors or funders?
5. Who, by name, is accountable for our external exposure across all parts of the institution?

With hindsight

In July 2020, the UK, US and Canadian governments publicly attributed attacks on COVID-19 vaccine research organizations to APT29, a group associated with Russian intelligence. The NCSC and Canada’s Communications Security Establishment assessed that the group was almost certainly part of the Russian intelligence services. The US National Security Agency agreed, and CISA endorsed the technical advice. The advisory described malware, called WellMess and WellMail, not previously linked to the group in public. Later that month, the US Justice Department charged two Chinese nationals with a long-running hacking campaign that, it said, had also targeted COVID-19 research.

In December 2020, the European Medicines Agency, the body that evaluates medicines for the European Union, disclosed that documents related to vaccine applications had been unlawfully accessed in a cyberattack. Targeting of research and health policy information continued well beyond the pandemic.

Research security became policy

Those events confirmed what the May advisory implied: research institutions had become intelligence targets in their own right, rather than collateral in someone else’s conflict. A university or hospital research office that thought of itself as an open, collaborative place had to accept that it also held information foreign governments wanted.

Federal policy followed. In January 2021, a national security presidential memorandum, NSPM-33, directed agencies to strengthen protections for federally funded research, including research security programs at institutions receiving large amounts of federal research funding. The CHIPS and Science Act of 2022 added research security requirements of its own. Research security moved from a niche concern to a standing compliance obligation for major research universities and their medical centers.

Legacy doors closed, slowly

Vendors moved on the legacy authentication problem too. Microsoft began retiring basic authentication, the password-only method behind many legacy protocols, in its Exchange Online email service from October 2022. Institutions that had relied on those protocols for old clients and devices had to replace them, which many had deferred since 2020.

The spraying technique itself never went away. In January 2024, Microsoft disclosed that Midnight Blizzard, a Russian state-sponsored group it also calls Nobelium, had used a password spray in late November 2023. The attack compromised a legacy, non-production test account. Microsoft later said that account did not have multi-factor authentication enabled. The group used it to reach a small percentage of Microsoft’s corporate email accounts, including senior leadership. The same family of actors, the same technique and the same kind of forgotten door appeared nearly four years after the 2020 advisory.

From spies to criminals, same entry point

The advisory’s core advice only grew more urgent. The 2024 attack on Change Healthcare, which disrupted claims and pharmacy operations across the United States, was described in congressional testimony as beginning with compromised credentials on a remote access portal that lacked multi-factor authentication. That is precisely the combination the 2020 advisory warned about: a password that worked, and a door from the internet with no second check.

The health sector’s own guidance hardened in parallel. In January 2024, HHS published voluntary cybersecurity performance goals for the health care and public health sector, with multi-factor authentication among the essential goals. At the end of 2024, HHS proposed HIPAA Security Rule updates that would make multi-factor authentication an explicit requirement for regulated entities, with limited exceptions. The HIPAA Security Rule is the federal regulation that sets baseline security standards for organizations handling patient information electronically. The proposal drew heavy comment from the sector about its cost and pace, and organizations should track its status with counsel.

What held up

The arc from 2020 to 2024 is sobering in its simplicity. The attackers changed, and so did their motives, from spies seeking research to criminals disrupting payments. The entry point stayed much the same. An organization that closed every password-only door to the internet in 2020, across every part of its structure, was protecting itself against threats that had not yet appeared.

What held up less well was the assumption that the fix was technical. The institutions that struggled most were rarely missing the technology. They were missing one owner with authority over every unit, every directory and every forgotten test account. The strongest case for treating basic controls as a board-level question rests there.