Netflix has a new documentary series airing next week — “Web of Make Believe: Death, Lies & the Internet” — in which Yours Truly apparently has a decent amount of screen time. The debut episode explores the far-too-common harassment tactic of “swatting” — wherein fake bomb threats or hostage situations are phoned in to police as part of a scheme to trick them into visiting potentially deadly force on a target’s address.

The producers of the Netflix show said footage from an interview I sat for in early 2020 on swatting and other threats should appear in the first episode. They didn’t specify what additional topics the series would scrutinize, but Netflix’s teaser for the show suggests it concerns cybercrimes that result in deadly, real-world kinetic attacks.

“Conspiracy. Fraud. Violence. Murder,” reads the Netflix short description for the series. “What starts out virtual can get real all too quickly — and when the web is worldwide, so are the consequences.”

Our family has been victimized by multiple swatting attacks over the past decade. Our first swatting, in March 2013, resulted in Fairfax County, Va. police surrounding our home and forcing me into handcuffs at gunpoint. For an excruciating two minutes, I had multiple police officers pointing rifles, shotguns and pistols directly at me.

More recently, our family was subjected to swatting attacks by a neo-Nazi group that targeted journalists, judges and corporate executives. We’ve been fortunate that none of our swatting events ended in physical harm, and that our assailants have all faced justice.

But these dangerous hoaxes can quickly turn deadly: In March 2019, 26-year-old serial swatter Tyler Barriss was sentenced to 20 years in prison for making a phony emergency call to police in late 2017 that resulted in the shooting death of an innocent Kansas resident.

In 2021, an 18-year-old Tennessee man who helped set in motion a fraudulent distress call to police that led to the death of a 60-year-old grandfather in was sentenced to five years in prison.

The first season of the new documentary series will be available on Netflix starting June 15. See you on TV!

The U.S. Department of Justice (DOJ) recently revised its policy on charging violations of the Computer Fraud and Abuse Act (CFAA), a 1986 law that remains the primary statute by which federal prosecutors pursue cybercrime cases. The new guidelines state that prosecutors should avoid charging security researchers who operate in “good faith” when finding and reporting vulnerabilities. But legal experts continue to advise researchers to proceed with caution, noting the new guidelines can’t be used as a defense in court, nor are they any kind of shield against civil prosecution.

In a statement about the changes, Deputy Attorney General Lisa O. Monaco said the DOJ “has never been interested in prosecuting good-faith computer security research as a crime,” and that the new guidelines “promote cybersecurity by providing clarity for good-faith security researchers who root out vulnerabilities for the common good.”

What constitutes “good faith security research?” The DOJ’s new policy (PDF) borrows language from a Library of Congress rulemaking (PDF) on the Digital Millennium Copyright Act (DMCA), a similarly controversial law that criminalizes production and dissemination of technologies or services designed to circumvent measures that control access to copyrighted works. According to the government, good faith security research means:

“…accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.”

“Security research not conducted in good faith — for example, for the purpose of discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services — might be called ‘research,’ but is not in good faith.”

The new DOJ policy comes in response to a Supreme Court ruling last year in Van Buren v. United States (PDF), a case involving a former police sergeant in Florida who was convicted of CFAA violations after a friend paid him to use police resources to look up information on a private citizen.

But in an opinion authored by Justice Amy Coney Barrett, the Supreme Court held that the CFAA does not apply to a person who obtains electronic information that they are otherwise authorized to access and then misuses that information.

Orin Kerr, a law professor at University of California, Berkeley, said the DOJ’s updated policy was not unexpected given the Supreme Court ruling in the Van Buren case. Kerr noted that while the new policy says one measure of “good faith” involves researchers taking steps to prevent harm to third parties, what exactly those steps might constitute is another matter.

“The DOJ is making clear they’re not going to prosecute good faith security researchers, but be really careful before you rely on that,” Kerr said. “First, because you could still get sued [civilly, by the party to whom the vulnerability is being reported], but also the line as to what is legitimate security research and what isn’t is still murky.”

Kerr said the new policy also gives CFAA defendants no additional cause for action.

“A lawyer for the defendant can make the pitch that something is good faith security research, but it’s not enforceable,” Kerr said. “Meaning, if the DOJ does bring a CFAA charge, the defendant can’t move to dismiss it on the grounds that it’s good faith security research.”

Kerr added that he can’t think of a CFAA case where this policy would have made a substantive difference.

“I don’t think the DOJ is giving up much, but there’s a lot of hacking that could be covered under good faith security research that they’re saying they won’t prosecute, and it will be interesting to see what happens there,” he said.

The new policy also clarifies other types of potential CFAA violations that are not to be charged. Most of these include violations of a technology provider’s terms of service, and here the DOJ says “violating an access restriction contained in a term of service are not themselves sufficient to warrant federal criminal charges.” Some examples include:

-Embellishing an online dating profile contrary to the terms of service of the dating website;
-Creating fictional accounts on hiring, housing, or rental websites;
-Using a pseudonym on a social networking site that prohibits them;
-Checking sports scores or paying bills at work.

ANALYSIS

Kerr’s warning about the dangers that security researchers face from civil prosecution is well-founded. KrebsOnSecurity regularly hears from security researchers seeking advice on how to handle reporting a security vulnerability or data exposure. In most of these cases, the researcher isn’t worried that the government is going to come after them: It’s that they’re going to get sued by the company responsible for the security vulnerability or data leak.

Often these conversations center around the researcher’s desire to weigh the rewards of gaining recognition for their discoveries with the risk of being targeted with costly civil lawsuits. And almost just as often, the source of the researcher’s unease is that they recognize they might have taken their discovery just a tad too far.

Here’s a common example: A researcher finds a vulnerability in a website that allows them to individually retrieve every customer record in a database. But instead of simply polling a few records that could be used as a proof-of-concept and shared with the vulnerable website, the researcher decides to download every single file on the server.

Not infrequently, there is also concern because at some point the researcher suspected that their automated activities might have actually caused stability or uptime issues with certain services they were testing. Here, the researcher is usually concerned about approaching the vulnerable website or vendor because they worry their activities may already have been identified internally as some sort of external cyberattack.

What do I take away from these conversations? Some of the most trusted and feared security researchers in the industry today gained that esteem not by constantly taking things to extremes and skirting the law, but rather by publicly exercising restraint in the use of their powers and knowledge — and by being effective at communicating their findings in a way that maximizes the help and minimizes the potential harm.

If you believe you’ve discovered a security vulnerability or data exposure, try to consider first how you might defend your actions to the vulnerable website or vendor before embarking on any automated or semi-automated activity that the organization might reasonably misconstrue as a cyberattack. In other words, try as best you can to minimize the potential harm to the vulnerable site or vendor in question, and don’t go further than you need to prove your point.

Costa Rica’s national health service was hacked sometime earlier this morning by a Russian ransomware group known as Hive. The intrusion comes just weeks after Costa Rican President Rodrigo Chaves declared a state of emergency in response to a data ransom attack from a different Russian ransomware gang — Conti. Ransomware experts say there is good reason to believe the same cybercriminals are behind both attacks, and that Hive has been helping Conti rebrand and evade international sanctions targeting extortion payouts to cybercriminals operating in Russia.

The Costa Rican publication CRprensa.com reports that affected systems at the Costa Rican Social Security Fund (CCSS) were taken offline on the morning of May 31, but that the extent of the breach was still unclear. The CCSS is responsible for Costa Rica’s public health sector, and worker and employer contributions are mandated by law.

A copy of the ransom note left behind by the intruders and subsequently uploaded to Virustotal.com indicates the CCSS intrusion was the work of Hive, which typically demands payment for a digital key needed to unlock files and servers compromised by the group’s ransomware.

On May 8, President Chaves used his first day in office to declare a national state of emergency after the Conti ransomware group threatened to publish gigabytes of sensitive data stolen from Costa Rica’s Ministry of Finance and other government agencies. Conti initially demanded $10 million, and later doubled the amount when Costa Rica refused to pay. On May 20, Conti leaked more than 670 gigabytes of data taken from Costa Rican government servers.

As CyberScoop reported on May 17, Chaves told local media he believed that collaborators within Costa Rica were helping Conti extort the government. Chaves offered no information to support this claim, but the timeline of Conti’s descent on Costa Rica is worth examining.

Most of Conti’s public communications about the Costa Rica attack have very clearly assigned credit for the intrusion to an individual or group calling itself “unc1756.” In March 2022, a new user by the same name registered on the Russian language crime forum Exploit.

On the evening of April 18, Costa Rica’s Ministry of Finance disclosed the Conti intrusion via Twitter. Earlier that same day, the user unc1756 posted a help wanted ad on Exploit saying they were looking to buy access to “special networks” in Costa Rica.

“By special networks I mean something like Haciendas,” unc1756 wrote on Exploit. Costa Rica’s Ministry of Finance is known in Spanish as the “Ministerio Hacienda de Costa Rica.” Unc1756 said they would pay $USD 500 or more for such access, and would work only with Russian-speaking people.

THE NAME GAME DISTRACTION

Experts say there are clues to suggest Conti and Hive are working together in their attacks on Costa Rica, and that the intrusions are tied to a rebranding effort by Conti. Shortly after Russia invaded Ukraine at the end of February, Conti declared its full support, aligning itself directly with Russia and against anyone who would stand against the motherland.

Conti quickly deleted the declaration from its website, but the damage had already been done, and any favor or esteem that Conti had earned among the Ukrainian cybercriminal underground effectively evaporated overnight.

Shortly thereafter, a Ukrainian security expert leaked many months worth of internal chat records between Conti personnel as they plotted and executed attacks against hundreds of victim organizations. Those candid messages exposed what it’s like to work for Conti, how they undermined the security of their targets, as well as how the group’s leaders strategized for the upper hand in ransom negotiations.

But Conti’s declaration of solidarity with the Kremlin also made it increasingly ineffective as an instrument of financial extortion. According to cyber intelligence firm ADVIntel, Conti’s alliance with the Russian state soon left it largely unable to receive ransom payments because victim companies are being advised that paying a Conti ransom demand could mean violating U.S. economic sanctions on Russia.

“Conti as a brand became associated with the Russian state — a state that is currently undergoing extreme sanctions,” ADVIntel wrote in a lengthy analysis (PDF). “In the eyes of the state, each ransom payment going to Conti may have potentially gone to an individual under sanction, turning simple data extortion into a violation of OFAC regulation and sanction policies against Russia.”

ADVIntel says it first learned of Conti’s intrusion into Costa Rican government systems on April 14, and that it has seen internal Conti communications indicating that getting paid in the Costa Rica attack was not the goal.

Rather, ADVIntel argues, Conti was simply using it as a way to appear publicly that it was still operating as the world’s most lucrative ransomware collective, when in reality the core Conti leadership was busy dismantling the crime group and folding themselves and top affiliates into other ransomware groups that are already on friendly terms with Conti.

“The only goal Conti had wanted to meet with this final attack was to use the platform as a tool of publicity, performing their own death and subsequent rebirth in the most plausible way it could have been conceived,” ADVIntel concluded.

ADVIntel says Conti’s leaders and core affiliates are dispersing to several Conti-loyal crime collectives that use either ransomware lockers or strictly engage in data theft for ransom, including AlphV/BlackCat, AvosLocker, BlackByte, HelloKitty, Hive, and Karakurt.

Still, Hive appears to be perhaps the biggest beneficiary of any attrition from Conti: Twice over the past week, both Conti and Hive and claimed responsibility for hacking the same companies. When the discrepancy was called out on Twitter, Hive updated its website to claim it was not affiliated with Conti.

Conti and Hive’s Costa Rican exploits mark the latest in a string of recent cyberattacks against government targets across Latin America. Around the same time it hacked Costa Rica in April, Conti announced it had hacked Peru’s National Directorate of Intelligence, threatening to publish sensitive stolen data if the government did not pay a ransom.

But Conti and Hive are not alone in targeting Latin American victims of late. According to data gathered from the victim shaming blogs maintained by multiple ransomware groups, over the past 90 days ransom actors have hacked and sought to extort 15 government agencies in Brazil, nine in Argentina, six in Columbia, four in Ecuador and three in Chile.

A recent report (PDF) by the Inter-American Development Bank suggests many Latin American countries lack the technical expertise or cybercrime laws to deal with today’s threats and threat actors.

“This study shows that the Latin American and Caribbean (LAC) region is not sufficiently prepared to handle cyberattacks,” the IADB document explains. “Only 7 of the 32 countries studied have a critical infrastructure protection plan, while 20 have established cybersecurity incident response teams, often called CERTs or CSIRTs. This limits their ability to identify and respond to attacks.”

Some of more tech-savvy Democrats in the U.S. Senate are asking the Federal Trade Commission (FTC) to investigate identity-proofing company ID.me for “deceptive statements” the company and its founder allegedly made over how they handle facial recognition data collected on behalf of the Internal Revenue Service, which until recently required anyone seeking a new IRS account online to provide a live video selfie to ID.me.

In a letter to FTC Chair Lina Khan, the Senators charge that ID.me’s CEO Blake Hall has offered conflicting statements about how his company uses the facial scan data it collects on behalf of the federal government and many states that use the ID proofing technology to screen applicants for unemployment insurance.

The lawmakers say that in public statements and blog posts, ID.me has frequently emphasized the difference between two types of facial recognition: One-to-one, and one-to-many. In the one-to-one approach, a live video selfie is compared to the image on a driver’s license, for example. One-to-many facial recognition involves comparing a face against a database of other faces to find any potential matches.

Americans have particular reason to be concerned about the difference between these two types of facial recognition, says the letter to the FTC, signed by Sens. Cory Booker (D-N.J.), Edward Markey (D-Mass.), Alex Padilla (D-Calif.), and Ron Wyden (D-Ore.):

“While one-to-one recognition involves a one-time comparison of two images in order to confirm an applicant’s identity, the use of one-to-many recognition means that millions of innocent people will have their photographs endlessly queried as part of a digital ‘line up.’ Not only does this violate individuals’ privacy, but the inevitable false matches associated with one-to-many recognition can result in applicants being wrongly denied desperately-needed services for weeks or even months as they try to get their case reviewed.”

“This risk is especially acute for people of color: NIST’s Facial Recognition Vendor Test found that many facial recognition algorithms have rates of false matches that are as much as 100 times higher for individuals from countries in West Africa, East Africa and East Asia than for individuals from Eastern European countries. This means Black and Asian Americans could be disproportionately likely to be denied benefits due to a false match in a one-to-many facial recognition system.”

The lawmakers say that throughout the latter half of 2021, ID.me published statements and blog posts stating it did not use one-to-many facial recognition and that the approach was “problematic” and “tied to surveillance operations.” But several days after a Jan. 16, 2022 post here about the IRS’s new facial ID requirement went viral and prompted a public backlash, Hall acknowledged in a LinkedIn posting that ID.me does use one-to-many facial recognition.

“Within days, the company edited the numerous blog posts and white papers on its website that previously stated the company did not use one-to-many to reflect the truth,” the letter alleges. “According to media reports, the company’s decision to correct its prior misleading statements came after mounting internal pressure from its employees.”

Cyberscoop’s Tonya Riley published excerpts from internal ID.me employee Slack messages wherein some expressed dread and unease with the company’s equivocation on its use of one-to-many facial recognition.

In February, the IRS announced it would no longer require facial scans or other biometric data from taxpayers seeking to create an account at the agency’s website. The agency also pledged that any biometric data shared with ID.me would be permanently deleted.

But the IRS still requires new account applicants to sign up with either ID.me or Login.gov, a single sign-on solution already used to access 200 websites run by 28 federal agencies. It also still offers the option of providing a live selfie for verification purposes, although the IRS says this data will be deleted automatically.

Asked to respond to concerns raised in the letter from Senate lawmakers, ID.me instead touted its successes in stopping fraud.

“Five state workforce agencies have publicly credited ID.me with helping to prevent $238 billion dollars in fraud,” the statement reads. “Conditions were so bad during the pandemic that the deputy assistant director of the FBI called the fraud ‘an economic attack on the United States.’ ID.me played a critical role in stopping that attack in more than 20 states where the service was rapidly adopted for its equally important ability to increase equity and verify individuals left behind by traditional options. We look forward to cooperating with all relevant government bodies to clear up any misunderstandings.”

As Cyberscoop reported on Apr. 14, the House Oversight and Reform Committee last month began an investigation into ID.me’s practices, with committee chairwoman Carolyn Maloney (D-N.Y.) saying the committee’s questions to the company would help shape policy on how the government wields facial recognition technology.

A copy of the letter the senators sent to the FTC is here (PDF).

Millions of U.S. government employees and contractors have been issued a secure smart ID card that enables physical access to buildings and controlled spaces, and provides access to government computer networks and systems at the cardholder’s appropriate security level. But many government employees aren’t issued an approved card reader device that lets them use these cards at home or remotely, and so turn to low-cost readers they find online. What could go wrong? Here’s one example.

KrebsOnSecurity recently heard from a reader — we’ll call him “Mark” because he wasn’t authorized to speak to the press — who works in IT for a major government defense contractor and was issued a Personal Identity Verification (PIV) government smart card designed for civilian employees. Not having a smart card reader at home and lacking any obvious guidance from his co-workers on how to get one, Mark opted to purchase a $15 reader from Amazon that said it was made to handle U.S. government smart cards.

The USB-based device Mark settled on is the first result that currently comes up one when searches on Amazon.com for “PIV card reader.” The card reader Mark bought was sold by a company called Saicoo, whose sponsored Amazon listing advertises a “DOD Military USB Common Access Card (CAC) Reader” and has more than 11,700 mostly positive ratings.

The Common Access Card (CAC) is the standard identification for active duty uniformed service personnel, selected reserve, DoD civilian employees, and eligible contractor personnel. It is the principal card used to enable physical access to buildings and controlled spaces, and provides access to DoD computer networks and systems.

Mark said when he received the reader and plugged it into his Windows 10 PC, the operating system complained that the device’s hardware drivers weren’t functioning properly. Windows suggested consulting the vendor’s website for newer drivers.

So Mark went to the website mentioned on Saicoo’s packaging and found a ZIP file containing drivers for Linux, Mac OS and Windows:

Out of an abundance of caution, Mark submitted Saicoo’s drivers file to Virustotal.com, which simultaneously scans any shared files with more than five dozen antivirus and security products. Virustotal reported that some 43 different security tools detected the Saicoo drivers as malicious. The consensus seems to be that the ZIP file currently harbors a malware threat known as Ramnit, a fairly common but dangerous trojan horse that spreads by appending itself to other files.

Ramnit is a well-known and older threat — first surfacing more than a decade ago — but it has evolved over the years and is still employed in more sophisticated data exfiltration attacks. Amazon said in a written statement that it was investigating the reports.

“Seems like a potentially significant national security risk, considering that many end users might have elevated clearance levels who are using PIV cards for secure access,” Mark said.

Mark said he contacted Saicoo about their website serving up malware, and received a response saying the company’s newest hardware did not require any additional drivers. He said Saicoo did not address his concern that the driver package on its website was bundled with malware.

In response to KrebsOnSecurity’s request for comment, Saicoo sent a somewhat less reassuring reply.

“From the details you offered, issue may probably caused by your computer security defense system as it seems not recognized our rarely used driver & detected it as malicious or a virus,” Saicoo’s support team wrote in an email.

“Actually, it’s not carrying any virus as you can trust us, if you have our reader on hand, please just ignore it and continue the installation steps,” the message continued. “When driver installed, this message will vanish out of sight. Don’t worry.”

The trouble with Saicoo’s apparently infected drivers may be little more than a case of a technology company having their site hacked and responding poorly. Will Dormann, a vulnerability analyst at CERT/CC, wrote on Twitter that the executable files (.exe) in the Saicoo drivers ZIP file were not altered by the Ramnit malware — only the included HTML files.

Dormann said it’s bad enough that searching for device drivers online is one of the riskiest activities one can undertake online.

“Doing a web search for drivers is a VERY dangerous (in terms of legit/malicious hit ration) search to perform, based on results of any time I’ve tried to do it,” Dormann added. “Combine that with the apparent due diligence of the vendor outlined here, and well, it ain’t a pretty picture.”

But by all accounts, the potential attack surface here is enormous, as many federal employees clearly will purchase these readers from a myriad of online vendors when the need arises. Saicoo’s product listings, for example, are replete with comments from customers who self-state that they work at a federal agency (and several who reported problems installing drivers).

A thread about Mark’s experience on Twitter generated a strong response from some of my followers, many of whom apparently work for the U.S. government in some capacity and have government-issued CAC or PIV cards.

Two things emerged clearly from that conversation. The first was general confusion about whether the U.S. government has any sort of list of approved vendors. It does. The General Services Administration (GSA), the agency which handles procurement for federal civilian agencies, maintains a list of approved card reader vendors at idmanagement.gov (Saicoo is not on that list). [Thanks to @MetaBiometrics and @shugenja for the link!]

The other theme that ran through the Twitter discussion was the reality that many people find buying off-the-shelf readers more expedient than going through the GSA’s official procurement process, whether it’s because they were never issued one or the reader they were using simply no longer worked or was lost and they needed another one quickly.

“Almost every officer and NCO [non-commissioned officer] I know in the Reserve Component has a CAC reader they bought because they had to get to their DOD email at home and they’ve never been issued a laptop or a CAC reader,” said David Dixon, an Army veteran and author who lives in Northern Virginia. “When your boss tells you to check your email at home and you’re in the National Guard and you live 2 hours from the nearest [non-classified military network installation], what do you think is going to happen?”

Interestingly, anyone asking on Twitter about how to navigate purchasing the right smart card reader and getting it all to work properly is invariably steered toward militarycac.com. The website is maintained by Michael Danberry, a decorated and retired Army veteran who launched the site in 2008 (its text and link-heavy design very much takes one back to that era of the Internet and webpages in general). His site has even been officially recommended by the Army (PDF). Mark shared emails showing Saicoo itself recommends militarycac.com.

“The Army Reserve started using CAC logon in May 2006,” Danberry wrote on his “About” page. “I [once again] became the ‘Go to guy’ for my Army Reserve Center and Minnesota. I thought Why stop there? I could use my website and knowledge of CAC and share it with you.”

Danberry did not respond to requests for an interview — no doubt because he’s busy doing tech support for the federal government. The friendly message on Danberry’s voicemail instructs support-needing callers to leave detailed information about the issue they’re having with CAC/PIV card readers.

Dixon said Danberry has “done more to keep the Army running and connected than all the G6s [Army Chief Information Officers] put together.”

In many ways, Mr. Danberry is the equivalent of that little known software developer whose tiny open-sourced code project ends up becoming widely adopted and eventually folded into the fabric of the Internet.  I wonder if he ever imagined 15 years ago that his website would one day become “critical infrastructure” for Uncle Sam?