The U.S. Federal Communications Commission (FCC) is asking for feedback on new proposed rules to crack down on SIM swapping and number port-out fraud, increasingly prevalent scams in which identity thieves hijack a target’s mobile phone number and use that to wrest control over the victim’s online identity.

In a long-overdue notice issued Sept. 30, the FCC said it plans to move quickly on requiring the mobile companies to adopt more secure methods of authenticating customers before redirecting their phone number to a new device or carrier.

“We have received numerous complaints from consumers who have suffered significant distress, inconvenience, and financial harm as a result of SIM swapping and port-out fraud,” the FCC wrote. “Because of the serious harms associated with SIM swap fraud, we believe that a speedy implementation is appropriate.”

The FCC said the proposal was in response to a flood of complaints to the agency and the U.S. Federal Trade Commission (FTC) about fraudulent SIM swapping and number port-out fraud. SIM swapping happens when the fraudsters trick or bribe an employee at a mobile phone store into transferring control of a target’s phone number to a device they control.

From there, the attackers can reset the password for almost any online account tied to that mobile number, because most online services still allow people to reset their passwords simply by clicking a link sent via SMS to the phone number on file.

Scammers commit number port-out fraud by posing as the target and requesting that their number be transferred to a different mobile provider (and to a device the attackers control).

The FCC said the carriers have traditionally sought to address both forms of phone number fraud by requiring static data about the customer that is no longer secret and has been exposed in a variety of places already — such as date of birth and Social Security number. By way of example, the commission pointed to the recent breach at T-Mobile that exposed this data on 40 million current, past and prospective customers.

What’s more, victims of SIM swapping and number port-out fraud are often the last to know about their victimization. The FCC said it plans to prohibit wireless carriers from allowing a SIM swap unless the carrier uses a secure method of authenticating its customer. Specifically, the commission proposes that carriers be required to verify a “pre-established password” with customers before making any changes to their accounts.

According to the FCC, several examples of pre-established passwords include:

-a one-time passcode sent via text message to the account phone number or a pre-registered backup number
-a one-time passcode sent via email to the email address associated with the account
-a passcode sent using a voice call to the account phone number or pre-registered back-up telephone number.

The commission said it was also considering updating its rules to require wireless carriers to develop procedures for responding to failed authentication attempts and to notify customers immediately of any requests for SIM changes.

Additionally, the FCC said it may impose additional customer service, training, and transparency requirements for the carriers, noting that too many customer service personnel at the wireless carriers lack training on how to assist customers who’ve had their phone numbers stolen.

The FCC said some of the consumer complaints it has received “describe wireless carrier customer service representatives and store employees who do not know how to address instances of fraudulent SIM swaps or port-outs, resulting in customers spending many hours on the phone and at retail stores trying to get resolution. Other consumers complain that their wireless carriers have refused to provide them with documentation related to the fraudulent SIM swaps, making it difficult for them to pursue claims with their financial institutions or law enforcement.”

“Several consumer complaints filed with the Commission allege that the wireless carrier’s store employees are involved in the fraud, or that carriers completed SIM swaps despite the customer having previously set a PIN or password on the account,” the commission continued.

Allison Nixon, an expert on SIM swapping attacks chief research officer with New York City-based cyber intelligence firm Unit221B, said any new authentication requirements will have to balance the legitimate use cases for customers requesting a new SIM card when their device is lost or stolen. A SIM card is the small, removable smart card that associates a mobile device to its carrier and phone number.

“Ultimately, any sort of static defense is only going to work in the short term,” Nixon said. “The use of SMS as a 2nd factor in itself is a static defense. And the criminals adapted and made the problem actually worse than the original problem it was designed to solve. The long term solution is that the system needs to be responsive to novel fraud schemes and adapt to it faster than the speed of legislation.”

Eager to weigh in on the FCC’s proposal? They want to hear from you. The electronic comment filing system is here, and the docket number for this proceeding is WC Docket No. 21-341.

In February, KrebsOnSecurity wrote about a novel cybercrime service that helped attackers intercept the one-time passwords (OTPs) that many websites require as a second authentication factor in addition to passwords. That service quickly went offline, but new research reveals a number of competitors have since launched bot-based services that make it relatively easy for crooks to phish OTPs from targets.

Many websites now require users to supply both a password and a numeric code/OTP token sent via text message, or one generated by mobile apps like Authy and Google Authenticator. The idea is that even if the user’s password gets stolen, the attacker still can’t access the user’s account without that second factor — i.e. without access to the victim’s mobile device or phone number.

The OTP interception service featured earlier this year — Otp[.]agency — advertised a web-based bot designed to trick targets into giving up OTP tokens. The customer would enter a target’s phone number and name, and OTP Agency would initiate an automated phone call that alerts that person about unauthorized activity on their account.

The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”), and that code would then get relayed back to the bad guy customers’ panel at the OTP Agency website.

OTP Agency took itself offline within hours of that story. But according to research from cyber intelligence firm Intel 471, multiple new OTP interception services have emerged to fill that void. And all of them operate via Telegram, a cloud-based instant messaging system.

“Intel 471 has seen an uptick in services on the cybercrime underground that allow attackers to intercept one-time password (OTP) tokens,” the company wrote in a blog post today. “Over the past few months, we’ve seen actors provide access to services that call victims, appear as a legitimate call from a specific bank and deceive victims into typing an OTP or other verification code into a mobile phone in order to capture and deliver the codes to the operator. Some services also target other popular social media platforms or financial services, providing email phishing and SIM swapping capabilities.”

Intel471 says one new Telegram OTP bot called “SMSRanger” is popular because it’s remarkably easy to use, and probably because of the many testimonials posted by customers who seem happy with its frequent rate of success in extracting OTP tokens when the attacker already has the target’s “fullz,” personal information such as Social Security number and date of birth. From their analysis:

“Those who pay for access can use the bot by entering commands similar to how bots are used on popular workforce collaboration tool Slack. A simple slash command allows a user to enable various ‘modes’ — scripts aimed as various services — that can target specific banks, as well as PayPal, Apple Pay, Google Pay, or a wireless carrier.

Once a target’s phone number has been entered, the bot does the rest of the work, ultimately granting access to whatever account has been targeted. Users claim that SMSRanger has an efficacy rate of about 80% if the victim answered the call and the full information (fullz) the user provided was accurate and updated.”

Another OTP interception service called SMS Buster requires a tad more effort from a customer, Intel 471 explains:

“The bot provides options to disguise a call to make it appear as a legitimate contact from a specific bank while letting the attackers choose to dial from any phone number. From there, an attacker could follow a script to trick a victim into providing sensitive details such as an ATM personal identification number (PIN), card verification value (CVV) and OTP, which could then be sent to an individual’s Telegram account. The bot, which was used by attackers targeting Canadian victims, gives users the chance to launch attacks in French and English.” 

These services are springing up because they work and they’re profitable. And they’re profitable because far too many websites and services funnel users toward multi-factor authentication methods that can be intercepted, spoofed, or misdirected — like SMS-based one-time codes, or even app-generated OTP tokens.

The idea behind true “two-factor authentication” is that the user is required to present two out of three of the following: Something they have (mobile devices); something they know (passwords); or something they are (biometrics). For example, you present your credentials to a website, and the site prompts you to approve the login via a prompt that pops up on your registered mobile device. That is true two-factor authentication: Something you have, and something you know (and maybe also even something you are).

In addition, these so-called “push notification” methods include important time-based contexts that add security: They happen directly after the user submits their credentials; and the opportunity to approve the push notification expires after a short period.

But in so many instances, what sites request is basically two things you know (a password and a one-time code) to be submitted through the same channel (a web browser). This is usually still better than no multi-factor authentication at all, but as these services show there are now plenty of options of circumventing this protection.

I hope these OTP interception services make clear that you should never provide any information in response to an unsolicited phone call. It doesn’t matter who claims to be calling: If you didn’t initiate the contact, hang up. Don’t put them on hold while you call your bank; the scammers can get around that, too. Just hang up. Then you can call your bank or whoever else you need.

Unfortunately, those most likely to fall for these OTP interception schemes are people who are less experienced with technology. If you’re the resident or family IT geek and have the ability to update or improve the multi-factor authentication profiles for your less tech-savvy friends and loved ones, that would be a fabulous way to show you care — and to help them head off a potential disaster at the hands of one of these bot services.

When was the last time you reviewed your multi-factor settings and options at the various websites entrusted with your most precious personal and financial information? It might be worth paying a visit to 2fa.directory (formerly twofactorauth[.]org) for a checkup.

The new $30 AirTag tracking device from Apple has a feature that allows anyone who finds one of these tiny location beacons to scan it with a mobile phone and discover its owner’s phone number if the AirTag has been set to lost mode. But according to new research, this same feature can be abused to redirect the Good Samaritan to an iCloud phishing page — or to any other malicious website.

The AirTag’s “Lost Mode” lets users alert Apple when an AirTag is missing. Setting it to Lost Mode generates a unique URL at https://found.apple.com, and allows the user to enter a personal message and contact phone number. Anyone who finds the AirTag and scans it with an Apple or Android phone will immediately see that unique Apple URL with the owner’s message.

When scanned, an AirTag in Lost Mode will present a short message asking the finder to call the owner at at their specified phone number. This information pops up without asking the finder to log in or provide any personal information. But your average Good Samaritan might not know this.

That’s important because Apple’s Lost Mode doesn’t currently stop users from injecting arbitrary computer code into its phone number field — such as code that causes the Good Samaritan’s device to visit a phony Apple iCloud login page.

The vulnerability was discovered and reported to Apple by Bobby Rauch, a security consultant and penetration tester based in Boston. Rauch told KrebsOnSecurity the AirTag weakness makes the devices cheap and possibly very effective physical trojan horses.

“I can’t remember another instance where these sort of small consumer-grade tracking devices at a low cost like this could be weaponized,” Rauch said.

Consider the scenario where an attacker drops a malware-laden USB flash drive in the parking lot of a company he wants to hack into. Odds are that sooner or later some employee is going to pick that sucker up and plug it into a computer — just to see what’s on it (the drive might even be labeled something tantalizing, like “Employee Salaries”).

If this sounds like a script from a James Bond movie, you’re not far off the mark. A USB stick with malware is very likely how U.S. and Israeli cyber hackers got the infamous Stuxnet worm into the internal, air-gapped network that powered Iran’s nuclear enrichment facilities a decade ago. In 2008, a cyber attack described at the time as “the worst breach of U.S. military computers in history” was traced back to a USB flash drive left in the parking lot of a U.S. Department of Defense facility.

In the modern telling of this caper, a weaponized AirTag tracking device could be used to redirect the Good Samaritan to a phishing page, or to a website that tries to foist malicious software onto her device.

Rauch contacted Apple about the bug on June 20, but for three months when he inquired about it the company would say only that it was still investigating. Last Thursday, the company sent Rauch a follow-up email stating they planned to address the weakness in an upcoming update, and in the meantime would he mind not talking about it publicly?

Rauch said Apple never acknowledged basic questions he asked about the bug, such as if they had a timeline for fixing it, and if so whether they planned to credit him in the accompanying security advisory. Or whether his submission would qualify for Apple’s “bug bounty” program, which promises financial rewards of up to $1 million for security researchers who report security bugs in Apple products.

Rauch said he’s reported many software vulnerabilities to other vendors over the years, and that Apple’s lack of communication prompted him to go public with his findings — even though Apple says staying quiet about a bug until it is fixed is how researchers qualify for recognition in security advisories.

“I told them, ‘I’m willing to work with you if you can provide some details of when you plan on remediating this, and whether there would be any recognition or bug bounty payout’,” Rauch said, noting that he told Apple he planned to publish his findings within 90 days of notifying them. “Their response was basically, ‘We’d appreciate it if you didn’t leak this.'”

Rauch’s experience echoes that of other researchers interviewed in a recent Washington Post article about how not fun it can be to report security vulnerabilities to Apple, a notoriously secretive company. The common complaints were that Apple is slow to fix bugs and doesn’t always pay or publicly recognize hackers for their reports, and that researchers often receive little or no feedback from the company.

The risk, of course, is that some researchers may decide it’s less of a hassle to sell their exploits to vulnerability brokers, or on the darknet — both of which often pay far more than bug bounty awards.

There’s also a risk that frustrated researchers will simply post their findings online for everyone to see and exploit — regardless of whether the vendor has released a patch. Earlier this week, a security researcher who goes by the handle “illusionofchaos” released writeups on three zero-day vulnerabilities in Apple’s iOS mobile operating system — apparently out of frustration over trying to work with Apple’s bug bounty program.

Ars Technica reports that on July 19 Apple fixed a bug that llusionofchaos reported on April 29, but that Apple neglected to credit him in its security advisory.

“Frustration with this failure of Apple to live up to its own promises led illusionofchaos to first threaten, then publicly drop this week’s three zero-days,” wrote Jim Salter for Ars. “In illusionofchaos’ own words: ‘Ten days ago I asked for an explanation and warned then that I would make my research public if I don’t receive an explanation. My request was ignored so I’m doing what I said I would.'”

Rauch said he realizes the AirTag bug he found probably isn’t the most pressing security or privacy issue Apple is grappling with at the moment. But he said neither is it difficult to fix this particular flaw, which requires additional restrictions on data that AirTag users can enter into the Lost Mode’s phone number settings.

“It’s a pretty easy thing to fix,” he said. “Having said that, I imagine they probably want to also figure out how this was missed in the first place.”

Apple has not responded to requests for comment.

Update, 12:31: Rauch shared an email showing Apple communicated their intention to fix the bug just hours before — not after — KrebsOnSecurity reached out to them for comment. The story above has been changed to reflect that.

In October 2016, media outlets reported that data collected by some of the world’s most renowned cybersecurity experts had identified frequent and unexplained communications between an email server used by the Trump Organization and Alfa Bank, one of Russia’s largest financial institutions. Those publications set off speculation about a possible secret back-channel of communications, as well as a series of lawsuits and investigations that culminated last week with the indictment of the same former federal cybercrime prosecutor who brought the data to the attention of the FBI five years ago.

Since 2018, access to an exhaustive report commissioned by the U.S. Senate Armed Services Committee on data that prompted those experts to seek out the FBI has been limited to a handful of Senate committee leaders, Alfa Bank, and special prosecutors appointed to look into the origins of the FBI investigation on alleged ties between Trump and Russia.

That report is now public, ironically thanks to a pair of lawsuits filed by Alfa Bank, which doesn’t directly dispute the information collected by the researchers. Rather, it claims that the data they found was the result of a “highly sophisticated cyberattacks against it in 2016 and 2017” intended “to fabricate apparent communications” between Alfa Bank and the Trump Organization.

The data at issue refers to communications traversing the Domain Name System (DNS), a global database that maps computer-friendly coordinates like Internet addresses (e.g., 8.8.8.8) to more human-friendly domain names (example.com). Whenever an Internet user gets online to visit a website or send an email, the user’s device sends a query through the Domain Name System.

Many different entities capture and record this DNS data as it traverses the public Internet, allowing researchers to go back later and see which Internet addresses resolved to what domain names, when, and for how long. Sometimes the metadata generated by these lookups can be used to identify or infer persistent network connections between different Internet hosts.

The DNS strangeness was first identified in 2016 by a group of security experts who told reporters they were alarmed at the hacking of the Democratic National Committee, and grew concerned that the same attackers might also target Republican leaders and institutions.

Scrutinizing the Trump Organization’s online footprint, the researchers determined that for several months during the spring and summer of 2016, Internet servers at Alfa Bank in Russia, Spectrum Health in Michigan, and Heartland Payment Systems in New Jersey accounted for nearly all of the several thousand DNS lookups for a specific Trump Organization server (mail1.trump-email.com).

The researchers said they couldn’t be sure what kind of communications between those servers had caused the DNS lookups, but concluded that the data would be extremely difficult to fabricate.

As recounted in this 2018 New Yorker story, New York Times journalist Eric Lichtblau met with FBI officials in late September 2016 to discuss the researchers’ findings, and that the bureau asked him to hold the story because publishing might disrupt an ongoing investigation. On Sept. 21, 2016, Lichtblau reportedly shared the DNS data with B.G.R., a Washington lobbying firm that worked with Alfa Bank.

Lichtblau’s reporting on the DNS findings ended up buried in an October 31, 2016 story titled “Investigating Donald Trump, F.B.I. Sees No Clear Link to Russia,” which stated that the FBI “ultimately concluded that there could be an innocuous explanation, like marketing email or spam,” that might explain the unusual DNS connections.

But that same day, Slate’s Franklin Foer published a story based on his interactions with the researchers. Foer noted that roughly two days after Lichtblau shared the DNS data with B.G.R., the Trump Organization email server domain vanished from the Internet — its domain effectively decoupled from its Internet address.

Foer wrote that The Times hadn’t yet been in touch with the Trump campaign about the DNS data when the Trump email domain suddenly went offline.  Odder still, four days later the Trump Organization created a new host — trump1.contact-client.com — and the very first DNS lookup to that new domain came from servers at Alfa Bank.

The researchers concluded that the new domain enabled communication to the very same server via a different route.

“When a new host name is created, the first communication with it is never random,” Foer wrote. “To reach the server after the resetting of the host name, the sender of the first inbound mail has to first learn of the name somehow. It’s simply impossible to randomly reach a renamed server.”

“That party had to have some kind of outbound message through SMS, phone, or some noninternet channel they used to communicate [the new configuration],” DNS expert Paul Vixie told Foer. “The first attempt to look up the revised host name came from Alfa Bank. If this was a public server, we would have seen other traces. The only look-ups came from this particular source.”

THE THEORIES

Both the Trump organization and Alfa Bank have denied using or establishing any sort of secret channel of communications, and have offered differing explanations as to how the data gathered by the experts could have been faked or misinterpreted.

In a follow-up story by Foer, the Trump Organization suggested that the DNS lookups might be the result of spam or email advertising various Trump properties, and said a Florida based marketing firm called Cendyn registered and managed the email server in question.

But Cendyn told CNN that its contract to provide email marketing services to the Trump Organization ended in March 2016 — weeks before the DNS lookups chronicled by the researchers started appearing. Cendyn told CNN that a different client had been communicating with Alfa Bank using Cendyn communications applications — a claim that Alfa Bank denied.

Alfa Bank subsequently hired computer forensics firms Mandiant and Stroz Friedberg to examine the DNS data presented by the researchers. Both companies concluded there was no evidence of email communications between Alfa Bank and the Trump Organization. However, both firms also acknowledged that Alfa Bank didn’t share any DNS data for the relevant four-month time period identified by the researchers.

Another theory for the DNS weirdness outlined in Mandiant’s report is that Alfa Bank’s servers performed the repeated DNS lookups for the Trump Organization server because its internal Trend Micro antivirus product routinely scanned domains in emails for signs of malicious activity — and that incoming marketing emails promoting Trump properties could have explained the traffic.

The researchers maintained this did not explain similar and repeated DNS lookups made to the Trump Organization email server by Spectrum Health, which is closely tied to the DeVos family (Betsy DeVos would later be appointed Secretary of Education by President Trump).

FISHING EXPEDITION

In June 2020, Alfa Bank filed two “John Doe” lawsuits, one in Pennsylvania and another in Florida. Their stated purpose was to identify the anonymous hackers behind the “highly sophisticated cyberattacks” that they claim were responsible for the mysterious DNS lookups.

Alfa Bank has so far subpoenaed at least 49 people or entities — including all of the security experts quoted in the 2016 media stories referenced above, and others who’d merely offered their perspectives on the matter via social media. At least 15 of those individuals or entities have since been deposed. Alfa Bank’s most recent subpoena was issued Aug. 26, 2021.

L. Jean Camp, a professor at the Indiana University School of Informatics and Computing, was among the first to publish some of the DNS data collected by the research group. In 2017, Alfa Bank sent Camp a series of threatening letters suggesting she was “a central figure” in the what the company would later claim was “malicious cyber activity targeting its computer network.” The letters and responses from her attorneys are published on her website.

Camp’s attorneys and Indiana University have managed to keep her from being deposed by both Alfa Bank and John H. Durham, the special counsel appointed by the Trump administration to look into the origins of the Russia investigation (although Camp said Alfa Bank was able to obtain certain emails through the school’s public records request policy).

“If MIT had had the commitment to academic freedom that Indiana University has shown throughout this entire process, Aaron Swartz would still be alive,” Camp said.

Camp said she’s bothered that the Alfa Bank and Trump special counsel investigations have cast the researchers in such a sinister light, when many of those subpoenaed have spent a lifetime trying to make the Internet more secure.

“Not including me, they’ve subpoenaed some people who are significant, consistent and important contributors to the security of American networks against the very attacks coming from Russia,” Camp said. “I think they’re using law enforcement to attack network security, and to determine the ways in which their previous attacks have been and are being detected.”

Nicholas Weaver, a lecturer at the computer science department at University of California, Berkeley, told KrebsOnSecurity he complied with the subpoena requests for specific emails he’d sent to colleagues about the DNS data, noting that Alfa Bank could have otherwise obtained them through the schools’ public records policy.

Weaver said Alfa Bank’s lawsuit has nothing to do with uncovering the truth about the DNS data, but rather with intimidating and silencing researchers who’ve spoken out about it.

“It’s clearly abusive, so I’m willing to call it out for what it is, which is a John Doe lawsuit for a fishing expedition,” Weaver said.

TURNABOUT IS FAIR PLAY

Among those subpoenaed and deposed by Alfa Bank was Daniel J. Jones, a former investigator for the FBI and the U.S. Senate who is perhaps best known for his role in leading the investigation into the U.S. Central Intelligence Agency’s use of torture in the wake of the Sept. 11 attacks.

Jones runs The Democracy Integrity Project (TDIP), a nonprofit in Washington, D.C. whose stated mission includes efforts to research, investigate and help mitigate foreign interference in elections in the United States and its allies overseas. In 2018, U.S. Senate investigators asked TDIP to produce and share a detailed analysis of the DNS data, which it did without payment. That lengthy report was never publicly released by the committee nor anyone else.

That is, until Sept. 14, 2021, when Jones and TDIP filed their own lawsuit against Alfa Bank. According to Jones’ complaint, Alfa Bank had entered into a confidentiality agreement regarding certain sensitive and personal information Jones was compelled to provide as part of complying with the subpoena.

Yet on Aug. 20, Alfa Bank attorneys sent written notice that it was challenging portions of the confidentiality agreement. Jones’ complaint asserts that Alfa Bank intends to publicly file portions of these confidential exhibits, an outcome that could jeopardize his safety.

This would not be the first time testimony Jones provided under a confidentiality agreement ended up in the public eye. TDIP’s complaint notes that before Jones met with FBI officials in 2017 to discuss Russian disinformation campaigns, he was assured by two FBI agents that his identity would be protected from exposure and that any information he provided to the FBI would not be associated with him.

Nevertheless, in 2018 the House Permanent Select Committee on Intelligence released a redacted report on Russian active measures. The report blacked out Jones’ name, but a series of footnotes in the report named his employer and included links to his organization’s website. Jones’ complaint spends several pages detailing the thousands of death threats he received after that report was published online.

THE TDIP REPORT

As part of his lawsuit against Alfa Bank, Jones published 40 pages from the 600+ page report he submitted to the U.S. Senate in 2018. From reviewing its table of contents, the remainder of the unpublished report appears to delve deeply into details about Alfa Bank’s history, its owners, and their connections to the Kremlin.

The report notes that unlike other domains the Trump Organization used to send mass marketing emails, the domain at issue — mail1.trump-email.com — was configured in such a way that would have prevented it from effectively sending marketing or bulk emails. Or at least prevented most of the missives sent through the domain from ever making it past spam filters.

Nor was the domain configured like other Trump Organization domains that demonstrably did send commercial email, Jones’ analysis found. Also, the mail1.trump-email.com domain was never once flagged as sending spam by any of the 57 different spam block lists published online at the time.

“If large amounts of marketing emails were emanating from mail1.trump-email.com, it’s likely that some receivers of those emails would have marked them as spam,” Jones’ 2018 report reasons. “Spam is nothing new on the internet, and mass mailings create easily observed phenomena, such as a wide dispersion of backscatter queries from spam filters. No such evidence is found in the logs.”

However, Jones’ report did find that mail1.trump-email.com was configured to accept incoming email. Jones cites testing conducted by one of the researchers who found the mail1.trump-email.com rejected messages with an automated reply saying the server couldn’t accept messages from that particular sender.

“This test reveals that either the server was configured to reject email from everyone, or that the server was configured to accept only emails from specific senders,” TDIP wrote.

The report also puts a finer point on the circumstances surrounding the disappearance of that Trump Organization email domain just two days after The New York Times shared the DNS data with Alfa Bank’s representatives.

“After the record was deleted for mail1.trump-email.com on Sept. 23, 2016, Alfa Bank and Spectrum Health continued to conduct DNS lookups for mail1.trump-email.com,” reads the report. “In the case of Alfa Bank, this behavior persisted until late Friday night on Sept. 23, 2016 (Moscow time). At that point, Alfa Bank ceased its DNS lookups of mail1.trump-email.com.”

Less than ten minutes later, a server assigned to Alfa Bank was the first source in the DNS data-set examined (37 million DNS records from January 1, 2016 to January 15, 2017) to conduct a DNS look-up for the server name ‘trump1.contact-client.com.’ The answer received was 66.216.133.29 — the same IP address used for mail1.trump-email.com that was deleted in the days after The New York Times inquired with Alfa Bank about the unusual server connections.

“No servers associated with Alfa Bank ever conducted a DNS lookup for trump1.contact-client.com again, and the next DNS look-up for trump1.contact-client.com did not occur until October 5, 2016,” the report continues. “Three of these five look-ups from October 2016 originated from Russia.”

A copy of the complaint filed by Jones against Alfa Bank is available here (PDF).

THE SUSSMANN INDICTMENT

The person who first brought the DNS data to the attention of the FBI in Sept. 2016 was Michael Sussmann, a 57-year-old cybersecurity lawyer and former computer crimes prosecutor who represented the Democratic National Committee and Hillary Clinton’s presidential campaign.

Last week, the special counsel Durham indicted Sussmann on charges of making a false statement to the FBI. The New York Times reports the accusation focuses on a meeting Sussmann had Sept. 19, 2016 with James A. Baker, the FBI’s top lawyer at the time. Sussmann had reportedly met with Baker to discuss the DNS data uncovered by the researchers.

“The indictment says Mr. Sussmann falsely told the F.B.I. lawyer that he had no clients, but he was really representing both a technology executive and the Hillary Clinton campaign,” The Times wrote.

Sussmann has pleaded not guilty to the charges.

ANALYSIS

The Sussmann indictment refers to the various researchers who contacted him in 2016 by placeholder names, such as Tech Executive-1 and Researcher-1 and Researcher-2. The tone of indictment reads as if describing a vast web of nefarious or illegal activities, although it doesn’t attempt to address the veracity of any specific concerns raised by the researchers.  Here is one example:

“From in or about July 2016 through at least in or about February 2017, however, Originator-I, Researcher-I, and Researcher-2 also exploited Internet Company­-1′ s data and other data to assist Tech Executive-I in his efforts to conduct research concerning Trump’s potential ties to Russia.”

Quoting from emails between Tech Executive-1 and the researchers, the indictment makes clear that Mr. Durham has subpoenaed many of the same researchers who’ve been subpoenaed and or deposed in the concurrent John Doe lawsuits from Russia’s Alfa Bank.

To date, Alfa Bank has yet to name a single defendant in its lawsuits. In the meantime, the Sussmann indictment is being dissected by many users on social media who have been closely following the Trump administration’s inquiry into the Russia investigation. The majority of these social media posts appear to be crowdsourcing an effort to pinpoint the real-life identities behind the placeholder names in the indictment.

At one level, it doesn’t matter which explanation of the DNS data you believe: There is a very real possibility that the way this entire inquiry has been handled could negatively affect the FBI’s ability to collect crucial and sensitive investigative tips for years to come.

After all, who in their right mind is going to volunteer confidential information to the FBI if they fear there’s even the slightest chance that future shifting political winds could end up seeing them prosecuted, threatened with physical violence or death on social media, and/or exposed to expensive legal fees and depositions from private companies as a result?

Such a perception could give rise to a sort of “chilling effect,” discouraging honest, well-meaning people from speaking up when they suspect or know about a potential threat to national security or sovereignty.

This would be a less-than-ideal outcome in the context of today’s top cyber threat for most organizations: Ransomware. With few exceptions, the U.S. government has watched helplessly as organized cybercrime gangs — many of whose members hail from Russia or from former Soviet nations that are friendly to Moscow — have extorted billions of dollars from victims, and disrupted or ruined countless businesses.

To help shift the playing field against ransomware actors, the Justice Department and other federal law enforcement agencies have been trying to encourage more ransomware victims to come forward and share sensitive details about their attacks. The U.S. government has even offered up to $10 million for information leading to the arrest and conviction of cybercriminals involved in ransomware.

But given the way the government has essentially shot the all of the messengers with its handling of the Sussmann case, who could blame those with useful and valid tips if they opted to stay silent?

It happens all the time: Organizations get hacked because there isn’t an obvious way for security researchers to let them know about security vulnerabilities or data leaks. Or maybe it isn’t entirely clear who should get the report when remote access to an organization’s internal network is being sold in the cybercrime underground.

In a bid to minimize these scenarios, a growing number of major companies are adopting “Security.txt,” a proposed new Internet standard that helps organizations describe their vulnerability disclosure practices and preferences.

The idea behind Security.txt is straightforward: The organization places a file called security.txt in a predictable place — such as example.com/security.txt, or example.com/.well-known/security.txt. What’s in the security.txt file varies somewhat, but most include links to information about the entity’s vulnerability disclosure policies and a contact email address.

The security.txt file made available by USAA, for example, includes links to its bug bounty program; an email address for disclosing security related matters; its public encryption key and vulnerability disclosure policy; and even a link to a page where USAA thanks researchers who have reported important cybersecurity issues.

Other security.txt disclosures are less verbose, as in the case of HCA Healthcare, which lists a contact email address, and a link to HCA’s “responsible disclosure” policies. Like USAA and many other organizations that have published security.txt files, HCA Healthcare also includes a link to information about IT security job openings at the company.

Having a security.txt file can make it easier for organizations to respond to active security threats. For example, just this morning a trusted source forwarded me the VPN credentials for a major clothing retailer. Finding no security.txt file at the retailer’s site using gotsecuritytxt.com (which checks a domain for the presence of this contact file), KrebsonSecurity sent an alert to its “security@” email address for the retailer’s domain.

Many organizations have long unofficially used (if not advertised) the email address security@[companydomain] to accept reports about security incidents or vulnerabilities. Perhaps this particular retailer also did so at one point, however my message was returned with a note saying the email had been blocked. KrebsOnSecurity also sent a message to the retailer’s chief information officer (CIO) — the only person in a C-level position at the retailer who was in my immediate LinkedIn network. I still have no idea if anyone has read it.

Although security.txt is not yet an official Internet standard as approved by the Internet Engineering Task Force (IETF), its basic principles have so far been adopted by at least eight percent of the Fortune 100 companies. According to a review of the domain names for the latest Fortune 100 firms via gotsecuritytxt.com, those include Alphabet, Amazon, Facebook, HCA Healthcare, Kroger, Procter & Gamble, USAA and Walmart.

There may be another good reason for consolidating security contact and vulnerability reporting information in one, predictable place. Alex Holden, founder of the Milwaukee-based consulting firm Hold Security, said it’s not uncommon for malicious hackers to experience problems getting the attention of the proper people within the very same organization they have just hacked.

“In cases of ransom, the bad guys try to contact the company with their demands,” Holden said. “You have no idea how often their messages get caught in filters, get deleted, blocked or ignored.”

GET READY TO BE DELUGED

So if security.txt is so great, why haven’t more organizations adopted it yet? It seems that setting up a security.txt file tends to invite a rather high volume of spam. Most of these junk emails come from self-appointed penetration testers who — without any invitation to do so — run automated vulnerability discovery tools and then submit the resulting reports in hopes of securing a consulting engagement or a bug bounty fee.

This dynamic was a major topic of discussion in these Hacker News threads on security.txt, wherein a number of readers related their experience of being so flooded with low-quality vulnerability scan reports that it became difficult to spot the reports truly worth pursuing further.

Edwin “EdOverflow” Foudil, the co-author of the proposed notification standard, acknowledged that junk reports are a major downside for organizations that offer up a security.txt file.

“This is actually stated in the specification itself, and it’s incredibly important to highlight that organizations that implement this are going to get flooded,” Foudil told KrebsOnSecurity. “One reason bug bounty programs succeed is that they are basically a glorified spam filter. But regardless of what approach you use, you’re going to get inundated with these crappy, sub-par reports.”

Often these sub-par vulnerability reports come from individuals who have scanned the entire Internet for one or two security vulnerabilities, and then attempted to contact all vulnerable organizations at once in some semi-automated fashion. Happily, Foudil said, many of these nuisance reports can be ignored or grouped by creating filters that look for messages containing keywords commonly found in automated vulnerability scans.

Foudil said despite the spam challenges, he’s heard tremendous feedback from a number of universities that have implemented security.txt.

“It’s been an incredible success with universities, which tend to have lots of older, legacy systems,” he said. “In that context, we’ve seen a ton of valuable reports.”

Foudil says he’s delighted that eight of the Fortune 100 firms have already implemented security.txt, even though it has not yet been approved as an IETF standard. When and if security.txt is approved, he hopes to spend more time promoting its benefits.

“I’m not trying to make money off this thing, which came about after chatting with quite a few people at DEFCON [the annual security conference in Las Vegas] who were struggling to report security issues to vendors,” Foudil said. “The main reason I don’t go out of my way to promote it now is because it’s not yet an official standard.”

Has your organization considered or implemented security.txt? Why or why not? Sound off in the comments below.