In May 2019, KrebsOnSecurity broke the news that the website of mortgage settlement giant First American Financial Corp. [NYSE:FAF] was leaking more than 800 million documents — many containing sensitive financial data — related to real estate transactions dating back 16 years. This week, the U.S. Securities and Exchange Commission settled its investigation into the matter after the Fortune 500 company agreed to pay a paltry penalty of less than $500,000.

If you bought or sold a property in the last two decades or so, chances are decent that you also gave loads of personal and financial documents to First American. According to data from the American Land Title Association, First American is the second largest mortgage title and settlement company in the United States, handling nearly a quarter of all closings each year.

The SEC says First American derives nearly 92 percent of its revenue from its title insurance segment, earning $7.1 billion last year.

Title insurance protects homebuyers from the prospect of someone contesting their legitimacy as the new homeowner. According to SimpleShowing.com, there are actually two title insurance policies in each transaction — one for the buyer and one for the lender (the latter also needs protection as they’re providing the mortgage to purchase the home).

Title insurance is not mandated by law, but most lenders require it as part of any mortgage transaction. In other words, if you wish to take out a mortgage on a home you will not be able to do so without giving companies like First American gobs of documents about your income, assets and liabilities — including quite a bit of sensitive financial data.

Aside from its core business competency — checking to make sure the property at issue in any real estate transaction is unencumbered by any liens or other legal claims against it — First American basically has one job: Protect the privacy and security of all these documents.

It’s easy to see why companies like First American might not view protecting this data as sacrosanct, as the entire industry’s incentive for safeguarding all those sensitive documents is somewhat misaligned.

That is to say, in the title insurance industry the parties to a real estate transaction aren’t customers, but rather they are are the product. The actual customers of the title insurance companies are principally the banks which back these mortgage transactions.

We see a similar dynamic with social media platforms, where the “user” is not the customer at all but the product whose data is being bought and sold by these platforms.

Roughly five months before KrebsOnSecurity notified First American that anyone with a web browser could view sensitive document in its “Eagle Pro” database online just by changing some characters at the end of a link, an internal security audit at First American flagged the exact same vulnerability.

But the company never acted to fix it until the news media came calling.

The SEC’s administrative proceeding (PDF) explains how things slipped through the cracks. Under First American’s documented vulnerability remediation policies, the data leak was classified as a security weakness with a “level 3” severity, which placed it in the “medium risk” category and required remediation within 45 days.

But rather than recording the vulnerability as a level 3 severity, due to a clerical error the vulnerability was erroneously entered as a level 2 or “low risk” severity in First American’s automated tracking system. Level 2 issues required remediation within 90 days. Even so, First American missed that mark.

The SEC said that under First American’s remediation policies, if the person responsible for fixing the problem is unable to do so based on the timeframes listed above, that employee must have their management contact the company’s information security department to discuss their remediation plan and proposed time estimate.

“If it is not technically possible to remediate the vulnerability, or if remediation is cost prohibitive, the [employee] and their management must contact Information Security to obtain a waiver or risk acceptance approval from the CISO,” the SEC explained. “The [employee] did not request a waiver or risk acceptance from the CISO.”

So, someone within First American accepted the risk, but that person neglected to ensure the higher-ups within the company also were comfortable with that risk. It’s difficult not to hum a tune whenever the phrase “accepted the risk” comes up if you’ve ever seen this excellent infosec industry parody.

The SEC took aim at First American because a few days after our May 24, 2019 story ran, the company issued an 8-K filing with the agency stating First American had no prior indication of any vulnerability.

“That statement demonstrated that First American’s senior management was not properly informed of the prior report of a vulnerability and a failure to remediate the problem,” wrote Michael Volkov, a 30-year federal prosecutor who now runs The Volkov Law Group in Washington, D.C.

Reporting for Reuters Regulatory Intelligence, Richard Satran says the SEC charged First American with violating Rule 13a-15(a) of the Exchange Act.

“The rule broadly requires firms involved in securities issuance to have a compliance process in place to assure material information follows securities laws,” Satran wrote. “The SEC avoided getting into the specific details of the breach and instead focused on the way its disclosure was handled.”

Mark Rasch, also former federal prosecutor in Washington, said the SEC is signaling with this action that it intends to take on more cases in which companies flub security governance in some big way.

“It’s a win for the SEC, and for First America, but it’s hardly justice,” Rasch said. “It’s a paltry fine, and it involves no admission of guilt by First American.”

Rasch said First American’s first problem was labeling the weakness as a medium risk.

“This is lots of sensitive data you’re exposing to anyone with a web browser,” Rasch said. “That’s a high-risk vulnerability. It also means you probably don’t know whether or not anyone has accessed that data. There’s no way to tell unless you can go back through all your logs all those years.”

The SEC said the 800 million+ records had been publicly available on First American’s website since 2013. In August 2019, the company said a third-party investigation into the exposure identified just 32 consumers whose non-public personal information likely was accessed without authorization.

When KrebsOnSecurity asked how long it maintained access logs or how far back in time that review went, First American declined to be more specific, saying only that its logs covered a period that was typical for a company of its size and nature.

However, documents from New York financial regulators show First American was unable to determine whether records were accessed prior to Jun 2018 (one year prior to fixing the weakness).

The records exposed by First American would have been a virtual gold mine for phishers and scammers involved in Business Email Compromise (BEC) scams, which often impersonate real estate agents, closing agencies, title and escrow firms in a bid to trick property buyers into wiring funds to fraudsters. According to the FBI, BEC scams are the most costly form of cybercrime today.

First American is not out of the regulatory woods yet from this enormous data leak. In July 2020, the New York State Department of Financial Services announced the company was the target of their first ever cybersecurity enforcement action in connection with the incident, charges that could bring steep financial penalties. That inquiry is ongoing.

The DFS considers each instance of exposed personal information a separate violation, and the company faces penalties of up to $1,000 per violation. According to the SEC, First American’s EaglePro database contained tens of millions of document images that included non-public personal information.

The U.S. Department of Justice (DOJ) last week announced the arrest of a 55-year-old Latvian woman who’s alleged to have worked as a programmer for Trickbot, a malware-as-a-service platform responsible for infecting millions of computers and seeding many of those systems with ransomware.

Just how did a self-employed web site designer and mother of two come to work for one of the world’s most rapacious cybercriminal groups and then leave such an obvious trail of clues indicating her involvement with the gang? This post explores answers to those questions, as well as some of the ways Trickbot and other organized cybercrime gangs gradually recruit, groom and trust new programmers.

The indictment released by the DOJ (PDF) is heavily redacted, and only one of the defendants is named: Alla “Max” Witte, a 55-year-old Latvian national who was arrested Feb. 6 in Miami, Fla.

The DOJ alleges Witte was responsible for “overseeing the creation of code related to the monitoring and tracking of authorized users of the Trickbot malware, the control and deployment of ransomware, obtaining payments from ransomware victims, and developing tools and protocols for the storage of credentials stolen and exfiltrated from victims infected by Trickbot.”

The indictment also says Witte provided code to the Trickbot Group for a web panel used to access victim data stored in a database. According to the government, that database contained a large number of credit card numbers and stolen credentials from the Trickbot botnet, as well as information about infected machines available as bots.

“Witte provided code to this repository that showed an infected computer or ‘bot’ status in different colors based on the colors of a traffic light and allowed other Trickbot Group members to know when their co-conspirators were working on a particular infected machine,” the indictment alleges.

While any law enforcement action against a crime group that has targeted hospitals, schools, public utilities and governments is good news, Witte’s indictment and arrest were probably inevitable: It is hard to think of an accused cybercriminal who has made more stunningly poor and rookie operational security mistakes than this Latvian senior citizen.

For starters, it appears at one point in 2020 Witte actually hosted Trickbot malware on a vanity website registered in her name — allawitte[.]nl.

While it is generally a bad idea for cybercriminals to mix their personal life with work, Witte’s social media accounts mention a close family member (perhaps her son or husband) had the first name “Max,” which allegedly was her hacker handle.

Unlike many accused cybercriminals who hail from Russia or former Soviet countries, Witte did not feel obligated to avoid traveling to areas where she might be within reach of U.S. law enforcement agencies. According to her indictment, Witte was living in the South American nation of Suriname and she was arrested in Miami while flying from Suriname. It is not clear where her intended destination was.

Alex Holden, founder of the cybersecurity intelligence firm Hold Security, said Witte’s greatest lapse in judgment came around Christmas time in 2019, when she infected one of her own computers with the Trickbot malware — allowing it to steal and log her data within the botnet interface.

“On top of the password re-use, the data shows a great insight into her professional and personal Internet usage,” Holden wrote in a blog post on Witte’s arrest.

“Many in the gang not only knew her gender but her name too,” Holden wrote. “Several group members had AllaWitte folders with data. They refer to Alla almost like they would address their mothers.”

So how did this hacker mom with apparently zero sense of self-preservation come to work for one of the world’s most predatory cybercriminal gangs?

The government’s indictment dedicates several pages to describing the hiring processes of the Trickbot group, which continuously scoured fee-based Russian and Belarussian-based job websites for resumes of programmers looking for work. Those who responded were asked to create various programs designed to test the applicant’s problem-solving and coding skills.

Here’s a snippet of translated instant message text between two of the unnamed Trickbot defendants, in which they discuss an applicant who understood immediately that he was being hired to help with cybercrime activity.

The following conversation, on or about June 1, 2016, concerned a potential new Trickbot hire who successfully completed a test task that involved altering a Firefox Web browser.

Other conversation snippets in the indictment suggest most new recruits understand that the projects and test tasks they are being asked to tackle are related to cybercrime activity.

“The majority understand that this is blackhat and asking for the commercial target,” wrote the defendant identified only as Co-Conspirator 8 (CC8).

But what about new hires that aren’t hip to exactly how the programs they’re being asked to create get used? Another source in the threat intelligence industry who has had access to the inner workings of Trickbot provided some additional context on how developers are onboarded into the group.

“There’s a two-step hiring process where at first you may not understand who you’re working for,” said the source. “But that timeframe is typically pretty short, like less than a year.”

After that, if the candidate is talented and industrious enough, someone in the Trickbot group will “read in” the new recruit — i.e. explain in plain terms how their work is being used.

“If you’re good, at some point they’re going to read you in and you’ll know, but if you’re not good or you’re not okay with that, they will triage that pretty quickly and your services will no longer be required,” the source said. “But if you make it past that first year, the chances that you still don’t know what you’re doing are very slim.”

According to the DOJ, Witte had access to Trickbot for roughly two years between 2018 and 2020.

Investigators say prior to launching Trickbot, some members of the conspiracy previously were responsible for disseminating Dyre, a particularly stealthy password stealer that looked for passwords used at various banks. The government says Trickbot members — including Witte — routinely used bank account passwords stolen by their malware to drain victim bank accounts and send the money to networks of money mules.

The hiring model adopted by Trickbot allows the gang to recruit a steady stream of talented developers cheaply and covertly. But it also introduces the very real risk that new recruits may offer investigators a way to infiltrate the group’s operations, and possibly even identify co-conspirators.

Ransomware attacks are nearly all perpetrated these days by ransomware affiliate groups which constantly recruit new members to account for attrition, competition from other ransomware groups, and for the odd affiliate who gets busted by law enforcement.

Under the ransomware affiliate model, a cybercriminal can earn up to 85 percent of the total ransom paid by a victim company he or she is responsible for compromising and bringing to the group. But from time to time, poor operational security by an affiliate exposes the gang’s entire operation.

On June 7, the DOJ announced it had clawed back $2.3 million worth of Bitcoin that Colonial Pipeline paid to ransomware extortionists last month. The funds had been sent to DarkSide, a ransomware-as-a-service syndicate that disbanded after a May 14 farewell message to affiliates saying its Internet servers and cryptocurrency stash were seized by unknown law enforcement entities.

“The proceeds of the victim’s ransom payment…had been transferred to a specific address, for which the FBI has the ‘private key,’ or the rough equivalent of a password needed to access assets accessible from the specific Bitcoin address,” the DOJ explained, somewhat cryptically.

Multiple security experts quickly zeroed in on how investigators were able to retrieve the funds, which did not represent the total amount Colonial paid (~$4.4 million): The amount seized was roughly what a top DarkSide affiliate would have earned for scoring the initial malware infection that precipitated the ransomware incident.

KrebsOnSecurity recently had occasion to contact the Russian Federal Security Service (FSB), the Russian equivalent of the U.S. Federal Bureau of Investigation (FBI). In the process of doing so, I encountered a small snag: The FSB’s website said in order to communicate with them securely, I needed to download and install an encryption and virtual private networking (VPN) appliance that is flagged by at least 20 antivirus products as malware.

The reason I contacted the FSB — one of the successor agencies to the Russian KGB — ironically enough had to do with security concerns raised by an infamous Russian hacker about the FSB’s own preferred method of being contacted.

KrebsOnSecurity was seeking comment from the FSB about a blog post published by Vladislav “BadB” Horohorin, a former international stolen credit card trafficker who served seven years in U.S. federal prison for his role in the theft of $9 million from RBS WorldPay in 2009. Horohorin, a citizen of Russia, Israel and Ukraine, is now back where he grew up in Ukraine, running a cybersecurity consulting business.

Visit the FSB’s website and you might notice its web address starts with http:// instead of https://, meaning the site is not using an encryption certificate. In practical terms, any information shared between the visitor and the website is sent in plain text and will be visible to anyone who has access to that traffic.

This appears to be the case regardless of which Russian government site you visit. According to Russian search giant Yandex, the laws of the Russian Federation demand that encrypted connections be installed according to the Russian GOST cryptographic algorithm.

That means those who have a reason to send encrypted communications to a Russian government organization — including ordinary things like making a payment for a government license or fine, or filing legal documents — need to first install CryptoPro, a Windows-only application that loads the GOST encryption libraries on a user’s computer.

But if you want to talk directly to the FSB over an encrypted connection, you can just install their own client, which bundles the CryptoPro code. Visit the FSB’s site and select the option to “transfer meaningful information to operational units,” and you’ll see a prompt to install a “random number generation” application that is needed before a specific contact form on the FSB’s website will load properly.

Mind you, I’m not suggesting anyone go do that: Horohorin pointed out that this random number generator was flagged by 20 different antivirus and security products as malicious.

“Think well before contacting the FSB for any questions or dealing with them, and if you nevertheless decide to do this, it is better to use a virtual machine,” Horohorin wrote. “And a spacesuit. And, preferably, while in another country.”

It’s probably worth mentioning that the FSB is the same agency that’s been sanctioned for malicious cyber activity by the U.S. government on multiple occasions over the past five years. According to the most recent sanctions by the U.S. Treasury Department, the FSB is known for recruiting criminal hackers from underground forums and offering them legal cover for their actions.

“To bolster its malicious cyber operations, the FSB cultivates and co-opts criminal hackers, including the previously designated Evil Corp., enabling them to engage in disruptive ransomware attacks and phishing campaigns,” reads a Treasury assessment from April 2021.

While Horohorin seems convinced the FSB is disseminating malware, it is not unusual for a large number of security tools used by VirusTotal or other similar malware “sandbox” services to incorrectly flag safe files as bad or suspicious — an all-too-common condition known as a “false positive.”

Late last year I warned my followers on Twitter to put off installing updates for their Dell products until the company could explain why a bunch of its software drivers were being detected as malware by two dozen antivirus tools. Those all turned out to be false positives.

To really figure out what this FSB software was doing, I turned to Lance James, the founder of Unit221B, a New York City based cybersecurity firm. James said each download request generates a new executable program. That is because the uniqueness of the file itself is part of what makes the one-to-one encrypted connection possible.

“Essentially it is like a temporary, one-time-use VPN, using a separate key for each download” James said. “The executable is the handshake with you to exchange keys, as it stores the key for that session in the exe. It’s a terrible approach. But it’s what it is.”

James said the FSB’s program does not appear to be malware, at least in terms of the actions it takes on a user’s computer.

“There’s no sign of actual trojan activity here except the fact it self deletes,” James said. “It uses GOST encryption, and [the antivirus products] may be thinking that those properties look like ransomware.”

James says he suspects the antivirus false-positives were triggered by certain behaviors which could be construed as malware-like. The screenshot below — from VirusTotal — says some of the file’s contents align with detection rules made to find instances of ransomware.

Other detection rules tripped by this file include program routines that erase event logs from the user’s system — a behavior often seen in malware that is trying to hide its tracks.

On a hunch that just including the GOST encryption routine in a test program might be enough to trigger false positives in VirusTotal, James wrote and compiled a short program in C++ that invoked the GOST cipher but otherwise had no networking components. He then uploaded the file for scanning at VirusTotal.

Even though James’ test program did nothing untoward or malicious, it was flagged by six antivirus engines as potentially hostile. Symantec’s machine learning engine seemed particularly certain that James’ file might be bad, awarding it the threat name “ML.Attribute.HighConfidence” — the same designation it assigned to the FSB’s program.

KrebsOnSecurity installed the FSB’s software on a test computer using a separate VPN, and straight away it connected to an Internet address currently assigned to the FSB (213.24.76.xxx).

The program prompted me to click on various parts of the screen to generate randomness for an encryption key, and when that was done it left a small window which explained in Russian that the connection was established and that I should visit a specific link on the FSB’s site.

Doing so opened up a page where I could leave a message for the FSB. I asked them if they had any response to their program being broadly flagged as malware.

After all the effort, I’m disappointed to report that I have not yet received a reply. Nor did I hear back from S-Terra CSP, the company that makes the VPN software offered by the FSB.

James said that given their position, he could see why many antivirus products might think it’s malware.

“Since they won’t use our crypto and we won’t use theirs,” James said. “It’s a great explanation on political weirdness with crypto.”

Still, James said, a number of things just don’t make sense about the way the FSB has chosen to deploy its one-time VPN software.

“The way they have set this up to suddenly trust a dynamically changing exe is still very concerning. Also, why would you send me a 256 random number generator seed in an exe when the computer has a perfectly valid and tested random number generator built in? You’re sending an exe to me with a key you decide over a non-secure environment. Why the fuck if you’re a top intelligence agency would you do that?”

Why indeed. I wonder how many people would share information about federal crimes with the FBI if the agency required everyone to install an executable file first — to say nothing of one that looks a lot like ransomware to antivirus firms?

After doing this research, I learned the FSB recently launched a website that is only reachable via Tor, software that protects users’ anonymity by bouncing their traffic between different servers and encrypting the traffic at every step of the way. Unlike the FSB’s clear web site, the agency’s Tor site does not ask visitors to download some dodgy software before contacting them.

“The application is running for a limited time to ensure your safety,” the instructions for the FSB’s random number generator assure, with just a gentle nudge of urgency. “Do not forget to close the application when finished.”

Yes, don’t forget that. Also, do not forget to incinerate your computer when finished.

Fake, positive reviews have infiltrated nearly every corner of life online these days, confusing consumers while offering an unwelcome advantage to fraudsters and sub-par products everywhere. Happily, identifying and tracking these fake reviewer accounts is often the easiest way to spot scams. Here’s the story of how bogus reviews on a counterfeit Microsoft Authenticator browser extension exposed dozens of other extensions that siphoned personal and financial data.

After hearing from a reader about a phony Microsoft Authenticator extension that appeared on the Google Chrome Store, KrebsOnSecurity began looking at the profile of the account that created it. There were a total of five reviews on the extension before it was removed: Three Google users gave it one star, warning people to stay far away from it; but two of the reviewers awarded it between three and four stars.

“It’s great!,” the Google account Theresa Duncan enthused, improbably. “I’ve only had very occasional issues with it.”

“Very convenient and handing,” assessed Anna Jones, incomprehensibly.

Google’s Chrome Store said the email address tied to the account that published the knockoff Microsoft extension also was responsible for one called “iArtbook Digital Painting.” Before it was removed from the Chrome Store, iArtbook had garnered just 22 users and three reviews. As with the knockoff Microsoft extension, all three reviews were positive, and all were authored by accounts with first and last names, like Megan Vance, Olivia Knox, and Alison Graham.

Google’s Chrome Store doesn’t make it easy to search by reviewer. For that I turned to Hao Nguyen, the developer behind chrome-stats.com, which indexes and makes searchable a broad array of attributes about extensions available from Google.

Looking at the Google accounts that left positive reviews on both the now-defunct Microsoft Authenticator and iArtbook extensions, KrebsOnSecurity noticed that each left positive reviews on a handful of other extensions that have since been removed.

Like an ever-expanding venn diagram, a review of the extensions commented on by each new fake reviewer found led to the discovery of even more phony reviewers and extensions. In total, roughly 24 hours worth of digging through chrome-stats.com unearthed more than 100 positive reviews on a network of patently fraudulent extensions.

Those reviews in turn lead to the relatively straightforward identification of:

-39 reviewers who were happy with extensions that spoofed major brands and requested financial data
-45 malicious extensions that collectively had close to 100,000 downloads
-25 developer accounts tied to multiple banned applications

The extensions spoofed a range of consumer brands, including Adobe, Amazon, Facebook, HBO, Microsoft, Roku and Verizon. Scouring the manifests for each of these other extensions in turn revealed that many of the same developers were tied to multiple apps being promoted by the same phony Google accounts.

Some of the fake extensions have only a handful of downloads, but most have hundreds or thousands. A fake Microsoft Teams extension attracted 16,200 downloads in the roughly two months it was available from the Google store. A counterfeit version of CapCut, a professional video editing software suite, claimed nearly 24,000 downloads over a similar time period.

Unlike malicious browser extensions that can turn your PC into a botnet or harvest your cookies, none of the extensions examined here request any special permissions from users. Once installed, however, they invariably prompt the user to provide personal and financial data — all the while pretending to be associated with major brand names.

In some cases, the fake reviewers and phony extension developers used in this scheme share names, such as the case with “brook ice,” the Google account that positively reviewed the malicious Adobe and Microsoft Teams extensions. The email address brookice100@gmail.com was used to register the developer account responsible for producing two of the phony extensions examined in this review (PhotoMath and Dollify).

As we can see from the spreadsheet snippet above, many of the Google accounts that penned positive reviews on patently bogus extensions left comments on multiple apps on the same day.

Additionally, Google’s account recovery tools indicate many different developer email addresses tied to extensions reviewed here share the same recovery email — suggesting a relatively few number of anonymous users are controlling the entire scheme. When the spreadsheet data shown above is sorted by email address of the extension developer, the grouping of the reviews by date becomes even clearer.

KrebsOnSecurity shared these findings with Google and will update this story in the event they respond. Either way, Google somehow already detected all of these extensions as fraudulent and removed them from its store.

However, there may be a future post here about how long that bad extension identification and removal process has taken over time. Overall, most of these extensions were available for two to three months before being taken down.

As for the “so what?” here? I performed this research mainly because I could, and I thought it was interesting enough to share. Also, I got fascinated with the idea that finding fake applications might be as simple as identifying and following the likely fake reviewers. I’m positive there is more to this network of fraudulent extensions than is documented here.

As this story illustrates, it pays to be judicious about installing extensions. Leaving aside these extensions which are outright fraudulent, so many legitimate extensions get abandoned or sold each year to shady marketers that it’s wise to only trust extensions that are actively maintained (and perhaps have a critical mass of users that would make noise if anything untoward happened with the software).

According to chrome-stats.com, the majority of extensions — more than 100,000 of them — are effectively abandoned by their authors, or haven’t been updated in more than two years. In other words, there a great many developers who are likely to be open to someone else buying up their creation along with their user base.

The information that informed this report is searchable in this Google spreadsheet.