Login
Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.
This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.
In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.
DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.
The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.
In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.
Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.
In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.
The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.
There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.
The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.
A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.
Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.
The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.
Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.
The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.
The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.
FreshRSS 
Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
# Inception Expiration ZSK Tags KSK Tag(CKA_LABEL)
1 2022-10-01T00:00:00 2022-10-22T00:00:00 18733,20826
2 2022-10-11T00:00:00 2022-11-01T00:00:00 18733
3 2022-10-21T00:00:00 2022-11-11T00:00:00 18733
4 2022-10-31T00:00:00 2022-11-21T00:00:00 18733
5 2022-11-10T00:00:00 2022-12-01T00:00:00 18733
6 2022-11-20T00:00:00 2022-12-11T00:00:00 18733
7 2022-11-30T00:00:00 2022-12-21T00:00:00 18733
8 2022-12-10T00:00:00 2022-12-31T00:00:00 18733
9 2022-12-20T00:00:00 2023-01-10T00:00:00 00951,18733
...PASSED.
It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:
SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<
At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:
The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.
Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.
For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.
The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.
Image: Shutterstock.com
Three different cybercriminal groups claimed access to internal networks at communications giant T-Mobile in more than 100 separate incidents throughout 2022, new data suggests. In each case, the goal of the attackers was the same: Phish T-Mobile employees for access to internal company tools, and then convert that access into a cybercrime service that could be hired to divert any T-Mobile user’s text messages and phone calls to another device.
The conclusions above are based on an extensive analysis of Telegram chat logs from three distinct cybercrime groups or actors that have been identified by security researchers as particularly active in and effective at “SIM-swapping,” which involves temporarily seizing control over a target’s mobile phone number.
Countless websites and online services use SMS text messages for both password resets and multi-factor authentication. This means that stealing someone’s phone number often can let cybercriminals hijack the target’s entire digital life in short order — including access to any financial, email and social media accounts tied to that phone number.
All three SIM-swapping entities that were tracked for this story remain active in 2023, and they all conduct business in open channels on the instant messaging platform Telegram. KrebsOnSecurity is not naming those channels or groups here because they will simply migrate to more private servers if exposed publicly, and for now those servers remain a useful source of intelligence about their activities.
Each advertises their claimed access to T-Mobile systems in a similar way. At a minimum, every SIM-swapping opportunity is announced with a brief “Tmobile up!” or “Tmo up!” message to channel participants. Other information in the announcements includes the price for a single SIM-swap request, and the handle of the person who takes the payment and information about the targeted subscriber.
The information required from the customer of the SIM-swapping service includes the target’s phone number, and the serial number tied to the new SIM card that will be used to receive text messages and phone calls from the hijacked phone number.
Initially, the goal of this project was to count how many times each entity claimed access to T-Mobile throughout 2022, by cataloging the various “Tmo up!” posts from each day and working backwards from Dec. 31, 2022.
But by the time we got to claims made in the middle of May 2022, completing the rest of the year’s timeline seemed unnecessary. The tally shows that in the last seven-and-a-half months of 2022, these groups collectively made SIM-swapping claims against T-Mobile on 104 separate days — often with multiple groups claiming access on the same days.
The 104 days in the latter half of 2022 in which different known SIM-swapping groups claimed access to T-Mobile employee tools.
KrebsOnSecurity shared a large amount of data gathered for this story with T-Mobile. The company declined to confirm or deny any of these claimed intrusions. But in a written statement, T-Mobile said this type of activity affects the entire wireless industry.
“And we are constantly working to fight against it,” the statement reads. “We have continued to drive enhancements that further protect against unauthorized access, including enhancing multi-factor authentication controls, hardening environments, limiting access to data, apps or services, and more. We are also focused on gathering threat intelligence data, like what you have shared, to help further strengthen these ongoing efforts.”
While it is true that each of these cybercriminal actors periodically offer SIM-swapping services for other mobile phone providers — including AT&T, Verizon and smaller carriers — those solicitations appear far less frequently in these group chats than T-Mobile swap offers. And when those offers do materialize, they are considerably more expensive.
The prices advertised for a SIM-swap against T-Mobile customers in the latter half of 2022 ranged between USD $1,000 and $1,500, while SIM-swaps offered against AT&T and Verizon customers often cost well more than twice that amount.
To be clear, KrebsOnSecurity is not aware of specific SIM-swapping incidents tied to any of these breach claims. However, the vast majority of advertisements for SIM-swapping claims against T-Mobile tracked in this story had two things in common that set them apart from random SIM-swapping ads on Telegram.
First, they included an offer to use a mutually trusted “middleman” or escrow provider for the transaction (to protect either party from getting scammed). More importantly, the cybercriminal handles that were posting ads for SIM-swapping opportunities from these groups generally did so on a daily or near-daily basis — often teasing their upcoming swap events in the hours before posting a “Tmo up!” message announcement.
In other words, if the crooks offering these SIM-swapping services were ripping off their customers or claiming to have access that they didn’t, this would be almost immediately obvious from the responses of the more seasoned and serious cybercriminals in the same chat channel.
There are plenty of people on Telegram claiming to have SIM-swap access at major telecommunications firms, but a great many such offers are simply four-figure scams, and any pretenders on this front are soon identified and banned (if not worse).
One of the groups that reliably posted “Tmo up!” messages to announce SIM-swap availability against T-Mobile customers also reliably posted “Tmo down!” follow-up messages announcing exactly when their claimed access to T-Mobile employee tools was discovered and revoked by the mobile giant.
A review of the timestamps associated with this group’s incessant “Tmo up” and “Tmo down” posts indicates that while their claimed access to employee tools usually lasted less than an hour, in some cases that access apparently went undiscovered for several hours or even days.
How could these SIM-swapping groups be gaining access to T-Mobile’s network as frequently as they claim? Peppered throughout the daily chit-chat on their Telegram channels are solicitations for people urgently needed to serve as “callers,” or those who can be hired to social engineer employees over the phone into navigating to a phishing website and entering their employee credentials.
Allison Nixon is chief research officer for the New York City-based cybersecurity firm Unit 221B. Nixon said these SIM-swapping groups will typically call employees on their mobile devices, pretend to be someone from the company’s IT department, and then try to get the person on the other end of the line to visit a phishing website that mimics the company’s employee login page.
Nixon argues that many people in the security community tend to discount the threat from voice phishing attacks as somehow “low tech” and “low probability” threats.
“I see it as not low-tech at all, because there are a lot of moving parts to phishing these days,” Nixon said. “You have the caller who has the employee on the line, and the person operating the phish kit who needs to spin it up and down fast enough so that it doesn’t get flagged by security companies. Then they have to get the employee on that phishing site and steal their credentials.”
In addition, she said, often there will be yet another co-conspirator whose job it is to use the stolen credentials and log into employee tools. That person may also need to figure out how to make their device pass “posture checks,” a form of device authentication that some companies use to verify that each login is coming only from employer-issued phones or laptops.
For aspiring criminals with little experience in scam calling, there are plenty of sample call transcripts available on these Telegram chat channels that walk one through how to impersonate an IT technician at the targeted company — and how to respond to pushback or skepticism from the employee. Here’s a snippet from one such tutorial that appeared recently in one of the SIM-swapping channels:
“Hello this is James calling from Metro IT department, how’s your day today?”
(yea im doing good, how r u)
i’m doing great, thank you for asking
i’m calling in regards to a ticket we got last week from you guys, saying you guys were having issues with the network connectivity which also interfered with [Microsoft] Edge, not letting you sign in or disconnecting you randomly. We haven’t received any updates to this ticket ever since it was created so that’s why I’m calling in just to see if there’s still an issue or not….”
The TMO UP data referenced above, combined with comments from the SIM-swappers themselves, indicate that while many of their claimed accesses to T-Mobile tools in the middle of 2022 lasted hours on end, both the frequency and duration of these events began to steadily decrease as the year wore on.
T-Mobile declined to discuss what it may have done to combat these apparent intrusions last year. However, one of the groups began to complain loudly in late October 2022 that T-Mobile must have been doing something that was causing their phished access to employee tools to die very soon after they obtained it.
One group even remarked that they suspected T-Mobile’s security team had begun monitoring their chats.
Indeed, the timestamps associated with one group’s TMO UP/TMO DOWN notices show that their claimed access was often limited to less than 15 minutes throughout November and December of 2022.
Whatever the reason, the calendar graphic above clearly shows that the frequency of claimed access to T-Mobile decreased significantly across all three SIM-swapping groups in the waning weeks of 2022.
T-Mobile US reported revenues of nearly $80 billion last year. It currently employs more than 71,000 people in the United States, any one of whom can be a target for these phishers.
T-Mobile declined to answer questions about what it may be doing to beef up employee authentication. But Nicholas Weaver, a researcher and lecturer at University of California, Berkeley’s International Computer Science Institute, said T-Mobile and all the major wireless providers should be requiring employees to use physical security keys for that second factor when logging into company resources.
A U2F device made by Yubikey.
“These breaches should not happen,” Weaver said. “Because T-Mobile should have long ago issued all employees security keys and switched to security keys for the second factor. And because security keys provably block this style of attack.”
The most commonly used security keys are inexpensive USB-based devices. A security key implements a form of multi-factor authentication known as Universal 2nd Factor (U2F), which allows the user to complete the login process simply by inserting the USB key and pressing a button on the device. The key works without the need for any special software drivers.
The allure of U2F devices for multi-factor authentication is that even if an employee who has enrolled a security key for authentication tries to log in at an impostor site, the company’s systems simply refuse to request the security key if the user isn’t on their employer’s legitimate website, and the login attempt fails. Thus, the second factor cannot be phished, either over the phone or Internet.
Nixon said one confounding aspect of SIM-swapping is that these criminal groups tend to recruit teenagers to do their dirty work.
“A huge reason this problem has been allowed to spiral out of control is because children play such a prominent role in this form of breach,” Nixon said.
Nixon said SIM-swapping groups often advertise low-level jobs on places like Roblox and Minecraft, online games that are extremely popular with young adolescent males.
“Statistically speaking, that kind of recruiting is going to produce a lot of people who are underage,” she said. “They recruit children because they’re naive, you can get more out of them, and they have legal protections that other people over 18 don’t have.”
For example, she said, even when underage SIM-swappers are arrested, the offenders tend to go right back to committing the same crimes as soon as they’re released.
In January 2023, T-Mobile disclosed that a “bad actor” stole records on roughly 37 million current customers, including their name, billing address, email, phone number, date of birth, and T-Mobile account number.
In August 2021, T-Mobile acknowledged that hackers made off with the names, dates of birth, Social Security numbers and driver’s license/ID information on more than 40 million current, former or prospective customers who applied for credit with the company. That breach came to light after a hacker began selling the records on a cybercrime forum.
In the shadow of such mega-breaches, any damage from the continuous attacks by these SIM-swapping groups can seem insignificant by comparison. But Nixon says it’s a mistake to dismiss SIM-swapping as a low volume problem.
“Logistically, you may only be able to get a few dozen or a hundred SIM-swaps in a day, but you can pick any customer you want across their entire customer base,” she said. “Just because a targeted account takeover is low volume doesn’t mean it’s low risk. These guys have crews that go and identify people who are high net worth individuals and who have a lot to lose.”
Nixon said another aspect of SIM-swapping that causes cybersecurity defenders to dismiss the threat from these groups is the perception that they are full of low-skilled “script kiddies,” a derisive term used to describe novice hackers who rely mainly on point-and-click hacking tools.
“They underestimate these actors and say this person isn’t technically sophisticated,” she said. “But if you’re rolling around in millions worth of stolen crypto currency, you can buy that sophistication. I know for a fact some of these compromises were at the hands of these ‘script kiddies,’ but they’re not ripping off other people’s scripts so much as hiring people to make scripts for them. And they don’t care what gets the job done, as long as they get to steal the money.”
Web hosting giant GoDaddy made headlines this month when it disclosed that a multi-year breach allowed intruders to steal company source code, siphon customer and employee login credentials, and foist malware on customer websites. Media coverage understandably focused on GoDaddy’s admission that it suffered three different cyberattacks over as many years at the hands of the same hacking group. But it’s worth revisiting how this group typically got in to targeted companies: By calling employees and tricking them into navigating to a phishing website.
In a filing with the U.S. Securities and Exchange Commission (SEC), GoDaddy said it determined that the same “sophisticated threat actor group” was responsible for three separate intrusions, including:
-March 2020: A spear-phishing attack on a GoDaddy employee compromised the hosting login credentials of approximately 28,000 GoDaddy customers, as well as login credentials for a small number employees;
-November 2021: A compromised GoDaddy password let attackers steal source code and information tied to 1.2 million customers, including website administrator passwords, sFTP credentials, and private SSL keys;
-December 2022: Hackers gained access to and installed malware on GoDaddy’s cPanel hosting servers that “intermittently redirected random customer websites to malicious sites.”
“Based on our investigation, we believe these incidents are part of a multi-year campaign by a sophisticated threat actor group that, among other things, installed malware on our systems and obtained pieces of code related to some services within GoDaddy,” the company stated in its SEC filing.
What else do we know about the cause of these incidents? We don’t know much about the source of the November 2021 incident, other than GoDaddy’s statement that it involved a compromised password, and that it took about two months for the company to detect the intrusion. GoDaddy has not disclosed the source of the breach in December 2022 that led to malware on some customer websites.
But we do know the March 2020 attack was precipitated by a spear-phishing attack against a GoDaddy employee. GoDaddy described the incident at the time in general terms as a social engineering attack, but one of its customers affected by that March 2020 breach actually spoke to one of the hackers involved.
The hackers were able to change the Domain Name System (DNS) records for the transaction brokering site escrow.com so that it pointed to an address in Malaysia that was host to just a few other domains, including the then brand-new phishing domain servicenow-godaddy[.]com.
The general manager of Escrow.com found himself on the phone with one of the GoDaddy hackers, after someone who claimed they worked at GoDaddy called and said they needed him to authorize some changes to the account.
In reality, the caller had just tricked a GoDaddy employee into giving away their credentials, and he could see from the employee’s account that Escrow.com required a specific security procedure to complete a domain transfer.
The general manager of Escrow.com said he suspected the call was a scam, but decided to play along for about an hour — all the while recording the call and coaxing information out of the scammer.
“This guy had access to the notes, and knew the number to call,” to make changes to the account, the CEO of Escrow.com told KrebsOnSecurity. “He was literally reading off the tickets to the notes of the admin panel inside GoDaddy.”
About halfway through this conversation — after being called out by the general manager as an imposter — the hacker admitted that he was not a GoDaddy employee, and that he was in fact part of a group that enjoyed repeated success with social engineering employees at targeted companies over the phone.
Absent from GoDaddy’s SEC statement is another spate of attacks in November 2020, in which unknown intruders redirected email and web traffic for multiple cryptocurrency services that used GoDaddy in some capacity.
It is possible this incident was not mentioned because it was the work of yet another group of intruders. But in response to questions from KrebsOnSecurity at the time, GoDaddy said that incident also stemmed from a “limited” number of GoDaddy employees falling for a sophisticated social engineering scam.
“As threat actors become increasingly sophisticated and aggressive in their attacks, we are constantly educating employees about new tactics that might be used against them and adopting new security measures to prevent future attacks,” GoDaddy said in a written statement back in 2020.
Voice phishing or “vishing” attacks typically target employees who work remotely. The phishers will usually claim that they’re calling from the employer’s IT department, supposedly to help troubleshoot some issue. The goal is to convince the target to enter their credentials at a website set up by the attackers that mimics the organization’s corporate email or VPN portal.
Experts interviewed for an August 2020 story on a steep rise in successful voice phishing attacks said there are generally at least two people involved in each vishing scam: One who is social engineering the target over the phone, and another co-conspirator who takes any credentials entered at the phishing page — including multi-factor authentication codes shared by the victim — and quickly uses them to log in to the company’s website.
The attackers are usually careful to do nothing with the phishing domain until they are ready to initiate a vishing call to a potential victim. And when the attack or call is complete, they disable the website tied to the domain.
This is key because many domain registrars will only respond to external requests to take down a phishing website if the site is live at the time of the abuse complaint. This tactic also can stymie efforts by companies that focus on identifying newly-registered phishing domains before they can be used for fraud.
A U2F device made by Yubikey.
GoDaddy’s latest SEC filing indicates the company had nearly 7,000 employees as of December 2022. In addition, GoDaddy contracts with another 3,000 people who work full-time for the company via business process outsourcing companies based primarily in India, the Philippines and Colombia.
Many companies now require employees to supply a one-time password — such as one sent via SMS or produced by a mobile authenticator app — in addition to their username and password when logging in to company assets online. But both SMS and app-based codes can be undermined by phishing attacks that simply request this information in addition to the user’s password.
One multifactor option — physical security keys — appears to be immune to these advanced scams. The most commonly used security keys are inexpensive USB-based devices. A security key implements a form of multi-factor authentication known as Universal 2nd Factor (U2F), which allows the user to complete the login process simply by inserting the USB device and pressing a button on the device. The key works without the need for any special software drivers.
The allure of U2F devices for multi-factor authentication is that even if an employee who has enrolled a security key for authentication tries to log in at an impostor site, the company’s systems simply refuse to request the security key if the user isn’t on their employer’s legitimate website, and the login attempt fails. Thus, the second factor cannot be phished, either over the phone or Internet.
In July 2018, Google disclosed that it had not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical security keys in place of one-time codes.
A security firm has discovered that a six-year-old crafty botnet known as Mylobot appears to be powering a residential proxy service called BHProxies, which offers paying customers the ability to route their web traffic anonymously through compromised computers. Here’s a closer look at Mylobot, and a deep dive into who may be responsible for operating the BHProxies service.
The BHProxies website.
First identified in 2017 by the security firm Deep Instinct, Mylobot employs a number of fairly sophisticated methods to remain undetected on infected hosts, such as running exclusively in the computer’s temporary memory, and waiting 14 days before attempting to contact the botnet’s command and control servers.
Last year, researchers at Minerva Labs spotted the botnet being used to blast out sextortion scams. But according to a new report from BitSight, the Mylobot botnet’s main functionality has always been about transforming the infected system into a proxy.
The Mylobot malware includes more than 1,000 hard-coded and encrypted domain names, any one of which can be registered and used as control networks for the infected hosts. BitSight researchers found significant overlap in the Internet addresses used by those domains and a domain called BHproxies[.]com.
BHProxies sells access to “residential proxy” networks, which allow someone to rent a residential IP address to use as a relay for their Internet communications, providing anonymity and the advantage of being perceived as a residential user surfing the web. The service is currently advertising access to more than 150,000 devices globally.
“At this point, we cannot prove that BHProxies is linked to Mylobot, but we have a strong suspicion,” wrote BitSight’s Stanislas Arnoud.
To test their hypothesis, BitSight obtained 50 proxies from BHProxies. The researchers were able to use 48 of those 50 proxies to browse to a website they controlled — allowing them to record the true IP addresses of each proxy device.
“Among these 48 recovered residential proxies IP addresses, 28 (58.3%) of those were already present in our sinkhole systems, associated with the Mylobot malware family,” Arnoud continued. “This number is probably higher, but we don’t have a full visibility of the botnet. This gave us clear evidence that Mylobot infected computers are used by the BHProxies service.”
BitSight said it is currently seeing more than 50,000 unique Mylobot infected systems every day, and that India appears to be the most targeted country, followed by the United States, Indonesia and Iran.
“We believe we are only seeing part of the full botnet, which may lead to more than 150,000 infected computers as advertised by BHProxies’ operators,” Arnoud wrote.
The website BHProxies[.]com has been advertised for nearly a decade on the forum Black Hat World by the user BHProxies. BHProxies has authored 129 posts on Black Hat World since 2012, and their last post on the forum was in December 2022.
BHProxies initially was fairly active on Black Hat World between May and November 2012, after which it suddenly ceased all activity. The account didn’t resume posting on the forum until April 2014.
According to cyber intelligence firm Intel 471, the user BHProxies also used the handle “hassan_isabad_subar” and marketed various software tools, including “Subar’s free email creator” and “Subar’s free proxy scraper.”
Intel 471’s data shows that hassan_isabad_subar registered on the forum using the email address jesus.fn.christ@gmail.com. In a June 2012 private message exchange with a website developer on Black Hat World, hassan_isabad_subar confided that they were working at the time to develop two websites, including the now-defunct customscrabblejewelry.com.
DomainTools.com reports that customscrabblejewelry.com was registered in 2012 to a Teresa Shotliff in Chesterland, Ohio. A search on jesus.fn.christ@gmail.com at Constella Intelligence, a company that tracks compromised databases, shows this email address is tied to an account at the fundraising platform omaze.com, for a Brian Shotliff from Chesterland, Ohio.
Reached via LinkedIn, Mr. Shotliff said he sold his BHProxies account to another Black Hat World forum user from Egypt back in 2014. Shotliff shared an April 2014 password reset email from Black Hat World, which shows he forwarded the plaintext password to the email address legendboy2050@yahoo.com. He also shared a PayPal receipt and snippets of Facebook Messenger logs showing conversations in March 2014 with legendboy2050@yahoo.com.
Constella Intelligence confirmed that legendboy2050@yahoo.com was indeed another email address tied to the hassan_isabad_subar/BHProxies identity on Black Hat World. Constella also connects legendboy2050 to Facebook and Instagram accounts for one Abdala Tawfik from Cairo. This user’s Facebook page says Tawfik also uses the name Abdalla Khafagy.
Tawfik’s Instagram account says he is a former operations manager at the social media network TikTok, as well as a former director at Crypto.com.
Abdalla Khafagy’s LinkedIn profile says he was “global director of community” at Crypto.com for about a year ending in January 2022. Before that, the resume says he was operations manager of TikTok’s Middle East and North Africa region for approximately seven months ending in April 2020.
Khafagy’s LinkedIn profile says he is currently founder of LewkLabs, a Dubai-based “blockchain-powered, SocialFi content monetization platform” that last year reported funding of $3.26 million from private investors.
The only experience listed for Khafagy prior to the TikTok job is labeled “Marketing” at “Confidential,” from February 2014 to October 2019.
Reached via LinkedIn, Mr. Khafagy told KrebsOnSecurity that he had a Black Hat World account at some point, but that he didn’t recall ever having used an account by the name BHProxies or hassan_isabad_subar. Khafagy said he couldn’t remember the name of the account he had on the forum.
“I had an account that was simply hacked from me shortly after and I never bothered about it because it wasn’t mine in the first place,” he explained.
Khafagy declined to elaborate on the five-year stint in his resume marked “Confidential.” When asked directly whether he had ever been associated with the BHProxies service, Mr. Khafagy said no.
That Confidential job listing is interesting because its start date lines up with the creation of BHproxies[.]com. Archive.org indexed its first copy of BHProxies[.]com on Mar. 5, 2014, but historic DNS records show BHproxies[.]com first came online Feb. 25, 2014.
Shortly after that conversation with Mr. Khafagy, Mr. Shotliff shared a Facebook/Meta message he received that indicated Mr. Khafagy wanted him to support the claim that the BHProxies account had somehow gone missing.
“Hey mate, it’s been a long time. Hope you are doing well. Someone from Krebs on Security reached out to me about the account I got from you on BHW,” Khafagy’s Meta account wrote. “Didn’t we try to retrieve this account? I remember mentioning to you that it got stolen and I was never able to retrieve it.”
Mr. Shotliff said Khafagy’s sudden message this week was the first time he’d heard that claim.
“He bought the account,” Shotliff said. “He might have lost the account or had it stolen, but it’s not something I remember.”
If you liked this story, you may also enjoy these other investigations into botnet-based proxy services:
A Deep Dive Into the Residential Proxy Service ‘911’
911 Proxy Service Implodes After Disclosing Breach
Meet the Administrators of the RSOCKS Proxy Botnet
The Link Between AWM Proxy & the Glupteba Botnet
15-Year-Old Malware Proxy Network VIP72 Goes Dark
Who’s Behind the TDSS Botnet?
ESET Research has compiled a timeline of cyberattacks that used wiper malware and have occurred since Russia’s invasion of Ukraine in 2022
The post A year of wiper attacks in Ukraine appeared first on WeLiveSecurity
SMBs need to not only reduce their odds of being hit by an attack, but also implement processes that they can follow if their defenses are breached
The post ESET SMB Digital Security Sentiment Report: The damaging effects of a breach appeared first on WeLiveSecurity
I found myself going down a previously unexplored rabbit hole recently, or more specifically, what I thought was "a" rabbit hole but in actual fact was an ever-expanding series of them that led me to what I refer to in the title of this post as "6 rabbits deep". It's a tale of firewalls, APIs and sifting through layers and layers of different services to sniff out the root cause of something that seemed very benign, but actually turned out to be highly impactful. Let's go find the rabbits!
When you buy an API key on Have I Been Pwned (HIBP), Stripe handles all the payment magic. I love Stripe, it's such an awesome service that abstracts away so much pain and it's dead simple to integrate via their various APIs. It's also dead simple to configure Stripe to send notices back to your own service via webhooks. For example, when an invoice is paid or a customer is updated, Stripe sends information about that event to HIBP and then lists each call on the webhooks dashboard in their portal:
There are a whole range of different events that can be listened to and webhooks fired, here we're seeing just a couple of them that are self explanatory in name. When an invoice is paid, the callback looks something like this:
HIBP has received this call and updated it's own DB such that for a new customer, they can now retrieve an API key or for an existing customer whose subscription has renewed, the API key validity period has been extended. The same callback is also issued when someone upgrades an API key, for example when going from 10RPM (requests per minute) to 50RPM. It's super important that HIBP gets that callback so it can appropriately upgrade the customer's key and they can immediately begin making more requests. When that call doesn't happen, well, let's go down the first rabbit hole.
This should never happen:
This came in via HIBP's API key support portal and is pretty self-explanatory. I checked the customer's account on Stripe and it did indeed show an active 50RPM subscription, but when drilling down into the associated payment, I found the following:
Ok, so at least I know where things have started to go wrong, but why? Over to the webhooks dashboard and into the failed payments and things look... suboptimal:
Dammit! Fortunately this is only a small single-digit percentage of all callbacks, but every time this fails it's either stopping someone like the guy above from making the requests they've paid for or potentially, causing someone's API key to expire even though they've paid for it. The latter in particular I was really worried about as it would nuke their key and whatever they'd built on top of it would cease to function. Fortunately, because that's such an impactful action I'd built in heaps of buffer for just such an occurrence and I'd gotten onto this issue quickly, but it was disconcerting all the same.
So, what's happening? Well, the response is HTTP 403 "Forbidden" and the body is clearly a Cloudflare challenge page so something at their end is being triggered. Looks like it's time to go down the next rabbit hole.
Desperate just to quickly restore functionality, I dropped into Cloudflare's WAF and allowed all Stripe's outbound IPs used for webhooks to bypass their security controls:
This wasn't ideal, but it only created risk for requests originating from Stripe and it got things up and running again quickly. With time up my sleeve I could now delve deeper and work out precisely what was going on, starting with the logs. Cloudflare has a really extensive set of APIs that can control a heap of features of the service, including pulling back logs (note: this is a feature of their Enterprise plan). I queried out a slice of the logs corresponding to when some of the 403s from Stripe's dashboard occurred and found 2 entries similar to this one:
{"BotScore":1,"BotScoreSrc":"Verified Bot","CacheCacheStatus":"unknown","ClientASN":16509,"ClientCountry":"us","ClientIP":"54.187.205.235","ClientRequestHost":"haveibeenpwned.com","ClientRequestMethod":"POST","ClientRequestReferer":"","ClientRequestURI":"[redacted]","ClientRequestUserAgent":"Stripe/1.0 (+https://stripe.com/docs/webhooks)","EdgeRateLimitAction":"","EdgeResponseStatus":403,"EdgeStartTimestamp":1674073983931000000,"FirewallMatchesActions":["managedChallenge"],"FirewallMatchesRuleIDs":["6179ae15870a4bb7b2d480d4843b323c"],"FirewallMatchesSources":["firewallManaged"],"OriginResponseStatus":0,"WAFAction":"unknown","WorkerSubrequest":false}That's one of Stripe's outbound IP's on 54.187.205.235 and the "FirewallMatchesRuleIDs" collection has a value in it. Ergo, something about this request triggered the firewall and caused it to be challenged. I'm sure many of us have gone through the following thought process before:
What did I change?
Did I change anything?
Did they change something?
Except "they" could have been either Cloudflare or Stripe; if it wasn't me (and I was fairly certain it wasn't), was it a Cloudflare change to the rules or a Stripe change to a webhook payload that was now triggering an existing rule? Time to dig deeper again so it's over to the Cloudflare dashboard and down into the WAF events for requests to the webhook callback path:
Yep, something proper broke! Let's drill deeper and look at recent events for that IP:
As you dig deeper through troubleshooting exercises like this, you gradually turn up more and more information that helps piece the entire puzzle together. In this case, it looks like the "Inbound Anomaly Score Exceeded" rule was being triggered. What's that? And why? Time to go down another rabbit hole.
So, deeper and deeper down the rabbit holes we go, this time into the depths of the requests that triggered the managed rule:
Well that's comprehensive 🙂
There's a lot to unpack here so let's begin with the ruleset that the previously identified "Inbound Anomaly Score Exceeded" rule belongs to, the Cloudflare OWASP Core Ruleset:
The Cloudflare OWASP Core Ruleset is Cloudflare’s implementation of the OWASP ModSecurity Core Rule SetOpen external link (CRS). Cloudflare routinely monitors for updates from OWASP based on the latest version available from the official code repository.
That link is yet another rabbit hole altogether so let me summarise succinctly here: Cloudflare uses OWASP's rules to identify anomalous traffic based on a customer-defined paranoia level (how strict you want to be) and then applies a score threshold (also customer-defined) at which an action will be taken, for example challenging the request. What I learned as this saga progressed is that the "Inbound Anomoly Score Exceeded" rule is actually a rollup of the rules beneath it. The OWASP score of "26" is the sum of the 6 rules listed beneath it and once it exceeds 25, the superset rule is triggered.
Further - and this is the really important bit - Cloudflare routinely updates the rules from OWASP which makes sense because these are ever-evolving in response to new threats. And when did they last upgrade the rules? It looks like they announced it right before I started having issues:
Whilst it's not entirely clear from above when this release was scheduled to occur, I did reach out to Cloudflare support and was advised it had already taken place:
Please note that we did bump the OWASP version, which we are integrating with to 3.3.4 as noted on our scheduled changes.
So maybe it's not Cloudflare's fault or Stripe's fault, but OWASP's fault? In fairness to all, I don't think it's anyone's fault per se and is instead just an unfortunate result of everyone doing their best to keep the bad guys out. Unless... it really is Stripe's fault because there's something in the request payload that was always fishy and is now being caught? But why for only some requests and not others? Next rabbit!
Sometimes, people on the internet lose their minds a bit over things they really shouldn't. One of those things, in my experience, is Cloudflare's interception of traffic and it's something I wrote about in detail nearly 7 years ago now in my piece on security absolutism. Cloudflare plays an enormously valuable role in the internet's ecosystem and a substantial part of the value comes from being able to inspect, cache, optimise, and yes, even reject traffic. When you use Cloudflare to protect your website, they're applying rulesets like the aforementioned OWASP ones and in order to do that, they must be able to inspect your traffic! But they don't log it, not all of it, rather just "metadata generated by our products" as they refer to it on their logs page. We saw an example of that earlier on with Stripe's request from their IP showing it triggered a firewall rule, but what we didn't see is the contents of that POST request, the actual payload that triggered the rule. Let's go grab that.
Because the contents of a POST request can contain sensitive information, Cloudflare doesn't log it. Obviously they see it in transit (that's how OWASP's rules can be applied to it), but it's not stored anywhere and even if you want to capture it, they don't want to be able to see it. That's where payload logging (another Enterprise plan feature) comes in and what's really neat about that is every payload must be encrypted with a public key retained by Cloudflare whilst only you retain the private key. The setup looks like this:
Pretty self-explanatory and once done, right under where we previously saw the additional logs we now have the ability to decrypt the payload:
As promised, this requires the private key from earlier:
And now, finally, we have the actual payload that triggered the rule, seen here with my own test data:
[ " },\n \"billing_reason\": \"subscription_update\",\n \"charge\": null,\n \"collection_method\": \"charge_automatically\",\n \"created\": 1674351619,\n \"currency\": \"usd\",\n \"custom_fields\": null,\n \"customer\": \"cus_MkA71FpZ7XXRlt\",\n \"customer_address\": ", " },\n \"customer_email\": \"troy-hunt+1@troyhunt.com\",\n \"customer_name\": \"Troy Hunt 1\",\n \"customer_phone\": null,\n \"customer_shipping\": null,\n \"customer_tax_exempt\": \"none\",\n \"customer_tax_ids\": [\n\n ],\n \"default_payment_method\": null,\n \"default_source\": null,\n \"default_tax_rates\": [\n\n ],\n \"description\": \"You can manage your subscription (i.e. cancel it or regenerate the API key) at any time by verifying your email address here: https://haveibeenpwned.com/API/Key\",\n \"discount\": null,\n \"discounts\": [\n\n ],\n \"due_date\": null,\n \"ending_balance\": -11804,\n \"footer\": null,\n \"from_invoice\": null,\n \"hosted_invoice_url\": \"https://invoice.stripe.com/i/acct_1EdQYpEF14jWlYDw/test_YWNjdF8xRWRRWXBFRjE0aldsWUR3LF9OREo5SlpqUFFvVnFtQnBVcE91YUFXemtkRHFpQWNWLDY0ODkyNDIw02004bEyljdC?s=ap\",\n \"invoice_pdf\": \"https://pay.stripe.com/invoice/acct_1EdQYpEF14jWlYDw/test_YWNjdF8xRWRRWXBFRjE0aldsWUR3LF9OREo5SlpqUFFvVnFtQnBVcE91YUFXemtkRHFpQWNWLDY0ODkyNDIw02004bEyljdC/pdf?s=ap\",\n \"last_finalization_error\": null,\n \"latest_revision\": null,\n \"lines\": ", " ", " ],\n \"discountable\": false,\n \"discounts\": [\n\n ],\n \"invoice_item\": \"ii_1MSsXfEF14jWlYDwB1nfZvFm\",\n \"livemode\": false,\n \"metadata\": ", " },\n \"period\": ", " },\n \"plan\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4eLcJ7JYF02f\",\n \"tiers_mode\": null,\n \"transform_usage\": null,\n \"trial_period_days\": null,\n \"usage_type\": \"licensed\"\n },\n \"price\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4eLcJ7JYF02f\",\n \"recurring\": ", " },\n \"tax_behavior\": \"unspecified\",\n \"tiers_mode\": null,\n \"transform_quantity\": null,\n \"type\": \"recurring\",\n \"unit_amount\": 15000,\n \"unit_amount_decimal\": \"15000\"\n },\n \"proration\": true,\n \"proration_details\": ", " \"il_1MMjfcEF14jWlYDwoe7uhDPF\"\n ]\n }\n },\n \"quantity\": 1,\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subscription_item\": \"si_N6xapJ8gSXdp7W\",\n \"tax_amounts\": [\n\n ],\n \"tax_rates\": [\n\n ],\n \"type\": \"invoiceitem\",\n \"unit_amount_excluding_tax\": \"-14304\"\n },\n ", " ],\n \"discountable\": true,\n \"discounts\": [\n\n ],\n \"livemode\": false,\n \"metadata\": ", " },\n \"period\": ", " },\n \"plan\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4lTSl4axd9mt\",\n \"tiers_mode\": null,\n \"transform_usage\": null,\n \"trial_period_days\": null,\n \"usage_type\": \"licensed\"\n },\n \"price\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4lTSl4axd9mt\",\n \"recurring\": ", " },\n \"tax_behavior\": \"unspecified\",\n \"tiers_mode\": null,\n \"transform_quantity\": null,\n \"type\": \"recurring\",\n \"unit_amount\": 2500,\n \"unit_amount_decimal\": \"2500\"\n },\n \"proration\": false,\n \"proration_details\": ", " },\n \"quantity\": 1,\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subscription_item\": \"si_NDJ98tQrCcviJf\",\n \"tax_amounts\": [\n\n ],\n \"tax_rates\": [\n\n ],\n \"type\": \"subscription\",\n \"unit_amount_excluding_tax\": \"2500\"\n }\n ],\n \"has_more\": false,\n \"total_count\": 2,\n \"url\": \"/v1/invoices/in_1MSsXfEF14jWlYDwxHKk4ASA/lines\"\n },\n \"livemode\": false,\n \"metadata\": ", " },\n \"next_payment_attempt\": null,\n \"number\": \"04FC1917-0008\",\n \"on_behalf_of\": null,\n \"paid\": true,\n \"paid_out_of_band\": false,\n \"payment_intent\": null,\n \"payment_settings\": ", " },\n \"period_end\": 1674351619,\n \"period_start\": 1674351619,\n \"post_payment_credit_notes_amount\": 0,\n \"pre_payment_credit_notes_amount\": 0,\n \"quote\": null,\n \"receipt_number\": null,\n \"rendering_options\": null,\n \"starting_balance\": 0,\n \"statement_descriptor\": null,\n \"status\": \"paid\",\n \"status_transitions\": ", " },\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subtotal\": -11804,\n \"subtotal_excluding_tax\": -11804,\n \"tax\": null,\n \"test_clock\": null,\n \"total\": -11804,\n \"total_discount_amounts\": [\n\n ],\n \"total_excluding_tax\": -11804,\n \"total_tax_amounts\": [\n\n ],\n \"transfer_data\": null,\n \"webhooks_delivered_at\": 1674351619\n }\n },\n \"livemode\": false,\n \"pending_webhooks\": 1,\n \"request\": ", " },\n \"type\": \"invoice.paid\"\n}" ]But enough of what's present in the payload, it's what's absent that especially struck me. No obvious XSS patterns, nor SQL injection or any other suspicious looking strings. The request looked totally benign, so why did it trigger the rule?
I wanted to compare the payload of a blocked request with a similar request that wasn't blocked, but they're only logged at Cloudflare when they trigger a rule. No problem, it's easy to grab the full request from Stripe's webhook history so I found one that passed and one that failed and diff'd them both:
This clearly isn't the full 200 lines, but it's a very similar story over the remainder of the files; tiny differences largely down to dates, IDs, and of course, the customers themselves. No suspicious patterns, no funky characters, nothing visibly abnormal. It's a bit pointless to even mention it because they're near identical, but the payload on the left is the one that passed the firewall whilst the payload on the right was blocked.
Next rabbit hole!
Completely running out of ideas and options, focus moved to the folks inside Cloudflare who were already aware there was an issue:
We are actively looking into this and will likely release an update to the Cloudflare OWASP ruleset soon
— Michael Tremante (@MichaelTremante) January 20, 2023
What followed was a period of back and forth initially with Cloudflare, then Stripe as well with everyone trying to nut out exactly where things were going wrong. Essentially, the process went like this:
Is Cloudflare inadvertently blocking the requests?
Is the OWASP ruleset raising false positives?
Is Stripe issuing requests that are deemed to be malicious?
And round and round we went. At one time, Cloudflare identified a change in the OWASP ruleset which appeared to have resulted in their implementation inadvertently triggering the WAF. They rolled it back and... the same thing happened. We deferred back to Stripe on the assumption that something must have changed on their end, but they couldn't identify any change that would have any sort of material impact. We were stumped, but we also had an easy fix just one last rabbit hole away...
The joy of a managed firewall is that someone else takes all the rigmarole of looking after it away. I'm going to talk more about that in the summary shortly but clearly, that also creates risk as you're delegating control of traffic flow to someone else. Fortunately, Cloudflare gives you a load of configurability with their managed rules which makes it easy to add custom exceptions:
This meant I could create a simple exception that was much more intelligent than the previous "just let all outbound Stripe IPs in" by filtering down to the specific path those webhooks were flowing in to:
And finally, because sequence matters, I dragged that rule right up to the top of the pile so it would cause matching inbound requests to skip all the other rules:
And finally, there were no more rabbits 😊
I know what you're thinking - "what was the actual root cause?" - and to be honest, I still don't know. I don't know if it was Cloudflare or OWASP or Stripe or if it even impacted other customers of these services and to be honest, yes, that's a little frustrating. But I learned a bunch of stuff and for that alone, this was a worthwhile exercise I took three big lessons away from:
Firstly, understanding the plumbing of how all these bits work together is super important. I was lucky this wasn't a time critical issue and I had the luxury of learning without being under duress; how rules, payload inspection and exception management all work together is really valuable stuff to understand. And just like that, as if to underscore my first point, I found this right before hitting the publish button on the blog post:
I added a couple more OWASP rules to the exception in Cloudflare (things like a MySQL rule that was adding 5 points), and we were back in business.
Secondly, I look at the managed WAF Cloudflare provides more favourably than I did before simply because I have a better understanding of how comprehensive it is. I want to write code and run apps on the web, that's my focus, and I want someone else to provide that additional layer on top that continuously adapts to block new and emerging threats. I want to understand it (and I now do, at least certainly better than before), but I don't want managing it day in and day out to be my job.
And finally, IMHO, Stripe needs a better mechanism to report on webhook failures:
In live mode you are notified after 3 days of trying. You can also query the events (https://t.co/0mujOPssV0) to create a running list of statuses on web hooks that have been sent and alert on that via your own app.
— Blake Krone (@blakekrone) January 19, 2023
Waiting until stuff breaks really isn't ideal and whilst I'm sure you could plug into the (very extensive) API ecosystem Stripe has, this feels like an easy feature for them to build in. So, Stripe friends, when you read this that's a big "yes" vote from me for some form of anomalous webhook response alerting.
This experience was equal parts frustration and fun and whilst the former is probably obvious, the latter is simply due to having an opportunity to learn something new that's a pretty important part of the service I run. May my frustrated fun story here make your life easier in the future if you face the same problems 😊
Millions of Americans receiving food assistance benefits just earned a new right that they can’t yet enforce: The right to be reimbursed if funds on their Electronic Benefit Transfer (EBT) cards are stolen by card skimming devices secretly installed at cash machines and grocery store checkout lanes.
On December 29, 2022, President Biden signed into law the Consolidated Appropriations Act of 2023, which — for the first time ever — includes provisions for the replacement of stolen EBT benefits. This is a big deal because in 2022, organized crime groups began massively targeting EBT accounts — often emptying affected accounts at ATMs immediately after the states disperse funds each month.
EBT cards can be used along with a personal identification number (PIN) to pay for goods at participating stores, and to withdraw cash from an ATM. However, EBT cards differ from debit cards issued to most Americans in two important ways. First, most states do not equip EBT cards with smart chip technology, which can make the cards more difficult and expensive for skimming thieves to clone.
More critically, EBT participants traditionally have had little hope of recovering food assistance funds when their cards were copied by card-skimming devices and used for fraud. That’s because while the EBT programs are operated by individually by the states, those programs are funded by the U.S. Department of Agriculture (USDA), which until late last year was barred from reimbursing states for stolen EBT funds.
The protections passed in the 2023 Appropriations Act allow states to use federal funds to replace stolen EBT benefits, and they permit states to seek reimbursement for any skimmed EBT funds they may have replaced from their own coffers (dating back to Oct. 1, 2022).
But first, all 50 states must each submit a plan for how they are going to protect and replace food benefits stolen via card skimming. Guidance for the states in drafting those plans was issued by the USDA on Jan. 31 (PDF), and states that don’t get them done before Feb. 27, 2023 risk losing the ability to be reimbursed for EBT fraud losses.
Deborah Harris is a staff attorney at The Massachusetts Law Reform Institute (MLRI), a nonprofit legal assistance organization that has closely tracked the EBT skimming epidemic. In November 2022, the MLRI filed a class-action lawsuit against Massachusetts on behalf of thousands of low-income families who were collectively robbed of more than $1 million in food assistance benefits by card skimming devices secretly installed at cash machines and grocery store checkout lanes across the state.
Harris said she’s pleased that the USDA guidelines were issued so promptly, and that the guidance for states was not overly prescriptive. For example, some security experts have suggested that adding contactless capability to EBT cards could help participants avoid skimming devices altogether. But Harris said contactless cards do not require a PIN, which is the only thing that stops EBT cards from being drained at the ATM when a participant’s card is lost or stolen.
Then again, nothing in the guidance even mentions chip-based cards, or any other advice for improving the physical security of EBT cards. Rather, it suggests states should seek to develop the capability to perform basic fraud detection and alerting on suspicious transactions, such as when an EBT card that is normally used only in one geographic area suddenly is used to withdraw cash at an ATM halfway across the country.
“Besides having the states move fast to approve their plans, we’d also like to see a focused effort to move states from magstripe-only cards to chip, and also assisting states to develop the algorithms that will enable them to identify likely incidents of stolen benefits,” Harris said.
Harris said Massachusetts has begun using algorithms to look for these suspicious transaction patterns throughout its EBT network, and now has the ability to alert households and verify transactions. But she said most states do not have this capability.
“We have heard that other states aren’t currently able to do that,” Harris said. “But encouraging states to more affirmatively identify instances of likely theft and assisting with the claims and verification process is critical. Most households can’t do that on their own, and in Massachusetts it’s very hard for a person to get a copy of their transaction history. Some states can do that through third-party apps, but something so basic should not be on the burden of EBT households.”
Some states aren’t waiting for direction from the federal government to beef up EBT card security. Like Maryland, which identified more than 1,400 households hit by EBT skimming attacks last year — a tenfold increase over 2021.
Advocates for EBT beneficiaries in Maryland are backing Senate Bill 401 (PDF), which would require the use of chip technology and ongoing monitoring for suspicious activity (a hearing on SB401 is scheduled in the Maryland Senate Finance Commission for Thursday, Feb. 23, at 1 p.m.).
Michelle Salomon Madaio is a director at the Homeless Persons Representation Project, a legal assistance organization based in Silver Spring, Md. Madaio said the bill would require the state Department of Human Services to replace skimmed benefits, not only after the bill goes into effect but also retroactively from January 2020 to the present.
Madaio said the bill also would require the state to monitor for patterns of suspicious activity on EBT cards, and to develop a mechanism to contact potentially affected households.
“For most of the skimming victims we’ve worked with, the fraudulent transactions would be pretty easy to spot because they mostly happened in the middle of the night or out of state, or both,” Madaio said. “To make matters worse, a lot of families whose benefits were scammed then incurred late fees on many other things as a result.”
It is not difficult to see why organized crime groups have pounced on EBT cards as easy money. In most traditional payment card transactions, there are usually several parties that have a financial interest in minimizing fraud and fraud losses, including the bank that issued the card, the card network (Visa, MasterCard, Discover, etc.), and the merchant.
But that infrastructure simply does not exist within state EBT programs, and it certainly isn’t a thing at the inter-state level. What that means is that the vast majority of EBT cards have zero fraud controls, which is exactly what continues to make them so appealing to thieves.
For now, the only fraud controls available to most EBT cardholders include being especially paranoid about where they use their cards, and frequently changing their PINs.
According to USDA guidance issued prior to the passage of the appropriations act, EBT cardholders should consider changing their card PIN at least once a month.
“By changing PINs frequently, at least monthly, and doing so before benefit issuance dates, households can minimize their risk of stolen benefits from a previously skimmed EBT card,” the USDA advised.
No longer relegated to a side-show, tech is embedded into virtually every new piece of gear entering the battlefield
The post Security amidst a global frost appeared first on WeLiveSecurity
