Login
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) said today it is investigating a breach at business intelligence company Sisense, whose products are designed to allow companies to view the status of multiple third-party online services in a single dashboard. CISA urged all Sisense customers to reset any credentials and secrets that may have been shared with the company, which is the same advice Sisense gave to its customers Wednesday evening.
New York City based Sisense has more than a thousand customers across a range of industry verticals, including financial services, telecommunications, healthcare and higher education. On April 10, Sisense Chief Information Security Officer Sangram Dash told customers the company had been made aware of reports that “certain Sisense company information may have been made available on what we have been advised is a restricted access server (not generally available on the internet.)”
“We are taking this matter seriously and promptly commenced an investigation,” Dash continued. “We engaged industry-leading experts to assist us with the investigation. This matter has not resulted in an interruption to our business operations. Out of an abundance of caution, and while we continue to investigate, we urge you to promptly rotate any credentials that you use within your Sisense application.”
In its alert, CISA said it was working with private industry partners to respond to a recent compromise discovered by independent security researchers involving Sisense.
“CISA is taking an active role in collaborating with private industry partners to respond to this incident, especially as it relates to impacted critical infrastructure sector organizations,” the sparse alert reads. “We will provide updates as more information becomes available.”
Sisense declined to comment when asked about the veracity of information shared by two trusted sources with close knowledge of the breach investigation. Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud.
Customers can use Gitlab either as a solution that is hosted in the cloud at Gitlab.com, or as a self-managed deployment. KrebsOnSecurity understands that Sisense was using the self-managed version of Gitlab.
Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth of Sisense customer data, which apparently included millions of access tokens, email account passwords, and even SSL certificates.
The incident raises questions about whether Sisense was doing enough to protect sensitive data entrusted to it by customers, such as whether the massive volume of stolen customer data was ever encrypted while at rest in these Amazon cloud servers.
It is clear, however, that unknown attackers now have all of the credentials that Sisense customers used in their dashboards.
The breach also makes clear that Sisense is somewhat limited in the clean-up actions that it can take on behalf of customers, because access tokens are essentially text files on your computer that allow you to stay logged in for extended periods of time — sometimes indefinitely. And depending on which service we’re talking about, it may be possible for attackers to re-use those access tokens to authenticate as the victim without ever having to present valid credentials.
Beyond that, it is largely up to Sisense customers to decide if and when they change passwords to the various third-party services that they’ve previously entrusted to Sisense.
Earlier today, a public relations firm working with Sisense reached out to learn if KrebsOnSecurity planned to publish any further updates on their breach (KrebsOnSecurity posted a screenshot of the CISO’s customer email to both LinkedIn and Mastodon on Wednesday evening). The PR rep said Sisense wanted to make sure they had an opportunity to comment before the story ran.
But when confronted with the details shared by my sources, Sisense apparently changed its mind.
“After consulting with Sisense, they have told me that they don’t wish to respond,” the PR rep said in an emailed reply.
Update, 6:49 p.m., ET: Added clarification that Sisense is using a self-hosted version of Gitlab, not the cloud version managed by Gitlab.com.
Also, Sisense’s CISO Dash just sent an update to customers directly. The latest advice from the company is far more detailed, and involves resetting a potentially large number of access tokens across multiple technologies, including Microsoft Active Directory credentials, GIT credentials, web access tokens, and any single sign-on (SSO) secrets or tokens.
The full message from Dash to customers is below:
“Good Afternoon,
We are following up on our prior communication of April 10, 2024, regarding reports that certain Sisense company information may have been made available on a restricted access server. As noted, we are taking this matter seriously and our investigation remains ongoing.
Our customers must reset any keys, tokens, or other credentials in their environment used within the Sisense application.
Specifically, you should:
– Change Your Password: Change all Sisense-related passwords on http://my.sisense.com
– Non-SSO:
– Replace the Secret in the Base Configuration Security section with your GUID/UUID.
– Reset passwords for all users in the Sisense application.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Single Sign-On (SSO):
– If you use SSO JWT for the user’s authentication in Sisense, you will need to update sso.shared_secret in Sisense and then use the newly generated value on the side of the SSO handler.
– We strongly recommend rotating the x.509 certificate for your SSO SAML identity provider.
– If you utilize OpenID, it’s imperative to rotate the client secret as well.
– Following these adjustments, update the SSO settings in Sisense with the revised values.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Customer Database Credentials: Reset credentials in your database that were used in the Sisense application to ensure continuity of connection between the systems.
– Data Models: Change all usernames and passwords in the database connection string in the data models.
– User Params: If you are using the User Params feature, reset them.
– Active Directory/LDAP: Change the username and user password of users whose authorization is used for AD synchronization.
– HTTP Authentication for GIT: Rotate the credentials in every GIT project.
– B2D Customers: Use the following API PATCH api/v2/b2d-connection in the admin section to update the B2D connection.
– Infusion Apps: Rotate the associated keys.
– Web Access Token: Rotate all tokens.
– Custom Email Server: Rotate associated credentials.
– Custom Code: Reset any secrets that appear in custom code Notebooks.
If you need any assistance, please submit a customer support ticket at https://community.sisense.com/t5/support-portal/bd-p/SupportPortal and mark it as critical. We have a dedicated response team on standby to assist with your requests.
At Sisense, we give paramount importance to security and are committed to our customers’ success. Thank you for your partnership and commitment to our mutual security.
Regards,
Sangram Dash
Chief Information Security Officer”
The nonprofit organization that supports the Firefox web browser said today it is winding down its new partnership with Onerep, an identity protection service recently bundled with Firefox that offers to remove users from hundreds of people-search sites. The move comes just days after a report by KrebsOnSecurity forced Onerep’s CEO to admit that he has founded dozens of people-search networks over the years.
Mozilla Monitor. Image Mozilla Monitor Plus video on Youtube.
Mozilla only began bundling Onerep in Firefox last month, when it announced the reputation service would be offered on a subscription basis as part of Mozilla Monitor Plus. Launched in 2018 under the name Firefox Monitor, Mozilla Monitor also checks data from the website Have I Been Pwned? to let users know when their email addresses or password are leaked in data breaches.
On March 14, KrebsOnSecurity published a story showing that Onerep’s Belarusian CEO and founder Dimitiri Shelest launched dozens of people-search services since 2010, including a still-active data broker called Nuwber that sells background reports on people. Onerep and Shelest did not respond to requests for comment on that story.
But on March 21, Shelest released a lengthy statement wherein he admitted to maintaining an ownership stake in Nuwber, a consumer data broker he founded in 2015 — around the same time he launched Onerep.
Shelest maintained that Nuwber has “zero cross-over or information-sharing with Onerep,” and said any other old domains that may be found and associated with his name are no longer being operated by him.
“I get it,” Shelest wrote. “My affiliation with a people search business may look odd from the outside. In truth, if I hadn’t taken that initial path with a deep dive into how people search sites work, Onerep wouldn’t have the best tech and team in the space. Still, I now appreciate that we did not make this more clear in the past and I’m aiming to do better in the future.” The full statement is available here (PDF).
Onerep CEO and founder Dimitri Shelest.
In a statement released today, a spokesperson for Mozilla said it was moving away from Onerep as a service provider in its Monitor Plus product.
“Though customer data was never at risk, the outside financial interests and activities of Onerep’s CEO do not align with our values,” Mozilla wrote. “We’re working now to solidify a transition plan that will provide customers with a seamless experience and will continue to put their interests first.”
KrebsOnSecurity also reported that Shelest’s email address was used circa 2010 by an affiliate of Spamit, a Russian-language organization that paid people to aggressively promote websites hawking male enhancement drugs and generic pharmaceuticals. As noted in the March 14 story, this connection was confirmed by research from multiple graduate students at my alma mater George Mason University.
Shelest denied ever being associated with Spamit. “Between 2010 and 2014, we put up some web pages and optimize them — a widely used SEO practice — and then ran AdSense banners on them,” Shelest said, presumably referring to the dozens of people-search domains KrebsOnSecurity found were connected to his email addresses (dmitrcox@gmail.com and dmitrcox2@gmail.com). “As we progressed and learned more, we saw that a lot of the inquiries coming in were for people.”
Shelest also acknowledged that Onerep pays to run ads on “on a handful of data broker sites in very specific circumstances.”
“Our ad is served once someone has manually completed an opt-out form on their own,” Shelest wrote. “The goal is to let them know that if they were exposed on that site, there may be others, and bring awareness to there being a more automated opt-out option, such as Onerep.”
Reached via Twitter/X, HaveIBeenPwned founder Troy Hunt said he knew Mozilla was considering a partnership with Onerep, but that he was previously unaware of the Onerep CEO’s many conflicts of interest.
“I knew Mozilla had this in the works and we’d casually discussed it when talking about Firefox monitor,” Hunt told KrebsOnSecurity. “The point I made to them was the same as I’ve made to various companies wanting to put data broker removal ads on HIBP: removing your data from legally operating services has minimal impact, and you can’t remove it from the outright illegal ones who are doing the genuine damage.”
Playing both sides — creating and spreading the same digital disease that your medicine is designed to treat — may be highly unethical and wrong. But in the United States it’s not against the law. Nor is collecting and selling data on Americans. Privacy experts say the problem is that data brokers, people-search services like Nuwber and Onerep, and online reputation management firms exist because virtually all U.S. states exempt so-called “public” or “government” records from consumer privacy laws.
Those include voting registries, property filings, marriage certificates, motor vehicle records, criminal records, court documents, death records, professional licenses, and bankruptcy filings. Data brokers also can enrich consumer records with additional information, by adding social media data and known associates.
The March 14 story on Onerep was the second in a series of three investigative reports published here this month that examined the data broker and people-search industries, and highlighted the need for more congressional oversight — if not regulation — on consumer data protection and privacy.
On March 8, KrebsOnSecurity published A Close Up Look at the Consumer Data Broker Radaris, which showed that the co-founders of Radaris operate multiple Russian-language dating services and affiliate programs. It also appears many of their businesses have ties to a California marketing firm that works with a Russian state-run media conglomerate currently sanctioned by the U.S. government.
On March 20, KrebsOnSecurity published The Not-So-True People-Search Network from China, which revealed an elaborate web of phony people-search companies and executives designed to conceal the location of people-search affiliates in China who are earning money promoting U.S. based data brokers that sell personal information on Americans.
I hate having to use that word - "alleged" - because it's so inconclusive and I know it will leave people with many unanswered questions. (Edit: 12 days after publishing this blog post, it looks like the "alleged" caveat can be dropped, see the addition at the end of the post for more.) But sometimes, "alleged" is just where we need to begin and over the course of time, proper attribution is made and the dots are joined. We're here at "alleged" for two very simple reasons: one is that AT&T is saying "the data didn't come from us", and the other is that I have no way of proving otherwise. But I have proven, with sufficient confidence, that the data is real and the impact is significant. Let me explain:
Firstly, just as a primer if you're new to this story, read BleepingComputer's piece on the incident. What it boils down to is in August 2021, someone with a proven history of breaching large organisations posted what they claimed were 70 million AT&T records to a popular hacking forum and asked for a very large amount of money should anyone wish to purchase the data. From that story:
From the samples shared by the threat actor, the database contains customers' names, addresses, phone numbers, Social Security numbers, and date of birth.
Fast forward two and a half years and the successor to this forum saw a post this week alleging to contain the entire corpus of data. Except that rather than put it up for sale, someone has decided to just dump it all publicly and make it easily accessible to the masses. This isn't unusual: "fresh" data has much greater commercial value and is often tightly held for a long period before being released into the public domain. The Dropbox and LinkedIn breaches, for example, occurred in 2012 before being broadly distributed in 2016 and just like those incidents, the alleged AT&T data is now in very broad circulation. It is undoubtedly in the hands of thousands of internet randos.
AT&T's position on this is pretty simple:
AT&T continues to tell BleepingComputer today that they still see no evidence of a breach in their systems and still believe that this data did not originate from them.
The old adage of "absence of evidence is not evidence of absence" comes to mind (just because they can't find evidence of it doesn't mean it didn't happen), but as I said earlier on, I (and others) have so far been unable to prove otherwise. So, let's focus on what we can prove, starting with the accuracy of the data.
The linked article talks about the author verifying the data with various people he knows, as well as other well-known infosec identities verifying its accuracy. For my part, I've got 4.8M Have I Been Pwned (HIBP) subscribers I can lean on to assist with verification, and it turns out that 153k of them are in this data set. What I'll typically do in a scenario like this is reach out to the 30 newest subscribers (people who will hopefully recall the nature of HIBP from their recent memory), and ask them if they're willing to assist. I linked to the story from the beginning of this blog post and got a handful of willing respondents for whom I sent their data and asked two simple questions:
The first reply I received was simple, but emphatic:
This individual had their name, phone number, home address and most importantly, their social security number exposed. Per the linked story, social security numbers and dates of birth exist on most rows of the data in encrypted format, but two supplemental files expose these in plain text. Taken at face value, it looks like whoever snagged this data also obtained the private encryption key and simply decrypted the vast bulk (but not all of) the protected values.
The above example simply didn't have plain text entries for the encrypted data. Just by way of raw numbers, the file that aligns with the "70M" headline actually has 73,481,539 lines with 49,102,176 unique email addresses. The file with decrypted SSNs has 43,989,217 lines and the decrypted dates of birth file only has 43,524 rows. (Edit: the reason for this later became clear - there is only one entry per date of birth which is then referenced from multiple records.) The last file, for example, has rows that look just like this:
FreshRSS .encrypted_value='*0g91F1wJvGV03zUGm6mBWSg==' .decrypted_value='1996-07-18'That encrypted value is precisely what appears in the large file hence providing an easy way of matching all the data together. But those numbers also obviously mean that not every impacted individual had their SSN exposed, and most individuals didn't have their date of birth leaked. (Edit: per above, the same entries in the DoB file are referenced by multiple source records so whilst not every record had a DoB recorded, the difference isn't as stark as I originally reported.)
As I'm fond of saying, there's only one thing worse than your data appearing on the dark web: it's appearing on the clear web. And that's precisely where it is; the forum this was posted to isn't within the shady underbelly of a Tor hidden service, it's out there in plain sight on a public forum easily accessed by a normal web browser. And the data is real.
That last response is where most people impacted by this will now find themselves - "what do I do?" Usually I'd tell them to get in touch with the impacted organisation and request a copy of their data from the breach, but if AT&T's position is that it didn't come from them then they may not be much help. (Although if you are a current or previous customer, you can certainly request a copy of your personal information regardless of this incident.) I've personally also used identity theft protection services since as far back as the 90's now, simply to know when actions such as credit enquiries appear against my name. In the US, this is what services like Aura do and it's become common practice for breached organisations to provide identity protection subscriptions to impacted customers (full disclosure: Aura is a previous sponsor of this blog, although we have no ongoing or upcoming commercial relationship).
What I can't do is send you your breached data, or an indication of what fields you had exposed. Whilst I did this in that handful of aforementioned cases as part of the breach verification process, this is something that happens entirely manually and is infeasible en mass. HIBP only ever stores email addresses and never the additional fields of personal information that appear in data breaches. In case you're wondering why that is, we got a solid reminder only a couple of months ago when a service making this sort of data available to the masses had an incident that exposed tens of billions of rows of personal information. That's just an unacceptable risk for which the old adage of "you cannot lose what you do not have" provides the best possible fix.
As I said in the intro, this is not the conclusive end I wanted for this blog post... yet. As impacted HIBP subscribers receive their notifications and particularly as those monitoring domains learn of the aliases in the breach (many domain owners use unique aliases per service they sign up to), we may see a more conclusive outcome to this incident. That may not necessarily be confirmation that the data did indeed originate from AT&T, it could be that it came from a third party processor they use or from another entity altogether that's entirely unrelated. The truth is somewhere there in the data, I'll add any relevant updates to this blog post if and when it comes out.
As of now, all 49M impacted email addresses are searchable within HIBP.
Edit (31 March): AT&T have just released a short statement making 2 important points:
AT&T data-specific fields were contained in a data set
it is not yet known whether the data in those fields originated from AT&T or one of its vendors
They've also been mass-resetting account passcodes after TechCrunch apparently alerted AT&T to the presence of these in the data set. That article also includes the following statement from AT&T:
Based on our preliminary analysis, the data set appears to be from 2019 or earlier, impacting approximately 7.6 million current AT&T account holders and approximately 65.4 million former account holders
Between originally publishing this blog post and AT&T's announcements today, there have been dozens of comments left below that attribute the source of the breach to AT&T in ways that made it increasingly unlikely that the data could have been sourced from anywhere else. I know that many journos (and myself) reached out to folks in AT&T to draw their attention to this, I'm happy to now end this blog post by quoting myself from the opening para 😊
But sometimes, "alleged" is just where we need to begin and over the course of time, proper attribution is made and the dots are joined.
The data privacy company Onerep.com bills itself as a Virginia-based service for helping people remove their personal information from almost 200 people-search websites. However, an investigation into the history of onerep.com finds this company is operating out of Belarus and Cyprus, and that its founder has launched dozens of people-search services over the years.
Onerep’s “Protect” service starts at $8.33 per month for individuals and $15/mo for families, and promises to remove your personal information from nearly 200 people-search sites. Onerep also markets its service to companies seeking to offer their employees the ability to have their data continuously removed from people-search sites.
A testimonial on onerep.com.
Customer case studies published on onerep.com state that it struck a deal to offer the service to employees of Permanente Medicine, which represents the doctors within the health insurance giant Kaiser Permanente. Onerep also says it has made inroads among police departments in the United States.
But a review of Onerep’s domain registration records and that of its founder reveal a different side to this company. Onerep.com says its founder and CEO is Dimitri Shelest from Minsk, Belarus, as does Shelest’s profile on LinkedIn. Historic registration records indexed by DomainTools.com say Mr. Shelest was a registrant of onerep.com who used the email address dmitrcox2@gmail.com.
A search in the data breach tracking service Constella Intelligence for the name Dimitri Shelest brings up the email address dimitri.shelest@onerep.com. Constella also finds that Dimitri Shelest from Belarus used the email address d.sh@nuwber.com, and the Belarus phone number +375-292-702786.
Nuwber.com is a people search service whose employees all appear to be from Belarus, and it is one of dozens of people-search companies that Onerep claims to target with its data-removal service. Onerep.com’s website disavows any relationship to Nuwber.com, stating quite clearly, “Please note that OneRep is not associated with Nuwber.com.”
However, there is an abundance of evidence suggesting Mr. Shelest is in fact the founder of Nuwber. Constella found that Minsk telephone number (375-292-702786) has been used multiple times in connection with the email address dmitrcox@gmail.com. Recall that Onerep.com’s domain registration records in 2018 list the email address dmitrcox2@gmail.com.
It appears Mr. Shelest sought to reinvent his online identity in 2015 by adding a “2” to his email address. The Belarus phone number tied to Nuwber.com shows up in the domain records for comversus.com, and DomainTools says this domain is tied to both dmitrcox@gmail.com and dmitrcox2@gmail.com. Other domains that mention both email addresses in their WHOIS records include careon.me, docvsdoc.com, dotcomsvdot.com, namevname.com, okanyway.com and tapanyapp.com.
Onerep.com CEO and founder Dimitri Shelest, as pictured on the “about” page of onerep.com.
A search in DomainTools for the email address dmitrcox@gmail.com shows it is associated with the registration of at least 179 domain names, including dozens of mostly now-defunct people-search companies targeting citizens of Argentina, Brazil, Canada, Denmark, France, Germany, Hong Kong, Israel, Italy, Japan, Latvia and Mexico, among others.
Those include nuwber.fr, a site registered in 2016 which was identical to the homepage of Nuwber.com at the time. DomainTools shows the same email and Belarus phone number are in historic registration records for nuwber.at, nuwber.ch, and nuwber.dk (all domains linked here are to their cached copies at archive.org, where available).
Nuwber.com, circa 2015. Image: Archive.org.
Update, March 21, 11:15 a.m. ET: Mr. Shelest has provided a lengthy response to the findings in this story. In summary, Shelest acknowledged maintaining an ownership stake in Nuwber, but said there was “zero cross-over or information-sharing with OneRep.” Mr. Shelest said any other old domains that may be found and associated with his name are no longer being operated by him.
“I get it,” Shelest wrote. “My affiliation with a people search business may look odd from the outside. In truth, if I hadn’t taken that initial path with a deep dive into how people search sites work, Onerep wouldn’t have the best tech and team in the space. Still, I now appreciate that we did not make this more clear in the past and I’m aiming to do better in the future.” The full statement is available here (PDF).
Original story:
Historic WHOIS records for onerep.com show it was registered for many years to a resident of Sioux Falls, SD for a completely unrelated site. But around Sept. 2015 the domain switched from the registrar GoDaddy.com to eNom, and the registration records were hidden behind privacy protection services. DomainTools indicates around this time onerep.com started using domain name servers from DNS provider constellix.com. Likewise, Nuwber.com first appeared in late 2015, was also registered through eNom, and also started using constellix.com for DNS at nearly the same time.
Listed on LinkedIn as a former product manager at OneRep.com between 2015 and 2018 is Dimitri Bukuyazau, who says their hometown is Warsaw, Poland. While this LinkedIn profile (linkedin.com/in/dzmitrybukuyazau) does not mention Nuwber, a search on this name in Google turns up a 2017 blog post from privacyduck.com, which laid out a number of reasons to support a conclusion that OneRep and Nuwber.com were the same company.
“Any people search profiles containing your Personally Identifiable Information that were on Nuwber.com were also mirrored identically on OneRep.com, down to the relatives’ names and address histories,” Privacyduck.com wrote. The post continued:
“Both sites offered the same immediate opt-out process. Both sites had the same generic contact and support structure. They were – and remain – the same company (even PissedConsumer.com advocates this fact: https://nuwber.pissedconsumer.com/nuwber-and-onerep-20160707878520.html).”
“Things changed in early 2016 when OneRep.com began offering privacy removal services right alongside their own open displays of your personal information. At this point when you found yourself on Nuwber.com OR OneRep.com, you would be provided with the option of opting-out your data on their site for free – but also be highly encouraged to pay them to remove it from a slew of other sites (and part of that payment was removing you from their own site, Nuwber.com, as a benefit of their service).”
Reached via LinkedIn, Mr. Bukuyazau declined to answer questions, such as whether he ever worked at Nuwber.com. However, Constella Intelligence finds two interesting email addresses for employees at nuwber.com: d.bu@nuwber.com, and d.bu+figure-eight.com@nuwber.com, which was registered under the name “Dzmitry.”
PrivacyDuck’s claims about how onerep.com appeared and behaved in the early days are not readily verifiable because the domain onerep.com has been completely excluded from the Wayback Machine at archive.org. The Wayback Machine will honor such requests if they come directly from the owner of the domain in question.
Still, Mr. Shelest’s name, phone number and email also appear in the domain registration records for a truly dizzying number of country-specific people-search services, including pplcrwlr.in, pplcrwlr.fr, pplcrwlr.dk, pplcrwlr.jp, peeepl.br.com, peeepl.in, peeepl.it and peeepl.co.uk.
The same details appear in the WHOIS registration records for the now-defunct people-search sites waatpp.de, waatp1.fr, azersab.com, and ahavoila.com, a people-search service for French citizens.
The German people-search site waatp.de.
A search on the email address dmitrcox@gmail.com suggests Mr. Shelest was previously involved in rather aggressive email marketing campaigns. In 2010, an anonymous source leaked to KrebsOnSecurity the financial and organizational records of Spamit, which at the time was easily the largest Russian-language pharmacy spam affiliate program in the world.
Spamit paid spammers a hefty commission every time someone bought male enhancement drugs from any of their spam-advertised websites. Mr. Shelest’s email address stood out because immediately after the Spamit database was leaked, KrebsOnSecurity searched all of the Spamit affiliate email addresses to determine if any of them corresponded to social media accounts at Facebook.com (at the time, Facebook allowed users to search profiles by email address).
That mapping, which was done mainly by generous graduate students at my alma mater George Mason University, revealed that dmitrcox@gmail.com was used by a Spamit affiliate, albeit not a very profitable one. That same Facebook profile for Mr. Shelest is still active, and it says he is married and living in Minsk [Update, Mar. 16: Mr. Shelest’s Facebook account is no longer active].
The Italian people-search website peeepl.it.
Scrolling down Mr. Shelest’s Facebook page to posts made more than ten years ago show him liking the Facebook profile pages for a large number of other people-search sites, including findita.com, findmedo.com, folkscan.com, huntize.com, ifindy.com, jupery.com, look2man.com, lookerun.com, manyp.com, peepull.com, perserch.com, persuer.com, pervent.com, piplenter.com, piplfind.com, piplscan.com, popopke.com, pplsorce.com, qimeo.com, scoutu2.com, search64.com, searchay.com, seekmi.com, selfabc.com, socsee.com, srching.com, toolooks.com, upearch.com, webmeek.com, and many country-code variations of viadin.ca (e.g. viadin.hk, viadin.com and viadin.de).
The people-search website popopke.com.
Domaintools.com finds that all of the domains mentioned in the last paragraph were registered to the email address dmitrcox@gmail.com.
Mr. Shelest has not responded to multiple requests for comment. KrebsOnSecurity also sought comment from onerep.com, which likewise has not responded to inquiries about its founder’s many apparent conflicts of interest. In any event, these practices would seem to contradict the goal Onerep has stated on its site: “We believe that no one should compromise personal online security and get a profit from it.”
The people-search website findmedo.com.
Max Anderson is chief growth officer at 360 Privacy, a legitimate privacy company that works to keep its clients’ data off of more than 400 data broker and people-search sites. Anderson said it is concerning to see a direct link between between a data removal service and data broker websites.
“I would consider it unethical to run a company that sells people’s information, and then charge those same people to have their information removed,” Anderson said.
Last week, KrebsOnSecurity published an analysis of the people-search data broker giant Radaris, whose consumer profiles are deep enough to rival those of far more guarded data broker resources available to U.S. police departments and other law enforcement personnel.
That story revealed that the co-founders of Radaris are two native Russian brothers who operate multiple Russian-language dating services and affiliate programs. It also appears many of the Radaris founders’ businesses have ties to a California marketing firm that works with a Russian state-run media conglomerate currently sanctioned by the U.S. government.
KrebsOnSecurity will continue investigating the history of various consumer data brokers and people-search providers. If any readers have inside knowledge of this industry or key players within it, please consider reaching out to krebsonsecurity at gmail.com.
Update, March 15, 11:35 a.m. ET: Many readers have pointed out something that was somehow overlooked amid all this research: The Mozilla Foundation, the company that runs the Firefox Web browser, has launched a data removal service called Mozilla Monitor that bundles OneRep. That notice says Mozilla Monitor is offered as a free or paid subscription service.
“The free data breach notification service is a partnership with Have I Been Pwned (“HIBP”),” the Mozilla Foundation explains. “The automated data deletion service is a partnership with OneRep to remove personal information published on publicly available online directories and other aggregators of information about individuals (“Data Broker Sites”).”
In a statement shared with KrebsOnSecurity.com, Mozilla said they did assess OneRep’s data removal service to confirm it acts according to privacy principles advocated at Mozilla.
“We were aware of the past affiliations with the entities named in the article and were assured they had ended prior to our work together,” the statement reads. “We’re now looking into this further. We will always put the privacy and security of our customers first and will provide updates as needed.”
Related tags
The Minnesota-based Internet provider U.S. Internet Corp. has a business unit called Securence, which specializes in providing filtered, secure email services to businesses, educational institutions and government agencies worldwide. But until it was notified last week, U.S. Internet was publishing more than a decade’s worth of its internal email — and that of thousands of Securence clients — in plain text out on the Internet and just a click away for anyone with a Web browser.
Headquartered in Minnetonka, Minn., U.S. Internet is a regional ISP that provides fiber and wireless Internet service. The ISP’s Securence division bills itself “a leading provider of email filtering and management software that includes email protection and security services for small business, enterprise, educational and government institutions worldwide.”
U.S. Internet/Securence says your email is secure. Nothing could be further from the truth.
Roughly a week ago, KrebsOnSecurity was contacted by Hold Security, a Milwaukee-based cybersecurity firm. Hold Security founder Alex Holden said his researchers had unearthed a public link to a U.S. Internet email server listing more than 6,500 domain names, each with its own clickable link.
A tiny portion of the more than 6,500 customers who trusted U.S. Internet with their email.
Drilling down into those individual domain links revealed inboxes for each employee or user of these exposed host names. Some of the emails dated back to 2008; others were as recent as the present day.
Securence counts among its customers dozens of state and local governments, including: nc.gov — the official website of North Carolina; stillwatermn.gov, the website for the city of Stillwater, Minn.; and cityoffrederickmd.gov, the website for the government of Frederick, Md.
Incredibly, included in this giant index of U.S. Internet customer emails were the internal messages for every current and former employee of U.S. Internet and its subsidiary USI Wireless. Since that index also included the messages of U.S. Internet’s CEO Travis Carter, KrebsOnSecurity forwarded one of Mr. Carter’s own recent emails to him, along with a request to understand how exactly the company managed to screw things up so spectacularly.
Individual inboxes of U.S. Wireless employees were published in clear text on the Internet.
Within minutes of that notification, U.S. Internet pulled all of the published inboxes offline. Mr. Carter responded and said his team was investigating how it happened. In the same breath, the CEO asked if KrebsOnSecurity does security consulting for hire (I do not).
[Author’s note: Perhaps Mr. Carter was frantically casting about for any expertise he could find in a tough moment. But I found the request personally offensive, because I couldn’t shake the notion that maybe the company was hoping it could buy my silence.]
Earlier this week, Mr. Carter replied with a highly technical explanation that ultimately did little to explain why or how so many internal and customer inboxes were published in plain text on the Internet.
“The feedback from my team was a issue with the Ansible playbook that controls the Nginx configuration for our IMAP servers,” Carter said, noting that this incorrect configuration was put in place by a former employee and never caught. U.S. Internet has not shared how long these messages were exposed.
“The rest of the platform and other backend services are being audited to verify the Ansible playbooks are correct,” Carter said.
Holden said he also discovered that hackers have been abusing a Securence link scrubbing and anti-spam service called Url-Shield to create links that look benign but instead redirect visitors to hacked and malicious websites.
“The bad guys modify the malicious link reporting into redirects to their own malicious sites,” Holden said. “That’s how the bad guys drive traffic to their sites and increase search engine rankings.”
For example, clicking the Securence link shown in the screenshot directly above leads one to a website that tries to trick visitors into allowing site notifications by couching the request as a CAPTCHA request designed to separate humans from bots. After approving the deceptive CAPTCHA/notification request, the link forwards the visitor to a Russian internationalized domain name (рпроаг[.]рф).
The link to this malicious and deceptive website was created using Securence’s link-scrubbing service. Notification pop-ups were blocked when this site tried to disguise a prompt for accepting notifications as a form of CAPTCHA.
U.S. Internet has not responded to questions about how long it has been exposing all of its internal and customer emails, or when the errant configuration changes were made. The company also still has not disclosed the incident on its website. The last press release on the site dates back to March 2020.
KrebsOnSecurity has been writing about data breaches for nearly two decades, but this one easily takes the cake in terms of the level of incompetence needed to make such a huge mistake unnoticed. I’m not sure what the proper response from authorities or regulators should be to this incident, but it’s clear that U.S. Internet should not be allowed to manage anyone’s email unless and until it can demonstrate more transparency, and prove that it has radically revamped its security.
Until earlier this week, the support website for networking equipment vendor Juniper Networks was exposing potentially sensitive information tied to customer products, including which devices customers bought, as well as each product’s warranty status, service contracts and serial numbers. Juniper said it has since fixed the problem, and that the inadvertent data exposure stemmed from a recent upgrade to its support portal.
Sunnyvale, Calif. based Juniper Networks makes high-powered Internet routers and switches, and its products are used in some of the world’s largest organizations. Earlier this week KrebsOnSecurity heard from a reader responsible for managing several Juniper devices, who found he could use Juniper’s customer support portal to find device and support contract information for other Juniper customers.
Logan George is a 17-year-old intern working for an organization that uses Juniper products. George said he found the data exposure earlier this week by accident while searching for support information on a particular Juniper product.
George discovered that after logging in with a regular customer account, Juniper’s support website allowed him to list detailed information about virtually any Juniper device purchased by other customers. Searching on Amazon.com in the Juniper portal, for example, returned tens of thousands of records. Each record included the device’s model and serial number, the approximate location where it is installed, as well as the device’s status and associated support contract information.
Information exposed by the Juniper support portal. Columns not pictured include Serial Number, Software Support Reference number, Product, Warranty Expiration Date and Contract ID.
George said the exposed support contract information is potentially sensitive because it shows which Juniper products are most likely to be lacking critical security updates.
“If you don’t have a support contract you don’t get updates, it’s as simple as that,” George said. “Using serial numbers, I could see which products aren’t under support contracts. And then I could narrow down where each device was sent through their serial number tracking system, and potentially see all of what was sent to the same location. A lot of companies don’t update their switches very often, and knowing what they use allows someone to know what attack vectors are possible.”
In a written statement, Juniper said the data exposure was the result of a recent upgrade to its support portal.
“We were made aware of an inadvertent issue that allowed registered users to our system to access serial numbers that were not associated with their account,” the statement reads. “We acted promptly to resolve this issue and have no reason to believe at this time that any identifiable or personal customer data was exposed in any way. We take these matters seriously and always use these experiences to prevent further similar incidents. We are actively working to determine the root cause of this defect and thank the researcher for bringing this to our attention.”
The company has not yet responded to requests for information about exactly when those overly permissive user rights were introduced. However, the changes may date back to September 2023, when Juniper announced it had rebuilt its customer support portal.
George told KrebsOnSecurity the back-end for Juniper’s support website appears to be supported by Salesforce, and that Juniper likely did not have the proper user permissions established on its Salesforce assets. In April 2023, KrebsOnSecurity published research showing that a shocking number of organizations — including banks, healthcare providers and state and local governments — were leaking private and sensitive data thanks to misconfigured Salesforce installations.
Nicholas Weaver, a researcher at University of California, Berkeley’s International Computer Science Institute (ICSI) and lecturer at UC Davis, said the complexity layered into modern tech support portals leaves much room for error.
“This is a reminder of how hard it is to build these large systems like support portals, where you need to be able to manage gazillions of users with distinct access roles,” Weaver said. “One minor screw up there can produce hilarious results.”
Last month, computer maker Hewlett Packard Enterprise announced it would buy Juniper Networks for $14 billion, reportedly to help beef up the 100-year-old technology company’s artificial intelligence offerings.
Update, 11:01 a.m. ET: An earlier version of this story quoted George as saying he was able to see support information for the U.S. Department of Defense. George has since clarified that while one block of device records he found was labeled “Department of Defense,” that record appears to belong to a different country.
I've always thought of it a bit like baseball cards; a kid has a card of this one player that another kid is keen on, and that kid has a card the first one wants so they make a trade. They both have a bunch of cards they've collected over time and by virtue of existing in the same social circles, trades are frequent, and cards flow back and forth on a regular basis. That's the analogy I often use to describe the data breach "personal stash" ecosystem, but with one key difference: if you trade a baseball card then you no longer have the original card, but if you trade a data breach which is merely a digital file, it replicates.
There are personal stashes of data breaches all over the place and they're usually presented like this one:
You'll recognise many of those names because they're noteworthy incidents that received a bunch of press. My Space. Adobe. LinkedIn. Ashley Madison.
The same incidents appear here:
And so on and so forth. Stashes of breaches like this are all over the place and they fuel an exchange ecosystem that replicates billions of records of personal data over and over again. Your data. My data. The data of a significant portion of the global internet-using population, just freely flowing backwards and forwards not just in the shady corners of "the dark web" but traded out there in the clear on mainstream websites. Until inevitably:
Diogo Santos Coelho was 14 when he started RaidForums, and was 21 by the time he was arrested for running the service 2 years ago. A kid, exchanging data without the maturity to understand the consequences of his actions. RaidForums left a void that was quickly filled by BreachForums:
Conor Fitzpatrick was 20 years old when he was finally picked up for running the service last year. Still just a kid, at least in the colloquial fashion in which we refer to youngsters as when we get a bit older, but surely still legally a minor when he chose to begin collecting data breaches.
Websites like these are taken down for a simple reason:
The ecosystem of personal stashes exchanged with other parties fuels crime.
For example, data breaches seed services set up with the express intent of monetising a broad range of personal attributes to the detriment of people who are already victims of a breach. Call them shady versions of Have I Been Pwned if you will, and this talk I gave at AusCERT a couple of years ago is a great explainer (deep-linked to the start of that segment):
The first service I spoke about in that segment was We Leak Info and it was run by two 22 year old guys. The website first appeared 3 years earlier - only a year after the creators had left childhood - and it allowed anyone with the money to access anyone else's personal data including:
names, email addresses, usernames, phone numbers, and passwords
One of the duo was later sentenced to 2 years in prison for his role, and when you read the sorts of conversations they were having, you can't help but think they behaved exactly like you'd expect a couple of young guys who thought they were anonymous would:
In the video, I mentioned Jordan Bloom in relation to LeakedSource, a veritable older gentleman of this class of crime being 24 when the site first appeared.
The company operating LeakedSource, Defiant Tech Inc, which was founded by Jordan Bloom, eventually entered a guilty plea to charges that included trafficking in identity information and when you read what that involved, you can see why this would attract the ire of law enforcement agencies:
However, unlike other breach notification services, such as Have I Been Pwned, LeakedSource also gave subscribers access to usernames, passwords (including in clear text), email addresses and IP addresses. LeakedSource services were often advertised on hacking forums and there was suspicion that its operators were actively looking to hack organizations whose data they could add to their database.
In 2016, a well-wisher purchased my own data from LeakedSource and sent over a dozen different records similar to this one:
Not mentioned in my talk but running in the same era was Leakbase, yet another service that collated huge volumes of sensitive data and sold it to absolutely anyone:
And just like all the other ones, the same data appeared over and over again:
It went dark at the end of 2017 amidst speculation the disappearance was tied to the takedown of the Hansa dark web market. If that was the case, why did we never hear of charges being laid as we did with We Leak Info and LeakedSource? Could it be that the operator of Leakbase was only ever so slightly younger than the other guys mentioned above and not having yet reached adulthood, managed to dodge charges? It would certainly be consistent with the demographic pattern of those with personal stashes of data breaches.
Speaking of patterns: We Leak Info, LeakedSource, Leakbase - it's like there's a theme of shady services attached to the word. As I say in the video, there's also a theme of attempting to remain anonymous (which clearly hasn't worked very well!), and a theme of attempting to eschew legal responsibility for how the data is used by merely putting words in the terms of service. For example, here's Jordan's go at deflecting his role in the ecosystem and yes, this was the entire terms of service:
I particularly like this clause:
You may only use this tool for your own personal security and data research. You may only search information about yourself, or those you are authorized in writing to do so.
That's not going to keep you out of trouble! Time and time again, I see this sort of wording on services used as if it's going to make a difference when the law comes asking hard questions; "Hey we literally told people to play nice with the data!"
We Leak Info used similar entertaining wording with some of the highlights including:
That last one in particular is an absolute zinger! But again, remember, we're talking about guys who stood this service up as teenagers and literally worked on the assumption of "as [l]ong as we cooperate they [the FBI] won't fuck with us" 🤦♂️ The ignorance of that attitude whilst advertising services on criminal forums is just mind-blowing, even for kids.
All of which brings me to the inspiration for this blog post:
Interesting find by @MayhemDayOne, wonder if it was from a shady breach search service (we’ve seen a bunch shut down over the years)? Either way, collecting and storing this data is now trivial so not a big surprise to see someone screw up their permissions and (re)leak it all. https://t.co/DM7udeUcRk
— Troy Hunt (@troyhunt) January 22, 2024
It's like I've seen it all before! No, really, because only a couple of days later someone running a service popped up and claimed responsibility for having exposed the data due to "a firewall misconfiguration". I'm not going to name or link the service, but I will describe a few key features:
I could write predictions about the future of this service but if you've read this far and paid attention to the precedents, you can reliably form your own conclusion. The outcome is easily predictable and indeed it was the predictability of the whole situation when I started getting bombarded with queries about the "Mother of all Breaches" that frustrated me; of course it was someone's personal stash, because we've seen it all before and we live in an era where it's dead easy to build services like this. Cloud is ubiquitous and storage is cheap, you can stand up great looking websites in next to no time courtesy of freely available templates, and the whole data breach trading ecosystem I referred to earlier can easily seed services like this.
Maybe the young guy running this service (assuming the previously observed patterns apply) will learn from history and quietly exit while the getting is good, I don't know, time will tell. At the very least, if he reads this and takes nothing else away, don't go driving around in a bright green Lamborghini!
Edit: In the original version of this blog post, it was incorrectly implied that Jordan Bloom may have been the person who pled guilty to charges when in fact it was the company that ran LeakedSource, Defiant Tech Inc, that the plea was entered under. To the extent that the blog contained words to the effect of, or otherwise implied or contained innuendo that Mr Bloom engaged in criminal or otherwise illegal conduct, or pled guilty to trafficking identify information, I apologise and unreservedly retract such statements and this blog has been edited to ensure that the facts involved in this matter are accurately portrayed.
Authorities in Australia, the United Kingdom and the United States this week levied financial sanctions against a Russian man accused of stealing data on nearly 10 million customers of the Australian health insurance giant Medibank. 33-year-old Aleksandr Ermakov allegedly stole and leaked the Medibank data while working with one of Russia’s most destructive ransomware groups, but little more is shared about the accused. Here’s a closer look at the activities of Mr. Ermakov’s alleged hacker handles.
Aleksandr Ermakov, 33, of Russia. Image: Australian Department of Foreign Affairs and Trade.
The allegations against Ermakov mark the first time Australia has sanctioned a cybercriminal. The documents released by the Australian government included multiple photos of Mr. Ermakov, and it was clear they wanted to send a message that this was personal.
It’s not hard to see why. The attackers who broke into Medibank in October 2022 stole 9.7 million records on current and former Medibank customers. When the company refused to pay a $10 million ransom demand, the hackers selectively leaked highly sensitive health records, including those tied to abortions, HIV and alcohol abuse.
The U.S. government says Ermakov and the other actors behind the Medibank hack are believed to be linked to the Russia-backed cybercrime gang REvil.
“REvil was among the most notorious cybercrime gangs in the world until July 2021 when they disappeared. REvil is a ransomware-as-a-service (RaaS) operation and generally motivated by financial gain,” a statement from the U.S. Department of the Treasury reads. “REvil ransomware has been deployed on approximately 175,000 computers worldwide, with at least $200 million paid in ransom.”
The sanctions say Ermakov went by multiple aliases on Russian cybercrime forums, including GustaveDore, JimJones, and Blade Runner. A search on the handle GustaveDore at the cyber intelligence platform Intel 471 shows this user created a ransomware affiliate program in November 2021 called Sugar (a.k.a. Encoded01), which focused on targeting single computers and end-users instead of corporations.
An ad for the ransomware-as-a-service program Sugar posted by GustaveDore warns readers against sharing information with security researchers, law enforcement, or “friends of Krebs.”
In November 2020, Intel 471 analysts concluded that GustaveDore’s alias JimJones “was using and operating several different ransomware strains, including a private undisclosed strain and one developed by the REvil gang.”
In 2020, GustaveDore advertised on several Russian discussion forums that he was part of a Russian technology firm called Shtazi, which could be hired for computer programming, web development, and “reputation management.” Shtazi’s website remains in operation today.
A Google-translated version of Shtazi dot ru. Image: Archive.org.
The third result when one searches for shtazi[.]ru in Google is an Instagram post from a user named Mikhail Borisovich Shefel, who promotes Shtazi’s services as if it were also his business. If this name sounds familiar, it’s because in December 2023 KrebsOnSecurity identified Mr. Shefel as “Rescator,” the cybercriminal identity tied to tens of millions of payment cards that were stolen in 2013 and 2014 from big box retailers Target and Home Depot, among others.
How close was the connection between GustaveDore and Mr. Shefel? The Treasury Department’s sanctions page says Ermakov used the email address ae.ermak@yandex.ru. A search for this email at DomainTools.com shows it was used to register just one domain name: millioner1[.]com. DomainTools further finds that a phone number tied to Mr. Shefel (79856696666) was used to register two domains: millioner[.]pw, and shtazi[.]net.
The December 2023 story here that outed Mr. Shefel as Rescator noted that Shefel recently changed his last name to “Lenin” and had launched a service called Lenin[.]biz that sells physical USSR-era Ruble notes bearing the image of Vladimir Lenin, the founding father of the Soviet Union. The Instagram account for Mr. Shefel includes images of stacked USSR-era Ruble notes, as well as multiple links to Shtazi.
The Instagram account of Mikhail Borisovich Shefel, aka MikeMike aka Rescator.
Intel 471’s research revealed Ermakov was affiliated in some way with REvil because the stolen Medibank data was published on a blog that had one time been controlled by REvil affiliates who carried out attacks and paid an affiliate fee to the gang.
But by the time of the Medibank hack, the REvil group had mostly scattered after a series of high-profile attacks led to the group being disrupted by law enforcement. In November 2021, Europol announced it arrested seven REvil affiliates who collectively made more than $230 million worth of ransom demands since 2019. At the same time, U.S. authorities unsealed two indictments against a pair of accused REvil cybercriminals.
“The posting of Medibank’s data on that blog, however, indicated a connection with that group, although the connection wasn’t clear at the time,” Intel 471 wrote. “This makes sense in retrospect, as Ermakov’s group had also been a REvil affiliate.”
It is easy to dismiss sanctions like these as ineffective, because as long as Mr. Ermakov remains in Russia he has little to fear of arrest. However, his alleged role as an apparent top member of REvil paints a target on him as someone who likely possesses large sums of cryptocurrency, said Patrick Gray, the Australian co-host and founder of the security news podcast Risky Business.
“I’ve seen a few people poo-poohing the sanctions…but the sanctions component is actually less important than the doxing component,” Gray said. “Because this guy’s life just got a lot more complicated. He’s probably going to have to pay some bribes to stay out of trouble. Every single criminal in Russia now knows he is a vulnerable 33 year old with an absolute ton of bitcoin. So this is not a happy time for him.”
Update, Feb. 21, 1:10 p.m. ET: The Russian security firm F.A.C.C.T reports that Ermakov has been arrested in Russia, and charged with violating domestic laws that prohibit the creation, use and distribution of malicious computer programs.
“During the investigation, several defendants were identified who were not only promoting their ransomware, but also developing custom-made malicious software, creating phishing sites for online stores, and driving user traffic to fraudulent schemes popular in Russia and the CIS,” F.A.C.C.T. wrote. “Among those detained was the owner of the nicknames blade_runner, GistaveDore, GustaveDore, JimJones.”
A Canadian man who says he’s been falsely charged with orchestrating a complex e-commerce scam is seeking to clear his name. His case appears to involve “triangulation fraud,” which occurs when a consumer purchases something online — from a seller on Amazon or eBay, for example — but the seller doesn’t actually own the item for sale. Instead, the seller purchases the item from an online retailer using stolen payment card data. In this scam, the unwitting buyer pays the scammer and receives what they ordered, and very often the only party left to dispute the transaction is the owner of the stolen payment card.
Triangulation fraud. Image: eBay Enterprise.
Timothy Barker, 56, was until recently a Band Manager at Duncan’s First Nation, a First Nation in northwestern Alberta, Canada. A Band Manager is responsible for overseeing the delivery of all Band programs, including community health services, education, housing, social assistance, and administration.
Barker told KrebsOnSecurity that during the week of March 31, 2023 he and the director of the Band’s daycare program discussed the need to purchase items for the community before the program’s budget expired for the year.
“There was a rush to purchase items on the Fiscal Year 2023 timeline as the year ended on March 31,” Barker recalled.
Barker said he bought seven “Step2 All Around Playtime Patio with Canopy” sets from a seller on Amazon.ca, using his payment card on file to pay nearly $2,000 for the items.
On the morning of April 7, Barker’s Facebook account received several nasty messages from an Ontario woman he’d never met. She demanded to know why he’d hacked her Walmart account and used it to buy things that were being shipped to his residence. Barker shared a follow-up message from the woman, who later apologized for losing her temper.
One of several messages from the Ontario woman whose Walmart account was used to purchase the goods that Barker ordered from Amazon.
“If this is not the person who did this to me, I’m sorry, I’m pissed,” the lady from Ontario said. “This order is being delivered April 14th to the address above. If not you, then someone who has the same name. Now I feel foolish.”
On April 12, 2023, before the Amazon purchases had even arrived at his home, Barker received a call from an investigator with the Royal Canadian Mounted Police (RCMP), who said Barker urgently needed to come down to the local RCMP office for an interview related to “an investigation.” Barker said the officer wouldn’t elaborate at the time on the nature of the investigation, and that he told the officer he was in Halifax for several days but could meet after his return home.
According to Barker, the investigator visited his home anyway the following day and began questioning his wife, asking about his whereabouts, his work, and when he might return home.
On April 14, six boxes arrived to partially fulfill his Amazon order; another box was delayed, and the Amazon.ca seller he’d purchased from said the remaining box was expected to ship the following week. Barker said he was confused because all six boxes came from Walmart instead of Amazon, and the shipping labels had his name and address on them but carried a contact phone number in Mexico.
Three days later, the investigator called again, demanding he submit to an interview.
“He then asked where my wife was and what her name is,” Barker said. “He wanted to know her itinerary for the day. I am now alarmed and frightened — this doesn’t feel right.”
Barker said he inquired with a local attorney about a consultation, but that the RCMP investigator showed up at his house before he could speak to the lawyer. The investigator began taking pictures of the boxes from his Amazon order.
“The [investigator] derisively asked why would anyone order so many play sets?” Barker said. “I started to give the very logical answer that we are helping families improve their children’s home life and learning for toddlers when he cut me off and gave the little speech about giving a statement after my arrest. He finally told me that he believes that I used someone’s credit card in Ontario to purchase the Walmart products.”
Eager to clear his name, Barker said he shared with the police copies of his credit card bills and purchase history at Amazon. But on April 21, the investigator called again to say he was coming to arrest Barker for theft.
“He said that if I was home at five o’clock then he would serve the papers at the house and it would go easy and I wouldn’t have to go to the station,” Barker recalled. “If I wasn’t home, then he would send a search team to locate me and drag me to the station. He said he would kick the door down if I didn’t answer my phone. He said he had every right to break our door down.”
Barker said he briefly conferred with an attorney about how to handle the arrest. Later that evening, the RCMP arrived with five squad cars and six officers.
“I asked if handcuffs were necessary – there is no danger of violence,” Barker said. “I was going to cooperate. His response was to turn me around and cuff me. He walked me outside and stood me beside the car for a full 4 or 5 minutes in full view of all the neighbors.”
Barker believes he and the Ontario woman are both victims of triangulation fraud, and that someone likely hacked the Ontario woman’s Walmart account and added his name and address as a recipient.
But he says he has since lost his job as a result of the arrest, and now he can’t find new employment because he has a criminal record. Barker’s former employer — Duncan’s First Nation — did not respond to requests for comment.
“In Canada, a criminal record is not a record of conviction, it’s a record of charges and that’s why I can’t work now,” Barker said. “Potential employers never find out what the nature of it is, they just find out that I have a criminal arrest record.”
Barker said that right after his arrest, the RCMP called the Ontario woman and told her they’d solved the crime and arrested the perpetrator.
“They even told her my employer had put me on administrative leave,” he said. “Surely, they’re not allowed to do that.”
Contacted by KrebsOnSecurity, the woman whose Walmart account was used to fraudulently purchase the child play sets said she’s not convinced this was a case of triangulation fraud. She declined to elaborate on why she believed this, other than to say the police told her Barker was a bad guy.
“I don’t think triangulation fraud was used in this case,” she said. “My actual Walmart.ca account was hacked and an order was placed on my account, using my credit card. The only thing Mr. Barker did was to order the item to be delivered to his address in Alberta.”
Barker shared with this author all of the documentation he gave to the RCMP, including screenshots of his Amazon.ca account showing that the items in dispute were sold by a seller named “Adavio,” and that the merchant behind this name was based in Turkey.
That Adavio account belongs to a young computer engineering student and “SEO expert” based in Adana, Turkey who did not respond to requests for comment.
Amazon.ca said it conducted an investigation and found that Mr. Barker never filed a complaint about the seller or transaction in question. The company noted that Adavio currently has a feedback rating of 4.5 stars out of 5.
“Amazon works hard to provide customers with a great experience and it’s our commitment to go above and beyond to make things right for customers,” Amazon.ca said in a written statement. “If a customer has an issue with an order, they may flag to Amazon through our Customer Service page.”
Barker said when he went to file a complaint with Amazon last year he could no longer find the Adavio account on the website, and that the site didn’t have a category for the type of complaint he wanted to file.
When he first approached KrebsOnSecurity about his plight last summer, Barker said he didn’t want any media attention to derail the chances of having his day in court, and confronting the RCMP investigator with evidence proving that he was being wrongfully prosecuted and maligned.
But a week before his court date arrived at the end of November 2023, prosecutors announced the charges against him would be stayed, meaning they had no immediate plans to prosecute the case further but that the investigation could still be reopened at some point in the future.
The RCMP declined to comment for this story, other than to confirm they had issued a stay of proceedings in the case.
Barker says the stay has left him in legal limbo — denying him the ability to clear his name, while giving the RCMP a free pass for a botched investigation. He says he has considered suing the investigating officer for defamation, but has been told by his attorney that the bar for success in such cases against the government is extremely high.
“I’m a 56-year-old law-abiding citizen, and I haven’t broken any laws,” Barker said, wondering aloud who would be stupid enough to use someone else’s credit card and have the stolen items shipped directly to their home.
“Their putting a stay on the proceedings without giving any evidence or explanation allows them to cover up bad police work,” he said. “It’s all so stupid.”
Triangulation fraud is hardly a new thing. KrebsOnSecurity first wrote about it from an e-commerce vendor’s perspective in 2015, but the scam predates that story by many years and is now a well-understood problem. The Canadian authorities should either let Mr. Barker have his day in court, or drop the charges altogether.
It feels like not a week goes by without someone sending me yet another credential stuffing list. It's usually something to the effect of "hey, have you seen the Spotify breach", to which I politely reply with a link to my old No, Spotify Wasn't Hacked blog post (it's just the output of a small set of credentials successfully tested against their service), and we all move on. Occasionally though, the corpus of data is of much greater significance, most notably the Collection #1 incident of early 2019. But even then, the rapid appearance of Collections #2 through #5 (and more) quickly became, as I phrased it in that blog post, "a race to the bottom" I did not want to take further part in.
Until the Naz.API list appeared. Here's the back story: this week I was contacted by a well-known tech company that had received a bug bounty submission based on a credential stuffing list posted to a popular hacking forum:
Whilst this post dates back almost 4 months, it hadn't come across my radar until now and inevitably, also hadn't been sent to the aforementioned tech company. They took it seriously enough to take appropriate action against their (very sizeable) user base which gave me enough cause to investigate it further than your average cred stuffing list. Here's what I found:
That last number was the real kicker; when a third of the email addresses have never been seen before, that's statistically significant. This isn't just the usual collection of repurposed lists wrapped up with a brand-new bow on it and passed off as the next big thing; it's a significant volume of new data. When you look at the above forum post the data accompanied, the reason why becomes clear: it's from "stealer logs" or in other words, malware that has grabbed credentials from compromised machines. Apparently, this was sourced from the now defunct illicit.services website which (in)famously provided search results for other people's data along these lines:
I was aware of this service because, well, just look at the first example query 🤦♂️
So, what does a stealer log look like? Website, username and password:
That's just the first 20 rows out of 5 million in that particular file, but it gives you a good sense of the data. Is it legit? Whilst I won't test a username and password pair on a service (that's way too far into the grey for my comfort), I regularly use enumeration vectors on websites to validate whether an account actually exists or not. For example, take that last entry for racedepartment.com, head to the password reset feature and mash the keyboard to generate a (quasi) random alias @hotmail.com:
And now, with the actual Hotmail address from that last line:
The email address exists.
The VideoScribe service on line 9:
Exists.
And even the service on the very first line:
From a verification perspective, this gives me a high degree of confidence in the legitimacy of the data. The question of how valid the accompanying passwords remain aside, time and time again the email addresses in the stealer logs checked out on the services they appeared alongside.
Another technique I regularly use for validation is to reach out to impacted HIBP subscribers and simply ask them: "are you willing to help verify the legitimacy of a breach and if so, can you confirm if your data looks accurate?" I usually get pretty prompt responses:
Yes, it does. This is one of the old passwords I used for some online services.
When I asked them to date when they might have last used that password, they believed it was was either 2020 or 2021.
And another whose details appears alongside a Webex URL:
Yes, it does. but that was very old password and i used it for webex cuz i didnt care and didnt use good pass because of the fear of leaking
And another:
Yes these are passwords I have used in the past.
Which got me wondering: is my own data in there? Yep, turns out it is and with a very old password I'd genuinely used pre-2011 when I rolled over to 1Password for all my things. So that sucks, but it does help me put the incident in more context and draw an important conclusion: this corpus of data isn't just stealer logs, it also contains your classic credential stuffing username and password pairs too. In fact, the largest file in the collection is just that: 312 million rows of email addresses and passwords.
Speaking of passwords, given the significance of this data set we've made sure to roll every single one of them into Pwned Passwords. Stefán has been working tirelessly the last couple of days to trawl through this massive corpus and get all the data in so that anyone hitting the k-anonymity API is already benefiting from those new passwords. And there's a lot of them: it's a rounding error off 100 million unique passwords that appeared 1.3 billion times across the corpus of data 😲 Now, what does that tell you about the general public's password practices? To be fair, there are instances of duplicated rows, but there's also a massive prevalence of people using the same password across multiple difference services and completely different people using the same password (there are a finite set of dog names and years of birth out there...) And now more than ever, the impact of this service is absolutely huge!
When we weren't looking, @haveibeenpwned's Pwned Passwords rocketed past 7 *billion* requests in a month 😲 pic.twitter.com/hVDxWp3oQG
— Troy Hunt (@troyhunt) January 16, 2024
Pwned Passwords remains totally free and completely open source for both code and data so do please make use of it to the fullest extent possible. This is such an easy thing to implement, and it has a profound impact on credential stuffing attacks so if you're running any sort of online auth service and you're worried about the impact of Naz.API, this now completely kills any attack using that data. Password reuse remain rampant so attacks of this type prosper (23andMe's recent incident comes immediately to mind), definitely get out in front of this one as early as you can.
So that's the story with the Naz.API data. All the email addresses are now in HIBP and searchable either individually or via domain and all those passwords are in Pwned Passwords. There are inevitably going to be queries along the lines of "can you show me the actual password" or "which website did my record appear against" and as always, this just isn't information we store or return in queries. That said, if you're following the age-old guidance of using a password manager, creating strong and unique ones and turning 2FA on for all your things, this incident should be a non-event. If you're not and you find yourself in this data, maybe this is the prompt you finally needed to go ahead and do those things right now 🙂
Edit: A few clarifications based on comments:
On Dec. 18, 2013, KrebsOnSecurity broke the news that U.S. retail giant Target was battling a wide-ranging computer intrusion that compromised more than 40 million customer payment cards over the previous month. The malware used in the Target breach included the text string “Rescator,” which also was the handle chosen by the cybercriminal who was selling all of the cards stolen from Target customers. Ten years later, KrebsOnSecurity has uncovered new clues about the real-life identity of Rescator.
Rescator, advertising a new batch of cards stolen in a 2014 breach at P.F. Chang’s.
Shortly after breaking the Target story, KrebsOnSecurity reported that Rescator appeared to be a hacker from Ukraine. Efforts to confirm my reporting with that individual ended when they declined to answer questions, and after I declined to accept a bribe of $10,000 not to run my story.
That reporting was based on clues from an early Russian cybercrime forum in which a hacker named Rescator — using the same profile image that Rescator was known to use on other forums — claimed to have originally been known as “Helkern,” the nickname chosen by the administrator of a cybercrime forum called Darklife.
KrebsOnSecurity began revisiting the research into Rescator’s real-life identity in 2018, after the U.S. Department of Justice unsealed an indictment that named a different Ukrainian man as Helkern.
It may be helpful to first recap why Rescator is thought to be so closely tied to the Target breach. For starters, the text string “Rescator” was found in some of the malware used in the Target breach. Investigators would later determine that a variant of the malware used in the Target breach was used in 2014 to steal 56 million payment cards from Home Depot customers. And once again, cards stolen in the Home Depot breach were sold exclusively at Rescator’s shops.
On Nov. 25, 2013, two days before Target said the breach officially began, Rescator could be seen in instant messages hiring another forum member to verify 400,000 payment cards that Rescator claimed were freshly stolen.
By the first week of December 2013, Rescator’s online store — rescator[.]la — was selling more than six million payment card records stolen from Target customers. Prior to the Target breach, Rescator had mostly sold much smaller batches of stolen card and identity data, and the website allowed cybercriminals to automate the sending of fraudulent wire transfers to money mules based in Lviv, Ukraine.
Finally, there is some honor among thieves, and in the marketplace for stolen payment card data it is considered poor form to advertise a batch of cards as “yours” if you are merely reselling cards sold to you by a third-party card vendor or thief. When serious stolen payment card shop vendors wish to communicate that a batch of cards is uniquely their handiwork or that of their immediate crew, they refer to it as “our base.” And Rescator was quite clear in his advertisements that these millions of cards were obtained firsthand.
The new clues about Rescator’s identity came into focus when I revisited the reporting around an April 2013 story here that identified the author of the OSX Flashback Trojan, an early Mac malware strain that quickly spread to more than 650,000 Mac computers worldwide in 2012.
That story about the Flashback author was possible because a source had obtained a Web browser authentication cookie for a founding member of a Russian cybercrime forum called BlackSEO. Anyone in possession of that cookie could then browse the invite-only BlackSEO forum and read the user’s private messages without having to log in.
BlackSEO.com VIP member “Mavook” tells forum admin Ika in a private message that he is the Flashback author.
The legitimate owner of that BlackSEO user cookie went by the nickname Ika, and Ika’s private messages on the forum showed he was close friends with the Flashback author. At the time, Ika also was the administrator of Pustota[.]pw — a closely-guarded Russian forum that counted among its members some of the world’s most successful and established spammers and malware writers.
For many years, Ika held a key position at one of Russia’s largest Internet service providers, and his (mostly glowing) reputation as a reliable provider of web hosting to the Russian cybercrime community gave him an encyclopedic knowledge about nearly every major player in that scene at the time.
The story on the Flashback author featured redacted screenshots that were taken from Ika’s BlackSEO account (see image above). The day after that story ran, Ika posted a farewell address to his mates, expressing shock and bewilderment over the apparent compromise of his BlackSEO account.
In a lengthy post on April 4, 2013 titled “I DON’T UNDERSTAND ANYTHING,” Ika told Pustota forum members he was so spooked by recent events that he was closing the forum and quitting the cybercrime business entirely. Ika recounted how the Flashback story had come the same week that rival cybercriminals tried to “dox” him (their dox named the wrong individual, but included some of Ika’s more guarded identities).
“It’s no secret that karma farted in my direction,” Ika said at the beginning of his post. Unbeknownst to Ika at the time, his Pustota forum also had been completely hacked that week, and a copy of its database shared with this author.
A Google translated version of the farewell post from Ika, the administrator of Pustota, a Russian language cybercrime forum focused on botnets and spam. Click to enlarge.
Ika said the two individuals who tried to dox him did so on an even more guarded Russian language forum — DirectConnection[.]ws, perhaps the most exclusive Russian cybercrime community ever created. New applicants of this forum had to pay a non-refundable deposit, and receive vouches by three established cybercriminals already on the forum. Even if one managed to steal (or guess) a user’s DirectConnection password, the login page could not be reached unless the visitor also possessed a special browser certificate that the forum administrator gave only to approved members.
In no uncertain terms, Ika declared that Rescator went by the nickname MikeMike on DirectConnection:
“I did not want to bring any of this to real life. Especially since I knew the patron of the clowns – specifically Pavel Vrublevsky. Yes, I do state with confidence that the man with the nickname Rescator a.k.a. MikeMike with his partner Pipol have been Pavel Vrublevsky’s puppets for a long time.”
Pavel Vrublevsky is a convicted cybercriminal who became famous as the CEO of the Russian e-payments company ChronoPay, which specialized in facilitating online payments for a variety of “high-risk” businesses, including gambling, pirated Mp3 files, rogue antivirus software and “male enhancement” pills.
As detailed in my 2014 book Spam Nation, Vrublevsky not-so-secretly ran a pharmacy affiliate spam program called Rx-Promotion, which paid spammers and virus writers to blast out tens of billions of junk emails advertising generic Viagra and controlled pharmaceuticals like pain relief medications. Much of my reporting on Vrublevsky’s cybercrime empire came from several years worth of internal ChronoPay emails and documents that were leaked online in 2010 and 2011.
Pavel Vrublevsky’s former Facebook profile photo.
In 2014, KrebsOnSecurity learned from a trusted source close to the Target breach investigation that the user MikeMike on DirectConnection — the same account that Ika said belonged to Rescator — used the email address “zaxvatmira@gmail.com.”
At the time, KrebsOnSecurity could not connect that email address to anything or anyone. However, a recent search on zaxvatmira@gmail.com at the breach tracking service Constella Intelligence returns just one result: An account created in November 2010 at the site searchengines[.]ru under the handle “r-fac1.”
A search on “r-fac1” at cyber intelligence firm Intel 471 revealed that this user’s introductory post on searchengines[.]ru advertised musictransferonline[.]com, an affiliate program that paid people to drive traffic to sites that sold pirated music files for pennies apiece.
According to leaked ChronoPay emails from 2010, this domain was registered and paid for by ChronoPay. Those missives also show that in August 2010 Vrublevsky authorized a payment of ~$1,200 for a multi-user license of an Intranet service called MegaPlan.
ChronoPay used the MegaPlan service to help manage the sprawling projects that Vrublevsky referred to internally as their “black” payment processing operations, including pirated pills, porn, Mp3s, and fake antivirus products. ChronoPay employees used their MegaPlan accounts to track payment disputes, order volumes, and advertising partnerships for these high-risk programs.
Borrowing a page from the Quentin Tarantino movie Reservoir Dogs, the employees adopted nicknames like “Mr. Kink,” “Mr. Heppner,” and “Ms. Nati.” However, in a classic failure of operational security, many of these employees had their MegaPlan account messages automatically forwarded to their real ChronoPay email accounts.
A screen shot of the org chart from ChronoPay’s MegaPlan Intranet system.
When ChronoPay’s internal emails were leaked in 2010, the username and password for its MegaPlan subscription were still working and valid. An internal user directory for that subscription included the personal (non-ChronoPay) email address tied to each employee Megaplan nickname. That directory listing said the email address zaxvatmira@gmail.com was assigned to the head of the Media/Mp3 division for ChronoPay, pictured at the top left of the organizational chart above as “Babushka Vani and Koli.”
[Author’s note: I initially overlooked the presence of the email address zaxvatmira@gmail.com in my notes because it did not show up in text searches of my saved emails, files or messages. I rediscovered it recently when a text search for zaxvatmira@gmail.com on my Mac found the address in a screenshot of the ChronoPay MegaPlan interface.]
The nickname two rungs down from “Babushka” in the ChronoPay org chart is “Lev Tolstoy,” which the MegaPlan service showed was picked by someone who used the email address v.zhabukin@freefrog-co-ru.
ChronoPay’s emails show that this Freefrog email address belongs to a Vasily Borisovich Zhabykin from Moscow. The Russian business tracking website rusprofile[.]ru reports that Zhabykin is or was the supervisor or owner of three Russian organizations, including one called JSC Hot Spot.
[Author’s note: The word “babushka” means “grandma” in Russian, and it could be that this nickname is a nod to the ChronoPay CEO’s wife, Vera. The leaked ChronoPay emails show that Vera Vrublevsky managed a group of hackers working with their media division, and was at least nominally in charge of MP3 projects for ChronoPay. Indeed, in messages exposed by the leaked ChronoPay email cache, Zhabykin stated that he was “directly subordinate” to Mrs. Vrublevsky].
JSC Hot Spot is interesting because its co-founder is another ChronoPay employee: 37-year-old Mikhail “Mike” Shefel. A Facebook profile for Mr. Shefel says he is or was vice president of payment systems at ChronoPay. However, the last update on that profile is from 2018, when Shefel appears to have legally changed his last name.
Archive.org shows that Hot Spot’s website — myhotspot[.]ru — sold a variety of consulting services, including IT security assessments, code and system audits, and email marketing. The earliest recorded archive of the Hot Spot website listed three clients on its homepage, including ChronoPay and Freefrog.
ChronoPay internal emails show that Freefrog was one of its investment projects that facilitated the sale of pirated Mp3 files. Rusprofile[.]ru reports that Freefrog’s official company name — JSC Freefrog — is incorporated by a thinly-documented entity based in the Seychelles called Impex Consulting Ltd., and it is unclear who its true owners are.
However, a search at DomainTools.com on the phone number listed on the homepage of myhotspot[.]ru (74957809554) reveals that number is associated with eight domain names.
Six of those domains are some variation of FreeFrog. Another domain registered to that phone number is bothunter[.]me, which included a copyright credit to “Hot Spot 2011.” At the annual Russian Internet Week IT convention in Moscow in 2012, Mr. Shefel gave a short presentation about bothunter, which he described as a service he designed to identify inauthentic (bot) accounts on Russian social media networks.
Interestingly, one of r-fac1’s first posts to Searchengines[.]ru a year earlier saw this user requesting help from other members who had access to large numbers of hacked social media accounts. R-fac1 told forum members that he was only looking to use those accounts to post harmless links and comments to the followers of the hacked profiles, and his post suggested he was testing something.
“Good afternoon,” r-fac1 wrote on Dec. 20, 2010. “I’m looking for people with their own not-recently-registered accounts on forums, (except for search) Social networks, Twitter, blogs, their websites. Tasks, depending on your accounts, post text and a link, sometimes just a link. Most often the topic is chatter, relaxation, discussion. Posting my links in your profiles, on your walls. A separate offer for people with a large set of contacts in instant messengers to try to use viral marketing.”
Neither Mr. Shefel nor Mr. Zhabykin responded to requests for comment.
Mr. Zhabykin soon moved on to bigger ventures, co-founding a cryptocurrency exchange based in Moscow’s financial center called Suex. In September 2021, Suex earned the distinction of becoming the first crypto firm to be sanctioned by the U.S. Department of the Treasury, which effectively blocked Suex from the global financial system. The Treasury alleged Suex helped to process millions in criminal transactions, including the proceeds of numerous ransomware attacks.
“I don’t understand how I got mixed up in this,” Zhabykin told The New York Times in 2021. Zhabykin said Suex, which is registered in the Czech Republic, was mostly a failure and had conducted only a half dozen or so transactions since 2019.
The Russian business tracking service Rusprofile says Zhabykin also is the owner of a company based in the United Kingdom called RideWithLocal; the company’s website says it specializes in arranging excursions for extreme sports, including snowboarding, skiing, surfing and parasailing. Images from the RideWithLocal Facebook page show helicopters dropping snowboarders and skiers atop some fairly steep mountains.
A screenshot from the Facebook page of RideWithLocal.
Constella Intelligence found a cached copy of a now-deleted LinkedIn profile for Mr. Zhabykin, who described himself as a “sporttech/fintech specialist and mentor.”
“I create products and services worldwide, focusing on innovation and global challenges,” his LinkedIn profile said. “I’ve started my career in 2002 and since then I worked in Moscow, different regions of Russia, including Siberia and in Finland, Brazil, United Kingdom, Sri Lanka. Over the last 15 years I contributed to many amazing products in the following industries: sports, ecology, sport tech, fin tech, electronic payments, big data, telecommunications, pulp and paper industry, wood processing and travel. My specialities are Product development, Mentorship, Strategy and Business development.”
Rusprofile reports that Mikhail Borisovich Shefel is associated with at least eight current or now-defunct companies in Russia, including Dengi IM (Money IM), Internet Capital, Internet Lawyer, Internet 2, Zao Hot Spot, and (my personal favorite) an entity incorporated in 2021 called “All the Money in the World.”
Constella Intelligence found several official documents for Mr. Shefel that came from hacked Russian phone, automobile and residence records. They indicate Mr. Shefel is the registrant of a black Porsche Cayenne (Plate:X537SR197) and a Mercedes (Plate:P003PX90). Those vehicle records show Mr. Shefel was born on May 28, 1986.
Rusprofile reveals that at some point near the end of 2018, Shefel changed his last name to Lenin. DomainTools reports that in 2018, Mr. Shefel’s company Internet 2 LLC registered the domain name Lenin[.]me. This now-defunct service sold physical USSR-era Ruble notes that bear the image of Vladimir Lenin, the founding father of the Soviet Union.
Meanwhile, Pavel Vrublevsky remains imprisoned in Russia, awaiting trial on fraud charges levied against the payment company CEO in March 2022. Authorities allege Vrublevsky operated several fraudulent SMS-based payment schemes. They also accused Vrublevsky of facilitating money laundering for Hydra, the largest Russian darknet market. Hydra trafficked in illegal drugs and financial services, including cryptocurrency tumbling for money laundering, exchange services between cryptocurrency and Russian rubles, and the sale of falsified documents and hacking services.
In 2013, Vrublevsky was sentenced to 2.5 years in a Russian penal colony for convincing one of his top spammers and botmasters to launch a distributed denial-of-service (DDoS) attack against a ChronoPay competitor that shut down the ticketing system for the state-owned Aeroflot airline.
Following his release, Vrublevsky began working on a new digital payments platform based in Hong Kong called HPay Ltd (a.k.a. Hong Kong Processing Corporation). HPay appears to have had a great number of clients that were running schemes which bamboozled people with fake lotteries and prize contests.
KrebsOnSecurity sought comment on this research from the Federal Bureau of Investigation (FBI) and the U.S. Secret Service, both of which have been involved in the Target breach investigation over the years. The FBI declined to comment. The Secret Service declined to confirm or dispute any of the findings, but said it is still interested in hearing from anyone who might have more information.
“The U.S. Secret Service does not comment on any open investigation and won’t confirm or deny the accuracy in any reporting related to a criminal manner,” the agency said in a written statement. “However, If you have any information relating to the subjects referenced in this article, please contact the U.S. Secret Service at mostwanted@usss.dhs.gov. The Secret Service pays a reward for information leading to the arrest of cybercriminals.”
A decade ago to the day, I published a tweet launching what would surely become yet another pet project that scratched an itch, was kinda useful to a few people but other than that, would shortly fade away into the same obscurity as all the other ones I'd launched over the previous couple of decades:
It's alive! "Have I been pwned?" by @troyhunt is now up and running. Search for your account across multiple breaches http://t.co/U0QyHZxP6k
— Have I Been Pwned (@haveibeenpwned) December 4, 2013
And then, as they say, things kinda escalated quickly. The very next day I published a blog post about how I made it so fast to search through 154M records and thus began a now 185-post epic where I began detailing the minutiae of how I built this thing, the decisions I made about how to run it and commentary on all sorts of different breaches. And now, a 10th birthday blog post about what really sticks out a decade later. And that's precisely what this 185th blog post tagging HIBP is - the noteworthy things of the years past, including a few things I've never discussed publicly before.
You know why it's called "Have I Been Pwned"? Try coming up with almost any conceivable normal sounding English name and getting a .com domain for it. Good luck! That was certainly part of it, but another part of the name choice was simply that I honestly didn't expect this thing to go anywhere. It's like I said in the intro of this post where I fully expected this to be another failed project, so why does the name matter?
But it's weird how "pwned" has stuck and increasingly, become synonymous with HIBP. For many people, the first time they ever hear the word is in the context of "Have I Been..." with an ensuing discussion often explaining the origins of the term as it relates to gaming culture. And if you do go and look for a definition of the term online, you'll come across resources such as How “PWNED” went from hacker slang to the internet’s favourite taunt:
Then in 2013, when various web services and sites saw an uptick in personal data breaches, security expert Troy Hunt created the website “Have I Been Pwned?” Anyone can type in an email address into the site to check if their personal data has been compromised in a security breach.
And somehow, this little project is now referenced in the definition of the name it emerged from. Weird.
But, because it's such an odd name that has so frequently been mispronounced or mistyped, I've ended up with a whole raft of bizarre domain names including haveibeenpaened.com, haveibeenpwnded.com, haveibeenporned.com and my personal favourite, haveibeenprawned.com (because a journo literally pronounced it that way in a major news segment 🤦♂️). Not to mention all the other weird variations including haveibeenburned.com, haveigotpwned.com, haveibeenrekt.com and after someone made the suggestion following the revelation that PornHub follows me, haveibeenfucked.com 🤷♂️
It's difficult to even know where to start here. How does the little site with the weird name end up in the press? Inevitably, "because data breaches", and it's nuts just how much exposure this project has had because of them. These are often mainstream news events and what reporters often want to impart to people is along the lines of "Here's what you should do if you've been impacted", which often boils down to checking HIBP.
Press is great for raising awareness of the project, but it has also quite literally DDoS'd the service with the Martin Lewis Money Show in the UK knocking it offline in 2016. Cool! No, for real, I learned some really valuable lessons from that experience which, of course, I shared in a blog post. And then ensured could never happen again.
Back in 2018, Gizmodo reckoned HIBP was one of the top 100 websites that shaped the internet as we knew it, alongside the likes of Wikipedia, Google, Amazon and Goatse (don't Google it). Only the year after it launched, TIME magazine reckon'd it was one of the 50 best websites of the year. And every time I do a Google search for a major news outlet, I find this little website. The Wall Street Journal. The Standard (nice headline!) USA Today. Toronto Star. De Telegraaf. VG. Le Monde. Corriere della Sera. It's wild - I just kept Googling for the largest newspapers in various parts of the world and kept getting hits!
The point is that it's had impact, and nobody is more surprised about that than me.
How on earth did I end up here?!
6 years and a few days ago now, I found myself in a place I'd only ever seen before in the movies: Congress. American Congress. Saying "pwned"!
For reasons I still struggle to completely grasp, the folks there thought it would be a good idea if I flew to the other side of the world and talked about the impact of data breaches on identity verification. "You know they're just trying to get you to DC so they can arrest you for all that stolen data you have, right?! 🤣", the internet quipped. But instead, I had one of the most memorable moments of my career as I read my testimony (these are public hearings so it's all recorded and available to watch), responded to questions from congressmen and congresswomen and rounded out the trip staring down at where they inaugurate presidents:
Today, that photo adorns the wall outside my office and dozens of times a day I look at it and ask the same question - how did it all lead to this?!
The potential sale of HIBP was a very painful, very expensive chapter of life, announced in a blog post from June 2019. For the most part, I was as transparent and honest as I could be about the reasons behind the decision, including the stress:
To be completely honest, it's been an enormously stressful year dealing with it all.
More than one year later, I finally wrote about the source of so much of that stress: divorce. Relationship circumstances had put a huge amount of pressure on me and I needed a relief valve which at the time, I thought would be the sale of the project I loved so much but was becoming increasingly demanding. Ultimately, Project Svalbard (the code name for the sale of HIBP), had the opposite effect as years of bitter legal battles with my ex ensued, in part due to the perceived value that would have been realised had it been sold and some big tech company owned my arse for years to come. The project I built out of a passion to do community good was now being used as a tool to extract as much money out of me as possible. There's a wild story to be told there one day but whilst that saga is now well and truly behind me, the scars are still raw.
There were many times throughout Project Svalbard where I felt like I was living out an episode of Silicon Valley, especially as I hopped between interviews at the who's-who of tech firms in San Francisco to meet potential acquirers. But there was one moment in particular that I knew at the time would form an indelible memory, so I took a photo of it:
I'm sitting in a rental car in Yosemite whilst driving from the aforementioned meetings in SF and onto Vegas for the annual big cyber-events. I had a scheduled call with a big tech firm who was a potential acquirer and should that deal go through, the guy I was speaking to would be my new boss. I'd done that dozens of times by now and I don't know if it was because I was especially tired or emotional or if there was something in the way he phrased the question, but this triggered something deep inside me:
So Troy, what would your perfect day in the office look like?
I didn't say it this directly, but I kid you not this is exactly what popped into my mind:
I get on my jet ski and I do whatever the fuck I want
My potential new overlord had somehow managed to find exactly the raw nerve to touch that made me realise how valuable independence had become to me. 6 months later, Project Svalbard was dead after a deal I'd struck fell through. I still can't talk about the precise circumstances due to being NDA'd up to wazoo, but the term we chose to use was "a change of business circumstances on behalf of the purchaser". With the benefit of hindsight, I've never been so happy to have lost so much 😊
10 years ago, I certainly didn't see this on the cards:
This is so cool, thanks @FBI 😊 pic.twitter.com/aqMi3as91O
— Troy Hunt (@troyhunt) June 28, 2023
Nor did I expect them to be actively feeding data into HIBP. Or the UK's NCA to be feeding data in. Or various other law enforcement agencies the world over. And I never envisioned a time where dozens of national governments would be happy to talk about using the service.
A couple of months ago, the ABC wrote a long piece on how this whole thing is, to use their term, a strange sign of the times.
He’s just “a dude on the web”, but Troy Hunt has ended up playing an oddly central role in global cybersecurity.
It's strange until you look at through the lens of aligned objectives: the whole idea of HIBP was "to do good things after bad things happen" which is well aligned with the mandates of law enforcement agencies. You could call it... common ground:
This is something I suspect a lot of people don't understand - that law enforcement agencies often work in conjunction with private enterprise to further their goals of protecting people just like you and me. It's something I certainly didn't understand 10 years ago, and I still remember the initial surprise when agencies started reaching out. Many years on, these have become really productive relationships with a bunch of top notch people, a number of whom I now count as friends and make an effort to spend time with on my travels.
This was never on the cards originally. In fact, I'd always been adamant that there should never be passwords in HIBP although in my defence, the sentiment was that they should never appear next to the username to which they originally accompanied. But looking at passwords through the lens of how breach data can be used to do good things, a list of known compromised passwords disassociated from any form of PII made a lot of sense. So, in 2017, Pwned Passwords was born. You know what I was saying earlier about things escalating quickly? Yeah:
Setting all new records for Pwned Passwords this week: biggest day ever yesterday at 282M requests and biggest rolling 30 days ever, now passing the 6 *billion* requests mark! pic.twitter.com/dQiuQim3da
— Troy Hunt (@troyhunt) September 12, 2023
As if to make the point, I just checked the latest stats and last week we did 301.6M requests in a single day. 100% of those requests - and that's not a rounded number either, it's 100.0000000000% - were served from Cloudflare's cache 🤯
There's so much I love about this service. I love that it's free, there's no auth, it's entirely open source (both code and data), the FBI feeds data into it and perhaps most importantly, it has real impact on security. It's such a simple thing, but every time you see a headline such as "Big online website hit with credential stuffing attack", a significant portion of the accounts being taken over have passwords that could easily have been blocked.
On multiple occasions now, I've had conversations that can best be paraphrased as follows:
Random Internet Person: I'm going to report you to the FBI for having all that stolen data
Me: Maybe you should start by Googling "troy hunt fbi" first...
But I understand where they're coming from and the paradox I refer to is the perceived conflict between handling what is usually the output of a crime whilst simultaneously trying to perform a community good. It's the same discussion I've often had with people citing privacy laws in their corner of the world (often the EU and GDPR) as the reason why HIBP shouldn't exist: "but you're processing data without informed consent!", they'll claim. The issue of there being other legal bases for processing aside, nobody consents to being in a data breach! The natural progression of that conversation is that being in a data breach is a parallel discussion to HIBP then indexing it and making it searchable, which is something I've devoted many words to addressing in the past.
But for all the bluster the occasional random internet person can have (and honestly, I could count the number of annual instances of this on one hand), nothing has come of any complaints. And when I say "complaints", it's often nothing more than a polite conversation which may simply conclude with an acknowledgment of opposing views and that's it. There has been one exception in the entire decade of running this service where a complaint did come via a government privacy regulator, I responded to all the questions that were asked and that was the end of it.
When you have a pet project like HIBP was in the beginning, it's usually just you putting in the hours. That's fine, it's a hobby and you're scratching an itch, so what does it matter that there's nobody else involved? Like many similar passion projects, HIBP consumed a lot of hours from early on, everything from obviously building the service then sourcing data breaches, verifying and disclosing them, writing up descriptions and even editing every single one of those 700+ logos by hand to be just the right dimensions and file size. But in the beginning, if I'd just stopped one day, what would happen? Nothing. But today, a genuinely important part of the internet that a huge number of individuals, corporations and governments have built dependencies on would stop working if I lost interest.
The dependency on just me was partly behind the possible sale in 2019, but clearly that didn't eventuate. There was always the option to employ people and build it out like most people would a normal company, but every time I gave that consideration it just didn't stack up for a whole bunch of reasons. It was certainly feasible from the perspective of building some sort of valuable commercial entity, but in just the same way as that question about my perfect day in the office sucked the soul from my body, so did the prospect of being responsible for other people. Employment contracts. Salary negotiations. Performance reviews. Sick leave and annual leave and all sorts of other people issues from strangers I'd need to entrust with "my baby". So, bringing in more people was a really unattractive idea, with 2 exceptions:
In early 2021, my (soon to be at the time) wife Charlotte started working for HIBP.
Charlotte had spent the last 8 years working with people just like me; software nerds. As a project manager for the NDC conferences based out of Norway, she'd dealt with hundreds of speakers (including me on many occasions), and thousands of attendees at the best conference I've ever been a part of. Plus, she spent a great deal of time coordinating sponsors, corporate attendees and all sorts of other folks that live in the tech world HIBP inhabited. For Charlotte, even though she's not a technical person (her qualifications are in PR and entrepreneurial studies), this was very familiar territory.
So, for the last few years, Charlotte has done absolutely everything that she can to ensure that I can focus on the things that need my attention. She onboards new corporate subscribers, handles masses of tickets for API and domain subscribers and does all the accounting and tax work. And she does this tirelessly every single day at all sorts of hours whether we're at home or travelling. She is... amazing 🤩
Earlier this year, Stefán Jökull Sigurðarson started working for us part time writing code, cleaning up code, migrating code and, well, doing lots of different code things.
Just today I asked Stefán what I should write about him, thinking he'd give me some bullet points I'd massage and then incorporate into this blog post. Instead, I reckon what he wrote was so spot on that I'm just going to quote the entire thing here:
"Just" that having had my eye on the service since it was released and then developing one of the first big integrations with the PwnedPasswords v2 API in EVE, coinciding with us meeting for the first time at NDC Oslo in 2018 shortly after, HIBP has managed to take me on this awesome journey where it has been a part of launching my public speaking career, contributing to OSS with Pwned Passwords, becoming an MVP and helped me meet a bunch of awesome people and allowed me to contribute to a better and hopefully safer internet. I'm very happy and honoured to a be a part of this project which is full of awesome challenges and interesting problems to deal with. Having meeting invites from the FBI in my inbox a few years after doing a few experimental rest calls to the Pwned Passwords API in early 2018 was definitely not something I was expecting 😅
What really resonated with me in Stefán's message is that for him, this isn't just a job, it's a passion. His journey is my journey in that we freely devoted our time to do something we love and it led to many wonderful things, including MVP roles and speaking at "Charlotte's" conference, NDC. Stefán is based in Iceland, but we've still had many opportunities to share beers together and establish a relationship that transcends merely writing code. I can't think of anyone better to do what he does today.
731 breaches later, here we are. So, what stands out? Just going off the top of my head here:
Ashley Madison. Every knows the name so it needs no introduction, but that incident in 2015 had a major impact on HIBP in terms of use of the service, and also a major impact on me in terms of the engagements I had with impacted parties. My blog post on Here’s what Ashley Madison members have told me still feels harrowing to read.
Collection #1. This is the one that really contributed to my stress levels in early 2019 and had a profound impact on my decision to look at selling the service. Read about where those 773M records came from (still the largest breach in HIBP to date).
Rosebutt. Don't make a joke about it, don't make a joke about it, don't... aw man, thanks The Register! (link to an archive.org version as they seem to have thought better of their image choice later on...) The point is that even serious data breaches can have their moments of levity.
Shit Express. Sometimes, you just need a bit of hilarity in your data breach. Shit Express is literally a site to send other people pieces of that - anonymously - and they got breached, thus somewhat affecting their anonymity. The more serious point is that as I later wrote, claims of anonymity are often highly misleading.
I often joke about my life being very much about getting up each morning, reading my emails and events from overnight and then just winging it from there. Of course there are the occasional scheduled things not to mention travel commitments, but for the most part it's very much just rolling with whatever is demanding attention on the day. This is also probably a significant part of why I don't really want to see this thing grow into a larger concern with more responsibilities, I just don't want to lose that freedom. Yet...
We're gradually moving in a direction where things become more formalised. 3 years ago, I did 100% of everything myself. 1 year ago, I did everything technical myself. 6 months ago, we had no ticketing system for support. But these are small, incremental steps forward and that's what I'd like to see continuing. I want HIBP to outlive me, I just don't want it to become a burden I'm beholden to in the process. I'd like to have more people involved but as you can see from above, that's been a very slow process with only those very close to me playing a role.
The only thing I have real certainty on at the moment is that there will be more breaches. I've commented many times recently that the scourge that is ransomware feels like it's really accelerated lately, I wonder how many of the people in the emails and documents and all sorts of other data that get dumped there ever learn of their exposure? It's a non-trivial exercise to index that (for all sorts of reasons), but it also seems like an increasingly worthy exercise. Who knows, let's see how I feel when I get up tomorrow morning 🙂
Finally, for this week's regular video, I'm going to make a birthday special and do it live with Charlotte. Please come and join us, I'm not entirely sure what we'll cover (I'll work it out on the morning!) but let's make a virtual 10th birthday party out of it 🎂
Allegedly, Acuity had a data breach. That's the context that accompanied a massive trove of data that was sent to me 2 years ago now. I looked into it, tried to attribute and verify it then put it in the "too hard basket" and moved onto more pressing issues. It was only this week as I desperately tried to make some space to process yet more data that I realised why I was short on space in the first place:
Ah, yeah - Acuity - that big blue 437GB blob. What follows is the process I went through trying to work out what an earth this thing is, the confusion surrounding the data, the shady characters dealing with it and ultimately, how it's now searchable in Have I Been Pwned (HIBP), which may be what brought you to this blog post in the first place.
One of the first things I do after receiving a data breach is to literally just Google it: acuity data breach. Which immediately yielded this top result from June:
Ah, so Acuity is a healthcare company. But wait - here's the next result:
That's not about healthcare, that's Acuity Brands. How many companies called "Acuity" that have been breached are there?! Let's see what references I have in my email:
Another one 🤦♂️ That "breach" could be circumstantial, so we'll call it a "maybe", but it's yet another Acuity with a question mark next to it. So how many "Acuity" companies are out there in total?! Just in the course of investigating this data, I came across a total of 6 of them that as far as I can tell, are completely unrelated:
Ugh, great. We'll work through them and try to figure out where they fit into the picture in a moment, but first let's look at the actual data. We already know it's 437GB, but it's the breadth of column headings that's most stunning; here's all 414 of them:
Just by eyeballing these, it really doesn't feel like the sort of data that comes from a healthcare provider, a brands company or a scheduler. The other 3, however... Maybe.
Some more data points before going further:
On that final point, here's an example of what I'm talking about:
The last names are the same, as are the salutations. The physical addresses are spot on accurate in their structure as are the phone numbers; there are no spaces, no dashes and no other artifacts typical of millions of different humans entering data. This is clean - too clean.
The "datasource" field is another interesting data point with the top 10 values being:
Each of these entries appeared at least hundreds of thousands of times, if not millions. Does that mean that Netflix, for example, provided customer data to this list? Almost certainly no, but it does feel reminiscent of the Acxiom / Live Ramp misattribution post I wrote a year ago where I listed full counts of a similar column. One of the top values there was also "TAGGED.COM" (also all in uppercase), alongside several other values that also appeared in both sources.
Back to attribution and a post on a popular hacking forum jumps out:
Many things here line up, for example the column names that are very unique to this data source, including "estimatedincomecode", "del_point_check_digit" and "secondaryaddresspresent". The attribution is to the insurance company named "Acuity", but is that accurate? Insurance companies collect a lot of data as it's relevant to how they run their business, but that data is highly unlikely to include fields such as:
That's much more in the "data enrichment" space where a company sells a massive data set so that it can expand the profile data of the purchaser's existing customer base. It's a legitimate, honest, legal business model. It's also indistinguishable from this:
Hey, it's 437GB! And the column names line up! And it's called Acuity! Slightly different column count to mine (and similar but different to the hacker forum post), and slightly different email count, but the similarities remain striking. How I got to this resource is also interesting, having come by someone I was discussing the data with a couple of years ago:
The YouTube video is a walkthrough of a campaign management tool to send emails to customers. Could that indicate the data as coming from Acuity Ads (now Illumin)? No, not in and of itself, the walkthrough there isn't that dissimilar to other campaign tools I've used in the past. No matter how much I looked, I just couldn't find a solid lead back to Acuity Ads and anything even remotely related was merely circumstantial. It could be from them, but it could also be from many other places and the mere fact that a near identical corpus of data was sitting there on an outright spam site only makes the whole mystery that much deeper. There was just one more interesting data point in that email:
i myself am in that dataset and i've been getting 100x more phishing/scam calls, emails, and physical mail
Let me end this with a best guess: this feels like the same situation as the massive Master Deeds incident in South Africa in 2017. In that case, a legally operating data aggregator (I think you know how I feel about those by now...) sold personal information to a real estate business who then left it publicly exposed. I say it feels the same because it's just such a clean set of data and it's clearly very comprehensive in terms of the columns. It's exactly what I'd expect a data aggregator to prepare and sell to other businesses so they could identify which of their existing customers likes needlework.
In the past, publishing blog posts like this has helped identify an origin service and if that happens again here then I'll be sure to provide an update. For now, I've loaded it into HIBP and flagged it as a spam list which means it won't impact the size of anyone's domains and bump them into a different subscription level. If you do have any interesting insights on this data, please leave a comment below and with any luck, one of the Acuity entities out there will emerge as the source.
Note: just after loading the data, I ran the calcs on how many of the addresses were pre-existing in HIBP. This seems like a statistically significant number 😲
So, 100% (just under actually, but it rounded up). Working through a bunch of sample addresses, they appeared across all sorts of other existing spam lists and dodgy data aggregator breaches. Who knows which ones came first, just more data in the big swimming pool of breaches. https://t.co/Ux2rw6uaAk
— Troy Hunt (@troyhunt) November 15, 2023
Edit (1 day later): After posting this, the party responsible for leaking the data turned around and said "that was only a small part of it, here's the whole thing", and released records encompassing a further 14M records. I've added those into HIBP and will shortly be re-sending notifications to people monitoring domains as the count of impacted addresses will likely have changed. Everything else about the subsequent dataset is consistent with what you'll read below in terms of structure, patterns and conclusions.
The same threat actor has leaked larger amounts of data from LinkedIn dated 2023. They claim this new data contains 35M lines and is 12 GB uncompressed. They also issue an apology to @troyhunt. #Breach #Clearnet #DarkWeb #DarkWebInformer #Database #Leaks #Leaked #LinkedIn https://t.co/qBFAofvppU pic.twitter.com/Clg5o92b6t
— Dark Web Informer (@DarkWebInformer) November 7, 2023
I like to think of investigating data breaches as a sort of scientific search for truth. You start out with a theory (a set of data coming from an alleged source), but you don't have a vested interested in whether the claim is true or not, rather you follow the evidence and see where it leads. Verification that supports the alleged source is usually quite straightforward, but disproving a claim can be a rather time consuming exercise, especially when a dataset contains fragments of truth mixed in with data that is anything but. Which is what we have here today.
To lead with the conclusion and save you reading all the details if you're not inclined, the dataset so many people flagged me this week titled "Linkedin Database 2023 2.5 Millions" turned out to be a combination of publicly available LinkedIn profile data and 5.8M email addresses mostly fabricated from a combination of first and last name. It all began with this tweet:
A threat actor has allegedly leaked a database from LinkedIn @LinkedIn dated 2023. They claim the database shows emails, profile data, phones, full names, and more confidential info. #Breach #Clearnet #DarkWeb #DarkWebInformer #Database #Leaks #Leaked #LinkedIn pic.twitter.com/8MQecKc1vz
— Dark Web Informer (@DarkWebInformer) November 4, 2023
All good lies are believable at face value; is it feasible a massive corpus of LinkedIn data is floating around? Well, they were proper breached in 2012 to the tune of 164M records (by which I mean that incident was genuinely internal data such as email addresses and passwords extracted out by a vulnerability), then they were massively scraped in 2021 with another 126M records going into Have I Been Pwned (HIBP). So, when you see a claim like the one above, it seems highly feasible at face value which is what many people take it at. But I'm a bit more suspicious than most people 🙂
First, the claim:
This one is similar to my twitter data scrapped [sic] but for linkedin plus 2023
Now, there's a whole debate about whether scraped data is breached data and indeed whether the definition of it even matters. With the rising prevalence of scraped data, this topic came up enough that I wrote a dedicated blog post about it a couple of years ago and concluded the following in terms of how we should define the term "breach":
A data breach occurs when information is obtained by an unauthorised party in a fashion in which it was not intended to be made available
Which makes scrapes like this alleged one a breach. If indeed it was accurate, LinkedIn data had been taken and redistributed in a way it was never intended to be by either the service itself or the individuals whose data was in this corpus. So, it's something to take seriously, and that warranted further investigation.
I scrolled through the 10M+ rows of data (many records spanned multiple rows due to line returns), and my eyes fell on a fellow Aussie who for the purposes of this exercise we'll call "EM", being the initials of her first and last name. Whilst the data I'm going to refer to is either public by design or fabricated, I don't want to use a real person as an example without their consent so let's just play it safe. Here's a fragment of EM's record:
There are 5 noteworthy parts of this I that immediately caught my attention:
On its own, this record would be unremarkable. It'd be entirely feasible - this could very well be legit - except when you keep looking through the remainder of the data. A pattern quickly emerged and I'm going to bold it here because it's the smoking gun that ultimately indicates that a bunch of this data is fake:
Every single record with multiple email addresses had exactly the same alias on completely unrelated domains and it was almost always in the form of "[first name].[last name]@".
Representing email addresses in this fashion is certainly common, but it's far from ubiquitous, and that's easy to demonstrate. For example, I have tons of emails from Pluralsight so I dig one out from my friend "CU":
There's no dot, rather a dash. Every single real Pluralsight email address I looked at was a dash rather than a dot, yet when I delved into the alleged LinkedIn data and dig out another sample Pluralsight address, here's what I found:
That's not LM's real address because it has a dot instead of a dash. Every. Single. One. Is. Fake.
Let's try this the other way around and load up the existing breached accounts in HIBP for the domain of one of EM's alleged email addresses and see how they're formed:
That's definitely not the same format as EM's address, not by a long shot. And time and time again, the same pattern of addresses in the corpus of data in the original tweet emerged, drawing me to what seems to be a pretty logical conclusion:
Each email address was fabricated by taking the actual domain of a company the individual legitimately worked at and then constructing the alias from their name.
And these are legitimate companies too because every single LinkedIn profile I checked had all the cues of accurate information and each domain I checked in the corpus of data was indeed the correct one for the company they worked at. I imagine someone has effectively worked through the following logic:
On that final point, what is the point? The data wasn't being sold in that original tweet, rather it was freely downloadable. But per the date on EM's profile, the data could have been obtained much earlier and previously monetised. And on that, the date wasn't constant across records, rather there was a broad range of them as recent as July last year and as old as... well, I stopped when the records got older than me. What is this?!
I suspect the answer may partly lie in the column headings which I've pasted here in their entirety:
"PROFILE_KEY", "PROFILE_USERNAMES", "PROFILE_SPENDESK_IDS", "PROFILE_LINKEDIN_PUBLIC_IDENTIFIER", "PROFILE_LINKEDIN_ID", "PROFILE_SALES_NAVIGATOR_ID", "PROFILE_LINKEDIN_MEMBER_ID", "PROFILE_SALESFORCE_IDS", "PROFILE_AUTOPILOT_IDS", "PROFILE_PIPL_IDS", "PROFILE_HUBSPOT_IDS", "PROFILE_HAS_LINKEDIN_SOURCE", "PROFILE_HAS_SALES_NAVIGATOR_SOURCE", "PROFILE_HAS_SALESFORCE_SOURCE", "PROFILE_HAS_SPENDESK_SOURCE", "PROFILE_HAS_ASGARD_SOURCE", "PROFILE_HAS_AUTOPILOT_SOURCE", "PROFILE_HAS_PIPL_SOURCE", "PROFILE_HAS_HUBSPOT_SOURCE", "PROFILE_FETCHED_AT", "PROFILE_LINKEDIN_FETCHED_AT", "PROFILE_SALES_NAVIGATOR_FETCHED_AT", "PROFILE_SALESFORCE_FETCHED_AT", "PROFILE_SPENDESK_FETCHED_AT", "PROFILE_ASGARD_FETCHED_AT", "PROFILE_AUTOPILOT_FETCHED_AT", "PROFILE_PIPL_FETCHED_AT", "PROFILE_HUBSPOT_FETCHED_AT", "PROFILE_LINKEDIN_IS_NOT_FOUND", "PROFILE_SALES_NAVIGATOR_IS_NOT_FOUND", "PROFILE_EMAILS", "PROFILE_PERSONAL_EMAILS", "PROFILE_PHONES", "PROFILE_FIRST_NAME", "PROFILE_LAST_NAME", "PROFILE_TEAM", "PROFILE_HIERARCHY", "PROFILE_PERSONA", "PROFILE_GENDER", "PROFILE_COUNTRY_CODE", "PROFILE_SUMMARY", "PROFILE_INDUSTRY_NAME", "PROFILE_BIRTH_YEAR", "PROFILE_MARVIN_SEARCHES", "PROFILE_POSITION_STARTED_AT", "PROFILE_POSITION_TITLE", "PROFILE_POSITION_LOCATION", "PROFILE_POSITION_DESCRIPTION", "PROFILE_COMPANY_NAME", "PROFILE_COMPANY_LINKEDIN_ID", "PROFILE_COMPANY_LINKEDIN_UNIVERSAL_NAME", "PROFILE_COMPANY_SALESFORCE_ID", "PROFILE_COMPANY_SPENDESK_ID", "PROFILE_COMPANY_HUBSPOT_ID", "PROFILE_SKILLS", "PROFILE_LANGUAGES", "PROFILE_SCHOOLS", "PROFILE_EXTERNAL_SEARCHES", "PROFILE_LINKEDIN_HEADLINE", "PROFILE_LINKEDIN_LOCATION", "PROFILE_SALESFORCE_CREATED_AT", "PROFILE_SALESFORCE_STATUS", "PROFILE_SALESFORCE_LAST_ACTIVITY_AT", "PROFILE_SALESFORCE_OWNER_CONTACT_ID", "PROFILE_SALESFORCE_OWNER_CONTACT_NAME", "PROFILE_SPENDESK_SIGNUP_AT", "PROFILE_SPENDESK_DELETED_AT", "PROFILE_SPENDESK_ROLES", "PROFILE_SPENDESK_AVERAGE_NPS_SCORE", "PROFILE_SPENDESK_NPS_SCORES_COUNT", "PROFILE_SPENDESK_FIRST_NPS_SCORE", "PROFILE_SPENDESK_LAST_NPS_SCORE", "PROFILE_SPENDESK_LAST_NPS_SCORE_SENT_AT", "PROFILE_SPENDESK_PAYMENTS_COUNT", "PROFILE_SPENDESK_TOTAL_EUR_SPENT", "PROFILE_SPENDESK_ACTIVE_SUBSCRIPTIONS_COUNT", "PROFILE_SPENDESK_LAST_ACTIVITY_AT", "PROFILE_AUTOPILOT_MAIL_CLICKED_COUNT", "PROFILE_AUTOPILOT_LAST_MAIL_CLICKED_AT", "PROFILE_AUTOPILOT_MAIL_OPENED_COUNT", "PROFILE_AUTOPILOT_LAST_MAIL_OPENED_AT", "PROFILE_AUTOPILOT_MAIL_RECEIVED_COUNT", "PROFILE_AUTOPILOT_LAST_MAIL_RECEIVED_AT", "PROFILE_AUTOPILOT_MAIL_UNSUBSCRIBED_AT", "PROFILE_AUTOPILOT_MAIL_REPLIED_AT", "PROFILE_AUTOPILOT_LISTS", "PROFILE_AUTOPILOT_SEGMENTS", "PROFILE_HUBSPOT_CFO_CONNECT_SLACK_MEMBER_STATUS", "PROFILE_HUBSPOT_IS_CFO_CONNECT_MEETUPS_MEMBER", "PROFILE_HUBSPOT_CFO_CONNECT_AREAS_OF_EXPERTISE", "PROFILE_HUBSPOT_CORPORATE_FINANCE_EXPERIENCE_YEARS_RANGE"
Check out some of those names: LinkedIn is obviously there, but so is Salesforce and Spendesk and Hubspot, among others. This reads more like an aggregation of multiple sources than it does data solely scraped from LinkedIn. My hope is that in posting this someone might pop up and say "I recognise those column headings, they're from..." Who knows.
So, here's where that leaves us: this data is a combination of information sourced from public LinkedIn profiles, fabricated emails address and in part (anecdotally based on simply eyeballing the data this is a small part), the other sources in the column headings above. But the people are real, the companies are real, the domains are real and in many cases, the email addresses themselves are real. There are over 1.8k HIBP subscribers in the data set and this is folks that have double opted-in so they've successfully received an email to that address in the past. Further, when the data was loaded into HIBP there were nearly a million email addresses that were already in the system so evidently, they were addresses that had previously been in use. Which stands to reason because even if every address was constructed by an algorithm, the pattern is common enough that there'll be a bunch of hits.
Because the conclusion is that there's a significant component of legitimate data in this corpus, I've loaded it into HIBP. But because there are also a significant number of fabricated email addresses in there, I've flagged it as a spam list which means the addresses won't impact the scale of anyone's paid subscription if they're monitoring domains. And whilst I know some people will suggest it shouldn't go in at all, time and time again when I've polled the public about similar incidents the overwhelming majority of people have said "we want to know about it then we'll make up our own minds what action needs to be taken". And in this case, even if you find an email address on your domain that doesn't actually exist, that person who either currently works at your company or previously did has still had their personal data dumped in this corpus. That's something most people will still want to know.
Lastly, one of the main reasons I decided to invest hours into this today is that I loathe disinformation and I hate people using that to then make statements that are completely off base. I'm looking at my Twitter feed now and see people angry at LinkedIn for this, blaming an insider due to recent layoffs there, accusing them of mishandling our data and so on and so forth. No, not this time, the evidence has led us somewhere completely different.
The victim shaming site operated by the Snatch ransomware group is leaking data about its true online location and internal operations, as well as the Internet addresses of its visitors, KrebsOnSecurity has found. The leaked data suggest that Snatch is one of several ransomware groups using paid ads on Google.com to trick people into installing malware disguised as popular free software, such as Microsoft Teams, Adobe Reader, Mozilla Thunderbird, and Discord.
First spotted in 2018, the Snatch ransomware group has published data stolen from hundreds of organizations that refused to pay a ransom demand. Snatch publishes its stolen data at a website on the open Internet, and that content is mirrored on the Snatch team’s darknet site, which is only reachable using the global anonymity network Tor.
The victim shaming website for the Snatch ransomware gang.
KrebsOnSecurity has learned that Snatch’s darknet site exposes its “server status” page, which includes information about the true Internet addresses of users accessing the website.
Refreshing this page every few seconds shows that the Snatch darknet site generates a decent amount of traffic, often attracting thousands of visitors each day. But by far the most frequent repeat visitors are coming from Internet addresses in Russia that either currently host Snatch’s clear web domain names or recently did.
The Snatch ransomware gang’s victim shaming site on the darknet is leaking data about its visitors. This “server status” page says that Snatch’s website is on Central European Summer Time (CEST) and is powered by OpenSSL/1.1.1f, which is no longer supported by security updates.
Probably the most active Internet address accessing Snatch’s darknet site is 193.108.114[.]41, which is a server in Yekaterinburg, Russia that hosts several Snatch domains, including snatchteam[.]top, sntech2ch[.]top, dwhyj2[.]top and sn76930193ch[.]top. It could well be that this Internet address is showing up frequently because Snatch’s clear-web site features a toggle button at the top that lets visitors switch over to accessing the site via Tor.
Another Internet address that showed up frequently in the Snatch server status page was 194.168.175[.]226, currently assigned to Matrix Telekom in Russia. According to DomainTools.com, this address also hosts or else recently hosted the usual coterie of Snatch domains, as well as quite a few domains phishing known brands such as Amazon and Cashapp.
The Moscow Internet address 80.66.64[.]15 accessed the Snatch darknet site all day long, and that address also housed the appropriate Snatch clear-web domains. More interestingly, that address is home to multiple recent domains that appear confusingly similar to known software companies, including libreoff1ce[.]com and www-discord[.]com.
This is interesting because the phishing domains associated with the Snatch ransomware gang were all registered to the same Russian name — Mihail Kolesnikov, a name that is somewhat synonymous with recent phishing domains tied to malicious Google ads.
Kolesnikov could be a nod to a Russian general made famous during Boris Yeltsin’s reign. Either way, it’s clearly a pseudonym, but there are some other commonalities among these domains that may provide insight into how Snatch and other ransomware groups are sourcing their victims.
DomainTools says there are more than 1,300 current and former domain names registered to Mihail Kolesnikov between 2013 and July 2023. About half of the domains appear to be older websites advertising female escort services in major cities around the United States (e.g. the now-defunct pittsburghcitygirls[.]com).
The other half of the Kolesnikov websites are far more recent phishing domains mostly ending in “.top” and “.app” that appear designed to mimic the domains of major software companies, including www-citrix[.]top, www-microsofteams[.]top, www-fortinet[.]top, ibreoffice[.]top, www-docker[.]top, www-basecamp[.]top, ccleaner-cdn[.]top, adobeusa[.]top, and www.real-vnc[.]top.
In August 2023, researchers with Trustwave Spiderlabs said they encountered domains registered to Mihail Kolesnikov being used to disseminate the Rilide information stealer trojan.
But it appears multiple crime groups may be using these domains to phish people and disseminate all kinds of information-stealing malware. In February 2023, Spamhaus warned of a huge surge in malicious ads that were hijacking search results in Google.com, and being used to distribute at least five different families of information stealing trojans, including AuroraStealer, IcedID/Bokbot, Meta Stealer, RedLine Stealer and Vidar.
For example, Spamhaus said victims of these malicious ads would search for Microsoft Teams in Google.com, and the search engine would often return a paid ad spoofing Microsoft or Microsoft Teams as the first result — above all other results. The malicious ad would include a logo for Microsoft and at first glance appear to be a safe and trusted place to download the Microsoft Teams client.
However, anyone who clicked on the result was whisked away instead to mlcrosofteams-us[.]top — yet another malicious domain registered to Mr. Kolesnikov. And while visitors to this website may believe they are only downloading the Microsoft Teams client, the installer file includes a copy of the IcedID malware, which is really good at stealing passwords and authentication tokens from the victim’s web browser.
Image: Spamhaus
The founder of the Swiss anti-abuse website abuse.ch told Spamhaus it is likely that some cybercriminals have started to sell “malvertising as a service” on the dark web, and that there is a great deal of demand for this service.
In other words, someone appears to have built a very profitable business churning out and promoting new software-themed phishing domains and selling that as a service to other cybercriminals. Or perhaps they are simply selling any stolen data (and any corporate access) to active and hungry ransomware group affiliates.
The tip about the exposed “server status” page on the Snatch darkweb site came from @htmalgae, the same security researcher who alerted KrebsOnSecurity earlier this month that the darknet victim shaming site run by the 8Base ransomware gang was inadvertently left in development mode.
That oversight revealed not only the true Internet address of the hidden 8Base site (in Russia, naturally), but also the identity of a programmer in Moldova who apparently helped to develop the 8Base code.
@htmalgae said the idea of a ransomware group’s victim shaming site leaking data that they did not intend to expose is deliciously ironic.
“This is a criminal group that shames others for not protecting user data,” @htmalgae said. “And here they are leaking their user data.”
All of the malware mentioned in this story is designed to run on Microsoft Windows devices. But Malwarebytes recently covered the emergence of a Mac-based information stealer trojan called AtomicStealer that was being advertised through malicious Google ads and domains that were confusingly similar to software brands.
Please be extra careful when you are searching online for popular software titles. Cracked, pirated copies of major software titles are a frequent source of infostealer infections, as are these rogue ads masquerading as search results. Make sure to double-check you are actually at the domain you believe you’re visiting *before* you download and install anything.
Stay tuned for Part II of this post, which includes a closer look at the Snatch ransomware group and their founder.
Further reading:
@HTMalgae’s list of the top Internet addresses seen accessing Snatch’s darknet site
Ars Technica: Until Further Notice Think Twice Before Using Google to Download Software
Bleeping Computer: Hackers Abuse Google Ads to Spread Malware in Legit Software
The password manager service LastPass is now forcing some of its users to pick longer master passwords. LastPass says the changes are needed to ensure all customers are protected by their latest security improvements. But critics say the move is little more than a public relations stunt that will do nothing to help countless early adopters whose password vaults were exposed in a 2022 breach at LastPass.
LastPass sent this notification to users earlier this week.
LastPass told customers this week they would be forced to update their master password if it was less than 12 characters. LastPass officially instituted this change back in 2018, but some undisclosed number of the company’s earlier customers were never required to increase the length of their master passwords.
This is significant because in November 2022, LastPass disclosed a breach in which hackers stole password vaults containing both encrypted and plaintext data for more than 25 million users.
Since then, a steady trickle of six-figure cryptocurrency heists targeting security-conscious people throughout the tech industry has led some security experts to conclude that crooks likely have succeeded at cracking open some of the stolen LastPass vaults.
KrebsOnSecurity last month interviewed a victim who recently saw more than three million dollars worth of cryptocurrency siphoned from his account. That user signed up with LastPass nearly a decade ago, stored their cryptocurrency seed phrase there, and yet never changed his master password — which was just eight characters. Nor was he ever forced to improve his master password.
That story cited research from Adblock Plus creator Wladimir Palant, who said LastPass failed to upgrade many older, original customers to more secure encryption protections that were offered to newer customers over the years.
For example, another important default setting in LastPass is the number of “iterations,” or how many times your master password is run through the company’s encryption routines. The more iterations, the longer it takes an offline attacker to crack your master password.
Palant said that for many older LastPass users, the initial default setting for iterations was anywhere from “1” to “500.” By 2013, new LastPass customers were given 5,000 iterations by default. In February 2018, LastPass changed the default to 100,100 iterations. And very recently, it upped that again to 600,000. Still, Palant and others impacted by the 2022 breach at LastPass say their account security settings were never forcibly upgraded.
Palant called this latest action by LastPass a PR stunt.
“They sent this message to everyone, whether they have a weak master password or not – this way they can again blame the users for not respecting their policies,” Palant said. “But I just logged in with my weak password, and I am not forced to change it. Sending emails is cheap, but they once again didn’t implement any technical measures to enforce this policy change.”
Either way, Palant said, the changes won’t help people affected by the 2022 breach.
“These people need to change all their passwords, something that LastPass still won’t recommend,” Palant said. “But it will somewhat help with the breaches to come.”
LastPass CEO Karim Toubba said changing master password length (or even the master password itself) is not designed to address already stolen vaults that are offline.
“This is meant to better protect customers’ online vaults and encourage them to bring their accounts up to the 2018 LastPass standard default setting of a 12-character minimum (but could opt out from),” Toubba said in an emailed statement. “We know that some customers may have chosen convenience over security and utilized less complex master passwords despite encouragement to use our (or others) password generator to do otherwise.”
A basic functionality of LastPass is that it will pick and remember lengthy, complex passwords for each of your websites or online services. To automatically populate the appropriate credentials at any website going forward, you simply authenticate to LastPass using your master password.
LastPass has always emphasized that if you lose this master password, that’s too bad because they don’t store it and their encryption is so strong that even they can’t help you recover it.
But experts say all bets are off when cybercrooks can get their hands on the encrypted vault data itself — as opposed to having to interact with LastPass via its website. These so-called “offline” attacks allow the bad guys to conduct unlimited and unfettered “brute force” password cracking attempts against the encrypted data using powerful computers that can each try millions of password guesses per second.
A chart on Palant’s blog post offers an idea of how increasing password iterations dramatically increases the costs and time needed by the attackers to crack someone’s master password. Palant said it would take a single high-powered graphics card about a year to crack a password of average complexity with 500 iterations, and about 10 years to crack the same password run through 5,000 iterations.
Image: palant.info
However, these numbers radically come down when a determined adversary also has other large-scale computational assets at their disposal, such as a bitcoin mining operation that can coordinate the password-cracking activity across multiple powerful systems simultaneously.
Meaning, LastPass users whose vaults were never upgraded to higher iterations and whose master passwords were weak (less than 12 characters) likely have been a primary target of distributed password-cracking attacks ever since the LastPass user vaults were stolen late last year.
Asked why some LastPass users were left behind on older security minimums, Toubba said a “small percentage” of customers had corrupted items in their password vaults that prevented those accounts from properly upgrading to the new requirements and settings.
“We have been able to determine that a small percentage of customers have items in their vaults that are corrupt and when we previously utilized automated scripts designed to re-encrypt vaults when the master password or iteration count is changed, they did not complete,” Toubba said. “These errors were not originally apparent as part of these efforts and, as we have discovered them, we have been working to be able to remedy this and finish the re-encryption.”
Nicholas Weaver, a researcher at University of California, Berkeley’s International Computer Science Institute (ICSI) and lecturer at UC Davis, said LastPass made a huge mistake years ago by not force-upgrading the iteration count for existing users.
“And now this is blaming the users — ‘you should have used a longer passphrase’ — not them for having weak defaults that were never upgraded for existing users,” Weaver said. “LastPass in my book is one step above snake-oil. I used to be, ‘Pick whichever password manager you want,’ but now I am very much, ‘Pick any password manager but LastPass.'”
Asked why LastPass isn’t recommending that users change all of the passwords secured by the encrypted master password that was stolen when the company got hacked last year, Toubba said it’s because “the data demonstrates that the majority of our customers follow our recommendations (or greater), and the probability of successfully brute forcing vault encryption is greatly reduced accordingly.”
“We’ve been telling customers since December of 2022 that they should be following recommended guidelines,” Toubba continued. “And if they haven’t followed the guidelines we recommended that they change their downstream passwords.”
In November 2022, the password manager service LastPass disclosed a breach in which hackers stole password vaults containing both encrypted and plaintext data for more than 25 million users. Since then, a steady trickle of six-figure cryptocurrency heists targeting security-conscious people throughout the tech industry has led some security experts to conclude that crooks likely have succeeded at cracking open some of the stolen LastPass vaults.
Taylor Monahan is lead product manager of MetaMask, a popular software cryptocurrency wallet used to interact with the Ethereum blockchain. Since late December 2022, Monahan and other researchers have identified a highly reliable set of clues that they say connect recent thefts targeting more than 150 people. Collectively, these individuals have been robbed of more than $35 million worth of crypto.
Monahan said virtually all of the victims she has assisted were longtime cryptocurrency investors, and security-minded individuals. Importantly, none appeared to have suffered the sorts of attacks that typically preface a high-dollar crypto heist, such as the compromise of one’s email and/or mobile phone accounts.
“The victim profile remains the most striking thing,” Monahan wrote. “They truly all are reasonably secure. They are also deeply integrated into this ecosystem, [including] employees of reputable crypto orgs, VCs [venture capitalists], people who built DeFi protocols, deploy contracts, run full nodes.”
Monahan has been documenting the crypto thefts via Twitter/X since March 2023, frequently expressing frustration in the search for a common cause among the victims. Then on Aug. 28, Monahan said she’d concluded that the common thread among nearly every victim was that they’d previously used LastPass to store their “seed phrase,” the private key needed to unlock access to their cryptocurrency investments.
MetaMask owner Taylor Monahan on Twitter. Image: twitter.com/tayvano_
Armed with your secret seed phrase, anyone can instantly access all of the cryptocurrency holdings tied to that cryptographic key, and move the funds to anywhere they like.
Which is why the best practice for many cybersecurity enthusiasts has long been to store their seed phrases either in some type of encrypted container — such as a password manager — or else inside an offline, special-purpose hardware encryption device, such as a Trezor or Ledger wallet.
“The seed phrase is literally the money,” said Nick Bax, director of analytics at Unciphered, a cryptocurrency wallet recovery company. “If you have my seed phrase, you can copy and paste that into your wallet, and then you can see all my accounts. And you can transfer my funds.”
Bax said he closely reviewed the massive trove of cryptocurrency theft data that Taylor Monahan and others have collected and linked together.
“It’s one of the broadest and most complex cryptocurrency investigations I’ve ever seen,” Bax said. “I ran my own analysis on top of their data and reached the same conclusion that Taylor reported. The threat actor moved stolen funds from multiple victims to the same blockchain addresses, making it possible to strongly link those victims.”
Bax, Monahan and others interviewed for this story say they’ve identified a unique signature that links the theft of more than $35 million in crypto from more than 150 confirmed victims, with roughly two to five high-dollar heists happening each month since December 2022.
KrebsOnSecurity has reviewed this signature but is not publishing it at the request of Monahan and other researchers, who say doing so could cause the attackers to alter their operations in ways that make their criminal activity more difficult to track.
But the researchers have published findings about the dramatic similarities in the ways that victim funds were stolen and laundered through specific cryptocurrency exchanges. They also learned the attackers frequently grouped together victims by sending their cryptocurrencies to the same destination crypto wallet.
A graphic published by @tayvano_ on Twitter depicting the movement of stolen cryptocurrencies from victims who used LastPass to store their crypto seed phrases.
By identifying points of overlap in these destination addresses, the researchers were then able to track down and interview new victims. For example, the researchers said their methodology identified a recent multi-million dollar crypto heist victim as an employee at Chainalysis, a blockchain analysis firm that works closely with law enforcement agencies to help track down cybercriminals and money launderers.
Chainalysis confirmed that the employee had suffered a high-dollar cryptocurrency heist late last month, but otherwise declined to comment for this story.
Bax said the only obvious commonality between the victims who agreed to be interviewed was that they had stored the seed phrases for their cryptocurrency wallets in LastPass.
“On top of the overlapping indicators of compromise, there are more circumstantial behavioral patterns and tradecraft which are also consistent between different thefts and support the conclusion,” Bax told KrebsOnSecuirty. “I’m confident enough that this is a real problem that I’ve been urging my friends and family who use LastPass to change all of their passwords and migrate any crypto that may have been exposed, despite knowing full well how tedious that is.”
LastPass declined to answer questions about the research highlighted in this story, citing an ongoing law enforcement investigation and pending litigation against the company in response to its 2022 data breach.
“Last year’s incident remains the subject of an ongoing investigation by law enforcement and is also the subject of pending litigation,” LastPass said in a written statement provided to KrebsOnSecurity. “Since last year’s attack on LastPass, we have remained in contact with law enforcement and continue to do so.”
Their statement continues:
“We have shared various technical information, Indicators of Compromise (IOCs), and threat actor tactics, techniques, and procedures (TTPs) with our law enforcement contacts as well as our internal and external threat intelligence and forensic partners in an effort to try and help identify the parties responsible. In the meantime, we encourage any security researchers to share any useful information they believe they may have with our Threat Intelligence team by contacting securitydisclosure@lastpass.com.”
On August 25, 2022, LastPass CEO Karim Toubba wrote to users that the company had detected unusual activity in its software development environment, and that the intruders stole some source code and proprietary LastPass technical information. On Sept. 15, 2022, LastPass said an investigation into the August breach determined the attacker did not access any customer data or password vaults.
But on Nov. 30, 2022, LastPass notified customers about another, far more serious security incident that the company said leveraged data stolen in the August breach. LastPass disclosed that criminal hackers had compromised encrypted copies of some password vaults, as well as other personal information.
In February 2023, LastPass disclosed that the intrusion involved a highly complex, targeted attack against a DevOps engineer who was one of only four LastPass employees with access to the corporate vault.
“This was accomplished by targeting the DevOps engineer’s home computer and exploiting a vulnerable third-party media software package, which enabled remote code execution capability and allowed the threat actor to implant keylogger malware,” LastPass officials wrote. “The threat actor was able to capture the employee’s master password as it was entered, after the employee authenticated with MFA, and gain access to the DevOps engineer’s LastPass corporate vault.”
Dan Goodin at Ars Technica reported and then confirmed that the attackers exploited a known vulnerability in a Plex media server that the employee was running on his home network, and succeeded in installing malicious software that stole passwords and other authentication credentials. The vulnerability exploited by the intruders was patched back in 2020, but the employee never updated his Plex software.
As it happens, Plex announced its own data breach one day before LastPass disclosed its initial August intrusion. On August 24, 2022, Plex’s security team urged users to reset their passwords, saying an intruder had accessed customer emails, usernames and encrypted passwords.
A basic functionality of LastPass is that it will pick and remember lengthy, complex passwords for each of your websites or online services. To automatically populate the appropriate credentials at any website going forward, you simply authenticate to LastPass using your master password.
LastPass has always emphasized that if you lose this master password, that’s too bad because they don’t store it and their encryption is so strong that even they can’t help you recover it.
But experts say all bets are off when cybercrooks can get their hands on the encrypted vault data itself — as opposed to having to interact with LastPass via its website. These so-called “offline” attacks allow the bad guys to conduct unlimited and unfettered “brute force” password cracking attempts against the encrypted data using powerful computers that can each try millions of password guesses per second.
“It does leave things vulnerable to brute force when the vaults are stolen en masse, especially if info about the vault HOLDER is available,” said Nicholas Weaver, a researcher at University of California, Berkeley’s International Computer Science Institute (ICSI) and lecturer at UC Davis. “So you just crunch and crunch and crunch with GPUs, with a priority list of vaults you target.”
How hard would it be for well-resourced criminals to crack the master passwords securing LastPass user vaults? Perhaps the best answer to this question comes from Wladimir Palant, a security researcher and the original developer behind the Adblock Plus browser plugin.
In a December 2022 blog post, Palant explained that the crackability of a LastPass master password depends largely on two things: The complexity of the master password, and the default settings for LastPass users, which appear to have varied quite a bit based on when those users began patronizing the service.
LastPass says that since 2018 it has required a twelve-character minimum for master passwords, which the company said “greatly minimizes the ability for successful brute force password guessing.”
But Palant said while LastPass indeed improved its master password defaults in 2018, it did not force all existing customers who had master passwords of lesser lengths to pick new credentials that would satisfy the 12-character minimum.
“If you are a LastPass customer, chances are that you are completely unaware of this requirement,” Palant wrote. “That’s because LastPass didn’t ask existing customers to change their master password. I had my test account since 2018, and even today I can log in with my eight-character password without any warnings or prompts to change it.”
Palant believes LastPass also failed to upgrade many older, original customers to more secure encryption protections that were offered to newer customers over the years. One important setting in LastPass is the number of “iterations,” or how many times your master password is run through the company’s encryption routines. The more iterations, the longer it takes an offline attacker to crack your master password.
Palant noted last year that for many older LastPass users, the initial default setting for iterations was anywhere from “1” to “500.” By 2013, new LastPass customers were given 5,000 iterations by default. In February 2018, LastPass changed the default to 100,100 iterations. And very recently, it upped that again to 600,000.
Palant said the 2018 change was in response to a security bug report he filed about some users having dangerously low iterations in their LastPass settings.
“Worse yet, for reasons that are beyond me, LastPass didn’t complete this migration,” Palant wrote. “My test account is still at 5,000 iterations, as are the accounts of many other users who checked their LastPass settings. LastPass would know how many users are affected, but they aren’t telling that. In fact, it’s painfully obvious that LastPass never bothered updating users’ security settings. Not when they changed the default from 1 to 500 iterations. Not when they changed it from 500 to 5,000. Only my persistence made them consider it for their latest change. And they still failed implementing it consistently.”
A chart on Palant’s blog post offers an idea of how increasing password iterations dramatically increases the costs and time needed by the attackers to crack someone’s master password. Palant said it would take a single GPU about a year to crack a password of average complexity with 500 iterations, and about 10 years to crack the same password run through 5,000 iterations.
Image: palant.info
However, these numbers radically come down when a determined adversary also has other large-scale computational assets at their disposal, such as a bitcoin mining operation that can coordinate the password-cracking activity across multiple powerful systems simultaneously.
Weaver said a password or passphrase with average complexity — such as “Correct Horse Battery Staple” is only secure against online attacks, and that its roughly 40 bits of randomness or “entropy” means a graphics card can blow through it in no time.
“An Nvidia 3090 can do roughly 4 million [password guesses] per second with 1000 iterations, but that would go down to 8 thousand per second with 500,000 iterations, which is why iteration count matters so much,” Weaver said. “So a combination of ‘not THAT strong of a password’ and ‘old vault’ and ‘low iteration count’ would make it theoretically crackable but real work, but the work is worth it given the targets.”
Reached by KrebsOnSecurity, Palant said he never received a response from LastPass about why the company apparently failed to migrate some number of customers to more secure account settings.
“I know exactly as much as everyone else,” Palant wrote in reply. “LastPass published some additional information in March. This finally answered the questions about the timeline of their breach – meaning which users are affected. It also made obvious that business customers are very much at risk here, Federated Login Services being highly compromised in this breach (LastPass downplaying as usual of course).”
Palant said upon logging into his LastPass account a few days ago, he found his master password was still set at 5,000 iterations.
KrebsOnSecurity interviewed one of the victims tracked down by Monahan, a software engineer and startup founder who recently was robbed of approximately $3.4 million worth of different cryptocurrencies. The victim agreed to tell his story in exchange for anonymity because he is still trying to claw back his losses. We’ll refer to him here as “Connor” (not his real name).
Connor said he began using LastPass roughly a decade ago, and that he also stored the seed phrase for his primary cryptocurrency wallet inside of LastPass. Connor chose to protect his LastPass password vault with an eight character master password that included numbers and symbols (~50 bits of entropy).
“I thought at the time that the bigger risk was losing a piece of paper with my seed phrase on it,” Connor said. “I had it in a bank security deposit box before that, but then I started thinking, ‘Hey, the bank might close or burn down and I could lose my seed phrase.'”
Those seed phrases sat in his LastPass vault for years. Then, early on the morning of Sunday, Aug. 27, 2023, Connor was awoken by a service he’d set up to monitor his cryptocurrency addresses for any unusual activity: Someone was draining funds from his accounts, and fast.
Like other victims interviewed for this story, Connor didn’t suffer the usual indignities that typically presage a cryptocurrency robbery, such as account takeovers of his email inbox or mobile phone number.
Connor said he doesn’t know the number of iterations his master password was given originally, or what it was set at when the LastPass user vault data was stolen last year. But he said he recently logged into his LastPass account and the system forced him to upgrade to the new 600,000 iterations setting.
“Because I set up my LastPass account so early, I’m pretty sure I had whatever weak settings or iterations it originally had,” he said.
Connor said he’s kicking himself because he recently started the process of migrating his cryptocurrency to a new wallet protected by a new seed phrase. But he never finished that migration process. And then he got hacked.
“I’d set up a brand new wallet with new keys,” he said. “I had that ready to go two months ago, but have been procrastinating moving things to the new wallet.”
Connor has been exceedingly lucky in regaining access to some of his stolen millions in cryptocurrency. The Internet is swimming with con artists masquerading as legitimate cryptocurrency recovery experts. To make matters worse, because time is so critical in these crypto heists, many victims turn to the first quasi-believable expert who offers help.
Instead, several friends steered Connor to Flashbots.net, a cryptocurrency recovery firm that employs several custom techniques to help clients claw back stolen funds — particularly those on the Ethereum blockchain.
According to Connor, Flashbots helped rescue approximately $1.5 million worth of the $3.4 million in cryptocurrency value that was suddenly swept out of his account roughly a week ago. Lucky for him, Connor had some of his assets tied up in a type of digital loan that allowed him to borrow against his various cryptocurrency assets.
Without giving away too many details about how they clawed back the funds, here’s a high level summary: When the crooks who stole Connor’s seed phrase sought to extract value from these loans, they were borrowing the maximum amount of credit that he hadn’t already used. But Connor said that left open an avenue for some of that value to be recaptured, basically by repaying the loan in many small, rapid chunks.
According to MetaMask’s Monahan, users who stored any important passwords with LastPass — particularly those related to cryptocurrency accounts — should change those credentials immediately, and migrate any crypto holdings to new offline hardware wallets.
“Really the ONLY thing you need to read is this,” Monahan pleaded to her 70,000 followers on Twitter/X: “PLEASE DON’T KEEP ALL YOUR ASSETS IN A SINGLE KEY OR SECRET PHRASE FOR YEARS. THE END. Split up your assets. Get a hw [hardware] wallet. Migrate. Now.”
If you also had passwords tied to banking or retirement accounts, or even just important email accounts — now would be a good time to change those credentials as well.
I’ve never been comfortable recommending password managers, because I’ve never seriously used them myself. Something about putting all your eggs in one basket. Heck, I’m so old-fashioned that most of my important passwords are written down and tucked away in safe places.
But I recognize this antiquated approach to password management is not for everyone. Connor says he now uses 1Password, a competing password manager that recently earned the best overall marks from Wired and The New York Times.
1Password says that three things are needed to decrypt your information: The encrypted data itself, your account password, and your Secret Key. Only you know your account password, and your Secret Key is generated locally during setup.
“The two are combined on-device to encrypt your vault data and are never sent to 1Password,” explains a 1Password blog post ‘What If 1Password Gets Hacked?‘ “Only the encrypted vault data lives on our servers, so neither 1Password nor an attacker who somehow manages to guess or steal your account password would be able to access your vaults – or what’s inside them.
Weaver said that Secret Key adds an extra level of randomness to all user master passwords that LastPass didn’t have.
“With LastPass, the idea is the user’s password vault is encrypted with a cryptographic hash (H) of the user’s passphrase,” Weaver said. “The problem is a hash of the user’s passphrase is remarkably weak on older LastPass vaults with master passwords that do not have many iterations. 1Password uses H(random-key||password) to generate the password, and it is why you have the QR code business when adding a new device.”
Weaver said LastPass deserves blame for not having upgraded iteration counts for all users a long time ago, and called the latest forced upgrades “a stunning indictment of the negligence on the part of LastPass.”
“That they never even notified all those with iteration counts of less than 100,000 — who are really vulnerable to brute force even with 8-character random passwords or ‘correct horse battery staple’ type passphrases — is outright negligence,” Weaver said. “I would personally advocate that nobody ever uses LastPass again: Not because they were hacked. Not because they had an architecture (unlike 1Password) that makes such hacking a problem. But because of their consistent refusal to address how they screwed up and take proactive efforts to protect their customers.”
Bax and Monahan both acknowledged that their research alone can probably never conclusively tie dozens of high-dollar crypto heists over the past year to the LastPass breach. But Bax says at this point he doesn’t see any other possible explanation.
“Some might say it’s dangerous to assert a strong connection here, but I’d say it’s dangerous to assert there isn’t one,” he said. “I was arguing with my fiance about this last night. She’s waiting for LastPass to tell her to change everything. Meanwhile, I’m telling her to do it now.”
Last week I was contacted by CERT Poland. They'd observed a phishing campaign that had collected 68k credentials from unsuspecting victims and asked if HIBP may be used to help alert these individuals to their exposure. The campaign began with a typical email requesting more information:
In this case, the email contained a fake purchase order attachment which requested login credentials that were then posted back to infrastructure controlled by the attacker:
All in all, CERT Poland identified 202 other phishing campaigns using the same infrastructure which has subsequently been taken offline. Data accumulated by the malicious activity spanned from October 2022 until just last week.
The advice to impacted individuals is as follows:
Today, the US Justice Department announced a multinational operation involving actions in the United States, France, Germany, the Netherlands, and the United Kingdom to disrupt the botnet and malware known as Qakbot and take down its infrastructure. Beyond just taking down the backbone of the operation, the FBI began actively intercepting traffic from the botnet and instructing infected machines the uninstall the malware:
To disrupt the botnet, the FBI was able to redirect Qakbot botnet traffic to and through servers controlled by the FBI, which in turn instructed infected computers in the United States and elsewhere to download a file created by law enforcement that would uninstall the Qakbot malware
As part of the operation, the FBI have requested support from Have I Been Pwned (HIBP) to help notify impacted victims of their exposure to the malware. We provided similar support in 2021 with the Emotet botnet, although this time around with a grand total of 6.43M impacted email addresses. These are now all searchable in HIBP albeit with the incident is flagged as "sensitive" so you'll need to verify you control the email address via the notification service first, or you can search any domains you control via the domain search feature. Further, the passwords from the malware will shortly be searchable in the Pwned Passwords service which can either be checked online or via the API. Pwned Passwords is presently requested 5 and a half billion times each month to help organisations prevent people from using known compromised passwords.
Guidance for those impacted by this incident is the same tried and tested advice given after previous malware incidents:
There's a "hidden" API on HIBP. Well, it's not "hidden" insofar as it's easily discoverable if you watch the network traffic from the client, but it's not meant to be called directly, rather only via the web app. It's called "unified search" and it looks just like this:
It's been there in one form or another since day 1 (so almost a decade now), and it serves a sole purpose: to perform searches from the home page. That is all - only from the home page. It's called asynchronously from the client without needing to post back the entire page and by design, it's super fast and super easy to use. Which is bad. Sometimes.
To understand why it's bad we need to go back in time all the way to when I first launched the API that was intended to be consumed programmatically by other people's services. That was easy, because it was basically just documenting the API that sat behind the home page of the website already, the predecessor to the one you see above. And then, unsurprisingly in retrospect, it started to be abused so I had to put a rate limit on it. Problem is, that was a very rudimentary IP-based rate limit and it could be circumvented by someone with enough IPs, so fast forward a bit further and I put auth on the API which required a nominal payment to access it. At the same time, that unified search endpoint was created and home page searches updated to use that rather than the publicly documented API. So, 2 APIs with 2 different purposes.
The primary objective for putting a price on the public API was to tackle abuse. And it did - it stopped it dead. By attaching a rate limit to a key that required a credit card to purchase it, abusive practices (namely enumerating large numbers of email addresses) disappeared. This wasn't just about putting a financial cost to queries, it was about putting an identity cost to them; people are reluctant to start doing nasty things with a key traceable back to their own payment card! Which is why they turned their attention to the non-authenticated, non-documented unified search API.
Let's look at a 3 day period of requests to that API earlier this year, keeping in mind this should only ever be requested organically by humans performing searches from the home page:
This is far from organic usage with requests peaking at 121.3k in just 5 minutes. Which poses an interesting question: how do you create an API that should only be consumed asynchronously from a web page and never programmatically via a script? You could chuck a CAPTCHA on the front page and require that be solved first but let's face it, that's not a pleasant user experience. Rate limit requests by IP? See the earlier problem with that. Block UA strings? Pointless, because they're easily randomised. Rate limit an ASN? It gets you part way there, but what happens when you get a genuine flood of traffic because the site has hit the mainstream news? It happens.
Over the years, I've played with all sorts of combinations of firewall rules based on parameters such as geolocations with incommensurate numbers of requests to their populations, JA3 fingerprints and, of course, the parameters mentioned above. Based on the chart above these obviously didn't catch all the abusive traffic, but they did catch a significant portion of it:
If you combine it with the previous graph, that's about a third of all the bad traffic in that period or in other words, two thirds of the bad traffic was still getting through. There had to be a better way, which brings us to Cloudflare's Turnstile:
With Turnstile, we adapt the actual challenge outcome to the individual visitor or browser. First, we run a series of small non-interactive JavaScript challenges gathering more signals about the visitor/browser environment. Those challenges include, proof-of-work, proof-of-space, probing for web APIs, and various other challenges for detecting browser-quirks and human behavior. As a result, we can fine-tune the difficulty of the challenge to the specific request and avoid ever showing a visual puzzle to a user.
"Avoid ever showing a visual puzzle to a user" is a polite way of saying they avoid the sucky UX of CAPTCHA. Instead, Turnstile offers the ability to issue a "non-interactive challenge" which implements the sorts of clever techniques mentioned above and as it relates to this blog post, that can be an invisible non-interactive challenge. This is one of 3 different widget types with the others being a visible non-interactive challenge and a non-intrusive interactive challenge. For my purposes on HIBP, I wanted a zero-friction implementation nobody saw, hence the invisible approach. Here's how it works:
Get it? Ok, let's break it down further as it relates to HIBP, starting with when the front page first loads and it embeds the Turnstile widget from Cloudflare:
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>The widget takes responsibility for running the non-interactive challenge and returning a token. This needs to be persisted somewhere on the client side which brings us to embedding the widget:
<div ID="turnstileWidget" class="cf-turnstile" data-sitekey="0x4AAAAAAADY3UwkmqCvH8VR" data-callback="turnstileCompleted"></div>Per the docs in that link, the main thing here is to have an element with the "cf-turnstile" class set on it. If you happen to go take a look at the HIBP HTML source right now, you'll see that element precisely as it appears in the code block above. However, check it out in your browser's dev tools so you can see how it renders in the DOM and it will look more like this:
Expand that DIV tag and you'll find a whole bunch more content set as a result of loading the widget, but that's not relevant right now. What's important is the data-token attribute because that's what's going to prove you're not a bot when you run the search. How you implement this from here is up to you, but what HIBP does is picks up the token and sets it in the "cf-turnstile-response" header then sends it along with the request when that unified search endpoint is called:
So, at this point we've issued a challenge, the browser has solved the challenge and received a token back, now that token has been sent along with the request for the actual resource the user wanted, in this case the unified search endpoint. The final step is to validate the token and for this I'm using a Cloudflare worker. I've written a lot about workers in the past so here's the short pitch: it's code that runs in each one of Cloudflare's 300+ edge nodes around the world and can inspect and modify requests and responses on the fly. I already had a worker to do some other processing on unified search requests, so I just added the following:
const token = request.headers.get('cf-turnstile-response');
if (token === null) {
return new Response('Missing Turnstile token', { status: 401 });
}
const ip = request.headers.get('CF-Connecting-IP');
let formData = new FormData();
formData.append('secret', '[secret key goes here]');
formData.append('response', token);
formData.append('remoteip', ip);
const turnstileUrl = 'https://challenges.cloudflare.com/turnstile/v0/siteverify';
const result = await fetch(turnstileUrl, {
body: formData,
method: 'POST',
});
const outcome = await result.json();
if (!outcome.success) {
return new Response('Invalid Turnstile token', { status: 401 });
}That should be pretty self-explanatory and you can find the docs for this on Cloudflare's server-side validation page which goes into more detail, but in essence, it does the following:
And because this is all done in a Cloudflare worker, any of those 401 responses never even touch the origin. Not only do I not need to process the request in Azure, the person attempting to abuse my API gets a nice speedy response directly from an edge node near them 🙂
So, what does this mean for bots? If there's no token then they get booted out right away. If there's a token but it's not valid then they get booted out at the end. But can't they just take a previously generated token and use that? Well, yes, but only once:
If the same response is presented twice, the second and each subsequent request will generate an error stating that the response has already been consumed.
And remember, a real browser had to generate that token in the first place so it's not like you can just automate the process of token generation then throw it at the API above. (Sidenote: that server-side validation link includes how to handle idempotency, for example when retrying failed requests.) But what if a real human fails the verification? That's entirely up to you but in HIBP's case, that 401 response causes a fallback to a full page post back which then implements other controls, for example an interactive challenge.
Time for graphs and stats, starting with the one in the hero image of this page where we can see the number of times Turnstile was issued and how many times it was solved over the week prior to publishing this post:
That's a 91% hit rate of solved challenges which is great. That remaining 9% is either humans with a false positive or... bots getting rejected 😎
More graphs, this time how many requests to the unified search page were rejected by Turnstile:
That 990k number doesn't marry up with the 476k unsolved ones from before because they're 2 different things: the unsolved challenges are when the Turnstile widget is loaded but not solved (hopefully due to it being a bot rather than a false positive), whereas the 401 responses to the API is when a successful (and previously unused) Turnstile token isn't in the header. This could be because the token wasn't present, wasn't solved or had already been used. You get more of a sense of how many of these rejected requests were legit humans when you drill down into attributes like the JA3 fingerprints:
In other words, of those 990k failed requests, almost 40% of them were from the same 5 clients. Seems legit 🤔
And about a third were from clients with an identical UA string:
And so on and so forth. The point being that the number of actual legitimate requests from end users that were inconvenienced by Turnstile would be exceptionally small, almost certainly a very low single-digit percentage. I'll never know exactly because bots obviously attempt to emulate legit clients and sometimes legit clients look like bots and if we could easily solve this problem then we wouldn't need Turnstile in the first place! Anecdotally, that very small false positive number stacks up as people tend to complain pretty quickly when something isn't optimal, and I implemented this all the way back in March. Yep, 5 months ago, and I've waited this long to write about it just to be confident it's actually working. Over 100M Turnstile challenges later, I'm confident it is - I've not seen a single instance of abnormal traffic spikes to the unified search endpoint since rolling this out. What I did see initially though is a lot of this sort of thing:
By now it should be pretty obvious what's going on here, and it should be equally obvious that it didn't work out real well for them 😊
The bot problem is a hard one for those of us building services because we're continually torn in different directions. We want to build a slick UX for humans but an obtrusive one for bots. We want services to be easily consumable, but only in the way we intend them to... which might be by the good bots playing by the rules!
I don't know exactly what Cloudflare is doing in that challenge and I'll be honest, I don't even know what a "proof-of-space" is. But the point of using a service like this is that I don't need to know! What I do know is that Cloudflare sees about 20% of the internet's traffic and because of that, they're in an unrivalled position to look at a request and make a determination on its legitimacy.
If you're in my shoes, go and give Turnstile a go. And if you want to consume data from HIBP, go and check out the official API docs, the uh, unified search doesn't work real well for you any more 😎
John Clifton Davies, a convicted fraudster estimated to have bilked dozens of technology startups out of more than $30 million through phony investment schemes, has a brand new pair of scam companies that are busy dashing startup dreams: A fake investment firm called Equity-Invest[.]ch, and Diligere[.]co.uk, a scam due diligence company that Equity-Invest insists all investment partners use.
A native of the United Kingdom, Mr. Davies absconded from justice before being convicted on multiple counts of fraud in 2015. Prior to his conviction, Davies served 16 months in jail before being cleared on suspicion of murdering his third wife on their honeymoon in India.
The scam artist John Bernard (left) in a recent Zoom call, and a photo of John Clifton Davies from 2015.
John Clifton Davies was convicted in 2015 of swindling businesses throughout the U.K. that were struggling financially and seeking to restructure their debt. For roughly six years, Davies ran a series of firms that pretended to offer insolvency services. Instead, he simply siphoned what little remaining money these companies had, spending the stolen funds on lavish cars, home furnishings, vacations and luxury watches.
In a three-part series published in 2020, KrebsOnSecurity exposed how Davies — wanted by authorities in the U.K. — had fled the country, taken on the surname Bernard, remarried, and moved to his new (and fourth) wife’s hometown in Ukraine.
After eluding justice in the U.K., Davies reinvented himself as The Private Office of John Bernard, pretending to be a billionaire Swiss investor who made his fortunes in the dot-com boom 20 years ago and who was seeking private equity investment opportunities.
In case after case, Bernard would promise to invest millions in hi-tech startups, only to insist that companies pay tens of thousands of dollars worth of due diligence fees up front. However, the due diligence company he insisted on using — another Swiss firm called The Inside Knowledge — also was secretly owned by Bernard, who would invariably pull out of the deal after receiving the due diligence money.
Bernard found a constant stream of new marks by offering extraordinarily generous finders fees to investment brokers who could introduce him to companies seeking an infusion of cash. Inside Knowledge and The Private Office both closed up shop not long after being exposed here in 2020.
In April 2023, KrebsOnSecurity wrote about Codes2You, a recent Davies venture which purports to be a “full cycle software development company” based in the U.K. The company’s website no longer lists any of Davies’ known associates, but the site does still reference software and cloud services tied to those associates — including MySolve, a “multi-feature platform for insolvency practitioners.”
Earlier this month, KrebsOnSecurity heard from an investment broker who found out his client had paid more than $50,000 in due diligence fees related to a supposed multi-million dollar investment offer from a Swiss concern called Equity-Invest[.]ch.
The investment broker, who spoke on condition that neither he nor his client be named, said Equity-Invest began getting cold feet after his client plunked down the due diligence fees.
“Things started to go sideways when the investor purportedly booked a trip to the US to meet the team but canceled last minute because ‘his pregnant wife got in a car accident,'” the broker explained. “After that, he was radio silent until the contract expired.”
The broker said he grew suspicious when he learned that the Equity-Invest domain name was less than six months old. The broker’s suspicions were confirmed after he discovered the due diligence company that Equity-Invest insisted on using — Diligere[.]co.uk — included an email address on its homepage for another entity called Ardelis Solutions.
A corporate entity in the UK called Ardelis Solutions was key to showing the connection to Davies’ former scam investment and due diligence firms in the Codes2You investigation published earlier this year.
Although Diligere’s website claims the due diligence firm has “13 years of experiance” [sic], its domain name was only registered in April 2023. What’s more, virtually all of the vapid corporate-speak published on Diligere’s homepage is identical to text on the now-defunct InsideKnowledge[.]ch — the fake due diligence firm secretly owned for many years by The Private Office of John Bernard (John Clifton Davies).
A snippet of text from the now-defunct website of the fake Swiss investor John Bernard, in real life John Clifton Davies.
“Our steadfast conviction and energy for results is what makes us stand out,” both sites state. “We care for our clients’ and their businesses, we share their ambitions and align our goals to complement their objectives. Our clients know we’re in this together. We work in close partnership with our clients to deliver palpable results regardless of geography, complexity or controversy.”
The copy on Diligere’s homepage is identical to that once on Insideknowledge[.]com, a phony due diligence company run by John Clifton Davies.
I've been teaching my 13-year old son Ari how to code since I first got him started on Scratch many years ago, and gradually progressed through to the current day where he's getting into Python in Visual Studio Code. As I was writing the new domain search API for Have I Been Pwned (HIBP) over the course of this year, I was trying to explain to him how powerful APIs are:
Think of HIBP as one website that does pretty much one thing; you load it in your browser and search through data breaches which then display on the screen. But when you have an API, it's no longer just locked into your browser, it's in all sorts of other systems. Mobile apps, other websites, dashboards and if you really want, you can even integrate the lights in your room with HIBP! Why? How? Well, there's a Home Assistant integration for HIBP and being pwned in a new breach could raise an event there you can then use YAML to perform an action with, for example flashing a light red. That might be weird and unnecessary, but when you have an API, suddenly all these things you never thought of are possible.
It took Brett Adams less than a day after we released the new domain search API last Monday for him to reach out to me with one of those ideas. He wanted to build a Splunk app (Brett is a Splunk MVP so this was right up his alley) to surface breached data about an organisation's domains right into the place where so many security engineers spend their days. He just wanted 2 new APIs to make the user experience the best it could be:
That seems so ridiculously obvious, why didn't I think of that originally?! But hey, easy fix, so the next day Brett had his APIs. And today, you also have the APIs because they're now all publicly documented and ready for you to consume. You also have Brett's Splunk app and because he's published it to Splunkbase, you can go and pull it into your own Splunk instance, plug in your HIBP API key and it's job done!
I'll leave you with a bunch of screen caps from Brett's work, starting with a zoomed in grab of what I suspect folks will find the most valuable - the addresses on their domains and their appearances across breaches:
That's a fragment of the broader dashboard that also breaks down the incidents over time:
The starting point for this is simply plugging your API key into the interface:
I like these headline figures and I picture particularly large organisations that have gone through various acquisitions of different brands with various domains finding this really useful:
And speaking of breaches, there's a lot of them which Brett has visualised across the course of time:
So that's it, you can see all the APIs documented on the HIBP website and you can grab Brett's app right now from Splunkbase. You can also find all the code for this in Brett's GitHub repo should you wish to have a read through it.
The HIBP APIs are there for other people to build awesome things. If you're one of those people, please get in touch with me and show me what you've created, I can't wait to see more integrations like Brett's 😊
This is a big one. A massive one. It's the culmination of a solid 7 months of work that finally, as of now, is live. The full back story is in my blog post from mid-June about The Big 5 Announcements but to save you trawling through all of that, here are the cliff notes:
I've spent the last 8 weeks since publishing that post crunching numbers, writing code, doing loads of formal things (namely terms of use and privacy policy), and regularly talking about it on my weekly video. I've had loads of enormously useful feedback, much of which has shaped the state of the services we're launching here today. Thank you everyone who contributed, now let me get into it and explain exactly what we've come up with 🙂
We've been thinking about the best way to structure this since January. How do we take something that has been provided for free for almost a decade and put a reasonable price on it? That's a highly subjective word - reasonable - and there'll never be complete consensus, so it's more about passing the pub test where your average person will look at this and go "yeah, that seems fair enough". Let me explain the thinking and how we reached the pricing structure you'll see further down:
Firstly, we wanted most domain searches to remain free. This keeps with the spirit of HIBP's roots being a community service and ensures the data is accessible without barrier to the majority of people. It would also mean that for most people, these changes would have absolutely no impact on the way they've been using the service, not unless they want access to the new bits.
Next, we wanted to divide the commercial offerings into a manageable number of tiers. The public API key has 4 tiers and I reckon that's the sweet spot; it's not too many options, but it's enough to provide a good separation between the scale of each. We then wanted to distribute the number of domains that would fall into the commercial category roughly equally between those 4 tiers, so it was pretty much a matter of taking what was left after the free ones and dividing them into 4 groups and putting a price on them.
Finally, we wanted the first commercial tier to be easily affordable so that most people could access it without thinking twice about it. My measure for that has always been "the cost of a cup of coffee", so I went down to my favourite local and checked what I was blindly paying when I waved my watch in the general direction of the EFTPOS machine:
$6 Aussie, or just under $4 in USD. Which led us to here (all in USD from now on):
| Plan | Breached addresses | Percent of all domains | Price / m |
| Pwned 0 | Up to 10 | 60% | Free! |
| Pwned 1 | Up to 25 | 10% | $3.95 |
| Pwned 2 | Up to 100 | 10% | $16.95 |
| Pwned 3 | Up to 500 | 10% | $28.50 |
| Pwned 4 | Unlimited | 10% | $115.00 |
What you're looking at here is a list of plan names (more on that soon), the size of the domain it covers (expressed in the number of breached email addresses on it), what percentage of all domains presently being monitored in HIBP this represents and, of course, the monthly price. As with the public API, if you subscribe annually then it's "pay for 10, get 12" which means that "Pwned 1" price works out at only $3.25 a month. As I flagged in the earlier post, this is all based around the number of addresses that appear in a breach, with one important caveat I'll expand on later: this number excludes all breaches flagged as a spam list. As a rough rule of thumb, over the years I've found approximately 20% of addresses on a domain have been breached so by that logic, you'll need 55 actual email addresses on a domain before there's a cost. Or up to 130 before it costs more than a coffee a month. (If you're a stickler for detail and are thinking those percentages are too perfect, I've rounded them from their actual values of 59.1%, 9.7%, 11.3%, 10.4% and 9.4%.)
But what if you have multiple domains? Easy - the one plan will cover all your domains within the size of that plan. For example, if you have 3 domains and one has 5 breached addresses, one has 20 and one has 90, you can get a single "Pwned 2" plan and cover them all. Or get a single "Pwned 1" plan and cover just the first 2. It's pretty simple.
So that was our initial thinking - stand this up as a product that sits alongside the existing API key one then you just purchase whichever one you want. Then, Brendan gave me a much better idea - combine them altogether! You can see the gears turning around in my head as I read his suggestion and as the days progressed and I gave it more thought, it became a brilliant idea. It massively simplifies the code base, it removes a lot of confusion that I'm sure would have otherwise ensued and perhaps most importantly, it gives you all something more than you would have had otherwise. The one fly in the ointment was the price disparity; the above prices are 13% to 15% higher than the old corresponding API key ones. So, what we've decided to do is run the old prices until 8 October then revise everything to the new prices above. That gives more than 60 days' notice to everyone with an existing API key (we'll have to email everyone anyway as the terms of use have changed to incorporate the domain bits), and there's clear verbiage everywhere about the change for anyone purchasing a new subscription. Plus, it gives everyone a little incentive to lock in for a year now and delay the increase until later in 2024. Thanks Brendan! 😊
So that's the rationale. There's no change for 60% of domains that have previously been searched, a negligible cost for the next 10% of them with the remainder paying commensurately more based on their scale. But we didn't just want to whack a cost on an existing service and you're down a few bucks a month with nothing more to show for it, let's talk about new stuff!
There are two brand new features we're now offering to all commercial subscribers. Even if your domain is small and has less than 10 breached addresses on it, you can still get access to these features via the entry level plan and they're both pretty self-explanatory: API-level access and formal support.
API first as I think it's the coolest and it's exactly what it sounds like: there's now a public endpoint you can throw a domain at and get a JSON response of breached aliases and the incidents they've appeared in. It looks just like this:
GET https://haveibeenpwned.com/api/v3/breacheddomain/{domain}
hibp-api-key: [your key]Which then responds like this:
{
"alias1": [
"Adobe"
],
"alias2": [
"Adobe",
"Gawker",
"Stratfor"
],
"alias3": [
"AshleyMadison"
]
}If you're already paying for an API key, you have immediate access to this! Same key, same logic in terms of resolving the returned breach name to the full thing via the unauthenticated API that returns breach metadata, the only caveats are that is has to be a domain you've previously demonstrated you control and it has to be within your plan size (e.g. you have a Pwned 1 plan and your domains don't exceed 25 breached addresses). Otherwise:
Subscription upgrade required.Just one more thing with the domain search API: it only makes sense to hit it after a new breach is loaded. There's absolutely no point in hammering away at it non-stop as you'll only get the same result so instead, try polling the brand new API we've just added to return only the most recent breach (it's massively cached at Cloudflare anyway) and just hit the domain search API when there's a new one. But because not everybody will do this and domain searches are expensive relative to other queries, the terms and conditions include this clause:
Controls such as rate limiting may be added to the domain search API if excessive API requests are made despite no new breaches appearing since the last request.
There is a rate limit based on a variety of factors and it's possible you may receive an HTTP 429 if you request it more frequently than is necessary. The only reason I'm not going into the details of how that works here is that I expect it will adapt and change pretty frequently in response to how people use the service. What I can confidently say now though, is that if you use the domain search feature in the way it's intended to work - querying each domain after a new breach is added - you won't have a problem with rate limits.
I'm really excited to see how people will integrate this data into their existing tooling, do please let me know if you do something awesome 😊
Then there's the formal support which we offer via Zendesk at support.haveibeenpwned.com. That launched with the API key upgrades last November and since that time, we've answered almost 600 tickets. We've been trying to fine tune things to the extent that the knowledge base there answers the most common questions, but there's certainly a great deal of time that still goes into supporting the questions that pop up. Adding domain searches to the mix will inevitably increase that, possibly by a significant order of magnitude which is why we're only making this available to commercial subscribers.
So, that's the new bits. If you're in that 60% group of people with smaller domains outside of the commercial tiers, you can get access to both the API and support by subscribing to the smallest possible plan for that cup of coffee a month. We feel that's a pretty reasonable balance, and I hope you do too.
Speaking of reasonable, about those spam lists...
I mentioned sharing as much as I could in my weekly update videos, including the intended pricing structure and how it would be based on the number of breached email addresses on a domain. Several people raised a very important point as it related to the calculations: data breaches ain't data breaches or more specifically, there are breaches in HIBP that shouldn't be treated like the other ones as they artificially inflate the pwn count. Could these be excluded?
The Onliner Spambot incident was the worst culprit and in the case of one person that contacted me, it caused his personal domain to read as though hundreds of addresses had been breached when the correct number was... zero. Someone else had their domain pegged at 40 breached addresses whereas once you took this breach out, the number came down to 13. This created somewhat of a rock and hard place situation because whilst those aliases did appear in this incident, they weren't real addresses. But what's a "real" email address anyway? Or more specifically, how can I tell via a string alone whether an address is real or not? A decade ago now I wrote about how hard this is and per the comments on that post, concluded that the only way to tell for sure is to send an email and have the recipient perform some sort of explicit action such as clicking on a link. Clearly, that's not feasible in this situation but equally, putting a price on a service based on a metric that has been artificially inflated just wasn't fair.
Adding spam lists back in 2016 was the right thing to do but equally, excluding them from the number that determines the pricing tier is also the right thing to do. We've tried to make this logic as clear as possible throughout the system and focus on a simple UX that's explicit but can also provide more insight if required,
And if you're interested in which breaches specifically have been classified as a spam list, I've added a filter to the API that lists all breaches. It's an unauthenticated API you can load directly in your browser via GET request and at the time of writing, has 11 breaches on it with nearly 1.4 billion records.
The very last thing from that screen cap is the "Enable debug mode" link and for that, we need to talk about "domain creep".
Data breaches are obviously an ongoing thing. Always have been, always will be so what that means is when you look at a domain today and see, say, 20 breached accounts on it, that might be 30 breached accounts tomorrow. I think everyone who uses HIBP understands that, but it does create a bit of a problem when domain searches are priced on a metric that can "creep". What if you've just paid for a year's worth of Pwned 1 subscription and per the example here, you've suddenly got more than 25 breached accounts on your domain and can no longer search it?
The sentiment of how this should be handled was always obvious: people have to get what they pay for. We didn't want a situation where someone could be left disappointed, and our fear was that the organic increase in breaches could lead to that event. The solution was easy: when you buy a subscription at a certain scale, every domain you're currently monitoring that can be searched on the first day of the subscription can still be searched on the last day of the subscription. If you take out one year of Pwned 1 today and per the example above, the domain creeps beyond 25 breached accounts tomorrow, it'll have zero impact for the next 364 days.
I'm conscious that this concept can get confusing: domain searches are based on the number of breached accounts on the domain but not including spam lists and then locked in at the size of the domain until the next subscription renew... phew! The debug mode link mentioned above aims to show all this logic in its raw detail:
Even though domain1.com in this example has grown to 26 breached addresses, because it was 22 breached addresses when the subscription was taken out then that's the number it's locked at until it renews in August next year. I hope this is clear enough, do please leave a comment if we can do better.
Lastly, let me put some raw numbers around the "domain creep" situation as I foresee this causing concern beyond what might be warranted. Let's start with the number of unique email addresses which is approximately 6 billion. There have been about 723M records added in the last 12 months and a bunch of those will be for the same email address (shout out to everyone who was pwned again in the last year!) Further, of that number, most email addresses were already pwned. That's a link through to the Twitter feed where I broadcast the percentage of previously seen addresses and you'll see that number is regularly around the 60% to 70% range. In other words, it's probably in the order of 250M new addresses we've seen in the last year which is appx 4% of the entire corpus. So, yes, over the course of time we'll see domains slip into higher plans, but only at about the rate of CPI.
Lastly, locking domain counts for the duration of the subscription creates additional incentive to make it an annual one, and that's beyond the existing incentive of "buy 10 months, get 12 months". That's also in addition to massively cutting down on the number of times you may need to deal with corporate bureaucracy. Speaking of which...
Let me start with a story: Many years ago during my lengthy tenure at Pfizer, I pushed hard to drive us away from traditional hosting models and towards modern cloud paradigms, namely the Azure App Service. Here we had a model where you could self-service provision resources that cost about $50 per month and completely replaced a model that was costing us tens of thousands a year. It was an easy win, however... the organisation demanded vendor assessments, compliance paperwork and a billing model which, of course, was favourable to them. But Microsoft's model was "chuck your credit card in and off you go", so that's what one of my colleagues did. And paid for it himself, entirely out of his own pocket in order to save one of the world's largest companies money. My point is that I've done time on the inside and I understand the barriers organisations put in place "because reasons". I touched on this in the June post about the upcoming domain changes:
To be honest, the experience with the public API keys has taught me that it's usually not money that's the barrier to using commercial services, it's corporate procurement bureaucracy. Onboarding documentation. Vendor assessments. Tax forms.
And so too, I have the experience from the outside having regularly received requests to invest hours doing manual labour for the sake of something an organisation is paying a few bucks a month for. That simply doesn't scale and the whole point of providing services like this at volume is that you can go and set everything up yourself with nothing more than a credit card. This one came in while preparing this blog post:
My company is looking to purchase an API key so we can automate user lookups on your site. Our procurement process is wildly complex and I was wondering if we have the option of submitting a Purchase Order instead of using the Stripe credit card payment method?
If this situation resonates, you have my sympathies and my own corporate bureaucracy scars are still raw! If there's more we can do to ease the onboarding path without creating manual labour on a per-customer basis then please let me know. I'm sure there are improvements that can be made, the last thing I want to see is you ending up like my old mate from Pfizer 😞
We've tried to do everything possible to remove barriers. We've made significant investments in legal counsel to get the terms of use and privacy policy right and we've tried to provide answers to all the regular questions in the FAQs. We've even publicly provided a W-8BEN-E US tax form which was often requested by folks in the US. But it won't be enough for some organisations, which is why we do exactly the same thing as Pfizer often found themselves doing which is to provide an enterprise-orientated process where we deal with all this rigmarole... and charge accordingly. If that's you, then get in touch with me.
There will be lots of "but what about...?" edge cases. Let me give you some examples and our views on them:
But what about addresses that don't actually exist?
For most data breaches, email addresses are extracted using a regular expression run over the entire corpus of data. You can see what this looks like in the open source email address extractor used to process breaches. So, what is an email address? Per my earlier explanation, it's anything that matches the regex when run across the breach. That could mean strings that aren't actually an address on a domain get caught up and reported incorrectly. It happens, but there's no way to practically stop it and it's extraordinarily rare.
But what about email addresses from years ago that still appear as breached on a domain?
The argument here is that whilst these are genuine addresses that did indeed exist at one point, they aren't really relevant anymore either due to their age or the address no longer existing (e.g. ex staff). I have both a philosophical and a technical view on this, with the former being that data breaches are immutable. At a point in time, addresses were exposed, and that fact can never be reversed. As for the latter point, those addresses remain in a storage construct we need to continue to support, and every single domain query needs to pick those addresses up and return them to the code processing the search (the design of HIBP means that Azure's Table Storage returns the entire partition on each domain query). Further, in most cases, that doesn't change the total number of breached accounts being a reasonable metric for organisation size and subsequently, the pricing tier they should fit into.
But what about old breaches I don't care about any more causing me to require a higher plan?
It's a similar answer to the previous point insofar as the immutability of history and the need to store the data. It also remains the most reliable metric we have to determine the size of the domain and in many cases, the organisation that owns it. Think of this measurement primarily as a means of slicing up the corpus of data within HIBP and distributing the cost as equitably as possible across the organisations using the domain search feature.
But what about people who don't want to use a credit card?
I'll give you a two-part answer on this, beginning with the recognition that cards can pose legitimate challenges for some people. Just as I was drafting this blog post, someone trying to sign up to the public API reached out after failing to subscribe multiple times with different cards:
For a variety of reasons, I believe the guy is legit, but Stripe reports two payments declined by his bank and another due to an invalid CVC. But using Stripe doesn't just mean credit cards, it also means Apple Pay and Google Pay, WeChat Pay in China, EPS in Belgium, Afterpay in Australia and a raft of other payment mechanisms in different parts of the world. It's hard to imagine a legitimate case where someone does not have access to any of the available payment mechanisms, which brings me to the second part:
The reason we don't support the likes of anonymous cryptocurrency and rely solely on fiat money payments is that it very quickly weeds out the bad actors. That was the whole rationale for putting a payment gateway on the public API back in 2019 - to cut out the abuse. It turns out that once you have to pass the sort of KYC barriers financial institutions put in place, people don't misbehave under their own identity. And yes, there's always fraudulent use of cards, but Stripe has gotten so good at handling that (we pay for their Radar service as well), our dispute rate is only one in many thousands of transactions.
But what about [other reasons related to calculations and costs]?
Amongst the corpus of 12.6 billion records, there will be anomalies. It'll almost certainly be sub-1% and the anomalies won't be evenly distributed across domains; they'll affect some more than others. It's infeasible to ever get that down to zero and it's also infeasible to respond to every single request I know will come through asking for an anomaly to be rectified. The most practical way we could find to deal with this is to keep the pricing structure such that anomalies will be unlikely to have much impact of consequence.
We're also conscious that some people will challenge the cost and it happens all the time with the existing public API key either because of the individual's position in life or the nature of the organisation they work in. But this is why we've structured it as we have, with the majority of domains being within that free tier and the entry level cost being the cup of coffee that gets you access to things like API level access and formal support. This was the most reasonable, equitable model we could come up with and I hope that shines through in the explanations above.
I know there'll be individuals with catch all domains that have ended up in a couple of dozen data breaches and they think paying $3.95 to see them is unreasonable. I know there'll be organisations with much larger numbers who feel it's unreasonable because similarly sized orgs are more profitable. But I also know that I've been running domain searches totally out of my own pocket for almost a decade so whilst I'm sympathetic to anyone who now needs to pay for a service that was previously free, I'm also comfortable that a reasonable and well thought out model has been arrived at.
I'm excited to see what people do with the new API. The email address search one is presently requested millions of times a day and people have built all sorts of amazing things with it, everything from corporate awareness campaigns to tooling to help protect customers from account takeover attacks to integration within the corporate SOC. It's cases like that last one where I think the domain search API will really shine and if you do something awesome with it, please get in touch and let me know.
I know this was a long read, I hope it adequately explains the rationale for the subscription service and that you use it to do amazing things 😊
You can get started right now from the domain search page on HIBP.
Update: Following feedback and consultation with a range of existing users of the service, we now provide a model for the education and non-profit sectors. See the KB titled Do you provide discounts based on the nature of the organisation? for more information.
Researchers this month uncovered a two-year-old Linux-based remote access trojan dubbed AVrecon that enslaves Internet routers into botnet that bilks online advertisers and performs password-spraying attacks. Now new findings reveal that AVrecon is the malware engine behind a 12-year-old service called SocksEscort, which rents hacked residential and small business devices to cybercriminals looking to hide their true location online.
Image: Lumen’s Black Lotus Labs.
In a report released July 12, researchers at Lumen’s Black Lotus Labs called the AVrecon botnet “one of the largest botnets targeting small-office/home-office (SOHO) routers seen in recent history,” and a crime machine that has largely evaded public attention since first being spotted in mid-2021.
“The malware has been used to create residential proxy services to shroud malicious activity such as password spraying, web-traffic proxying and ad fraud,” the Lumen researchers wrote.
Malware-based anonymity networks are a major source of unwanted and malicious web traffic directed at online retailers, Internet service providers (ISPs), social networks, email providers and financial institutions. And a great many of these “proxy” networks are marketed primarily to cybercriminals seeking to anonymize their traffic by routing it through an infected PC, router or mobile device.
Proxy services can be used in a legitimate manner for several business purposes — such as price comparisons or sales intelligence — but they are massively abused for hiding cybercrime activity because they make it difficult to trace malicious traffic to its original source. Proxy services also let users appear to be getting online from nearly anywhere in the world, which is useful if you’re a cybercriminal who is trying to impersonate someone from a specific place.
Spur.us, a startup that tracks proxy services, told KrebsOnSecurity that the Internet addresses Lumen tagged as the AVrecon botnet’s “Command and Control” (C2) servers all tie back to a long-running proxy service called SocksEscort.
SocksEscort[.]com, is what’s known as a “SOCKS Proxy” service. The SOCKS (or SOCKS5) protocol allows Internet users to channel their Web traffic through a proxy server, which then passes the information on to the intended destination. From a website’s perspective, the traffic of the proxy network customer appears to originate from a rented/malware-infected PC tied to a residential ISP customer, not from the proxy service customer.
The SocksEscort home page says its services are perfect for people involved in automated online activity that often results in IP addresses getting blocked or banned, such as Craigslist and dating scams, search engine results manipulation, and online surveys.
Spur tracks SocksEscort as a malware-based proxy offering, which means the machines doing the proxying of traffic for SocksEscort customers have been infected with malicious software that turns them into a traffic relay. Usually, these users have no idea their systems are compromised.
Spur says the SocksEscort proxy service requires customers to install a Windows based application in order to access a pool of more than 10,000 hacked devices worldwide.
“We created a fingerprint to identify the call-back infrastructure for SocksEscort proxies,” Spur co-founder Riley Kilmer said. “Looking at network telemetry, we were able to confirm that we saw victims talking back to it on various ports.”
According to Kilmer, AVrecon is the malware that gives SocksEscort its proxies.
“When Lumen released their report and IOCs [indicators of compromise], we queried our system for which proxy service call-back infrastructure overlapped with their IOCs,” Kilmer continued. “The second stage C2s they identified were the same as the IPs we labeled for SocksEscort.”
Lumen’s research team said the purpose of AVrecon appears to be stealing bandwidth – without impacting end-users – in order to create a residential proxy service to help launder malicious activity and avoid attracting the same level of attention from Tor-hidden services or commercially available VPN services.
“This class of cybercrime activity threat may evade detection because it is less likely than a crypto-miner to be noticed by the owner, and it is unlikely to warrant the volume of abuse complaints that internet-wide brute-forcing and DDoS-based botnets typically draw,” Lumen’s Black Lotus researchers wrote.
Preserving bandwidth for both customers and victims was a primary concern for SocksEscort in July 2022, when 911S5 — at the time the world’s largest known malware proxy network — got hacked and imploded just days after being exposed in a story here. Kilmer said after 911’s demise, SocksEscort closed its registration for several months to prevent an influx of new users from swamping the service.
Danny Adamitis, principal information security researcher at Lumen and co-author of the report on AVrecon, confirmed Kilmer’s findings, saying the C2 data matched up with what Spur was seeing for SocksEscort dating back to September 2022.
Adamitis said that on July 13 — the day after Lumen published research on AVrecon and started blocking any traffic to the malware’s control servers — the people responsible for maintaining the botnet reacted quickly to transition infected systems over to a new command and control infrastructure.
“They were clearly reacting and trying to maintain control over components of the botnet,” Adamitis said. “Probably, they wanted to keep that revenue stream going.”
Frustratingly, Lumen was not able to determine how the SOHO devices were being infected with AVrecon. Some possible avenues of infection include exploiting weak or default administrative credentials on routers, and outdated, insecure firmware that has known, exploitable security vulnerabilities.
KrebsOnSecurity briefly visited SocksEscort last year and promised a follow-up on the history and possible identity of its proprietors. A review of the earliest posts about this service on Russian cybercrime forums suggests the 12-year-old malware proxy network is tied to a Moldovan company that also offers VPN software on the Apple Store and elsewhere.
SocksEscort began in 2009 as “super-socks[.]com,” a Russian-language service that sold access to thousands of compromised PCs that could be used to proxy traffic. Someone who picked the nicknames “SSC” and “super-socks” and email address “michvatt@gmail.com” registered on multiple cybercrime forums and began promoting the proxy service.
According to DomainTools.com, the apparently related email address “michdomain@gmail.com” was used to register SocksEscort[.]com, super-socks[.]com, and a few other proxy-related domains, including ip-score[.]com, segate[.]org seproxysoft[.]com, and vipssc[.]us. Cached versions of both super-socks[.]com and vipssc[.]us show these sites sold the same proxy service, and both displayed the letters “SSC” prominently at the top of their homepages.
Image: Archive.org. Page translation from Russian via Google Translate.
According to cyber intelligence firm Intel 471, the very first “SSC” identity registered on the cybercrime forums happened in 2009 at the Russian language hacker community Antichat, where SSC asked fellow forum members for help in testing the security of a website they claimed was theirs: myiptest[.]com, which promised to tell visitors whether their proxy address was included on any security or anti-spam block lists.
Myiptest[.]com is no longer responding, but a cached copy of it from Archive.org shows that for about four years it included in its HTML source a Google Analytics code of US-2665744, which was also present on more than a dozen other websites.
Most of the sites that once bore that Google tracking code are no longer online, but nearly all of them centered around services that were similar to myiptest[.]com, such as abuseipdb[.]com, bestiptest[.]com, checkdnslbl[.]com, dnsbltools[.]com and dnsblmonitor[.]com.
Each of these services were designed to help visitors quickly determine whether the Internet address they were visiting the site from was listed by any security firms as spammy, malicious or phishous. In other words, these services were designed so that proxy service users could easily tell if their rented Internet address was still safe to use for online fraud.
Another domain with the Google Analytics code US-2665744 was sscompany[.]net. An archived copy of the site says SSC stands for “Server Support Company,” which advertised outsourced solutions for technical support and server administration.
Leaked copies of the hacked Antichat forum indicate the SSC identity registered on the forum using the IP address 71.229.207.214. That same IP was used to register the nickname “Deem3n®,” a prolific poster on Antichat between 2005 and 2009 who served as a moderator on the forum.
There was a Deem3n® user on the webmaster forum Searchengines.guru whose signature in their posts says they run a popular community catering to programmers in Moldova called sysadmin[.]md, and that they were a systems administrator for sscompany[.]net.
That same Google Analytics code is also now present on the homepages of wiremo[.]co and a VPN provider called HideIPVPN[.]com.
Wiremo sells software and services to help website owners better manage their customer reviews. Wiremo’s Contact Us page lists a “Server Management LLC” in Wilmington, DE as the parent company. Server Management LLC is currently listed in Apple’s App Store as the owner of a “free” VPN app called HideIPVPN.
“The best way to secure the transmissions of your mobile device is VPN,” reads HideIPVPN’s description on the Apple Store. “Now, we provide you with an even easier way to connect to our VPN servers. We will hide your IP address, encrypt all your traffic, secure all your sensitive information (passwords, mail credit card details, etc.) form [sic] hackers on public networks.”
When asked about the company’s apparent connection to SocksEscort, Wiremo responded, “We do not control this domain and no one from our team is connected to this domain.” Wiremo did not respond when presented with the findings in this report.
When the marital infidelity website AshleyMadison.com learned in July 2015 that hackers were threatening to publish data stolen from 37 million users, the company’s then-CEO Noel Biderman was quick to point the finger at an unnamed former contractor. But as a new documentary series on Hulu reveals [SPOILER ALERT!], there was just one problem with that theory: Their top suspect had killed himself more than a year before the hackers began publishing stolen user data.
The new documentary, The Ashley Madison Affair, begins airing today on Hulu in the United States and on Disney+ in the United Kingdom. The series features interviews with security experts and journalists, Ashley Madison executives, victims of the breach and jilted spouses.
The series also touches on shocking new details unearthed by KrebsOnSecurity and Jeremy Bullock, a data scientist who worked with the show’s producers at the Warner Bros. production company Wall to Wall Media. Bullock had spent many hours poring over the hundreds of thousands of emails that the Ashley Madison hackers stole from Biderman and published online in 2015.
Wall to Wall reached out in July 2022 about collaborating with Bullock after KrebsOnSecurity published A Retrospective on the 2015 Ashley Madison Breach. That piece explored how Biderman — who is Jewish — had become the target of concerted harassment campaigns by anti-Semitic and far-right groups online in the months leading up to the hack.
Whoever hacked Ashley Madison had access to all employee emails, but they only released Biderman’s messages — three years worth. Apropos of my retrospective report, Bullock found that a great many messages in Biderman’s inbox were belligerent and anti-Semitic screeds from a former Ashley Madison employee named William Brewster Harrison.
William Harrison’s employment contract with Ashley Madison parent Avid Life Media.
The messages show that Harrison was hired in March 2010 to help promote Ashley Madison online, but the messages also reveal Harrison was heavily involved in helping to create and cultivate phony female accounts on the service.
There is evidence to suggest that in 2010 Harrison was directed to harass the owner of Ashleymadisonsucks.com into closing the site or selling the domain to Ashley Madison.
Ashley Madison’s parent company — Toronto-based Avid Life Media — filed a trademark infringement complaint in 2010 that succeeded in revealing a man named Dennis Bradshaw as the owner. But after being informed that Bradshaw was not subject to Canadian trademark laws, Avid Life offered to buy AshleyMadisonSucks.com for $10,000.
When Bradshaw refused to sell the domain, he and his then-girlfriend were subject to an unrelenting campaign of online harassment and blackmail. It now appears those attacks were perpetrated by Harrison, who sent emails from different accounts at the free email service Vistomail pretending to be Bradshaw, his then-girlfriend and their friends.
[As the documentary points out, the domain AshleyMadisonSucks.com was eventually transferred to Ashley Madison, which then shrewdly used it for advertising and to help debunk theories about why its service was supposedly untrustworthy].
Harrison even went after Bradshaw’s lawyer and wife, listing them both on a website he created called Contact-a-CEO[.]com, which Harrison used to besmirch the name of major companies — including several past employers — all entities he believed had slighted him or his family in some way. The site also claimed to include the names, addresses and phone numbers of top CEOs.
A cached copy of Harrison’s website, contact-the-ceo.com.
An exhaustive analysis of domains registered to the various Vistomail pseudonyms used by Harrison shows he also ran Bash-a-Business[.]com, which Harrison dedicated to “all those sorry ass corporate executives out there profiting from your hard work, organs, lives, ideas, intelligence, and wallets.” Copies of the site at archive.org show it was the work of someone calling themselves “The Chaos Creator.”
Will Harrison was terminated as an Ashley Madison employee in November 2011, and by early 2012 he’d turned his considerable harassment skills squarely against the company. Ashley Madison’s long-suspected army of fake female accounts came to the fore in August 2012 after the former sex worker turned activist and blogger Maggie McNeill published screenshots apparently taken from Ashley Madison’s internal systems suggesting that a large percentage of the female accounts on the service were computer-operated bots.
Ashley Madison’s executives understood that only a handful of employees at the time would have had access to the systems needed to produce the screenshots McNeill published online. In one exchange on Aug. 16, 2012, Ashley Madison’s director of IT was asked to produce a list of all company employees with all-powerful administrator access.
“Who or what is asdfdfsda@asdf.com?,” Biderman asked, after being sent a list of nine email addresses.
“It appears to be the email address Will used for his profiles,” the IT director replied.
“And his access was never shut off until today?,” asked the company’s general counsel Mike Dacks.
A Biderman email from 2012.
What prompted the data scientist Bullock to reach out were gobs of anti-Semitic diatribes from Harrison, who had taken to labeling Biderman and others “greedy Jew bastards.”
“So good luck, I’m sure we’ll talk again soon, but for now, Ive got better things in the oven,” Harrison wrote to Biderman after his employment contract with Ashley Madison was terminated. “Just remember I outsmarted you last time and I will outsmart and out maneuver you this time too, by keeping myself far far away from the action and just enjoying the sideline view, cheering for the opposition.”
A 2012 email from William Harrison to former Ashley Madison CEO Noel Biderman.
Harrison signed his threatening missive with the salutation, “We are legion,” suggesting that whatever comeuppance he had in store for Ashley Madison would come from a variety of directions and anonymous hackers.
The leaked Biderman emails show that Harrison made good on his threats, and that in the months that followed Harrison began targeting Biderman and other Ashley Madison executives with menacing anonymous emails and spoofed phone calls laced with profanity and anti-Semitic language.
But on Mar. 5, 2014, Harrison committed suicide by shooting himself in the head with a handgun. This fact was apparently unknown to Biderman and other Ashley Madison executives more than a year later when their July 2015 hack was first revealed.
Does Harrison’s untimely suicide rule him out as a suspect in the 2015 hack? Who is The Chaos Creator, and what else transpired between Harrison and Ashley Madison prior to his death? We’ll explore these questions in Part II of this story, to be published early next week.
If you’ve ever owned a domain name, the chances are good that at some point you’ve received a snail mail letter which appears to be a bill for a domain or website-related services. In reality, these misleading missives try to trick people into paying for useless services they never ordered, don’t need, and probably will never receive. Here’s a look at the most recent incarnation of this scam — DomainNetworks — and some clues about who may be behind it.
The DomainNetworks mailer may reference a domain that is or was at one point registered to your name and address. Although the letter includes the words “marketing services” in the upper right corner, the rest of the missive is deceptively designed to look like a bill for services already rendered.
DomainNetworks claims that listing your domain with their promotion services will result in increased traffic to your site. This is a dubious claim for a company that appears to be a complete fabrication, as we’ll see in a moment. But happily, the proprietors of this enterprise were not so difficult to track down.
The website Domainnetworks[.]com says it is a business with a post office box in Hendersonville, N.C., and another address in Santa Fe, N.M. There are a few random, non-technology businesses tied to the phone number listed for the Hendersonville address, and the New Mexico address was used by several no-name web hosting companies.
However, there is little connected to these addresses and phone numbers that get us any closer to finding out who’s running Domainnetworks[.]com. And neither entity appears to be an active, official company in their supposed state of residence, at least according to each state’s Secretary of State database.
The Better Business Bureau listing for DomainNetworks gives it an “F” rating, and includes more than 100 reviews by people angry at receiving one of these scams via snail mail. Helpfully, the BBB says DomainNetworks previously operated under a different name: US Domain Authority LLC.
DomainNetworks has an “F” reputation with the Better Business Bureau.
Copies of snail mail scam letters from US Domain Authority posted online show that this entity used the domain usdomainauthority[.]com, registered in May 2022. The Usdomainauthority mailer also featured a Henderson, NC address, albeit at a different post office box.
Usdomainauthority[.]com is no longer online, and the site seems to have blocked its pages from being indexed by the Wayback Machine at archive.org. But searching on a long snippet of text from DomainNetworks[.]com about refund requests shows that this text was found on just one other active website, according to publicwww.com, a service that indexes the HTML code of existing websites and makes it searchable.
A deceptive snail mail solicitation from DomainNetwork’s previous iteration — US Domain Authority. Image: Joerussori.com
That other website is a domain registered in January 2023 called thedomainsvault[.]com, and its registration details are likewise hidden behind privacy services. Thedomainsvault’s “Frequently Asked Questions” page is quite similar to the one on the DomainNetworks website; both begin with the question of why the company is sending a mailer that looks like a bill for domain services.
Thedomainsvault[.]com includes no useful information about the entity or people who operate it; clicking the “Contact-us” link on the site brings up a page with placeholder Lorem Ipsum text, a contact form, and a phone number of 123456789.
However, searching passive DNS records at DomainTools.com for thedomainsvault[.]com shows that at some point whoever owns the domain instructed incoming email to be sent to ubsagency@gmail.com.
The first result that currently pops up when searching for “ubsagency” in Google is ubsagency[.]com, which says it belongs to a Las Vegas-based Search Engine Optimization (SEO) and digital marketing concern generically named both United Business Service and United Business Services. UBSagency’s website is hosted at the same Ann Arbor, Mich. based hosting firm (A2 Hosting Inc) as thedomainsvault[.]com.
UBSagency’s LinkedIn page says the company has offices in Vegas, Half Moon Bay, Calif., and Renton, Wash. But once again, none of the addresses listed for these offices reveal any obvious clues about who runs UBSagency. And once again, none of these entities appear to exist as official businesses in their claimed state of residence.
Searching on ubsagency@gmail.com in Constella Intelligence shows the address was used sometime before February 2019 to create an account under the name “Sammy\Sam_Alon” at the interior decorating site Houzz.com. In January 2019, Houzz acknowledged that a data breach exposed account information on an undisclosed number of customers, including user IDs, one-way encrypted passwords, IP addresses, city and ZIP codes, as well as Facebook information.
Sammy\Sam_Alon registered at Houzz using an Internet address in Huntsville, Ala. (68.35.149.206). Constella says this address was associated with the email tropicglobal@gmail.com, which also is tied to several other “Sammy” accounts at different stores online.
Constella also says a highly unique password re-used by tropicglobal@gmail.com across numerous sites was used in connection with just a few other email accounts, including shenhavgroup@gmail.com, and distributorinvoice@mail.com.
The shenhavgroup@gmail.com address was used to register a Twitter account for a Sam Orit Alon in 2013, whose account says they are affiliated with the Shenhav Group. According to DomainTools, shenhavgroup@gmail.com was responsible for registering roughly two dozen domains, including the now-defunct unitedbusinessservice[.]com.
Constella further finds that the address distributorinvoice@mail.com was used to register an account at whmcs.com, a web hosting platform that suffered a breach of its user database several years back. The name on the WHMCS account was Shmuel Orit Alon, from Kidron, Israel.
UBSagency also has a Facebook page, or maybe “had” is the operative word because someone appears to have defaced it. Loading the Facebook page for UBSagency shows several of the images have been overlaid or replaced with a message from someone who is really disappointed with Sam Alon.
“Sam Alon is a LIAR, THIEF, COWARD AND HAS A VERY SMALL D*CK,” reads one of the messages:
The current Facebook profile page for UBSagency includes a logo that is similar to the DomainNetworks logo.
The logo in the UBSagency profile photo includes a graphic of what appears to be a magnifying glass with a line that zig-zags through bullet points inside and outside the circle, a unique pattern that is remarkably similar to the logo for DomainNetworks:
The logos for DomainNetworks (left) and UBSagency.
Constella also found that the same Huntsville IP address used by Sam Alon at Houzz was associated with yet another Houzz account, this one for someone named “Eliran.”
The UBSagency Facebook page features several messages from an Eliran “Dani” Benz, who is referred to by commenters as an employee or partner with UBSagency. The last check-in on Benz’s profile is from a beach at Rishon Letziyon in Israel earlier this year.
Neither Mr. Alon nor Mr. Benz responded to multiple requests for comment.
It may be difficult to believe that anyone would pay an invoice for a domain name or SEO service they never ordered. However, there is plenty of evidence that these phony bills often get processed by administrative personnel at organizations that end up paying the requested amount because they assume it was owed for some services already provided.
In 2018, KrebsOnSecurity published How Internet Savvy are Your Leaders?, which examined public records to show that dozens of cities, towns, school districts and even political campaigns across the United States got snookered into paying these scam domain invoices from a similar scam company called WebListings Inc.
In 2020, KrebsOnSecurity featured a deep dive into who was likely behind the WebListings scam, which had been sending out these snail mail scam letters for over a decade. That investigation revealed the scam’s connection to a multi-level marketing operation run out of the U.K., and to two brothers living in Scotland.
Related tags
There are presently 201k people monitoring domains in Have I Been Pwned (HIBP). That's massive! That's 201k people that have searched for a domain, left their email address for future notifications when the domain appears in a new breach and successfully verified that they control the domain. But that's only a subset of all the domains searched, which totals 231k. In many instances, multiple people have searched for the same domain (most likely from the same company given they've successfully verified control), and also in many instances, people are obviously searching for and monitoring multiple domains. Companies have different brands, mergers and acquisitions happen and so on and so forth. Larger numbers of domains also means larger numbers of notifications; HIBP has now sent out 2.7M emails to those monitoring domains after a breach has occurred. And the largest number of the lot: all those domains being monitored encompass an eye watering 273M breached email addresses 😲
The point is, just as HIBP itself has escalated into something far bigger than I ever expected, so too has the domain search feature. Today, I'm launching an all new domain search experience and 5 announcements about major changes surrounding it. Let's jump into it!
Every time I look at numbers related to domain searches, they stagger me. One of the stats I found particularly interesting was that of those 200k people monitoring domains, 23k of them were monitoring 2 or more domains. 8.5k were monitoring 3 or more. 4.6k were 4 or more and so on and so forth. The point being that there are a very large number of people monitoring multiple domains. In fact, 1k people are monitoring 9 or more and hundreds have gone through the manual verification process at least 2 dozen times.
To make life much, much easier on those folks monitoring multiple domains, they're now all bundled up into a centralised dashboard accessible from the existing Domain search link on the website. Because I already know who is monitoring which domains and the email address they're using for notifications, that same email address can be used to verify your identity and drop you straight into the dashboard. Here's mine:
One of the problems the dashboard approach helps tackle is unsubscribing on an individual domain basis. In the past, the only way to unsubscribe from domain notifications was to wait until one landed in your inbox then unsubscribe from every single monitored domain in one go. It was an all or nothing affair that nuked the lot of them whereas now, it's a domain-by-domain exercise.
Another problem this solves is how I respond to an often-received question: "Hey, can you tell me which domains I'm currently subscribed to". Uh, the ones you verified? Like, possibly almost a decade ag... ah, yeah, that's a poor answer! The dashboard now makes the answer crystal clear.
And finally, another massive problem it helps tackle is verification, and that brings me to the second big announcement:
I originally introduced domain searches to HIBP only 6 weeks after the project first launched. Up until this week, it functioned exactly the same way for almost a decade: plug in a domain name, verify control of it then see the results. Each and every time. What it meant is that if you wanted to search a domain, you successfully demonstrated control then you came back later and tried to search it again, you had to go back through the same process:
You'd be surprised at how many emails I get about the difficulty this poses. We don't have any of those 4 aliases on our domain. We can't add a meta tag. We can't upload a file. We can't touch DNS. It leaves me prone to asking "well do you really have control of the domain?" Thing is, "control" is a bit of a nuanced term; there are many people in roles where they don't have access to any of the above means of verification but they're legitimately responsible for infosec and responding to precisely the sorts of notifications HIBP sends out after a breach. Usually in these cases they can get support to go through the verification process, but it involves formal internal processes, ticketing, documentation and having to explain to some IT ops person why a data breach website with a funny name needs one of the above things to happen. This doesn't fix the pain of doing it once, but it does mean that it's now a one-off pain.
As the popularity of HIBP and domain searches has grown over the years, another challenge has emerged. Let me illustrate by example: in January this year, I loaded a rather large breach into HIBP:
New scraped data: Twitter had over 200M accounts scraped from a vulnerable API in 2021. Email addresses were passed in and Twitter profiles returned. 98% were already in @haveibeenpwned. Read more: https://t.co/FRBDFk3nkp
— Have I Been Pwned (@haveibeenpwned) January 5, 2023
That's a sizeable whack of data, in fact it was the 14th largest in HIBP out of the existing 644 in there at the time. It also had a massive impact on HIBP subscribers; I sent over 1 million emails to individuals using the notification service which made it the single largest corpus of notification emails we'd ever sent by a significant margin. But further, I also sent 60,851 emails to people monitoring domains. And that's when this started happening:
6 minutes later...
And so on and so forth until my inbox looked like this:
This was Azure auto-scale doing its thing and it was one of the early attractions for me building HIBP on Microsoft's PaaS offering way back in 2013. Need more resources? Just add more cloud! Job done, next problem. Except there are 2 major drawbacks with this:
Domain searches were actually one of the last remaining remnants of a resource intensive process still running on PaaS; most of the other important bits (namely email address searches and Pwned Password's k-anonymity searches) had been on Azure Functions for ages. Functions are awesome as they're "serverless" (except for the servers they run on, but don't let me get in the marketing team's way here), in that you're never deploying large logical containers of compute like with auto-scale so that solves problem 1 above.
As of now, all domain searches run on Azure Functions. There's literally no domain search logic remaining in the Azure App Service PaaS model, it's all gone. That moves things over to much more scalable infrastructure and massively reduces the likelihood of a timeout when searching a larger domain.
I didn't just want to ship a model from years ago and reproduce all the assumptions of the day, so I made a bunch of tweaks to further optimise things. These are all things that benefit both those searching domains and me running the platform as they reduce overhead on everyone.
For example, there was no point searching for a domain then listing every alias on it "@domain.com" so now you'll just see "alias@" instead. Doesn't sound like a lot, but imagine a domain with tens of thousands of results and then a heap of orgs running searches on them. More data equals more processing equals more egress bandwidth equals more latency and more cost. (Sidenote: if you're wondering "how costly can a bit of bandwidth really be", read my post from last year on How I Got Pwned by My Cloud Costs.)
The same logic extended to exporting the domain search results in Excel or JSON format - strip out the redundant data. I went even harder on the JSON front as this format is primarily used for ingestion into other apps where there's a large amount of programmatic control. So, rather than returning a heap of redundant breach metadata over and over again, now each alias just lists the name of the breach and you can match that up to the data from the breaches API. To be clear, the domain search JSON format itself was never an "API"; it wasn't designed for programmatic consumption, it required manual verification first and I set no expectation of stability. That's something that will change soon - there'll be a proper API - but I'll come back to that at the end of this post.
Something else I've been working away on in the background is to better leverage Cloudflare's WAF to minimise the impact on the origin services. For example, last week I did a thread on blocking 401 and excessive 428 responses at the edge rather than having to process them (and pay to process them) at the origin. I've been using similar logic to keep some, well, let's just call it "very excessive" domain queries under control. For example, one particular domain was searched 140 times after a breach was loaded in April, followed by another 40 times immediately after a breach the following month:
Clearly, this is just unnecessary. Remember how domain searches are a resource intensive process that hits my bottom line pretty hard? Yeah, well, not any more!
And finally on the performance front, if you were previously monitoring multiple domains and you got a breach alert, you could run a single search that bundled all the results in together. You reckon searching for one domain can be resource intensive? Try throwing a bunch of them into the one search! As the system grew and grew, this model became increasingly hard to sustain and equally, it became increasingly noisy. So now, exactly the same domains can be searched one by one which breaks the processing down into smaller, more manageable units. Hey, wouldn't it be great to have an API around that so you could just automate the entire thing? Read on!
All these tweaks along with the move to Azure Functions has made a massive difference to the performance problem mentioned earlier, but another problem remains: I'm still paying for your domain searches. Azure Functions are charged based on a combination of how long they run for and how many resources they consume. Both those factors are extraordinarily small for individual email address searches, but they're not for domain searches. That's why soon, the largest users of the service are going to see a small fee.
Pick a brand. A big brand. If I was to bet you that either the brand directly or its parent company has used the HIBP domain search feature in the past, I'd win. I wouldn't win every bet, but I'd come out on top over a bunch of them and I know this because I have the data to be confident of my odds 🙂
Knowing which big brands use which domains for their email is actually a hard metric to define:
Anyone know where I can find a list of the Fortune 500’s domains used for email accounts? There may be more than 1 per company and it may be different to their primary website.
— Troy Hunt (@troyhunt) January 15, 2023
But by cobbling enough OSINT data together, I was able to confidently demonstrate that more than half the Fortune 500 have used this service and the vast majority of those continue to do so via ongoing domain monitoring. That's awesome! And that pattern extends all the way down to much more localised brands too; My bank. My telco. My supermarket. All sorts of commercial organisations running businesses and using data sourced from HIBP to help them do so.
I started analysing the metrics back at that tweet in Jan, just the week after all the domain searches following the scraped Twitter data going into HIBP. For the last 5 months, I've been trawling through the usage patterns and watching how organisations are using the service. I also paid a lot of attention to the reactions following the change in rate limits and annual billing for the public API that enables email address searches last Nov. That's now given me a pretty good sense of how to structure a commercial domain search model. It's not final yet, but I do hope to put the finishing touches on it next month and in the interim, welcome feedback on the high-level overview of how it'll work that I'll list here in point form:
That last point in particular is hotly requested and as of a couple of months ago, already under development:
UserVoice suggestion for @haveibeenpwned to add domain search capability to the API now started! Follow along, vote and subscribe to updates here: https://t.co/Z32eC0d9nb
— Troy Hunt (@troyhunt) April 20, 2023
I'm still working through the mechanics of all this, both technically and commercially. One part of that is looking at raw numbers, for example about half of all the domains being monitored have 10 or less breached accounts on them. These aren't commercial entities of any scale and whilst I'm not saying "10 is the free tier number", clearly there are a massive number of domains that are tiny and shouldn't be at all impacted by this.
To be honest, the experience with the public API keys has taught me that it's usually not money that's the barrier to using commercial services, it's corporate procurement bureaucracy. Onboarding documentation. Vendor assessments. Tax forms. All sorts of things that demand hours of our time, often for the sake of only $3.50 per month. So we politely decline 😊 I know that will be an issue, in fact I suspect it will be the issue and a lot of the work we've been doing this year is to try and ease that pain to the fullest extent possible. I'll talk more about that once things finally launch but for now, that's the direction we're heading and the sorts of issues we're tackling in preparation.
As we approach the 10th birthday of HIBP later this year, it's hard not to look back and reflect. So much has changed in that time, yet the service still feels very much like what it was on day 1. The challenge for me over this time has been to work out how to adapt to the changes whilst keeping true to the original intent of service. Nothing has happened quickly in that regard, and the transparent fashion in which I've chosen to run HIBP has made the rationale for any change very clear to everyone. Even this blog post has been 5 months in the making, gradually evolving to reflect my thinking on the issues until I was confident enough in the path forward.
Go and use the new dashboard. Give it a good run and let me know what you think as I'm sure there are many things we can do better. And do provide your feedback on the both the changes announced here and those to come regarding the commercial tiers too, the more input we get on this the better equipped we are to make good decisions.
It’s not often that a zero-day vulnerability causes a network security vendor to urge customers to physically remove and decommission an entire line of affected hardware — as opposed to just applying software updates. But experts say that is exactly what transpired this week with Barracuda Networks, as the company struggled to combat a sprawling malware threat which appears to have undermined its email security appliances in such a fundamental way that they can no longer be safely updated with software fixes.
The Barracuda Email Security Gateway (ESG) 900 appliance.
Campbell, Calif. based Barracuda said it hired incident response firm Mandiant on May 18 after receiving reports about unusual traffic originating from its Email Security Gateway (ESG) devices, which are designed to sit at the edge of an organization’s network and scan all incoming and outgoing email for malware.
On May 19, Barracuda identified that the malicious traffic was taking advantage of a previously unknown vulnerability in its ESG appliances, and on May 20 the company pushed a patch for the flaw to all affected appliances (CVE-2023-2868).
In its security advisory, Barracuda said the vulnerability existed in the Barracuda software component responsible for screening attachments for malware. More alarmingly, the company said it appears attackers first started exploiting the flaw in October 2022.
But on June 6, Barracuda suddenly began urging its ESG customers to wholesale rip out and replace — not patch — affected appliances.
“Impacted ESG appliances must be immediately replaced regardless of patch version level,” the company’s advisory warned. “Barracuda’s recommendation at this time is full replacement of the impacted ESG.”
In a statement, Barracuda said it will be providing the replacement product to impacted customers at no cost, and that not all ESG appliances were compromised.
“No other Barracuda product, including our SaaS email solutions, were impacted by this vulnerability,” the company said. “If an ESG appliance is displaying a notification in the User Interface, the ESG appliance had indicators of compromise. If no notification is displayed, we have no reason to believe that the appliance has been compromised at this time.”
Nevertheless, the statement says that “out of an abundance of caution and in furtherance of our containment strategy, we recommend impacted customers replace their compromised appliance.”
“As of June 8, 2023, approximately 5% of active ESG appliances worldwide have shown any evidence of known indicators of compromise due to the vulnerability,” the statement continues. “Despite deployment of additional patches based on known IOCs, we continue to see evidence of ongoing malware activity on a subset of the compromised appliances. Therefore, we would like customers to replace any compromised appliance with a new unaffected device.”
Rapid7‘s Caitlin Condon called this remarkable turn of events “fairly stunning,” and said there appear to be roughly 11,000 vulnerable ESG devices still connected to the Internet worldwide.
“The pivot from patch to total replacement of affected devices is fairly stunning and implies the malware the threat actors deployed somehow achieves persistence at a low enough level that even wiping the device wouldn’t eradicate attacker access,” Condon wrote.
Barracuda said the malware was identified on a subset of appliances that allowed the attackers persistent backdoor access to the devices, and that evidence of data exfiltration was identified on some systems.
Rapid7 said it has seen no evidence that attackers are using the flaw to move laterally within victim networks. But that may be small consolation for Barracuda customers now coming to terms with the notion that foreign cyberspies probably have been hoovering up all their email for months.
Nicholas Weaver, a researcher at University of California, Berkeley’s International Computer Science Institute (ICSI), said it is likely that the malware was able to corrupt the underlying firmware that powers the ESG devices in some irreparable way.
“One of the goals of malware is to be hard to remove, and this suggests the malware compromised the firmware itself to make it really hard to remove and really stealthy,” Weaver said. “That’s not a ransomware actor, that’s a state actor. Why? Because a ransomware actor doesn’t care about that level of access. They don’t need it. If they’re going for data extortion, it’s more like a smash-and-grab. If they’re going for data ransoming, they’re encrypting the data itself — not the machines.”
In addition to replacing devices, Barracuda says ESG customers should also rotate any credentials connected to the appliance(s), and check for signs of compromise dating back to at least October 2022 using the network and endpoint indicators the company has released publicly.
Update, June 9, 11:55 a.m. ET: Barracuda has issued an updated statement about the incident, portions of which are now excerpted above.
Code-signing certificates are supposed to help authenticate the identity of software publishers, and provide cryptographic assurance that a signed piece of software has not been altered or tampered with. Both of these qualities make stolen or ill-gotten code-signing certificates attractive to cybercriminal groups, who prize their ability to add stealth and longevity to malicious software. This post is a deep dive on “Megatraffer,” a veteran Russian hacker who has practically cornered the underground market for malware focused code-signing certificates since 2015.
One of Megatraffer’s ads on an English-language cybercrime forum.
A review of Megatraffer’s posts on Russian crime forums shows this user began peddling individual stolen code-signing certs in 2015 on the Russian-language forum Exploit, and soon expanded to selling certificates for cryptographically signing applications and files designed to run in Microsoft Windows, Java, Adobe AIR, Mac and Microsoft Office.
Megatraffer explained that malware purveyors need a certificate because many antivirus products will be far more interested in unsigned software, and because signed files downloaded from the Internet don’t tend to get blocked by security features built into modern web browsers. Additionally, newer versions of Microsoft Windows will complain with a bright yellow or red alert message if users try to install a program that is not signed.
“Why do I need a certificate?” Megatraffer asked rhetorically in their Jan. 2016 sales thread on Exploit. “Antivirus software trusts signed programs more. For some types of software, a digital signature is mandatory.”
At the time, Megatraffer was selling unique code-signing certificates for $700 apiece, and charging more than twice that amount ($1,900) for an “extended validation” or EV code-signing cert, which is supposed to only come with additional identity vetting of the certificate holder. According to Megatraffer, EV certificates were a “must-have” if you wanted to sign malicious software or hardware drivers that would reliably work in newer Windows operating systems.
Part of Megatraffer’s ad. Image: Ke-la.com.
Megatraffer has continued to offer their code-signing services across more than a half-dozen other Russian-language cybercrime forums, mostly in the form of sporadically available EV and non-EV code-signing certificates from major vendors like Thawte and Comodo.
More recently, it appears Megatraffer has been working with ransomware groups to help improve the stealth of their malware. Shortly after Russia invaded Ukraine in February 2022, someone leaked several years of internal chat logs from the Conti ransomware gang, and those logs show Megatraffer was working with the group to help code-sign their malware between July and October 2020.
According to cyber intelligence firm Intel 471, Megatraffer has been active on more than a half-dozen crime forums from September 2009 to the present day. And on most of these identities, Megatraffer has used the email address 774748@gmail.com. That same email address also is tied to two forum accounts for a user with the handle “O.R.Z.”
Constella Intelligence, a company that tracks exposed databases, finds that 774748@gmail.com was used in connection with just a handful of passwords, but most frequently the password “featar24“. Pivoting off of that password reveals a handful of email addresses, including akafitis@gmail.com.
Intel 471 shows akafitis@gmail.com was used to register another O.R.Z. user account — this one on Verified[.]ru in 2008. Prior to that, akafitis@gmail.com was used as the email address for the account “Fitis,” which was active on Exploit between September 2006 and May 2007. Constella found the password “featar24” also was used in conjunction with the email address spampage@yandex.ru, which is tied to yet another O.R.Z. account on Carder[.]su from 2008.
The email address akafitis@gmail.com was used to create a Livejournal blog profile named Fitis that has a large bear as its avatar. In November 2009, Fitis wrote, “I am the perfect criminal. My fingerprints change beyond recognition every few days. At least my laptop is sure of it.”
Fitis’s Livejournal account. Image: Archive.org.
Fitis’s real-life identity was exposed in 2010 after two of the biggest sponsors of pharmaceutical spam went to war with each other, and large volumes of internal documents, emails and chat records seized from both spam empires were leaked to this author. That protracted and public conflict formed the backdrop of my 2014 book — “Spam Nation: The Inside Story of Organized Cybercrime, from Global Epidemic to Your Front Door.”
One of the leaked documents included a Microsoft Excel spreadsheet containing the real names, addresses, phone numbers, emails, street addresses and WebMoney addresses for dozens of top earners in Spamit — at the time the most successful pharmaceutical spam affiliate program in the Russian hacking scene and one that employed most of the top Russian botmasters.
That document shows Fitis was one of Spamit’s most prolific recruiters, bringing more than 75 affiliates to the Spamit program over several years prior to its implosion in 2010 (and earning commissions on any future sales from all 75 affiliates).
The document also says Fitis got paid using a WebMoney account that was created when its owner presented a valid Russian passport for a Konstantin Evgenievich Fetisov, born Nov. 16, 1982 and residing in Moscow. Russian motor vehicle records show two different vehicles are registered to this person at the same Moscow address.
The most interesting domain name registered to the email address spampage@yahoo.com, fittingly enough, is fitis[.]ru, which DomainTools.com says was registered in 2005 to a Konstantin E. Fetisov from Moscow.
The Wayback Machine at archive.org has a handful of mostly blank pages indexed for fitis[.]ru in its early years, but for a brief period in 2007 it appears this website was inadvertently exposing all of its file directories to the Internet.
One of the exposed files — Glavmed.html — is a general invitation to the infamous Glavmed pharmacy affiliate program, a now-defunct scheme that paid tens of millions of dollars to affiliates who advertised online pill shops mainly by hacking websites and manipulating search engine results. Glavmed was operated by the same Russian cybercriminals who ran the Spamit program.
A Google translated ad circa 2007 recruiting for the pharmacy affiliate program Glavmed, which told interested applicants to contact the ICQ number used by Fitis, a.k.a. MegaTraffer. Image: Archive.org.
Archive.org shows the fitis[.]ru webpage with the Glavmed invitation was continuously updated with new invite codes. In their message to would-be Glavmed affiliates, the program administrator asked applicants to contact them at the ICQ number 165540027, which Intel 471 found was an instant messenger address previously used by Fitis on Exploit.
The exposed files in the archived version of fitis[.]ru include source code for malicious software, lists of compromised websites used for pharmacy spam, and a handful of what are apparently personal files and photos. Among the photos is a 2007 image labeled merely “fitis.jpg,” which shows a bespectacled, bearded young man with a ponytail standing next to what appears to be a newly-married couple at a wedding ceremony.
Mr. Fetisov did not respond to requests for comment.
As a veteran organizer of affiliate programs, Fitis did not waste much time building a new moneymaking collective after Spamit closed up shop. New York City-based cyber intelligence firm Flashpoint found that Megatraffer’s ICQ was the contact number for Himba[.]ru, a cost-per-acquisition (CPA) program launched in 2012 that paid handsomely for completed application forms tied to a variety of financial instruments, including consumer credit cards, insurance policies, and loans.
“Megatraffer’s entrenched presence on cybercrime forums strongly suggests that malicious means are used to source at least a portion of traffic delivered to HIMBA’s advertisers,” Flashpoint observed in a threat report on the actor.
Intel 471 finds that Himba was an active affiliate program until around May 2019, when it stopping paying its associates.
Fitis’s Himba affiliate program, circa February 2014. Image: Archive.org.
Flashpoint notes that in September 2015, Megatraffer posted a job ad on Exploit seeking experienced coders to work on browser plugins, installers and “loaders” — basically remote access trojans (RATs) that establish communication between the attacker and a compromised system.
“The actor specified that he is looking for full-time, onsite help either in his Moscow or Kiev locations,” Flashpoint wrote.
A number of Discord communities focused on cryptocurrency have been hacked this past month after their administrators were tricked into running malicious Javascript code disguised as a Web browser bookmark.
This attack involves malicious Javascript that is added to one’s browser by dragging a component from a web page to one’s browser bookmarks.
According to interviews with victims, several of the attacks began with an interview request from someone posing as a reporter for a crypto-focused news outlet online. Those who take the bait are sent a link to a Discord server that appears to be the official Discord of the crypto news site, where they are asked to complete a verification step to validate their identity.
As shown in this Youtube video, the verification process involves dragging a button from the phony crypto news Discord server to the bookmarks bar in one’s Web browser. From there, the visitor is instructed to go back to discord.com and then click the new bookmark to complete the verification process.
However, the bookmark is actually a clever snippet of Javascript that quietly grabs the user’s Discord token and sends it to the scammer’s website. The attacker then loads the stolen token into their own browser session and (usually late at night after the admins are asleep) posts an announcement in the targeted Discord about an exclusive “airdrop,” “NFT mint event” or some other potential money making opportunity for the Discord members.
The unsuspecting Discord members click the link provided by the compromised administrator account, and are asked to connect their crypto wallet to the scammer’s site, where it asks for unlimited spend approvals on their tokens, and subsequently drains the balance of any valuable accounts.
Meanwhile, anyone in the compromised Discord channel who notices the scam and replies is banned, and their messages are deleted by the compromised admin account.
Nicholas Scavuzzo is an associate at Ocean Protocol, which describes itself as an “open-source protocol that aims to allow businesses and individuals to exchange and monetize data and data-based services.” On May 22, an administrator for Ocean Protocol’s Discord server clicked a link in a direct message from a community member that prompted them to prove their identity by dragging a link to their bookmarks.
Scavuzzo, who is based in Maine, said the attackers waited until around midnight in his timezone time before using the administrator’s account to send out an unauthorized message about a new Ocean airdrop.
Scavuzzo said the administrator’s account was hijacked even though she had multi-factor authentication turned on.
“A CAPTCHA bot that allows Discord cookies to be accessed by the person hosting the CAPTCHA,” was how Scavuzzo described the attack. “I’ve seen all kinds of crypto scams, but I’ve never seen one like this.”
In this conversation, “Ana | Ocean” is a compromised Discord server administrator account promoting a phony airdrop.
Importantly, the stolen token only works for the attackers as long as its rightful owner doesn’t log out and back in, or else change their credentials.
Assuming the administrator can log in, that is. In Ocean’s case, one of the first things the intruders did once they swiped the administrator’s token was change the server’s access controls and remove all core Ocean team members from the server.
Fortunately for Ocean, Scavuzzo was able to reach the operator of the server that hosts the Discord channel, and have the channel’s settings reverted back to normal.
“Thankfully, we are a globally distributed team, so we have people awake at all hours,” Scavuzzo said, noting that Ocean is not aware of any Discord community members who fell for the phony airdrop offer, which was live for about 30 minutes. “This could have been a lot worse.”
On May 26, Aura Network reported on Twitter that its Discord server was compromised in a phishing attack that resulted in the deletion of Discord channels and the dissemination of fake Aura Network Airdrop Campaign links.
On May 27, Nahmii — a cryptocurrency technology based on the Ethereum blockchain — warned on Twitter that one of its community moderators on Discord was compromised and posting fake airdrop details.
On May 9, MetrixCoin reported that its Discord server was hacked, with fake airdrop details pushed to all users.
KrebsOnSecurity recently heard from a trusted source in the cybersecurity industry who dealt firsthand with one of these attacks and asked to remain anonymous.
“I do pro bono Discord security work for a few Discords, and I was approached by one of these fake journalists,” the source said. “I played along and got the link to their Discord, where they were pretending to be journalists from the Cryptonews website using several accounts.”
The source took note of all the Discord IDs of the admins of the fake Cryptonews Discord, so that he could ensure they were blocked from the Discords he helps to secure.
“Since I’ve been doing this for a while now, I’ve built up a substantial database of Discord users and messages, so often I can see these scammers’ history on Discord,” the source said.
In this case, he noticed a user with the “CEO” role in the fake Cryptonews Discord had been seen previously under another username — “Levatax.” Searching on that Discord ID and username revealed a young Turkish coder named Berk Yilmaz whose Github page linked to the very same Discord ID as the scammer CEO.
Reached via instant message on Telegram, Levatax said he’s had no involvement in such schemes, and that he hasn’t been on Discord since his Microsoft Outlook account was hacked months ago.
“The interesting thing [is] that I didn’t use Discord since few months or even social media because of the political status of Turkey,” Levatax explained, referring to the recent election in his country. “The only thing I confirm is losing my Outlook account which connected to my Discord, and I’m already in touch with Microsoft to recover it.”
The verification method used in the above scam involves a type of bookmark called a “bookmarklet” that stores Javascript code as a clickable link in the bookmarks bar at the top of one’s browser.
While bookmarklets can be useful and harmless, malicious Javascript that is executed in the browser by the user is especially dangerous. So please avoid adding (or dragging) any bookmarks or bookmarklets to your browser unless it was your idea in the first place.
The number of phishing websites tied to domain name registrar Freenom dropped precipitously in the months surrounding a recent lawsuit from social networking giant Meta, which alleged the free domain name provider has a long history of ignoring abuse complaints about phishing websites while monetizing traffic to those abusive domains.
The volume of phishing websites registered through Freenom dropped considerably since the registrar was sued by Meta. Image: Interisle Consulting.
Freenom is the domain name registry service provider for five so-called “country code top level domains” (ccTLDs), including .cf for the Central African Republic; .ga for Gabon; .gq for Equatorial Guinea; .ml for Mali; and .tk for Tokelau.
Freenom has always waived the registration fees for domains in these country-code domains, but the registrar also reserves the right to take back free domains at any time, and to divert traffic to other sites — including adult websites. And there are countless reports from Freenom users who’ve seen free domains removed from their control and forwarded to other websites.
By the time Meta initially filed its lawsuit in December 2022, Freenom was the source of well more than half of all new phishing domains coming from country-code top-level domains. Meta initially asked a court to seal its case against Freenom, but that request was denied. Meta withdrew its December 2022 lawsuit and re-filed it in March 2023.
“The five ccTLDs to which Freenom provides its services are the TLDs of choice for cybercriminals because Freenom provides free domain name registration services and shields its customers’ identity, even after being presented with evidence that the domain names are being used for illegal purposes,” Meta’s complaint charged. “Even after receiving notices of infringement or phishing by its customers, Freenom continues to license new infringing domain names to those same customers.”
Meta pointed to research from Interisle Consulting Group, which discovered in 2021 and again last year that the five ccTLDs operated by Freenom made up half of the Top Ten TLDs most abused by phishers.
Interisle partner Dave Piscitello said something remarkable has happened in the months since the Meta lawsuit.
“We’ve observed a significant decline in phishing domains reported in the Freenom commercialized ccTLDs in months surrounding the lawsuit,” Piscitello wrote on Mastodon. “Responsible for over 60% of phishing domains reported in November 2022, Freenom’s percentage has dropped to under 15%.”
Interisle collects data from 12 major blocklists for spam, malware, and phishing, and it receives phishing-specific data from Spamhaus, Phishtank, OpenPhish and the APWG Ecrime Exchange. The company publishes historical data sets quarterly, both on malware and phishing.
Piscitello said it’s too soon to tell the full impact of the Freenom lawsuit, noting that Interisle’s sources of spam and phishing data all have different policies about when domains are removed from their block lists.
“One of the things we don’t have visibility into is how each of the blocklists determine to remove a URL from their lists,” he said. “Some of them time out [listed domains] after 14 days, some do it after 30, and some keep them forever.”
Freenom did not respond to requests for comment.
This is the second time in as many years that a lawsuit by Meta against a domain registrar has disrupted the phishing industry. In March 2020, Meta sued domain registrar giant Namecheap, alleging cybersquatting and trademark infringement.
The two parties settled the matter in April 2022. While the terms of that settlement have not been disclosed, new phishing domains registered through Namecheap declined more than 50 percent the following quarter, Interisle found.
Phishing attacks using websites registered through Namecheap, before and after the registrar settled a lawsuit with Meta. Image: Interisle Consulting.
Unfortunately, the lawsuits have had little effect on the overall number of phishing attacks and phishing-related domains, which have steadily increased in volume over the years. Piscitello said the phishers tend to gravitate toward registrars that offer the least resistance and lowest price per domain. And with new top-level domains constantly being introduced, there is rarely a shortage of super low-priced domains.
“The abuse of a new top-level domain is largely the result of one registrar’s portfolio,” Piscitello told KrebsOnSecurity. “Alibaba or Namecheap or another registrar will run a promotion for a cheap domain, and then we’ll see flocking and migration of the phishers to that TLD. It’s like strip mining, where they’ll buy hundreds or thousands of domains, use those in a campaign, exhaust that TLD and then move on to another provider.”
Piscitello said despite the steep drop in phishing domains coming out of Freenom, the alternatives available to phishers are many. After all, there are more than 2,000 accredited domain registrars, not to mention dozens of services that let anyone set up a website for free without even owning a domain.
“There is no evidence that the trend line is even going to level off,” he said. “I think what the Meta lawsuit tells us is that litigation is like giving someone a standing eight count. It temporarily disrupts a process. And in that sense, litigation appears to be working.”
A Russian man identified by KrebsOnSecurity in January 2022 as a prolific and vocal member of several top ransomware groups was the subject of two indictments unsealed by the Justice Department today. U.S. prosecutors say Mikhail Pavolovich Matveev, a.k.a. “Wazawaka” and “Boriselcin” worked with three different ransomware gangs that extorted hundreds of millions of dollars from companies, schools, hospitals and government agencies.
An FBI wanted poster for Matveev.
Indictments returned in New Jersey and the District of Columbia allege that Matveev was involved in a conspiracy to distribute ransomware from three different strains or affiliate groups, including Babuk, Hive and LockBit.
The indictments allege that on June 25, 2020, Matveev and his LockBit co-conspirators deployed LockBit ransomware against a law enforcement agency in Passaic County, New Jersey. Prosecutors say that on May 27, 2022, Matveev conspired with Hive to ransom a nonprofit behavioral healthcare organization headquartered in Mercer County, New Jersey. And on April 26, 2021, Matveev and his Babuk gang allegedly deployed ransomware against the Metropolitan Police Department in Washington, D.C.
Meanwhile, the U.S. Department of Treasury has added Matveev to its list of persons with whom it is illegal to transact financially. Also, the U.S. State Department is offering a $10 million reward for the capture and/or prosecution of Matveev, although he is unlikely to face either as long as he continues to reside in Russia.
In a January 2021 discussion on a top Russian cybercrime forum, Matveev’s alleged alter ego Wazawaka said he had no plans to leave the protection of “Mother Russia,” and that traveling abroad was not an option for him.
“Mother Russia will help you,” Wazawaka concluded. “Love your country, and you will always get away with everything.”
In January 2022, KrebsOnSecurity published Who is the Network Access Broker ‘Wazawaka,’ which followed clues from Wazawaka’s many pseudonyms and contact details on the Russian-language cybercrime forums back to a 33-year-old Mikhail Matveev from Abaza, RU (the FBI says his date of birth is Aug. 17, 1992).
A month after that story ran, a man who appeared identical to the social media photos for Matveev began posting on Twitter a series of bizarre selfie videos in which he lashed out at security journalists and researchers (including this author), while using the same Twitter account to drop exploit code for a widely-used virtual private networking (VPN) appliance.
“Hello Brian Krebs! You did a really great job actually, really well, fucking great — it’s great that journalism works so well in the US,” Matveev said in one of the videos. “By the way, it is my voice in the background, I just love myself a lot.”
Prosecutors allege Matveev used a dizzying stream of monikers on the cybercrime forums, including “Boriselcin,” a talkative and brash personality who was simultaneously the public persona of Babuk, a ransomware affiliate program that surfaced on New Year’s Eve 2020.
Previous reporting here revealed that Matveev’s alter egos included “Orange,” the founder of the RAMP ransomware forum. RAMP stands for “Ransom Anon Market Place, and analysts at the security firm Flashpoint say the forum was created “directly in response to several large Dark Web forums banning ransomware collectives on their site following the Colonial Pipeline attack by ransomware group ‘DarkSide.”
As noted in last year’s investigations into Matveev, his alleged cybercriminal handles all were driven by a uniquely communitarian view that when organizations being held for ransom decline to cooperate or pay up, any data stolen from the victim should be published on the Russian cybercrime forums for all to plunder — not privately sold to the highest bidder.
In thread after thread on the crime forum XSS, Matveev’s alleged alias “Uhodiransomwar” could be seen posting download links to databases from companies that have refused to negotiate after five days.
Matveev is charged with conspiring to transmit ransom demands, conspiring to damage protected computers, and intentionally damaging protected computers. If convicted, he faces more than 20 years in prison.
Further reading:
Who is the Network Access Broker “Wazawaka?”
The New Jersey indictment against Matveev (PDF)
The indictment from the U.S. attorney’s office in Washington, D.C. (PDF)
Countless smartphones seized in arrests and searches by police forces across the United States are being auctioned online without first having the data on them erased, a practice that can lead to crime victims being re-victimized, a new study found. In response, the largest online marketplace for items seized in U.S. law enforcement investigations says it now ensures that all phones sold through its platform will be data-wiped prior to auction.
Researchers at the University of Maryland last year purchased 228 smartphones sold “as-is” from PropertyRoom.com, which bills itself as the largest auction house for police departments in the United States. Of phones they won at auction (at an average of $18 per phone), the researchers found 49 had no PIN or passcode; they were able to guess an additional 11 of the PINs by using the top-40 most popular PIN or swipe patterns.
Phones may end up in police custody for any number of reasons — such as its owner was involved in identity theft — and in these cases the phone itself was used as a tool to commit the crime.
“We initially expected that police would never auction these phones, as they would enable the buyer to recommit the same crimes as the previous owner,” the researchers explained in a paper released this month. “Unfortunately, that expectation has proven false in practice.”
The researchers said while they could have employed more aggressive technological measures to work out more of the PINs for the remaining phones they bought, they concluded based on the sample that a great many of the devices they won at auction had probably not been data-wiped and were protected only by a PIN.
Beyond what you would expect from unwiped second hand phones — every text message, picture, email, browser history, location history, etc. — the 61 phones they were able to access also contained significant amounts of data pertaining to crime — including victims’ data — the researchers found.
Some readers may be wondering at this point, “Why should we care about what happens to a criminal’s phone?” First off, it’s not entirely clear how these phones ended up for sale on PropertyRoom.
“Some folks are like, ‘Yeah, whatever, these are criminal phones,’ but are they?” said Dave Levin, an assistant professor of computer science at University of Maryland.
“We started looking at state laws around what they’re supposed to do with lost or stolen property, and we found that most of it ends up going the same route as civil asset forfeiture,” Levin continued. “Meaning, if they can’t find out who owns something, it eventually becomes the property of the state and gets shipped out to these resellers.”
Also, the researchers found that many of the phones clearly had personal information on them regarding previous or intended targets of crime: A dozen of the phones had photographs of government-issued IDs. Three of those were on phones that apparently belonged to sex workers; their phones contained communications with clients.
An overview of the phone functionality and data accessibility for phones purchased by the researchers.
One phone had full credit files for eight different people on it. On another device they found a screenshot including 11 stolen credit cards that were apparently purchased from an online carding shop. On yet another, the former owner had apparently been active in a Telegram group chat that sold tutorials on how to run identity theft scams.
The most interesting phone from the batches they bought at auction was one with a sticky note attached that included the device’s PIN and the notation “Gry Keyed,” no doubt a reference to the Graykey software that is often used by law enforcement agencies to brute-force a mobile device PIN.
“That one had the PIN on the back,” Levin said. “The message chain on that phone had 24 Experian and TransUnion credit histories”.
The University of Maryland team said they took care in their research not to further the victimization of people whose information was on the devices they purchased from PropertyRoom.com. That involved ensuring that none of the devices could connect to the Internet when powered on, and scanning all images on the devices against known hashes for child sexual abuse material.
It is common to find phones and other electronics for sale on auction platforms like eBay that have not been wiped of sensitive data, but in those cases eBay doesn’t possess the items being sold. In contrast, platforms like PropertyRoom obtain devices and resell them at auction directly.
PropertyRoom did not respond to multiple requests for comment. But the researchers said sometime in the past few months PropertyRoom began posting a notice stating that all mobile devices would be wiped of their data before being sold at auction.
“We informed them of our research in October 2022, and they responded that they would review our findings internally,” Levin said. “They stopped selling them for a while, but then it slowly came back, and then we made sure we won every auction. And all of the ones we got from that were indeed wiped, except there were four devices that had external SD [storage] cards in them that weren’t wiped.”
A copy of the University of Maryland study is here (PDF).
A quick summary first before the details: This week, the FBI in cooperation with international law enforcement partners took down a notorious marketplace trading in stolen identity data in an effort they've named "Operation Cookie Monster". They've provided millions of impacted email addresses and passwords to Have I Been Pwned (HIBP) so that victims of the incident can discover if they have been exposed. This breach has been flagged as "sensitive" which means it is not publicly searchable, rather you must demonstrate you control the email address being searched before the results are shown. This can be done via the free notification service on HIBP and involves you entering the email address then clicking on the link sent to your inbox. Specific guidance prepared by the FBI in conjunction with the Dutch police on further steps you can take to protect yourself are detailed at the end of this blog post on the gold background. That's the short version, here's the whole story:
Ever heard that saying about how "data is the new oil"? Or that "data is the currency of the digital economy"? You've probably seen stories and infographics about how much your personal information is worth, both to legitimate organisations and criminal networks. Like any valuable commodity, marketplaces selling data inevitably emerge, some operating as legal businesses and others, well, not so much. In its simplest form, the illegal data marketplace has long involved the exchange of currency for personal records containing attributes such as email addresses, passwords, names, etc. Cybercriminals then use this data for purposes ranging from identity theft to phishing attacks to credential stuffing. So, we (the good guys) adapt and build better defences. We block known breached passwords. We implement two factor authentication. We roll out user behavioural analytics that identifies abnormalities in logins (why is Joe suddenly logging in from the other side of the world with a new machine?) And in turn, the criminals adapt, which brings us to Genesis Market.
Until this week, Genesis had been up and running for 4 years. This is an excellent primer from Catalin Cimpanu, and it describes how in order to circumvent the aforementioned fraud protection measures, cybercriminals are increasingly relying on obtaining more abstract pieces of information from victims in order to gain access to their accounts. Rather than relying on the credentials themselves and then being subject to all the modern fraud detection services mentioned above, criminals instead began to trade in a combination of "fingerprints" and "cookies". The latter will be a familiar term to most people (and was obviously the inspiration for the name behind the FBI's operation), whilst the former refers to observable attributes of the user and their browser. To see a very easy demonstration of what fingerprinting involves, go and check out amiunique.org and hit the "View my browser fingerprint" button. You'll get something similar to this:
Among more than 1.6M sampled clients, nobody has the same fingerprint as me. Somehow, using the current version of Chrome on the current version of Windows, I am a unique snowflake. Why I'm so unique is partly explained by my time zone which is shared by less than half a percent of people, but it's when that's combined with the other observable fingerprint attributes that you realise just how special I really am. For example, less than 0.01% of people have a content language request header of "en-US,en,en-AU". Only 0.12% of people share a screen width of 5,120 pixel (I'm using an ultrawide monitor). And so on and so forth. Because they're so unique, fingerprints are increasingly used as a fraud detection method such that if a malicious party attempts to impersonate a legitimate users with otherwise correct attributes (for example, the correct cookies) but the wrong fingerprint, they're rejected. Which is why we now have IMPaaS.
There's an excellent IMPaaS explanation from the Eindhoven University of Technology in the Netherlands via a paper titled Impersonation-as-a-Service: Characterising the Emerging Criminal Infrastructure for User Impersonation at Scale. Released only a year and a half after the emergence of Genesis, the paper explains the mechanics of IMPaaS:
IMPaaS allows attackers to systematically collect and enforce user profiles (consisting of user credentials, cookies, device and behavioural fingerprints, and other metadata) to circumvent risk-based authentication system and effectively bypass multifactor authentication mechanisms
In other words, if you have all the bits of information a website requires to persist authenticated state after the login process has successfully completed (including after any 2FA requirements), you can perform a modern equivalent of session hijacking. Obtaining this level of information is typically done via malicious software running on the victim's machine which can then grab anything useful and send it off to a C2 server where it can then be sold and used to commit fraud (from the IMPaaS paper):
Catalin's story from the early days of Genesis showed how buyers could browse through a list of compromised victims and pick their target based on the various services they had authenticated too, along with their operating system and location. Pricing was inevitably based on the value of those services with the examples below going for $41.30 each (and just like a legitimate marketplace, these were marked down prices so a real bargain!)
To make things as turn-key as possible for the criminals, buyers would then run a browser extension from Genesis that would reconstruct the required fingerprint based on the information the malware had obtained and grant them access to the victims' accounts (I'm having flashbacks of Firesheep here). It was that simple... until this week. As of now, the following banner greets anyone browsing to the Genesis website:
The aptly named "Operation Cookie Monster" is a joint effort between the FBI and a coalition of law enforcement agencies across the globe who have now put an abrupt end to Genesis. I imagine they'll be having some "discussions" with those involved in running the service, but what about the individuals who are the victims? These are the people whose identities have been put up for sale, purchased by other criminals and then abused to their detriment. The FBI approached me and asked if HIBP could be used as a mechanism to help warn victims of their exposure in the same way as we'd previously done with the Emotet malware a couple of years ago. This is well aligned with the mantra of HIBP - to do good and constructive things with data breaches after they occur - and I was happy to provide support.
There are 2 separate things that have now been loaded into HIBP, each disassociated from the other:
The Pwned Passwords API is presently hit more than 4 billion times each month, and the downloadable data set is hit, well, I don't know because anyone can grab it run it offline. The point is that password corpuses loaded into HIBP have huge reach and are used by thousands of different online services to help people make better password choices. You're probably using it without even knowing it when you signup or login to various services but if you want to check it directly, you can browse to the web interface. (If you're worried about the privacy of your password, there's a full explainer on how the service preserves anonymity but I also suggest testing it after you've changed it as a generally good practice.)
The email address search is what HIBP is so well known for and that's obviously what will help you understand if you've been impacted. Per the opening paragraph, this breach is flagged as "sensitive" so you will not get a result when searching directly from the front page or via the API, rather you'll need to use the free notification service. This approach was chosen to avoid the risk of people being further targeted as a result of their inclusion in Genesis. All existing HIBP subscribers have been sent notification emails and between individuals and those monitoring domains, tens of thousands of emails have now been sent out. Whilst the volume of accounts represented is "8M", please note that this is merely an approximation (hence the perfectly round number on HIBP), intended to be an indicative representation of scale as many of the breached accounts didn't include email addresses. This number only represents the number of unique email addresses which showed up in the data set so consider it a subset of a much larger corpus.
Let me add some final context and this is important if you do find yourself in the Genesis data: due to the nature of how the malware collected personal information and the broad range of different services victims may have been using at the time, the exposed data can differ significantly person by person. What's been provided by the FBI is one set of passwords (incidentally, as SHA-1 and NTLM hash pairs fed into the law enforcement ingestion pipeline), one set of email addresses and a list of meta data. Beyond the data already listed here, the meta data includes names, physical addresses, phone numbers and full credit card details among other personal attributes. This does not mean that all impacted individuals had each of those data classes exposed. The hope is that by listing these fields it will help victims understand, for example, why they may have observed fraudulent transactions on their card, and they can then take informed and appropriate steps to better protect themselves.
Lastly, as flagged in the intro, following is the guidance prepared by the FBI and Dutch police on how people can safeguard themselves if they get a hit in the Genesis data or frankly, just want to better protect themselves in future:
The FBI reached out to Have I Been Pwned (HIBP) to continue sharing efforts to help victims determine if they've been victimized. In this instance, the data shared emanates from the Initial Access Broker Marketplace Genesis Market. The FBI has taken action against Genesis Market, and in the process has been able to extract victim information for the purposes of alerting victims.
In all, millions of passwords and email addresses were provided which span a wide range of countries and domains. These emails and passwords were sold on Genesis Market and were used by Genesis Market users to access the various accounts and platforms that were for sale.
Prepared in conjunction with the FBI, following is the recommended guidance for those that find themselves in this collection of data:
To safeguard yourself against fraud in the future, it is important that you immediately remove the malware from your computer and then change all your passwords. Do this as follows:
How can I prevent my data being stolen (again)?
Just one more thing to end on a lighter note: a quick shoutout to whoever at the bureau slipped a half-eaten cookie into the takedown image, having been munched on by what I can only assume is a very satisfied FBI agent after a successful "Operation Cookie Monster" 😊
John Clifton Davies, a 60-year-old con man from the United Kingdom who fled the country in 2015 before being sentenced to 12 years in prison for fraud, has enjoyed a successful life abroad swindling technology startups by pretending to be a billionaire investor. Davies’ newest invention appears to be “CodesToYou,” which purports to be a “full cycle software development company” based in the U.K.
The scam artist John Bernard a.k.a. Alan John Mykailov (left) in a recent Zoom call, and a mugshot of John Clifton Davies from nearly a decade earlier.
Several articles here have delved into the history of John Bernard, the pseudonym used by a fake billionaire technology investor who tricked dozens of startups into giving him tens of millions of dollars.
John Bernard’s real name is John Clifton Davies, a convicted fraudster from the United Kingdom who is currently a fugitive from justice. For several years until reinventing himself again quite recently, Bernard pretended to be a billionaire Swiss investor who made his fortunes in the dot-com boom 20 years ago.
“The Private Office of John Bernard” let it be known to investment brokers that he had tens of millions of dollars to invest in tech startups, and he attracted a stream of new victims by offering extraordinarily generous finder’s fees to brokers who helped him secure new clients. But those brokers would eventually get stiffed because Bernard’s company would never consummate a deal.
John Bernard’s former website, where he pretended to be a billionaire tech investor.
Bernard would promise to invest millions in tech startups, and then insist that companies pay tens of thousands of dollars worth of due diligence fees up front. However, the due diligence company he insisted on using — another Swiss firm called The Inside Knowledge GmbH — also was secretly owned by Bernard, who would invariably pull out of the deal after receiving the due diligence money.
A variety of clues suggest Davies has recently adopted at least one other identity — Alan John Mykhailov — who is listed as chairman of a British concern called CodesToYou LTD, incorporated in May 2022. The CodesToYou website says the company employs talented coders in several countries, and that its programmers offer “your ultimate balance between speed, cost and quality.”
The team from CodesToYou.
In response to questions from KrebsOnSecurity, CodesToYou’s marketing manager — who gave their name only as “Zhena” — said the company was not affiliated with any John Bernard or John Clifton Davies, and maintained that CodesToYou is a legitimate enterprise.
But publicly available information about this company and its leadership suggests otherwise. Official incorporation documents from the U.K.’s Companies House represent that CodesToYou is headed by an Alan John Mykhailov, a British citizen born in March 1958.
Companies House says Mykhailov is an officer in three other companies, including one called Blackstone Corporate Alliance Ltd. According to the Swiss business tracking service business-monitor.ch, Blackstone Corporate Alliance Ltd. is currently the entity holding a decision-making role in John Bernard’s fake due diligence company — The Inside Knowledge GmbH — which is now in liquidation.
A screen shot of the stock photos and corporate-speak on John Bernard’s old website. Image: Archive.org
Also listed as a partner in Blackstone Corporate Alliance Limited is Igor Hubskyi (a.k.a. Igor Gubskyi), a Ukrainian man who was previously president of The Inside Knowledge GmbH.
The CodesToYou website says the company’s marketing team lead is Maria Yakovleva, and the photo of this employee matches the profile for the LinkedIn account name “Maria Y.” That same LinkedIn profile and photo previously listed Maria by a different first and last name — Mariya Kulikova; back then, Ms. Kulikova’s LinkedIn profile said she was an executive assistant in The Private Office of Mr. John Bernard.
Companies House lists Alan John Mykhailov as a current officer in two other companies, including Frisor Limited, and Ardelis Solutions Limited. A cached copy of the now-defunct Ardelis Solutions website says it was a private equity firm.
CodesToYou’s Maria also included Ardelis Solutions in the work history section of her LinkedIn resume. That is, until being contacted by this author on LinkedIn, after which Maria’s profile picture and any mention of Ardelis Solutions were deleted.
Listed as head of business development at CodesToYou is David Bruno, a Canadian man whose LinkedIn profile says he is founder of an organization called “World Privacy Resource.” As KrebsOnSecurity reported in 2020, Bruno was at the time promoting himself as the co-CEO of a company called SafeSwiss Secure Communication AG, and the founder of another tech startup called Secure Swiss Data.
Secure Swiss Data’s domain — secureswissdata.com — is a Swiss concern that sells encrypted email and data services. According to DomainTools.com, that website name was registered in 2015 by The Inside Knowledge GmbH. In February 2020, a press release announced that Secure Swiss Data was purchased in an “undisclosed multimillion buyout” by SafeSwiss Secure Communication AG.
A cached copy of the Ardelis Solutions website, which said it was a private equity firm and included similar stock images as John Bernard’s investment website.
When reached in 2020 and asked about his relationship to Mr. Bernard, Mr. Bruno said the two were business partners and that he couldn’t imagine that Mr. Bernard would be involved in anything improper. To this day Mr. Bruno is the only person I’ve spoken to who has had anything positive to say about Mr. Bernard.
Mr. Bruno did not respond to requests for comment this time around, but his LinkedIn profile no longer makes any mention of Secure Swiss Data or SafeSwiss — both companies he claimed to run for many years. Nor does it mention CodesToYou. However, Mr. Bruno’s former company SafeSwiss is listed as one of the six “portfolio” companies whose services are promoted on the CodesToYou website.
In mid-2021, Bruno announced he was running for public office in Ontario.
“The Kenora resident is no stranger to the government as he contributed to Canada’s new Digital Charter, Bill C-11, which is a new Cyber Security policy,” reported Drydennow.com, a news website that covers Northwestern Ontario. Drydennow says the next federal election is expected to be held on or before Oct. 16, 2023.
John Clifton Davies was convicted in 2015 of swindling businesses throughout the U.K. that were struggling financially and seeking to restructure their debt. For roughly six years, Davies ran a series of firms that pretended to offer insolvency services, but instead simply siphoned what little remaining money these companies had.
The very first entity mentioned in the technology portfolio advertised on the CodesToYou website is called “MySolve,” and it purports to offer a “multi-feature platform for insolvency practitioners.”
Mr. Davies’ fourth wife, Iryna Davies, is listed as a director of one of the insolvency consulting businesses in the U.K. that was part of John Davies’ 2015 fraud conviction. Prior to his trial for fraud, Davies served 16 months in jail before being cleared of murdering his third wife on their honeymoon in India: Colette Davies, 39, died after falling 80 feet from a viewing point at a steep gorge in the Himachal Pradesh region of India.
Mr. Davies was charged with murder and fraud after he attempted to collect GBP 132,000 in her life insurance payout, but British prosecutors ultimately conceded they did not have enough evidence to convict him.
The scams favored by Davies and his alter egos are smart because he never approaches investors directly; rather, investors are incentivized to put his portfolio in front of tech firms seeking financial backing. And all the best cons begin as an idea or possibility planted in the target’s mind.
It’s also a reliable scam because companies bilked by small-time investment schemes rarely pursue legal action, mainly because the legal fees involved can quickly surpass the losses. On top of that, many victims will likely be too ashamed to admit their duping. Victims who do press their case in court and win then face the daunting challenge of collecting damages from a slew of ephemeral shell corporations.
The latest Bernard victim to speak publicly — a Norwegian company hoping to build a fleet of environmentally friendly shipping vessels — is now embroiled in a lawsuit over a deal gone bad. As part of that scam, Bernard falsely claimed to have secured $100 million from six other wealthy investors, including the founder of Uber and the artist Abel Makkonen Tesfaye, better known as The Weeknd.
If you liked this story, check out my previous reporting on John Bernard/Davies:
Due Diligence That Money Can’t Buy
Who is Tech Investor John Bernard?
Promising Infusions of Cash, Fake Investor John Bernard Walked Away With $30 Million
Investment Scammer John Davies Reinvents Himself?
Fake Investor John Bernard Sinks Norwegian Green Shipping Dreams
Related tags
Google says it has suspended the app for the Chinese e-commerce giant Pinduoduo after malware was found in versions of the software. The move comes just weeks after Chinese security researchers published an analysis suggesting the popular e-commerce app sought to seize total control over affected devices by exploiting multiple security vulnerabilities in a variety of Android-based smartphones.
In November 2022, researchers at Google’s Project Zero warned about active attacks on Samsung mobile phones which chained together three security vulnerabilities that Samsung patched in March 2021, and which would have allowed an app to add or read any files on the device.
Google said it believes the exploit chain for Samsung devices belonged to a “commercial surveillance vendor,” without elaborating further. The highly technical writeup also did not name the malicious app in question.
On Feb. 28, 2023, researchers at the Chinese security firm DarkNavy published a blog post purporting to show evidence that a major Chinese ecommerce company’s app was using this same three-exploit chain to read user data stored by other apps on the affected device, and to make its app nearly impossible to remove.
DarkNavy likewise did not name the app they said was responsible for the attacks. In fact, the researchers took care to redact the name of the app from multiple code screenshots published in their writeup. DarkNavy did not respond to requests for clarification.
“At present, a large number of end users have complained on multiple social platforms,” reads a translated version of the DarkNavy blog post. “The app has problems such as inexplicable installation, privacy leakage, and inability to uninstall.”
Update, March 27, 1:24 p.m. ET: Dan Goodin over at Ars Technica has an important update on this story that indicates the Pinduoduo code was exploiting a zero-day vulnerability in Android — not Samsung. From that piece:
“A preliminary analysis by Lookout found that at least two off-Play versions of Pinduoduo for Android exploited CVE-2023-20963, the tracking number for an Android vulnerability Google patched in updates that became available to end users two weeks ago. This privilege-escalation flaw, which was exploited prior to Google’s disclosure, allowed the app to perform operations with elevated privileges. The app used these privileges to download code from a developer-designated site and run it within a privileged environment.
“The malicious apps represent “a very sophisticated attack for an app-based malware,” Christoph Hebeisen, one of three Lookout researchers who analyzed the file, wrote in an email. “In recent years, exploits have not usually been seen in the context of mass-distributed apps. Given the extremely intrusive nature of such sophisticated app-based malware, this is an important threat mobile users need to protect against.”
On March 3, 2023, a denizen of the now-defunct cybercrime community BreachForums posted a thread which noted that a unique component of the malicious app code highlighted by DarkNavy also was found in the ecommerce application whose name was apparently redacted from the DarkNavy analysis: Pinduoduo.
A Mar. 3, 2023 post on BreachForums, comparing the redacted code from the DarkNavy analysis with the same function in the Pinduoduo app available for download at the time.
On March 4, 2023, e-commerce expert Liu Huafang posted on the Chinese social media network Weibo that Pinduoduo’s app was using security vulnerabilities to gain market share by stealing user data from its competitors. That Weibo post has since been deleted.
On March 7, the newly created Github account Davinci1010 published a technical analysis claiming that until recently Pinduoduo’s source code included a “backdoor,” a hacking term used to describe code that allows an adversary to remotely and secretly connect to a compromised system at will.
That analysis includes links to archived versions of Pinduoduo’s app released before March 5 (version 6.50 and lower), which is when Davinci1010 says a new version of the app removed the malicious code.
Pinduoduo has not yet responded to requests for comment. Pinduoduo parent company PDD Holdings told Reuters Google has not shared details about why it suspended the app.
The company told CNN that it strongly rejects “the speculation and accusation that Pinduoduo app is malicious just from a generic and non-conclusive response from Google,” and said there were “several apps that have been suspended from Google Play at the same time.”
Pinduoduo is among China’s most popular e-commerce platforms, boasting approximately 900 million monthly active users.
Most of the news coverage of Google’s move against Pinduoduo emphasizes that the malware was found in versions of the Pinduoduo app available outside of Google’s app store — Google Play.
“Off-Play versions of this app that have been found to contain malware have been enforced on via Google Play Protect,” a Google spokesperson said in a statement to Reuters, adding that the Play version of the app has been suspended for security concerns.
However, Google Play is not available to consumers in China. As a result, the app will still be available via other mobile app stores catering to the Chinese market — including those operated by Huawei, Oppo, Tencent and VIVO.
Google said its ban did not affect the PDD Holdings app Temu, which is an online shopping platform in the United States. According to The Washington Post, four of the Apple App Store’s 10 most-downloaded free apps are owned by Chinese companies, including Temu and the social media network TikTok.
The Pinduoduo suspension comes as lawmakers in Congress this week are gearing up to grill the CEO of TikTok over national security concerns. TikTok, which is owned by Beijing-based ByteDance, said last month that it now has roughly 150 million monthly active users in the United States.
A new cybersecurity strategy released earlier this month by the Biden administration singled out China as the greatest cyber threat to the U.S. and Western interests. The strategy says China now presents the “broadest, most active, and most persistent threat to both government and private sector networks,” and says China is “the only country with both the intent to reshape the international order and, increasingly, the economic, diplomatic, military, and technological power to do so.”
