Login
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.
Many things have changed since 2018, such as the names of the companies in the Fortune 100 list. But one aspect of that vaunted list that hasn’t shifted much since is that very few of these companies list any security professionals within their top executive ranks.
The next time you receive a breach notification letter that invariably says a company you trusted places a top priority on customer security and privacy, consider this: Only five of the Fortune 100 companies currently list a security professional in the executive leadership pages of their websites. This is largely unchanged from five of the Fortune 100 in 2018, the last time KrebsOnSecurity performed this analysis.
A review of the executives pages published by the 2022 list of Fortune 100 companies found only five — BestBuy, Cigna, Coca-Cola, Disney and Walmart — that listed a Chief Security Officer (CSO) or Chief Information Security Officer (CISO) in their highest corporate ranks.
One-third of last year’s Fortune 100 companies included a Chief Technology Officer (CTO) in their executive stables; 40 listed Chief Information Officer (CIO) roles, but just 21 included a Chief Risk Officer (CRO).
As I noted in 2018, this is not to say that 95 percent of the Fortune 100 companies don’t have a CISO or CSO in their employ: A review of LinkedIn suggests that most of them in fact do have people in those roles, and experts say some of the largest multinational companies will have multiple people in these positions.
But it is interesting to note which executive positions the top companies deem worth publishing in their executive leadership pages. For example, 88 percent listed a Director of Human Resources (or “Chief People Officer”), and 37 out of 100 included a Chief Marketing Officer.
Not that these roles are somehow more or less important than that of a CISO/CSO within the organization. Nor is the average pay hugely different among all these roles. Yet, considering how much marketing (think consumer/customer data) and human resources (think employee personal/financial data) are impacted by your average data breach, it’s somewhat remarkable that more companies don’t list their chief security personnel among their top ranks.
One likely explanation as to why a great many companies still don’t include their security leaders within their highest echelons is that these employees do not report directly to the company’s CEO, board of directors, or Chief Risk Officer.
The CSO or CISO position traditionally has reported to an executive in a technical role, such as the CTO or CIO. But workforce experts say placing the CISO/CSO on unequal footing with the organization’s top leaders makes it more likely that cybersecurity and risk concerns will take a backseat to initiatives designed to increase productivity and generally grow the business.
“Separation of duties is a fundamental concept of security, whether we’re talking about cyber threats, employee fraud, or physical theft,” said Tari Schreider, an analyst with Datos Insights. “But that critical separation is violated every day with the CISO or CSO reporting to the heads of technology.”
IANS, an organization geared toward CISOs/CSOs and their teams, surveyed more than 500 organizations last year and found roughly 65 percent of CISOs still report to a technical leader, such as the CTO or CIO: IANS found 46 percent of CISOs reported to a CIO, with 15 percent reporting directly to a CTO.
A survey last year by IANS found 65 percent of CISOs report to a tech function within organizations, such as the CTO or CIO. Image: IANS Research.
Schreider said one big reason many CISOs and CSOs aren’t listed in corporate executive biographies at major companies is that these positions often do not enjoy the same legal and insurance protections afforded to other officers within the company.
Typically, larger companies will purchase a “Directors and Officers” liability policy that covers legal expenses should one of the organization’s top executives find themselves dragged into court over some business failing on the part of their employer. But organizations that do not offer this coverage to their security leaders are unlikely to list those positions in their highest ranks, Schreider said.
“It’s frankly shocking,” Schreider said, upon hearing that only four of the Fortune 100 listed any security personnel in their top executive hierarchies. “If the company isn’t going to give them legal cover, then why give them the responsibility for security? Especially when CISOs and CSOs shouldn’t own the risk, yet the majority of them carry the mantle of responsibility and they tend to be scapegoats” when the organization eventually gets hacked, he said.
Schreider said while Datos Insights focuses mostly on the financial and insurance industries, a recent Datos survey echoes the IANS findings from last year. Datos surveyed 25 of the largest financial institutions by asset size (two of which are no longer in existence), and found just 22 percent of CSOs/CISOs reported to the CEO. A majority — 65 percent — had their CSOs/CISOs reporting to either a CTO or CIO.
“I’ve looked at these types of statistics for years and they’ve never really changed that much,” Schreider said. “The CISO or CSO is in the purview of the technical stack from a management perspective. Right, wrong or indifferent, that’s what’s happening.”
Earlier this year, IT consulting firm Accenture released results from surveying more than 3,000 respondents from 15 industries across 14 countries about their security maturity levels. Accenture found that only about one-third of the organizations they surveyed had enough security maturity under their belts to have integrated security into virtually every aspect of their businesses — and this includes having CISOs or CSOs report to someone in charge of overseeing risk for the business as a whole.
Not surprisingly, Accenture also found that only a third of respondents considered cybersecurity risk “to a great extent” when evaluating overall enterprise risk.
“This highlights there is still some way to go to make cybersecurity a proactive, strategic necessity within the business,” the report concluded.
One way of depicting the different stages of security maturity.
A spreadsheet tracking the prevalence of security leaders on the executive pages of the 2022 Fortune 100 firms is available here.
Update, July 23: Somehow overlooked Disney’s CSO listed on their leadership page. The story copy above has been updated to reflect that.
In 2021, we discussed a potential future shift from established public-key algorithms to so-called “post-quantum” algorithms, which may help protect sensitive information after the advent of quantum computers. We also shared some of our initial research on how to apply these algorithms to the Domain Name System Security Extensions, or DNSSEC. In the time since that blog post, we’ve continued to explore ways to address the potential operational impact of post-quantum algorithms on DNSSEC, while also closely tracking industry research and advances in this area.
Now, significant activities are underway that are setting the timeline for the availability and adoption of post-quantum algorithms. Since DNS participants – including registries and registrars – use public key-cryptography in a number of their systems, these systems may all eventually need to be updated to use the new post-quantum algorithms. We also announce two major contributions that Verisign has made in support of standardizing this technology: an Internet-Draft as well as a public, royalty-free license to certain intellectual property related to that Internet-Draft.
In this blog post, we review the changes that are on the horizon and what they mean for the DNS ecosystem, and one way we are proposing to ease the implementation of post-quantum signatures – Merkle Tree Ladder mode.
By taking these actions, we aim to be better prepared (while also helping others prepare) for a future where cryptanalytically relevant quantum computing and post-quantum cryptography become a reality.
In July 2022, the National Institute of Standards and Technology (NIST) selected one post-quantum encryption algorithm and three post-quantum signature algorithms for standardization, with standards for these algorithms arriving as early as 2024. In line with this work, the Internet Engineering Task Force (IETF) has also started standards development activities on applying post-quantum algorithms to internet protocols in various working groups, including the newly formed Post-Quantum Use in Protocols (PQUIP) working group. And finally, the National Security Agency (NSA) recently announced that National Security Systems are expected to transition to post-quantum algorithms by 2035.
Collectively, these announcements and activities indicate that many organizations are envisioning a (post-)quantum future, across many protocols. Verisign’s main concern continues to be how post-quantum cryptography impacts the DNS, and in particular, how post-quantum signature algorithms impact DNSSEC.
The standards being developed in the next few years are likely to be the ones deployed when the post-quantum transition eventually takes place, so now is the time to take operational requirements for specific protocols into account.
For DNSSEC, the operational concerns are twofold.
First, the large signature sizes of current post-quantum signatures selected by NIST would result in DNSSEC responses that exceed the size limits of the User Datagram Protocol, which is broadly deployed in the DNS ecosystem. While the Transmission Control Protocol and other transports are available, the additional overhead of having large post-quantum signatures on every response — which can be one to two orders of magnitude as long as traditional signatures —introduces operational risk to the DNS ecosystem that would be preferable to avoid.
Second, the large signatures would significantly increase memory requirements for resolvers using in-memory caches and authoritative nameservers using in-memory databases.
Figure 1, from Andy Fregly’s recent presentation at OARC 40, shows the impact on a fully signed DNS zone where, on average, there are 2.2 digital signatures per resource record set (covering both existence and non-existence proofs). The horizontal bars show the percentage of the zone file that would be comprised of signature data for the two prevalent current algorithms, RSA and ECDSA, and for the smallest and largest of the NIST PQC algorithms. At the low and high end of these examples, signatures with ECDSA would take up 40% of the zone and SPHINCS+ signatures would take up over 99% of the zone. The vertical bars give the percentage size increase of the zone file due to signatures. Again, comparing the low and high end, a zone fully signed with SPHINCS+ would be about 50 times the size of a zone fully signed with ECDSA.
In his 1988 article, “The First Ten Years of Public-Key Cryptography,” Whitfield Diffie, co-discoverer of public-key cryptography, commented on the lack of progress in finding public-key encryption algorithms that were as fast as the symmetric-key algorithms of the day: “Theorems or not, it seemed silly to expect that adding a major new criterion to the requirements of a cryptographic system could fail to slow it down.”
Diffie’s counsel also appears relevant to the search for post-quantum algorithms: It would similarly be surprising if adding the “major new criterion” of post-quantum security to the requirements of a digital signature algorithm didn’t impact performance in some way. Signature size may well be the tradeoff for post-quantum security, at least for now.
With this tradeoff in mind, Verisign’s post-quantum research team has explored ways to address the size impact, particularly to DNSSEC, arriving at a construction we call a Merkle Tree Ladder (MTL), a generalization of a single-rooted Merkle tree (see Figure 2). We have also defined a technique that we call the Merkle Tree Ladder mode of operation for using the construction with an underlying signature algorithm.
Similar to current deployments of public-key cryptography, MTL mode combines processes with complementary properties to balance performance and other criteria (see Table 1). In particular, in MTL mode, rather than signing individual messages with a post-quantum signature algorithm, ladders comprised of one or more Merkle tree nodes are signed using the post-quantum algorithm. Individual messages are then authenticated relative to the ladders using Merkle authentication paths.
| Criterion to Achieve | Initial Design with a Single Process | Improved Design Combining Complementary Processes | Benefit |
| Public-Key Property for Encryption | – Encrypt Individual Messages with Public-Key Algorithm | – Establish Symmetric Keys Using Public-Key Algorithm – Encrypt Multiple Messages Using Each Symmetric Key |
– Amortize Cost of Public-Key Operations Across Multiple Messages |
| Post-Quantum Property for Signatures | – Sign Individual Messages with Post-Quantum Algorithm | – Sign Merkle Tree Ladders using Post-Quantum Algorithm – Authenticate Multiple Messages Relative to Each Signed Ladder |
– Amortize Size of Post-Quantum Signature Across Multiple Messages |
Although the signatures on the ladders might be relatively large, the ladders and their signatures are sent infrequently. In contrast, the Merkle authentication paths that are sent for each message are relatively short. The combination of the two processes maintains the post-quantum property while amortizing the size impact of the signatures across multiple messages. (Merkle tree constructions, being based on hash functions, are naturally post-quantum.)
The two-part approach for public-key algorithms has worked well in practice. In Transport Layer Security, symmetric keys are established in occasional handshake operations, which may be more expensive. The symmetric keys are then used to encrypt multiple messages within a session without further overhead for key establishment. (They can also be used to start a new session).
We expect that a two-part approach for post-quantum signatures can similarly work well in an application like DNSSEC where verifiers are interested in authenticating a subset of messages from a large, evolving message series (e.g., DNS records).
In such applications, signed Merkle Tree Ladders covering a range of messages in the evolving series can be provided to a verifier occasionally. Verifiers can then authenticate messages relative to the ladders, given just a short Merkle authentication path.
Importantly, due to a property of Merkle authentication paths called backward compatibility, all verifiers can be given the same authentication path relative to the signer’s current ladder. This also helps with deployment in applications such as DNSSEC, since the authentication path can be published in place of a traditional signature. An individual verifier may verify the authentication path as long as the verifier has a previously signed ladder covering the message of interest. If not, then the verifier just needs to get the current ladder.
As reported in our presentation on MTL mode at the RSA Conference Cryptographers’ Track in April 2023, our initial evaluation of the expected frequency of requests for MTL mode signed ladders in DNSSEC is promising, suggesting that a significant reduction in effective signature size impact can be achieved.
To facilitate more public evaluation of MTL mode, Verisign’s post-quantum research team last week published the Internet-Draft “Merkle Tree Ladder Mode (MTL) Signatures.” The draft provides the first detailed, interoperable specification for applying MTL mode to a signature scheme, with SPHINCS+ as an initial example.
We chose SPHINCS+ because it is the most conservative of the NIST PQC algorithms from a cryptographic perspective, being hash-based and stateless. It is arguably most suited to be one of the algorithms in a long-term deployment of a critical infrastructure service like DNSSEC. With this focus, the specification has a “SPHINCS+-friendly” style. Implementers familiar with SPHINCS+ will find similar notation and constructions as well as common hash function instantiations. We are open to adding other post-quantum signature schemes to the draft or other drafts in the future.
Publishing the Internet-Draft is a first step toward the goal of standardizing a mode of operation that can reduce the size impact of post-quantum signature algorithms.
In support of this goal, Verisign also announced this week a public, royalty-free license to certain intellectual property related to the Internet-Draft published last week. Similar to other intellectual property rights declarations the company has made, we have announced a “Standards Development Grant” which provides the listed intellectual property under royalty-free terms for the purpose of facilitating standardization of the Internet-Draft we published on July 10, 2023. (The IPR declaration gives the official language.)
We expect to release an open-source implementation of the Internet-Draft soon, and, later this year, to publish an Internet-Draft on using MTL mode signatures in DNSSEC.
With these contributions, we invite implementers to take part in the next step toward standardization: evaluating initial versions of MTL mode to confirm whether they indeed provide practical advantages in specific use cases.
DNSSEC continues to be an important part of the internet’s infrastructure, providing cryptographic verification of information associated with the unique, stable identifiers in this ubiquitous namespace. That is why preparing for an eventual transition to post-quantum algorithms for DNSSEC has been and continues to be a key research and development activity at Verisign, as evidenced by our work on MTL mode and post-quantum DNSSEC more generally.
Our goal is that with a technique like MTL mode in place, protocols like DNSSEC can preserve the security characteristics of a pre-quantum environment while minimizing the operational impact of larger signatures in a post-quantum world.
In a later blog post, we’ll share more details on some upcoming changes to DNSSEC, and how these changes will provide both security and operational benefits to DNSSEC in the near term.
Verisign plans to continue to invest in research and standards development in this area, as we help prepare for a post-quantum future.
The post Next Steps in Preparing for Post-Quantum DNSSEC appeared first on Verisign Blog.
[This is Part III in a series on research conducted for a recent Hulu documentary on the 2015 hack of marital infidelity website AshleyMadison.com.]
In 2019, a Canadian company called Defiant Tech Inc. pleaded guilty to running LeakedSource[.]com, a service that sold access to billions of passwords and other data exposed in countless data breaches. KrebsOnSecurity has learned that the owner of Defiant Tech, a 32-year-old Ontario man named Jordan Evan Bloom, was hired in late 2014 as a developer for the marital infidelity site AshleyMadison.com. Bloom resigned from AshleyMadison citing health reasons in June 2015 — less than one month before unidentified hackers stole data on 37 million users — and launched LeakedSource three months later.
Jordan Evan Bloom, posing in front of his Lamborghini.
On Jan. 15, 2018, the Royal Canadian Mounted Police (RCMP) charged then 27-year-old Bloom, of Thornhill, Ontario, with selling stolen personal identities online through the website LeakedSource[.]com.
LeakedSource was advertised on a number of popular cybercrime forums as a service that could help hackers break into valuable or high-profile accounts. LeakedSource also tried to pass itself off as a legal, legitimate business that was marketing to security firms and professionals.
The RCMP arrested Bloom in December 2017, and said he made approximately $250,000 selling hacked data, which included information on 37 million user accounts leaked in the 2015 Ashley Madison breach.
Subsequent press releases from the RCMP about the LeakedSource investigation omitted any mention of Bloom, and referred to the defendant only as Defiant Tech. In a legal settlement that is quintessentially Canadian, the matter was resolved in 2019 after Defiant Tech agreed to plead guilty. The RCMP declined to comment for this story.
The Impact Team, the hacker group that claimed responsibility for stealing and leaking the AshleyMadison user data, also leaked several years worth of email from then-CEO Noel Biderman. A review of those messages shows that Ashley Madison hired Jordan Evan Bloom as a PHP developer in December 2014 — even though the company understood that Bloom’s success as a programmer and businessman was tied to shady and legally murky enterprises.
Bloom’s recommendation came to Biderman via Trevor Sykes, then chief technology officer for Ashley Madison parent firm Avid Life Media (ALM). The following is an email from Sykes to Biderman dated Nov. 14, 2014:
“Greetings Noel,
“We’d like to offer Jordan Bloom the position of PHP developer reporting to Mike Morris for 75k CAD/Year. He did well on the test, but he also has a great understanding of the business side of things having run small businesses himself. This was an internal referral.”
When Biderman responded that he needed more information about the candidate, Sykes replied that Bloom was independently wealthy as a result of his forays into the shadowy world of “gold farming” — the semi-automated use of large numbers of player accounts to win some advantage that is usually related to cashing out game accounts or inventory. Gold farming is particularly prevalent in massively multiplayer online role-playing games (MMORPGs), such as RuneScape and World of Warcraft.
“In his previous experience he had been doing RMT (Real Money Trading),” Sykes wrote. “This is the practice of selling virtual goods in games for real world money. This is a grey market, which is usually against the terms and services of the game companies.” Here’s the rest of his message to Biderman:
“RMT sellers traditionally have a lot of problems with chargebacks, and payment processor compliance. During my interview with him, I spent some time focusing in on this. He had to demonstrate to the processor, Paypal, at the time he had a business and technical strategy to address his charge back rate.”
“He ran this company himself, and did all the coding, including the integration with the processors,” Sykes continued in his assessment of Bloom. “Eventually he was squeezed out by Chinese gold farmers, and their ability to market with much more investment than he could. In addition the cost of ‘farming’ the virtual goods was cheaper in China to do than in North America.”
The gold farming reference is fascinating because in 2017 KrebsOnSecurity published Who Ran LeakedSource?, which examined clues suggesting that one of the administrators of LeakedSource also was the admin of abusewith[.]us, a site unabashedly dedicated to helping people hack email and online gaming accounts.
An administrator account Xerx3s on Abusewithus.
Abusewith[.]us began in September 2013 as a forum for learning and teaching how to hack accounts at Runescape, an MMORPG set in a medieval fantasy realm where players battle for kingdoms and riches.
The currency with which Runescape players buy and sell weapons, potions and other in-game items are virtual gold coins, and many of Abusewith[dot]us’s early members traded in a handful of commodities: Phishing kits and exploits that could be used to steal Runescape usernames and passwords from fellow players; virtual gold plundered from hacked accounts; and databases from hacked forums and websites related to Runescape and other online games.
That 2017 report here interviewed a Michigan man who acknowledged being administrator of Abusewith[.]us, but denied being the operator of LeakedSource. Still, the story noted that LeakedSource likely had more than one operator, and breached records show Bloom was a prolific member of Abusewith[.]us.
In an email to all employees on Dec. 1, 2014, Ashley Madison’s director of HR said Bloom graduated from York University in Toronto with a degree in theoretical physics, and that he has been an active programmer since high school.
“He’s a proprietor of a high traffic multiplayer game and developer/publisher of utilities such as PicTrace,” the HR director enthused. “He will be a great addition to the team.”
PicTrace appears to have been a service that allowed users to glean information about anyone who viewed an image hosted on the platform, such as their Internet address, browser type and version number. A copy of pictrace[.]com from Archive.org in 2012 redirects to the domain qksnap.com, which DomainTools.com says was registered to a Jordan Bloom from Thornhill, ON that same year.
The street address listed in the registration records for qksnap.com — 204 Beverley Glen Blvd — also shows up in the registration records for leakadvisor[.]com, a domain registered in 2017 just months after Canadian authorities seized the servers running LeakedSource.
Pictrace, one of Jordan Bloom’s early IT successes.
A review of passive DNS records from DomainTools indicates that in 2013 pictrace[.]com shared a server with just a handful of other domains, including Near-Reality[.]com — a popular RuneScape Private Server (RSPS) game based on the RuneScape MMORPG.
Copies of near-reality[.]com from 2013 via Archive.org show the top of the community’s homepage was retrofitted with a message saying Near Reality was no longer available due to a copyright dispute. Although the site doesn’t specify the other party to the copyright dispute, it appears Near-Reality got sued by Jagex, the owner of RuneScape.
The message goes on to say the website will no longer “encourage, facilitate, enable or condone (i) any infringement of copyright in RuneScape or any other Jagex product; nor (ii) any breach of the terms and conditions of RuneScape or any other Jagex product.”
A scene from the MMORPG RuneScape.
Near Reality also has a Facebook page that was last updated in 2019, when its owner posted a link to a news story about Defiant Tech’s guilty plea in the LeakedSource investigation. That Facebook page indicates Bloom also went by the nickname “Agentjags.”
“Just a quick PSA,” reads a post to the Near Reality Facebook page dated Jan. 21, 2018, which linked to a story about the charges against Bloom and a photo of Bloom standing in front of his lime-green Lamborghini. “Agentjags has got involved in some shady shit that may have compromised your personal details. I advise anyone who is using an old NR [Near Reality] password for anything remotely important should change it ASAP.”
By the beginning of 2016, Bloom was nowhere to be found, and was suspected of having fled his country for the Caribbean, according to the people commenting on the Near Reality Facebook page:
“Jordan aka Agentjags has gone missing,” wrote a presumed co-owner of the Facebook page. “He is supposedly hiding in St. Lucia, doing what he loved, scuba-diving. Any information to his whereabouts will be appreciated.”
KrebsOnSecurity ran the unusual nickname “AgentJags” through a search at Constella Intelligence, a commercial service that tracks breached data sets. That search returned just a few dozen results — and virtually all were accounts at various RuneScape-themed sites, including a half-dozen accounts at Abusewith[.]us.
Constella found other “AgentJags” accounts tied to the email address ownagegaming1@gmail.com. The marketing firm Apollo.io experienced a data breach several years back, and according to Apollo the email address ownagegaming1@gmail.com belongs to Jordan Bloom in Ontario.
Constella also revealed that the password frequently used by ownagegaming1@gmail.com across many sites was some variation on “niggapls,” which my 2017 report found was also the password used by the administrator of LeakedSource.
Constella discovered that the email eric.malek@rogers.com comes up when one searches for “AgentJags.” This is curious because emails leaked from Ashley Madison’s then-CEO Biderman show that Eric Malek from Toronto was the Ashley Madison employee who initially recommended Bloom for the PHP developer job.
According to DomainTools.com, Eric.Malek@rogers.com was used to register the domain devjobs.ca, which previously advertised “the most exciting developer jobs in Canada, delivered to you weekly.” Constella says eric.malek@rogers.com also had an account at Abusewith[.]us — under the nickname “Jags.”
Biderman’s email records show Eric Malek was also a PHP developer for Ashley Madison, and that he was hired into this position just a few months before Bloom — on Sept. 2, 2014. The CEO’s leaked emails show Eric Malek resigned from his developer position at Ashley Madison on June 19, 2015.
“Please note that Eric Malek has resigned from this position with Avid and his last day will be June 19th,” read a June 5, 2015 email from ALM’s HR director. “He is resigning to deal with some personal issues which include health issues. Because he is not sure how much time it will take to resolve, he is not requesting a leave of absence (his time off will be indefinite). Overall, he likes the company and plans to reach out to Trevor or I when the issues are resolved to see what is available at that time.”
A follow-up email from Biderman demanded, “want to know where he’s truly going….,” and it’s unclear whether there was friction with Malek’s departure. But ALM General Counsel Avi Weisman replied indicating that Malek probably would not sign an “Exit Acknowledgment Form” prior to leaving, and that the company had unanswered questions for Malek.
“Aneka should dig during exit interview,” Weisman wrote. “Let’s see if he balks at signing the Acknowledgment.”
Bloom’s departure notice from Ashley Madison’s HR person, dated June 23, 2015, read:
“Please note that Jordan Bloom has resigned from his position as PHP Developer with Avid. He is leaving for personal reasons. He has a neck issue that will require surgery in the upcoming months and because of his medical appointment schedule and the pain he is experiencing he can no longer commit to a full-time schedule. He may pick up contract work until he is back to 100%.”
A follow-up note to Biderman about this announcement read:
“Note that he has disclosed that he is independently wealthy so he can get by without FT work until he is on the mend. He has signed the Exit Acknowledgement Form already without issue. He also says he would consider reapplying to Avid in the future if we have opportunities available at that time.”
Perhaps Mr. Bloom hurt his neck from craning it around blind spots in his Lamborghini. Maybe it was from a bad scuba outing. Whatever the pain in Bloom’s neck was, it didn’t stop him from launching himself fully into LeakedSource[.]com, which was registered roughly one month after the Impact Team leaked data on 37 million Ashley Madison accounts.
Mr. Malek declined a request for comment. A now-deleted LinkedIn profile for Malek from December 2018 listed him as a “technical recruiter” from Toronto who also attended Mr. Bloom’s alma mater — York University. That resume did not mention Mr. Malek’s brief stint as a PHP developer at Ashley Madison.
“Developer, entrepreneur, and now technical recruiter of the most uncommon variety!” Mr. Malek’s LinkedIn profile enthused. “Are you a developer, or other technical specialist, interested in working with a recruiter who can properly understand your concerns and aspirations, technical, environmental and financial? Don’t settle for a ‘hack’; this is your career, let’s do it right! Connect with me on LinkedIn. Note: If you are not a resident of Canada/Toronto, I cannot help you.”
Mr. Bloom told KrebsOnSecurity he had no role in harming or hacking Ashley Madison. Bloom validated his identity by responding at one of the email addresses mentioned above, and agreed to field questions so long as KrebsOnSecurity agreed to publish our email conversation in full (PDF).
Bloom said Mr. Malek did recommend him for the Ashley Madison job, but that Mr. Malek also received a $5,000 referral bonus for doing so. Given Mr. Malek’s stated role as a technical recruiter, it seems likely he also recommended several other employees to Ashley Madison.
Bloom was asked whether anyone at the RCMP, Ashley Madison or any authority anywhere ever questioned him in connection with the July 2015 hack of Ashley Madison. He replied that he was called once by someone claiming to be from the Toronto Police Service asking if he knew anything about the Ashley Madison hack.
“The AM situation was not something they pursued according to the RCMP disclosure,” Bloom wrote. “Learning about the RCMP’s most advanced cyber investigative techniques and capabilities was very interesting though. I was eventually told information by a third party which included knowledge that law enforcement effectively knew who the hacker was, but didn’t have enough evidence to proceed with a case. That is the extent of my involvement with any authorities.”
As to his company’s guilty plea for operating LeakedSource, Bloom maintains that the judge at his preliminary inquiry found that even if everything the Canadian government alleged was true it would not constitute a violation of any law in Canada with respect the charges the RCMP leveled against him, which included unauthorized use of a computer and “mischief to data.”
“In Canada at the lower court level we are allowed to possess stolen information and manipulate our copies of them as we please,” Bloom said. “The judge however decided that a trial was required to determine whether any activities of mine were reckless, as the other qualifier of intentionally criminal didn’t apply. I will note here that nothing I was accused of doing would have been illegal if done in the United States of America according to their District Attorney. +1 for free speech in America vs freedom of expression in Canada.”
“Shortly after their having most of their case thrown out, the Government proposed an offer during a closed door meeting where they would drop all charges against me, provide full and complete personal immunity, and in exchange the Corporation which has since been dissolved would plead guilty,” Bloom continued. “The Corporation would also pay a modest fine.”
Bloom said he left Ashley Madison because he was bored, but he acknowledged starting LeakedSource partly in response to the Ashley Madison hack.
“I intended to leverage my gaming connections to get into security work including for other private servers such as Minecraft communities and others,” Bloom said. “After months of asking management for more interesting tasks, I became bored. Some days I had virtually nothing to do except spin in my chair so I would browse the source code for security holes to fix because I found it enjoyable.”
“I believe the decision to start LS [LeakedSource] was partly inspired by the AM hack itself, and the large number of people from a former friend group messaging me asking if XYZ person was in the leak after I revealed to them that I downloaded a copy and had the ability to browse it,” Bloom continued. “LS was never my idea – I was just a builder, and the only Canadian. In other countries it was never thought to be illegal on closer examination of their laws.”
Bloom said he still considers himself independently wealthy, and that still has the lime green Lambo. But he said he’s currently unemployed and can’t seem to land a job in what he views as his most promising career path: Information security.
“As I’m sure you’re aware, having negative media attention associated with alleged (key word) criminal activity can have a detrimental effect on employment, banking and relationships,” Bloom wrote. “I have no current interest in being a business owner, nor do I have any useful business ideas to be honest. I was and am interested in interesting Information Security/programming work but it’s too large of a risk for any business to hire someone who was formerly accused of a crime.”
If you liked this story, please consider reading the first two pieces in this series:
SEO Expert Hired and Fired by Ashley Madison Turned on Company, Promising Revenge
Top Suspect in 2015 Ashley Madison Hack Committed Suicide in 2014
FreshRSS 