A 20-year-old from Vancouver, Washington was indicted last week on federal hacking charges and for allegedly operating the “Satori” botnet, a malware strain unleashed last year that infected hundreds of thousands of wireless routers and other “Internet of Things” (IoT) devices. This outcome is hardly surprising given that the accused’s alleged alter ego has been relentless in seeking media attention for this global crime machine.

The Daily Beast‘s Kevin Poulsen broke the news last week that federal authorities in Alaska indicted Kenneth Currin Schuchman of Washington on two counts of violating the Computer Fraud and Abuse Act by using malware to damage computers between August and November 2017.

The 3-page indictment (PDF) is incredibly sparse, and includes few details about the meat of the charges against Schuchman. But according to Poulsen, the charges are related to Schuchman’s alleged authorship and use of the Satori botnet. Satori is a variant of the Mirai botnet, a powerful IoT malware strain that first came online in July 2016.

“Despite the havoc he supposedly wreaked, the accused hacker doesn’t seem to have been terribly knowledgeable about hacking,” Poulsen notes.

Schuchman reportedly went by the handle “Nexus Zeta,” the nickname used by a fairly inexperienced and clumsy ne’er-do-well who has tried on multiple occasions to get KrebsOnSecurity to write about the Satori botnet. In January 2018, Nexus Zeta changed the login page for his botnet control panel that he used to remotely control his hacked routers to include a friendly backhanded reference to this author:

This wasn’t the first time Nexus Zeta said hello. In late November 2017, he chatted me up on on Twitter and Jabber instant message for several days. Most of the communications came from two accounts: “9gigs_ProxyPipe” on Twitter, and ogmemes123@jabber.ru (9gigs_ProxyPipe would later change its Twitter alias to Nexus Zeta, and Nexus Zeta himself admitted that 9gigs_ProxyPipe was his Twitter account.)

In each case, this person wanted to talk about a new IoT botnet that he was “researching” and that he thought deserved special attention for its size and potential disruptive impact should it be used in a massive Distributed Denial-of-Service (DDoS) attack aimed at knocking a Web site offline — something for which Satori would soon become known.

Nexus Zeta’s Twitter nickname initially confused me because both 9gigs and ProxyPipe are names claimed by Robert Coelho, owner of ProxyPipe hosting (9gigs is a bit from one of Coelho’s Skype account names). Coelho’s sleuthing was quite instrumental in helping to unmask 21-year-old New Jersey resident Paras Jha as the author of the original Mirai IoT botnet (Jha later pleaded guilty to co-authoring and using Mirai and is due to be sentenced this month in Alaska and New Jersey). “Ogmemes” is from a nickname used by Jha and his Mirai botnet co-author.

On Nov. 28, 2017, 9gigs_ProxyPipe sent a message to the KrebsOnSecurity Twitter account:

“I have some information in regards to an incredibly dangerous IoT botnet you may find interesting,” the Twitter message read. “Let me know how you would prefer to communicate assuming you are interested.”

We connected on Jabber instant message. In our chats, Ogmemes123 said he couldn’t understand why nobody had noticed a botnet powered by a Mirai variant that had infected hundreds of thousands of IoT devices (he estimated the size of the botnet to be about 300,000-500,000 at the time). He also talked a lot about how close he was with Jha. Nexus Zeta’s Twitter account profile photo is a picture of Paras Jha. He also said he knew this new botnet was being used to attack ProxyPipe.

Less than 24 hours after that tweet from Nexus Zeta, I heard from ProxyPipe’s Coelho. They were under attack from a new Mirai variant.

“We’ve been mitigating attacks recently that are about 270 gigabits [in volume],” Coelho wrote in an email. “Looks like somebody tagged you on Twitter pretending to be from ProxyPipe — likely the attacker? Just wanted to give you a heads up since that is not us, or anyone that works with ProxyPipe.”

From reviewing Nexus Zeta’s myriad postings on the newbie-friendly hacker forum Hackforums-dot-net, it was clear that Nexus Zeta was an inexperienced, impressionable young man who wanted to associate himself with people closely tied to the 2017 whodunnit over the original Mirai IoT botnet variant. He also asked other Hackforums members for assistance in assembling his Mirai botnet:

In one conversation with Ogmemes123, I lost my cool and told him to quit running botnets or else go bore somebody else with his quest for publicity. He mostly stopped bugging me after that. That same day, Nexus Zeta spotted a tweet from security researcher Troy Mursch about the rapid growth of a new Mirai-like botnet.

“This is an all-time record for the most new unique IP addresses that I’ve seen added to the botnet in one day,” Mursch tweeted of the speed with which this new Mirai strain was infecting devices.

For weeks after that tweet, Nexus Zeta exchanged private twitter messages with Mursch and his team of botnet hunters at Bad Packets LLC in a bid to get them to Tweet or write about Satori/Masuta.

The following screenshots from their private Twitter discussions, republished with Mursch’s permission, showed that Nexus Zeta kept up the fiction with Mursch about his merely “researching” the activities of Satori. Mursch played along, and asked gently probing questions about the size, makeup and activities of a rapidly growing Satori botnet.

Early in their conversations, Nexus Zeta says he is merely following the visible daily Internet scanning that Satori generated each day in a constant search for newly infectable IoT devices. But as their conversations continue over several weeks, Nexus Zeta intimates that he has much deeper access to Satori.

Although it long ago would have been easy to write a series of stories about this individual and his exploits, I had zero interest in giving him the attention he clearly craved. But thanks to naivete and apparently zero sense of self-preservation, Nexus Zeta didn’t have to wait long for others to start connecting his online identities to his offline world.

On Dec. 5, Chinese cybersecurity firm Netlab360 released a report on Satori noting that the IoT malware was spreading rapidly to Chinese-made Huawei routers with the help of two security vulnerabilities, including one “zero day” flaw that was unknown to researchers at the time. The report said a quarter million infected devices were seen scanning for vulnerable systems, and that much of the scanning activity traced back to infected systems in Argentina, Columbia and Egypt, the same hotspots that Nexus Zeta cited in his Nov. 29 Twitter chat with Troy Mursch (see screen shot directly above).

In a taunting post published Dec. 29, 2017 titled “Good Zero Day Kiddie,” researchers at Israeli security firm CheckPoint pointed out that the domain name used as a control server to synchronize the activities of the Satori botnet — nexusiotsolutions-dot-net — was registered in 2016 to the email address nexuszeta1337@gmail.com. The CheckPoint report noted the name supplied in the original registration records for that domain was a “Caleb Wilson,” although the researchers correctly noted that this could be a pseudonym.

Perhaps the CheckPoint folks also knew the following tidbit, but chose not to publish it in their report: The email address nexuszeta1337@gmail.com was only ever used to register a single domain name (nexusiotsolutions-dot-net), according to a historic WHOIS record search at Domaintools.com [full disclosure: DomainTools is an advertiser on this site.] But the phone number in that original domain name record was used to register one other domain: zetastress-dot-net (a “stresser” is another name for a DDoS-for-hire-service). The registrant name listed in that original record? You guessed it:

Registrant Name: kenny Schuchman
Registrant Organization: ZetaSec Inc.
Registrant Street: 8709 Ne Mason Dr, No. 4
Registrant City: Vancouver
Registrant State/Province: Washington
Registrant Postal Code: 98662
Registrant Country: US
Registrant Phone: +1.3607267966
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: kenny.windwmx79@outlook.com

In April 2018 I heard from a source who said he engaged Nexus Zeta in a chat about his router-ravaging botnet and asked what kind of router Nexus Zeta trusted. According to my source, Nexus Zeta shared a screen shot of the output from his wireless modem’s Web interface, which revealed that he was connecting from an Internet service provider in Vancouver, Wash., where Schuchman lives.

“During our discussions, I learned we have the same model of router,” the source said. “He asked me my router model, and I told him. He shared that his router was also an ActionTec model, and sent a picture. This picture contains his home internet address.”

This matched a comprehensive “dox” that someone published on Pastebin in Feb. 2018, declaring Nexus Zeta to be 20-year-old Kenneth Currin Schuchman from Vancouver, Washington. The dox said Schuchman used the aliases Nexus Zeta and Caleb Wilson, and listed all of the email addresses tied to Nexus Zeta above, plus his financial data and physical address.

“Nexus is known by many to be autistic and a compulsive liar,” the dox begins.

“He refused to acknowledge that he was wrong or apologize, and since he has extremely poor opsec (uses home IP on everything), we have decided to dox him.

He was only hung around by few for the servers he had access to.
He lies about writing exploits that were made before his time, and faking bot counts on botnets he made.
He’s lied about having physical contact with Anna Senpai (Author of Mirai Botnet).”

As detailed in the Daily Beast story and Nexus Zeta’s dox, Schuchman was diagnosed with Asperger Syndrome and autism disorder, and at one point when he was 15 Schuchman reportedly wandered off while visiting a friend in Bend, Ore., briefly prompting a police search before he was found near his mother’s home in Vancouver, Wash.

Nexus Zeta clearly had limited hacking skills initially and almost no operational security. Indeed, his efforts to gain notoriety for his illegal hacking activities eventually earned him just that, as it usually does.

But it’s clear he was a quick learner; in the span of about a year, Nexus Zeta was able to progress from a relatively clueless newbie to the helm of an international menace that launched powerful DDoS attacks while ravaging hundreds of thousands of systems.

Instagram users should soon have more secure options for protecting their accounts against Internet bad guys.  On Tuesday, the Facebook-owned social network said it is in the process of rolling out support for third-party authentication apps. Unfortunately, this welcome new security offering does nothing to block Instagram account takeovers when thieves manage to hijack a target’s mobile phone number — an increasingly common crime.

For years, security experts have warned that hackers are exploiting weak authentication at Instagram to commandeer accounts. Instagram has long offered users a security option to have a one-time code sent via text message to a mobile device, but these codes can be intercepted via several methods (more on that in a bit).

The new authentication offering requires users to download a third-party app like Authy, Duo or Google Authenticator, which generates a one-time code that needs to be entered after the user supplies a password.

In a blog post Tuesday, Instagram said support for third-party authenticator apps “has begun to roll out and will be available to the global community in the coming weeks.

Instagram put me on a whitelist of accounts to get an early peek at the new security feature, so these options probably aren’t yet available to most users. But there’s a screenshot below that shows the multi-factor options available in the mobile app. When these options do become more widely available, Instagram says people can use a third-party app to receive a one-time code. To do this:

1. Go to your Settings.
2. Scroll down and tap Two-Factor Authentication.
3. If you haven’t already turned two-factor authentication on, tap Get Started.
4. Tap next to Authentication App, then follow the on-screen instructions.
5. Enter the confirmation code from the third party authentication app to complete the process.

Note that if you have previously enabled SMS-based authentication, it is likely still enabled unless and until you disable it. The app also prompts users to save a series of recovery codes, which should be kept in a safe place in case one’s mobile device is ever lost.

WHAT IT DOESN’T FIX

Instagram has received quite a lot of bad press lately from publications reporting numerous people who had their accounts hijacked even though they had Instagram’s SMS authentication turned on. The thing is, many of those stories have been about people having their Instagram accounts hijacked because fraudsters were able to hijack their mobile phone number.

In these cases, the fraudsters were able to hijack the Instagram accounts because Instagram allows users to reset their account passwords with a single factor — using nothing more than a text message sent to a mobile number on file. And nothing in these new authentication offerings will change that for people who have shared their mobile number with Instagram.

Criminals can and do exploit SMS-based password reset requests to hijack Instagram accounts by executing unauthorized “SIM swaps,” i.e., tricking the target’s mobile provider into transferring the phone number to a device or account they control and intercepting the password reset link sent via SMS. Once they hijack the target’s mobile number, they can then reset the password for the associated Instagram account.

I asked Instagram if there was any way for people who have supplied the company with their phone number to turn off SMS-based password reset requests. I received this response from their PR folks:

“I can confirm that disabling SMS two factor will not disable the ability to reset a password via SMS,” a spokesperson said via email. “We recommend that the community use a third-party app for authentication, in place of SMS authentication. We’ll continue to iterate and improve on this product to keep people safe on our platform.”

Fraudulent SIM swaps illustrate the value of moving away from SMS-based authentication when more secure options are available. Doing so makes one less likely to be targeted by these phone number hijacks, which are generally perpetrated by determined, well-organized attackers.

The hard truth is that if an attacker wants control over your mobile number badly enough, he will get it. And if he does, he will likely gain access to far more than your Instagram account: Someone who hacks your phone number can then compromise any account that allows authentication or password resets via text message or automated phone call.

In May, KrebsOnSecurity documented the case of a Boston man who had his Instagram account hijacked after a crooked T-Mobile employee transferred his phone number to another device without authorization. Additionally, authorities in California and Florida have recently arrested several men accused of conducting similar attacks, and according to charging documents all of these individuals routinely worked with associates at mobile phone stores to carry out their heists.

In case you missed it, KrebsOnSecurity ran a story earlier this month about the sound security advice allegedly offered by one of the most accomplished SIM swappers of late, who recommended using Internet-based phone services like Google Voice in lieu of relying on mobile phone providers for multi-factor authentication.

Standard disclaimer: If SMS-based authentication is the strongest form of extra security a Web site offers, this is still far better than relying on just passwords for login security. If app-based options are available, take advantage of that. If the site in question offers hardware-based security keys, even better. Twofactorauth.org lists multi-factor authentication options for hundreds of sites, including probably many that you use on a daily basis. Take a moment this week to strengthen your login options.

Fiserv, Inc., a major provider of technology services to financial institutions, just fixed a glaring weakness in its Web platform that exposed personal and financial details of countless customers across hundreds of bank Web sites, KrebsOnSecurity has learned.

Brookfield, Wisc.-based Fiserv [NASDAQ:FISV] is a Fortune 500 company with 24,000 employees and $5.7 billion in earnings last year. Its account and transaction processing systems power the Web sites for hundreds of financial institutions — mostly small community banks and credit unions.

Two weeks ago this author heard from security researcher Kristian Erik Hermansen, who said he’d discovered something curious while logged in to an account at a tiny local bank that uses Fiserv’s platform.

Hermansen had signed up to get email alerts any time a new transaction posted to his account, and he noticed the site assigned his alert a specific “event number.” Working on a hunch that these event numbers might be assigned sequentially and that other records might be available if requested directly, Hermansen requested the same page again but first edited the site’s code in his browser so that his event number was decremented by one digit.

In an instant, he could then view and edit alerts previously set up by another bank customer, and could see that customer’s email address, phone number and the last four digits of their bank account number.

Hermansen said a cybercriminal could abuse this access to enumerate all other accounts with activity alerts on file, and to add or delete phone numbers or email addresses to receive alerts about account transactions.

This would allow any customer of the bank to spy on the daily transaction activity of other customers, and perhaps even target customers who signed up for high minimum balance alerts (e.g., “alert me when the available balance goes below $5,000”).

“I shouldn’t be able to see this data,” Hermansen said. “Anytime you spend money that should be a private transaction between you and your bank, not available for everyone else to see.”

Hermansen said he told his bank about what he found, and that he tried unsuccessfully to get the attention of different Fiserv employees, including the company’s CEO via LinkedIn. But he wasn’t sure whether the flaw he found existed in all bank sites running on Fiserv’s ebanking platform, or just his bank’s installation.

Naturally, KrebsOnSecurity offered to help figure that out, and to get Fiserv’s attention, if warranted. Over the past week I signed up for accounts at two small local banks that each use Fiserv’s online banking platform.

In both cases I was able to replicate Hermansen’s findings and view email addresses, phone numbers, partial account numbers and alert details for other customers of each bank just by editing a single digit in a Web page request. I was relieved to find I could not use my online account access at one bank to view transaction alerts I’d set up at a different Fiserv affiliated bank.

But it was not difficult to find hundreds of other Fiserv-affiliated banks that would be just as vulnerable. If a bank is using Fiserv’s platform, it usually says so somewhere at the bottom of the bank’s home page. Another giveaway is that most of the bank sites using Fiserv display the same root domain name in the browser address bar after login: secureinternetbank.com.

Fiserv said in a statement that the problem stemmed from an issue with “a messaging solution available to a subset of online banking clients.” Fiserv declined to say exactly how many financial institutions may have been impacted overall. But experts tells KrebsOnSecurity that some 1,700 banks currently use Fiserv’s retail (consumer-focused) banking platform alone.

“Fiserv places a high priority on security, and we have responded accordingly,” Fiserv spokesperson Ann Cave said. “After receiving your email, we promptly engaged appropriate resources and worked around the clock to research and remediate the situation. We developed a security patch within 24 hours of receiving notification and deployed the patch to clients that utilize a hosted version of the solution. We will be deploying the patch this evening to clients that utilize an in-house version of the solution.”

This author confirmed that Fiserv no longer shows a sequential event number in their banking sites and has replaced them with a pseudo-random string.

Julie Conroy, research director with market analyst firm Aite Group, said the kinds of banks that use Fiserv’s platform mostly are those that can’t afford to build and maintain their own.

“These financial institutions use a core banking provider like Fiserv because they don’t have the wherewithal to do it on their own, so they’re really trusting Fiserv to do this on their behalf,” Conroy said. “This will not only reflect on Fiserv’s brand, but also it will impact customer’s perception about their small local bank, which is already struggling to compete with the larger, nationwide institutions.”

Allen Weinberg, partner and co-founder at Glenbrook Partners LLC, said the ability of fraudsters to edit account transaction alerts somewhat negates the value of these alerts in helping consumers fight fraud tied to their online banking accounts.

“If a fraudster can just turn off the alerts, there’s one less protection that consumers think they have,” Weinberg said. “I think consumers do rely in large part on these alerts to help them detect fraudulent activity.”

The weaknesses in Fiserv’s platform is what’s known as an “information disclosure” vulnerability. While these are among the most common types of security issues with Web sites, they are also perhaps the most preventable and easily fixed.

Nevertheless, disclosure flaws can be just as damaging to a company’s brand as other more severe types of security errors. Other notable security incidents involving recent information disclosure issues include a weakness at Panera Bread’s site that exposed tens of millions of customer records, and a bug in identity protection service LifeLock’s site that revealed email addresses for millions of customers.

The sextortion email scam last month that invoked a real password used by each recipient and threatened to release embarrassing Webcam videos almost certainly was not the work of one criminal or even one group of criminals. Rather, it’s likely that additional spammers and scammers piled on with their own versions of the phishing email after noticing that some recipients were actually paying up. The truth is we may never find out who’s responsible, but it’s still fun to follow some promising early leads and see where they take us.

On Aug. 7, 2018 — five days before my story about the sextortion scam innovation went viral — a user on the forum of free email service hMailServer posted a copy of the sextortion email he received, noting that it included a password he’d formerly used online.

Helpfully, this user pasted a great deal of information from the spam email message, including the domain name from which it was sent (williehowell-dot-com) and the Internet address of the server that sent the message (46.161.42.91).

A look at the other domain names registered to this IP address block 46.161.42.x reveals some interesting patterns:

46.161.42.51 mail25.uscourtsgov[.]com
46.161.42.52 mail24.uscourtsgov[.]com
46.161.42.53 mail23.uscourtsgov[.]com
46.161.42.54 mail22.uscourtsgov[.]com
46.161.42.55 mail21.uscourtsgov[.]com
46.161.42.56 mail20.uscourtsgov[.]com
46.161.42.57 mail19.uscourtsgov[.]com
46.161.42.58 mail18.uscourtsgov[.]com
46.161.42.59 mail17.uscourtsgov[.]com
46.161.42.60 mail16.uscourtsgov[.]com
46.161.42.61 mail15.uscourtsgov[.]com
46.161.42.62 mail14.uscourtsgov[.]com
46.161.42.63 mail13.uscourtsgov[.]com
46.161.42.64 mail12.uscourtsgov[.]com
46.161.42.65 mail11.uscourtsgov[.]com
46.161.42.66 mail10.uscourtsgov[.]com
46.161.42.67 mail9.uscourtsgov[.]com
46.161.42.68 mail8.uscourtsgov[.]com
46.161.42.69 mail7.uscourtsgov[.]com
46.161.42.70 mail6.uscourtsgov[.]com
46.161.42.71 mail5.uscourtsgov[.]com
46.161.42.72 mail4.uscourtsgov[.]com
46.161.42.73 mail3.uscourtsgov[.]com
46.161.42.74 mail2.uscourtsgov[.]com
46.161.42.75 mail1.uscourtsgov[.]com
46.161.42.76 mail[.]commarysmith[.]com
46.161.42.77 mail.joancooper[.]com
46.161.42.78 mail.florencewoods[.]com
46.161.42.79 mail.ednawest[.]com
46.161.42.80 mail.ethelwebb[.]com
46.161.42.81 mail.eleanorhunt[.]com
46.161.42.82 mail.sallypierce[.]com
46.161.42.83 mail.reginaberry[.]com
46.161.42.84 mail.junecarroll[.]com
46.161.42.85 mail.robertaharper[.]com
46.161.42.86 mail.reneelane[.]com
46.161.42.87 mail.almaaustin[.]com
46.161.42.88 mail.elsiekelley[.]com
46.161.42.89 mail.vickifields[.]com
46.161.42.90 mail.ellaoliver[.]com
46.161.42.91 mail.williehowell[.]com
46.161.42.92 mail.veramccoy[.]com
46.161.42.93 mail.agnesbishop[.]com
46.161.42.94 mail.tanyagilbert[.]com
46.161.42.95 mail.mattiehoffman[.]com
46.161.42.96 mail.hildahopkins[.]com
46.161.42.97 beckymiles[.]com
46.161.42.98 mail.fayenorris[.]com
46.161.42.99 mail.joannaleonard[.]com
46.161.42.100 mail.rosieweber[.]com
46.161.42.101 mail.candicemanning[.]com
46.161.42.102 mail.sherirowe[.]com
46.161.42.103 mail.leticiagoodman[.]com
46.161.42.104 mail.myrafrancis[.]com
46.161.42.105 mail.jasminemaxwell[.]com
46.161.42.106 mail.eloisefrench[.]com

Search Google for any of those two-name domains above (e.g., fayenorris-dot-com) and you’ll see virtually all of them were used in these sextortion emails, and most were registered at the end of May 2018 through domain registrar Namecheap.

Notice the preponderance of the domain uscourtsgov-dot-com in the list above. All of those two-name domains used domain name servers (DNS servers) from uscourtsgov-dot-com at the time these emails were sent. In early June 2018, uscourtsgov-dot-com was associated with a Sigma ransomware scam delivered via spam. Victims who wanted their files back had to pay a bitcoin ransom.

In the months just before either the password-laced sextortion scam or the uscourtsgov-dot-com ransomware scam, uscourtsgov-com was devoid of content, aside from a message promoting the spamming services of the web site mtaexpert-dot-info. Uscourtsgov-dot-com is now offline, but it was active as of two weeks ago. Here’s what its homepage looked like:

Interestingly, this same message promoting mtaexpert-dot-info appeared on the homepages of many other two-name domain names mentioned above (including fayenorris-dot-com):

In the email delivery space, MTA stands for mail transfer agent, and this MTA Expert company is essentially an anonymous spamming service. The screen shot below is from an Internet Archive cached copy of mtaexpert-dot-info:

Mtaexpert-dot-info doesn’t disclose who owns the site, and current WHOIS registration records for the domain are obscured by privacy services. But thanks to a historic WHOIS record lookup at Domaintools.com [full disclosure: Domaintools is an advertiser on this site], we can see that for about a week in May 2018 the WHOIS privacy veil briefly dropped off and revealed the following record:

Registrant Name: HICHAM AALLAM
Registrant Organization: investissonsorg
Registrant Street: RED ANASS BLOC 26 N 3 ROUTE DE TETOUANE
Registrant City: TANGER
Registrant State/Province: Tanger-Tetouan
Registrant Postal Code: 90001
Registrant Country: MA
Registrant Phone: +212.626280317
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: hicham.aallam60@gmail.com

Who is Hicham Aallam? According to his LinkedIn page, he is an email marketer living in Morocco and working for a company called Active Sun Network. His resume says he also works for AdGenics, which according to anti-spam group Spamhaus is a well-known spamming operation with a long, sordid history. AdGenics, a.k.a. Cabo Networks a.k.a SIFT Logic, is currently Number Six on Spamhaus’ Top Ten Worst Spammers list.

Contacted via LinkedIn, Aallam said he was unaware that his email service was used in the either the sextortion or ransomware campaigns linked to the above-mentioned domains. He said an ad for Mtaexpert-dot-info automatically gets shown on the home page of any site that is configured to use his email-sending scripts.

Aallam says he charges customers to use these scripts, but that he only had one semi-recent customer: A person who contacted him using the Skype name “brian.ortega_4” paid roughly $250 worth of the cryptocurrency Ethereum (ETH) on Apr. 3, 2018 for a license to MTA Experts’ mailing script. Here is a record of that transaction. All of the ETH transactions attributed to and from that account can be seen here.

Okay, so we still might not know who’s responsible for sending some of these sextortion emails, and it could well be one of Aallam’s other clients behind these two schemes. Nevertheless, it’s always fascinating to see how far one can get just by following a few breadcrumbs.

One final breadcrumb to follow: The Internet address space occupied by the uscourtsgov-dot-com and the sextortion-related domains — 46.161.42.0/24. In May 2018, RiskIQ published a detailed report (PDF) about a complex phishing scheme that used an address adjacent to uscourtsgov-dot-com in a bid to steal Ethereum from MyEtherWallet users.

The registered owner of the Internet address space is a “Barbarich_Viacheslav_Yuryevich,” which is the same name as the owner of the network AS41995, a.k.a. web-shield-dot-biz.

A different block of addresses that we can see in the graphic above assigned to Web-Shield — 146.185.241.0/24 — contains a metric truckload of domains involved in selling stolen credit cards.

Loyal readers of this site will notice a familiar domain there: Rescator. It belongs to a seasonsed cybercriminal by the same name who has been closely linked to the Target and Sally Beauty breaches, among many others. To this day — almost four years after the Target breach — the home page to Rescator’s stolen card shop includes a picture of Yours Truly as a postage stamp that reads, “As advertised by Brian Krebs.”

KrebsOnSecurity would like to thank security researcher Troy Mursch and anti-spam crusader Ron Guilmette for their assistance in this research.

In September 2017, Equifax disclosed that a failure to patch one of its Internet servers against a pervasive software flaw — in a Web component known as Apache Struts — led to a breach that exposed personal data on 147 million Americans. Now security experts are warning that blueprints showing malicious hackers how to exploit a newly-discovered Apache Struts bug are available online, leaving countless organizations in a rush to apply new updates and plug the security hole before attackers can use it to wriggle inside.

On Aug. 22, the Apache Software Foundation released software updates to fix a critical vulnerability in Apache Struts, a Web application platform used by an estimated 65 percent of Fortune 100 companies. Unfortunately, computer code that can be used to exploit the bug has since been posted online, meaning bad guys now have precise instructions on how to break into vulnerable, unpatched servers.

Attackers can exploit a Web site running the vulnerable Apache Struts installation using nothing more than a Web browser. The bad guy simply needs to send the right request to the site and the Web server will run any command of the attacker’s choosing. At that point, the intruder could take any number of actions, such as adding or deleting files, or copying internal databases.

An alert about the Apache security update was posted Wednesday by Semmle, the San Francisco software company whose researchers discovered the bug.

“The widespread use of Struts by leading enterprises, along with the proven potential impact of this sort of vulnerability, illustrate the threat that this vulnerability poses,” the alert warns.

“Critical remote code execution vulnerabilities like the one that affected Equifax and the one we announced today are incredibly dangerous for several reasons: Struts is used for publicly-accessible customer-facing websites, vulnerable systems are easily identified, and the flaw is easy to exploit,” wrote Semmle co-founder Pavel Avgustinov. “A hacker can find their way in within minutes, and exfiltrate data or stage further attacks from the compromised system. It’s crucially important to update affected systems immediately; to wait is to take an irresponsible risk.”

The timeline in the 2017 Equifax breach highlights how quickly attackers can take advantage of Struts flaws. On March 7, 2017, Apache released a patch for a similarly dangerous Struts flaw, and within 24 hours of that update security experts began tracking signs that attackers were exploiting vulnerable servers.

Just three days after the patch was released, attackers found Equifax’s servers were vulnerable to the Apache Struts flaw, and used the vulnerability as an initial entry point into the credit bureau’s network.

The vulnerability affects all supported versions of Struts 2. Users of Struts 2.3 should upgrade to version 2.3.35; users of Struts 2.5 should upgrade to 2.5.17.

More technical details about this bug from its discoverer, Man Yue Mo, are here. The Apache Software Foundation’s advisory is here.