The U.S. Securities and Exchange Commission (SEC) is investigating a security failure on the Web site of real estate title insurance giant First American Financial Corp. that exposed more than 885 million personal and financial records tied to mortgage deals going back to 2003, KrebsOnSecurity has learned.

In May, KrebsOnSecurity broke the news that the Web site for Santa Ana, Calif.-based First American [NYSE:FAF] exposed some 885 million documents related to real estate closings over the past 16 years, including bank account numbers and statements, mortgage and tax records, Social Security numbers, wire transaction receipts and drivers license images. No authentication was required to view the documents.

The initial tip on that story came from Ben Shoval, a real estate developer based in Seattle. Shoval said he recently received a letter from the SEC’s enforcement division which stated the agency was investigating the data exposure to determine if First American had violated federal securities laws.

In its letter, the SEC asked Shoval to preserve and share any documents or evidence he had related to the data exposure.

“This investigation is a non-public, fact-finding inquiry,” the letter explained. “The investigation does not mean that we have concluded that anyone has violated the law.”

The SEC did not respond to requests for comment.

Word of the SEC investigation comes weeks after regulators in New York said they were investigating the company in what could turn out to be the first test of the state’s strict new cybersecurity regulation, which requires financial companies to periodically audit and report on how they protect sensitive data, and provides for fines in cases where violations were reckless or willful. First American also is now the target of a class action lawsuit that alleges it “failed to implement even rudimentary security measures.”

First American has issued a series of statements over the past few months that seem to downplay the severity of the data exposure, which the company said was the result of a “design defect” in its Web site.

On June 18, First American said a review of system logs by an outside forensic firm, “based on guidance from the company, identified 484 files that likely were accessed by individuals without authorization. The company has reviewed 211 of these files to date and determined that only 14 (or 6.6%) of those files contain non-public personal information. The company is in the process of notifying the affected consumers and will offer them complimentary credit monitoring services.”

In a statement on July 16, First American said its now-completed investigation identified just 32 consumers whose non-public personal information likely was accessed without authorization.

“These 32 consumers have been notified and offered complimentary credit monitoring services,” the company said.

First American has not responded to questions about how long this “design defect” persisted on its site, how far back it maintained access logs, or how far back in those access logs the company’s review extended.

A ransomware outbreak that hit QuickBooks cloud hosting firm iNSYNQ in mid-July appears to have started with an email phishing attack that snared an employee working in sales for the company, KrebsOnSecurity has learned. It also looks like the intruders spent roughly ten days rooting around iNSYNQ’s internal network to properly stage things before unleashing the ransomware. iNSYNQ ultimately declined to pay the ransom demand, and it is still working to completely restore customer access to files.

Some of this detail came in a virtual “town hall” meeting held August 8, in which iNSYNQ chief executive Elliot Luchansky briefed customers on how it all went down, and what the company is doing to prevent such outages in the future.

A great many iNSYNQ’s customers are accountants, and when the company took its network offline on July 16 in response to the ransomware outbreak, some of those customers took to social media to complain that iNSYNQ was stonewalling them.

“We could definitely have been better prepared, and it’s totally unacceptable,” Luchansky told customers. “I take full responsibility for this. People waiting ridiculous amounts of time for a response is unacceptable.”

By way of explaining iNSYNQ’s initial reluctance to share information about the particulars of the attack early on, Luchansky told customers the company had to assume the intruders were watching and listening to everything iNSYNQ was doing to recover operations and data in the wake of the ransomware outbreak.

“That was done strategically for a good reason,” he said. “There were human beings involved with [carrying out] this attack in real time, and we had to assume they were monitoring everything we could say. And that posed risks based on what we did say publicly while the ransom negotiations were going on. It could have been used in a way that would have exposed customers even more. That put us in a really tough bind, because transparency is something we take very seriously. But we decided it was in our customers’ best interests to not do that.”

Luchansky did not say how much the intruders were demanding, but he mentioned two key factors that informed the company’s decision not to pay up.

“It was a very substantial amount, but we had the money wired and were ready to pay it in cryptocurrency in the case that it made sense to do so,” he told customers. “But we also understood [that paying] would put a target on our heads in the future, and even if we actually received the decryption key, that wasn’t really the main issue here. Because of the quick reaction we had, we were able to contain the encryption part” to roughly 50 percent of customer systems, he said.

Luchansky said the intruders seeded its internal network with MegaCortex, a potent new ransomware strain first spotted just a couple of months ago that is being used in targeted attacks on enterprises. He said the attack appears to have been carefully planned out in advance and executed “with human intervention all the way through.”

“They decided they were coming after us,” he said. “It’s one thing to prepare for these sorts of events but it’s an entirely different experience to deal with first hand.”

According to an analysis of MegaCortex published this week by Accenture iDefense, the crooks behind this ransomware strain are targeting businesses — not home users — and demanding ransom payments in the range of two to 600 bitcoins, which is roughly $20,000 to $5.8 million.

“We are working for profit,” reads the ransom note left behind by the latest version of MegaCortex. “The core of this criminal business is to give back your valuable data in the original form (for ransom of course).”

Luchansky did not mention in the town hall meeting exactly when the initial phishing attack was thought to have occurred, noting that iNSYNQ is still working with California-based CrowdStrike to gain a more complete picture of the attack.

But Alex Holden, founder of Milwaukee-based cyber intelligence firm Hold Security, showed KrebsOnSecurity information obtained from monitoring dark web communications which suggested the problem started on July 6, after an employee in iNSYNQ’s sales division fell for a targeted phishing email.

“This shows that even after the initial infection, if companies act promptly they can still detect and stop the ransomware,” Holden said. “For these infections hackers take sometimes days, weeks, or even months to encrypt your data.”

iNSYNQ did not respond to requests for comment on Hold Security’s findings.

Asked whether the company had backups of customer data and — if so — why iNSYNQ decided not to restore from those, Luchansky said there were backups but that some of those were also infected.

“The backup system is backing up the primary system, and that by definition entails some level of integration,” Luchansky explained. “The way our system was architected, the malware had spread into the backups as well, at least a little bit. So [by] just turning the backups back on, there was a good chance the the virus would then start to spread through the backup system more. So we had to treat the backups similarly to how we were treating the primary systems.”

Luchansky said their backup system has since been overhauled, and that if a similar attack happened in the future it would take days instead of weeks to recover. However, he declined to get into specifics about exactly what had changed, which is too bad because in every ransomware attack story I’ve written this seems to be the detail most readers are interested in and arguing about.

The CEO added that iNSYNQ also will be partnering with a company that helps firms detect and block targeted phishing attacks, and that it envisioned being able to offer this to its customers at a discounted rate. It wasn’t clear from Luchansky’s responses to questions whether the cloud hosting firm was also considering any kind of employee anti-phishing education and/or testing service.

Luchansky said iNSYNQ was about to restore access to more than 90 percent of customer files by Aug. 2 — roughly two weeks after the ransomware outbreak — and that the company would be offering customers a two month credit as a result of the outage.

Incessantly annoying and fraudulent robocalls. Corrupt wireless company employees taking hundreds of thousands of dollars in bribes to unlock and hijack mobile phone service. Wireless providers selling real-time customer location data, despite repeated promises to the contrary. A noticeable uptick in SIM-swapping attacks that lead to multi-million dollar cyberheists.

If you are somehow under the impression that you — the customer — are in control over the security, privacy and integrity of your mobile phone service, think again. And you’d be forgiven if you assumed the major wireless carriers or federal regulators had their hands firmly on the wheel.

No, a series of recent court cases and unfortunate developments highlight the sad reality that the wireless industry today has all but ceded control over this vital national resource to cybercriminals, scammers, corrupt employees and plain old corporate greed.

On Tuesday, Google announced that an unceasing deluge of automated robocalls had doomed a feature of its Google Voice service that sends transcripts of voicemails via text message.

Google said “certain carriers” are blocking the delivery of these messages because all too often the transcripts resulted from unsolicited robocalls, and that as a result the feature would be discontinued by Aug. 9. This is especially rich given that one big reason people use Google Voice in the first place is to screen unwanted communications from robocalls, mainly because the major wireless carriers have shown themselves incapable or else unwilling to do much to stem the tide of robocalls targeting their customers.

AT&T in particular has had a rough month. In July, the Electronic Frontier Foundation (EFF) filed a class action lawsuit on behalf of AT&T customers in California to stop the telecom giant and two data location aggregators from allowing numerous entities — including bounty hunters, car dealerships, landlords and stalkers — to access wireless customers’ real-time locations without authorization.

And on Monday, the U.S. Justice Department revealed that a Pakistani man was arrested and extradited to the United States to face charges of bribing numerous AT&T call-center employees to install malicious software and unauthorized hardware as part of a scheme to fraudulently unlock cell phones.

Ars Technica reports the scam resulted in millions of phones being removed from AT&T service and/or payment plans, and that the accused allegedly paid insiders hundreds of thousands of dollars to assist in the process.

We should all probably be thankful that the defendant in this case wasn’t using his considerable access to aid criminals who specialize in conducting unauthorized SIM swaps, an extraordinarily invasive form of fraud in which scammers bribe or trick employees at mobile phone stores into seizing control of the target’s phone number and diverting all texts and phone calls to the attacker’s mobile device.

Late last month, a federal judge in New York rejected a request by AT&T to dismiss a $224 million lawsuit over a SIM-swapping incident that led to $24 million in stolen cryptocurrency.

The defendant in that case, 21-year-old Manhattan resident Nicholas Truglia, is alleged to have stolen more than $80 million from victims of SIM swapping, but he is only one of many individuals involved in this incredibly easy, increasingly common and lucrative scheme. The plaintiff in that case alleges that he was SIM-swapped on two different occasions, both allegedly involving crooked or else clueless employees at AT&T wireless stores.

And let’s not forget about all the times various hackers figured out ways to remotely use a carrier’s own internal systems for looking up personal and account information on wireless subscribers.

So what the fresh hell is going on here? And is there any hope that lawmakers or regulators will do anything about these persistent problems? Gigi Sohn, a distinguished fellow at the Georgetown Institute for Technology Law and Policy, said the answer — at least in this administration — is probably a big “no.”

“The takeaway here is the complete and total abdication of any oversight of the mobile wireless industry,” Sohn told KrebsOnSecurity. “Our enforcement agencies aren’t doing anything on these topics right now, and we have a complete and total breakdown of oversight of these incredibly powerful and important companies.”

Aaron Mackey, a staff attorney at the EFF, said that on the location data-sharing issue, federal law already bars the wireless carriers from sharing this with third parties without the expressed consent of consumers.

“What we’ve seen is the Federal Communications Commission (FCC) is well aware of this ongoing behavior about location data sales,” Mackey said. “The FCC has said it’s under investigation, but there has been no public action taken yet and this has been going on for more than a year. The major wireless carriers are not only violating federal law, but they’re also putting people in harm’s way. There are countless stories of folks being able to pretend to be law enforcement and gaining access to information they can use to assault and harass people based on the carriers making location data available to a host of third parties.”

On the issue of illegal SIM swaps, Wired recently ran a column pointing to a solution that many carriers in Africa have implemented which makes it much more difficult for SIM swap thieves to ply their craft.

“The carrier would set up a system to let the bank query phone records for any recent SIM swaps associated with a bank account before they carried out a money transfer,” wrote Wired’s Andy Greenberg in April. “If a SIM swap had occurred in, say, the last two or three days, the transfer would be blocked. Because SIM swap victims can typically see within minutes that their phone has been disabled, that window of time let them report the crime before fraudsters could take advantage.”

So far, there is zero indication that the U.S.-based mobile carriers are paying any attention.

In terms of combating the deluge of robocalls, Sohn says we already have a workable approach to arresting these nuisance calls: It’s an authentication procedure known as “SHAKEN/STIR,” and it is premised on the idea that every phone has a certificate of authenticity attached to it that can be used to validate if the call is indeed originating from the number it appears to be calling from.

Under a SHAKEN/STIR regime, anyone who is spoofing their number (and most of these robocalls are spoofed to appear as though they come from a number that is in the same prefix as yours) gets automatically blocked.

Unfortunately, Sohn said, the FCC has allowed the wireless carriers to adopt this approach voluntarily. And — shocker — most of them haven’t, or else they are charging a premium for it.

“The FCC could make the carriers provide robocall apps for free to customers, but they’re not,” Sohn said. “The carriers instead are turning around and charging customers extra for this service. There was a fairly strong anti-robocalls bill that passed the House, but it’s now stuck in the legislative graveyard that is the Senate.”

What about the prospects of any kind of major overhaul to the privacy laws in this country that might give consumers more say over who can access their private data and what recourse they may have when companies entrusted with that information screw up?

Sohn said there are few signs that anyone in Congress is seriously championing consumer privacy as a major legislative issue. Most of the nascent efforts to bring privacy laws in the United States into the 21st Century she said are interminably bogged down on two sticky issues: Federal preemption of stronger state laws, and the ability of consumers to bring a private right of civil action in the courts against companies that violate those provisions.

“It’s way past time we had a federal privacy bill,” Sohn said. “Companies like Facebook and others are practically begging for some type of regulatory framework on consumer privacy, yet this congress can’t manage to put something together. To me it’s incredible we don’t even have a discussion draft yet. There’s not even a bill that’s being discussed and debated. That is really pitiful, and the closer we get to elections, the less likely it becomes because nobody wants to do anything that upsets their corporate contributions. And, frankly, that’s shameful.”

If you bank online and choose weak or re-used passwords, there’s a decent chance your account could be pilfered by cyberthieves — even if your bank offers multi-factor authentication as part of its login process. This story is about how crooks increasingly are abusing third-party financial aggregation services like Mint, Plaid, Yodlee, YNAB and others to surveil and drain consumer accounts online.

Crooks are constantly probing bank Web sites for customer accounts protected by weak or recycled passwords. Most often, the attacker will use lists of email addresses and passwords stolen en masse from hacked sites and then try those same credentials to see if they permit online access to accounts at a range of banks.

From there, thieves can take the list of successful logins and feed them into apps that rely on application programming interfaces (API)s from one of several personal financial data aggregators which help users track their balances, budgets and spending across multiple banks.

A number of banks that do offer customers multi-factor authentication — such as a one-time code sent via text message or an app — have chosen to allow these aggregators the ability to view balances and recent transactions without requiring that the aggregator service supply that second factor. That’s according to Brian Costello, vice president of data strategy at Yodlee, one of the largest financial aggregator platforms.

Costello said while some banks have implemented processes which pass through multi-factor authentication (MFA) prompts when consumers wish to link aggregation services, many have not.

“Because we have become something of a known quantity with the banks, we’ve set up turning off MFA with many of them,” Costello said.  “Many of them are substituting coming from a Yodlee IP or agent as a factor because banks have historically been relying on our security posture to help them out.”

Such reconnaissance helps lay the groundwork for further attacks: If the thieves are able to access a bank account via an aggregator service or API, they can view the customer’s balance(s) and decide which customers are worthy of further targeting.

This targeting can occur in at least one of two ways. The first involves spear phishing attacks to gain access to that second authentication factor, which can be made much more convincing once the attackers have access to specific details about the customer’s account — such as recent transactions or account numbers (even partial account numbers).

The second is through an unauthorized SIM swap, a form of fraud in which scammers bribe or trick employees at mobile phone stores into seizing control of the target’s phone number and diverting all texts and phone calls to the attacker’s mobile device.

But beyond targeting customers for outright account takeovers, the data available via financial aggregators enables a far more insidious type of fraud: The ability to link the target’s bank account(s) to other accounts that the attackers control.

That’s because PayPal, Zelle, and a number of other pure-play online financial institutions allow customers to link accounts by verifying the value of microdeposits. For example, if you wish to be able to transfer funds between PayPal and a bank account, the company will first send a couple of tiny deposits  — a few cents, usually — to the account you wish to link. Only after verifying those exact amounts will the account-linking request be granted.

Alex Holden is founder and chief technology officer of Hold Security, a Milwaukee-based security consultancy. Holden and his team closely monitor the cybercrime forums, and he said the company has seen a number of cybercriminals discussing how the financial aggregators are useful for targeting potential victims.

Holden said it’s not uncommon for thieves in these communities to resell access to bank account balance and transaction information to other crooks who specialize in cashing out such information.

“The price for these details is often very cheap, just a fraction of the monetary value in the account, because they’re not selling ‘final’ access to the account,” Holden said. “If the account is active, hackers then can go to the next stage for 2FA phishing or social engineering, or linking the accounts with another.”

Currently, the major aggregators and/or applications that use those platforms store bank logins and interactively log in to consumer accounts to periodically sync transaction data. But most of the financial aggregator platforms are slowly shifting toward using the OAuth standard for logins, which can give banks a greater ability to enforce their own fraud detection and transaction scoring systems when aggregator systems and apps are initially linked to a bank account.

That’s according to Don Cardinal, managing director of the Financial Data Exchange (FDX), which is seeking to unite the financial industry around a common, interoperable, and royalty-free standard for secure consumer and business access to their financial data.

“This is where we’re going,” Cardinal said. “The way it works today, you the aggregator or app stores the credentials encrypted and presents them to the bank. What we’re moving to is [an account linking process] that interactively loads the bank’s Web site, you login there, and the site gives the aggregator an OAuth token. In that token granting process, all the bank’s fraud controls are then direct to the consumer.”

Alissa Knight, a senior analyst with the Aite Group, a financial and technology analyst firm, said such attacks highlight the need to get rid of passwords altogether. But until such time, she said, more consumers should take full advantage of the strongest multi-factor authentication option offered by their bank(s), and consider using a password manager, which helps users pick and remember strong and unique passwords for each Web site.

“This is just more empirical data around the fact that passwords just need to go away,” Knight said. “For now, all the standard precautions we’ve been giving consumers for years still stand: Pick strong passwords, avoid re-using passwords, and get a password manager.”

Some of the most popular password managers include 1Password, Dashlane, LastPass and Keepass. Wired.com recently published a worthwhile writeup which breaks down each of these based on price, features and usability.

On Monday, a former Amazon employee was arrested and charged with stealing more than 100 million consumer applications for credit from Capital One. Since then, many have speculated the breach was perhaps the result of a previously unknown “zero-day” flaw, or an “insider” attack in which the accused took advantage of access surreptitiously obtained from her former employer. But new information indicates the methods she deployed have been well understood for years.

What follows is based on interviews with almost a dozen security experts, including one who is privy to details about the ongoing breach investigation. Because this incident deals with somewhat jargon-laced and esoteric concepts, much of what is described below has been dramatically simplified. Anyone seeking a more technical explanation of the basic concepts referenced here should explore some of the many links included in this story.

According to a source with direct knowledge of the breach investigation, the problem stemmed in part from a misconfigured open-source Web Application Firewall (WAF) that Capital One was using as part of its operations hosted in the cloud with Amazon Web Services (AWS).

Known as “ModSecurity,” this WAF is deployed along with the open-source Apache Web server to provide protections against several classes of vulnerabilities that attackers most commonly use to compromise the security of Web-based applications.

The misconfiguration of the WAF allowed the intruder to trick the firewall into relaying requests to a key back-end resource on the AWS platform. This resource, known as the “metadata” service, is responsible for handing out temporary information to a cloud server, including current credentials sent from a security service to access any resource in the cloud to which that server has access.

In AWS, exactly what those credentials can be used for hinges on the permissions assigned to the resource that is requesting them. In Capital One’s case, the misconfigured WAF for whatever reason was assigned too many permissions, i.e. it was allowed to list all of the files in any buckets of data, and to read the contents of each of those files.

The type of vulnerability exploited by the intruder in the Capital One hack is a well-known method called a “Server Side Request Forgery” (SSRF) attack, in which a server (in this case, CapOne’s WAF) can be tricked into running commands that it should never have been permitted to run, including those that allow it to talk to the metadata service.

Evan Johnson, manager of the product security team at Cloudflare, recently penned an easily digestible column on the Capital One hack and the challenges of detecting and blocking SSRF attacks targeting cloud services. Johnson said it’s worth noting that SSRF attacks are not among the dozen or so attack methods for which detection rules are shipped by default in the WAF exploited as part of the Capital One intrusion.

“SSRF has become the most serious vulnerability facing organizations that use public clouds,” Johnson wrote. “The impact of SSRF is being worsened by the offering of public clouds, and the major players like AWS are not doing anything to fix it. The problem is common and well-known, but hard to prevent and does not have any mitigations built into the AWS platform.”

Johnson said AWS could address this shortcoming by including extra identifying information in any request sent to the metadata service, as Google has already done with its cloud hosting platform. He also acknowledged that doing so could break a lot of backwards compatibility within AWS.

“There’s a lot of specialized knowledge that comes with operating a service within AWS, and to someone without specialized knowledge of AWS, [SSRF attacks are] not something that would show up on any critical configuration guide,” Johnson said in an interview with KrebsOnSecurity.

“You have to learn how EC2 works, understand Amazon’s Identity and Access Management (IAM) system, and how to authenticate with other AWS services,” he continued. “A lot of people using AWS will interface with dozens of AWS services and write software that orchestrates and automates new services, but in the end people really lean into AWS a ton, and with that comes a lot of specialized knowledge that is hard to learn and hard to get right.”

In a statement provided to KrebsOnSecurity, Amazon said it is inaccurate to argue that the Capital One breach was caused by AWS IAM, the instance metadata service, or the AWS WAF in any way.

“The intrusion was caused by a misconfiguration of a web application firewall and not the underlying infrastructure or the location of the infrastructure,” the statement reads. “AWS is constantly delivering services and functionality to anticipate new threats at scale, offering more security capabilities and layers than customers can find anywhere else including within their own datacenters, and when broadly used, properly configured and monitored, offer unmatched security—and the track record for customers over 13+ years in securely using AWS provides unambiguous proof that these layers work.”

Amazon pointed to several (mostly a la carte) services it offers AWS customers to help mitigate many of the threats that were key factors in this breach, including:

–Access Advisor, which helps identify and scope down AWS roles that may have more permissions than they need;
–GuardDuty, designed to raise alarms when someone is scanning for potentially vulnerable systems or moving unusually large amounts of data to or from unexpected places;
–The AWS WAF, which Amazon says can detect common exploitation techniques, including SSRF attacks;
–Amazon Macie, designed to automatically discover, classify and protect sensitive data stored in AWS.

William Bengston, formerly a senior security engineer at Netflix, wrote a series of blog posts last year on how Netflix built its own systems for detecting and preventing credential compromises in AWS. Interestingly, Bengston was hired roughly two months ago to be director of cloud security for Capital One. My guess is Capital One now wishes they had somehow managed to lure him away sooner.

Rich Mogull is founder and chief technology officer with DisruptOPS, a firm that helps companies secure their cloud infrastructure. Mogull said one major challenge for companies moving their operations from sprawling, expensive physical data centers to the cloud is that very often the employees responsible for handling that transition are application and software developers who may not be as steeped as they should in security.

“There is a basic skills and knowledge gap that everyone in the industry is fighting to deal with right now,” Mogull said. “For these big companies making that move, they have to learn all this new stuff while maintaining their old stuff. I can get you more secure in the cloud more easily than on-premise at a physical data center, but there’s going to be a transition period as you’re acquiring that new knowledge.”

Since news of the Capital One breach broke on Monday, KrebsOnSecurity has received numerous emails and phone calls from security executives who are desperate for more information about how they can avoid falling prey to the missteps that led to this colossal breach (indeed, those requests were part of the impetus behind this story).

Some of those people included executives at big competing banks that haven’t yet taken the plunge into the cloud quite as deeply as Capital One has. But it’s probably not much of a stretch to say they’re all lining up in front of the diving board.

It’s been interesting to watch over the past couple of years how various cloud providers have responded to major outages on their platforms — very often soon after publishing detailed post-mortems on the underlying causes of the outage and what they are doing to prevent such occurrences in the future. In the same vein, it would be wonderful if this kind of public accounting extended to other big companies in the wake of a massive breach.

I’m not holding out much hope that we will get such detail officially from Capital One, which declined to comment on the record and referred me to their statement on the breach and to the Justice Department’s complaint against the hacker. That’s probably to be expected, seeing as the company is already facing a class action lawsuit over the breach and is likely to be targeted by more lawsuits going forward.

But as long as the public and private response to data breaches remains orchestrated primarily by attorneys (which is certainly the case now at most major corporations), everyone else will continue to lack the benefit of being able to learn from and avoid those same mistakes.