Visa Warns of Fresh Skimmer Targeting E-Commerce Sites


Visa Warns of Fresh Skimmer Targeting E-Commerce Sites

Visa's payment fraud disruption team is warning of a recently uncovered digital skimmer called "Baka" that is stealing payment card data from e-commerce sites while hiding from security tools.

Researchers discovered the malicious code while examining a command-and-control infrastructure that previously hosted the ImageID skimmer.

Although Baka functions similarly to other JavaScript skimmers, the Visa fraud team found that this malicious code is able to load dynamically into e-commerce sites and then hide from security tools using obfuscation techniques, according to the Visa alert.

The Baka skimmer has been found in "several merchant websites across multiple global regions," the alert notes, but it does not provide further details.

"The most compelling components of this kit are the unique loader and obfuscation method," the Visa alert notes. "The skimmer loads dynamically to avoid static malware scanners and uses unique encryption parameters for each victim to obfuscate the malicious code. ... This skimmer variant avoids detection and analysis by removing itself from memory when it detects the possibility of dynamic analysis with developer tools or when data has been successfully exfiltrated."

How Baka Works

The Visa alert does not indicate how Baka is initially delivered to a network. But the report notes that the malicious code is hosted on several suspicious domains, including: jquery-cycle[.]com, b-metric[.]com, apienclave[.]com, quicdn[.]com, apisquere[.]com, ordercheck[.]online and pridecdn[.]com.

Once the initial infection takes hold, the skimmer is uploaded through the command-and-control server, but the code loads in memory. This means the malware is never present on the targeted e-commerce firm's server or saved to another device, helping it to avoid detection, according to the alert.

"The skimming payload decrypts to JavaScript written to resemble code that would be used to render pages dynamically," according to Visa.

Once embedded in an e-commerce site's checkout page, the skimmer begins to collect payment and other customer data from various fields and sends the information to the fraudsters' command-and-control server, Visa notes.

Once data exfiltration is complete, Baka performs a "clean-up" function that removes the skimming code from the checkout page, according to the alert. This also helps ensure that JavaScript is not spotted by anti-malware tools.

Visa's analysts found that the operators behind Baka use an XOR cipher as a way to obscure the malicious code and further hide it from detection, according to the alert.

"While the use of an XOR cipher is not new, this is the first time Visa has observed its use in JavaScript skimming malware," according to the alert.

Mitigating risks

The Visa alert advises e-commerce merchants to take several steps to mitigate skimming risks, including:

  • Run regular checks to determine if any code is attempting to communicate with a known command-and-control server;
  • Check code added through a service provider;
  • Vet content delivery networks and other third parties that have access to the checkout function;
  • Update and patch any software or services used on checkout sites and consider adding a firewall;
  • Limit access to online administrative portals and ensure that those with access use strong passwords.

Other Skimming Attacks

In November 2019, Visa researchers uncovered another type of skimmer called Pipka that had the ability to remove itself from the HTML of a compromised payment website after it executed, enabling it to avoid security detection (see: New JavaScript Skimmer Found on E-Commerce Sites).

Other security researchers have more recently warned about ongoing attacks against e-commerce websites using malicious JavaScript to steal payment card data.

For example, in August, security firm Group-IB warned of a cybercriminal gang called "UltraRank" that is using malicious code to skim payment card data and then selling that information to others on its own underground site (see: 'UltraRank' Gang Sells Card Data It Steals).

Earlier this month, security firm Malwarebytes warned that some fraudsters have started using encrypted messages on Telegram to steal data faster (see: Fraudsters Use Telegram App to Steal Payment Card Data).


BREAKING: Alleged Twitter Hacker Arrested

The alleged Twitter hacker has been arrested, The Wall Street Journal reports. Graham Ivan Clark, of Tampa, was arrested and charged as an adult on July 31, 2020. Clark faces 30 felony charges related to the hack, the report says.
The Twitter hack affected multiple celebrity and public official accounts, and tricked users into sending bitcoin to hackers. The Twitter attack raises serious economic, financial, political and national security concerns ahead of the 2020 U.S. Presidential Election.
How was Twitter security breached, who got hacked and what steps will the social media company take to further strengthen its platform? Here’s a regularly updated blog tracking the incident, Twitter’s investigation and corrective measures, and the high-stakes effort to keep social media secure.
Note: Blog originally published on July 16, 2020. Updated regularly thereafter with the latest investigation news.

Twitter Statements About Security Incident

In a July 18, 2020 statement about the security incident, Twitter indicated:
  • attackers targeted certain Twitter employees through a social engineering scheme.
  • The attackers successfully manipulated a small number of employees and used their credentials to access Twitter’s internal systems, including getting through two-factor protections.
  • 130 Twitter accounts were targeted.
  • For 45 of those accounts, the attackers were able to initiate a password reset, login to the account, and send Tweets.
  • For up to eight of the Twitter accounts involved, the attackers took the additional step of downloading the account’s information through our “Your Twitter Data” tool.
  • Twitter’s incident response team secured and revoked access to internal systems to prevent the attackers from further accessing the systems and the individual accounts.
  • For the 130 accounts that were targeted, attackers were not able to view previous account passwords, as those are not stored in plain text or available through the tools used in the attack. Attackers were able to view personal information including email addresses and phone numbers, which are displayed to some users of our internal support tools. In cases where an account was taken over by the attacker, they may have been able to view additional information. Our forensic investigation of these activities is still ongoing.

More Twitter Breach Investigation Updates:

  • Twitter said hackers who breached its systems likely read the direct messages of 36 accounts, including one belonging to an elected official in the Netherlands. SourceReuters, July 22, 2020.
  • More than a thousand Twitter employees and contractors as of early 2020 had access to internal tools that could change user account settings and hand control to others, making it hard to defend against the hacking that occurred in mid-July. SourceReuters, July 23, 2020.
  • The breach involved hackers using phone-based spear phishing. Essentially, hackers gained entry to Twitter’s network by reaching out to Twitter employees on their phones. SourceTwitter, July 30, 2020.
Twitter emphasized that the investigation is ongoing, and the details above could change.

Twitter Hacked: Information About the Breach

Note: Information below published on MSSP Alert on July 16, 2020 through July 17, 2020.
  • How Did Twitter Get Hacked/Breached?: A hacker allegedly gained access to a Twitter “admin” tool on the social media network that allowed them to hijack high-profile Twitter accounts to spread a cryptocurrency scam. SourceTechCrunch, July 16, 2020.
  • Which Twitter Accounts Got Hijacked?: The accounts of U.S. presidential candidate Joe Biden, reality TV star Kim Kardashian, former U.S. President Barack Obama, Tesla and Space-X founder Elon Musk, and Microsoft co-founder Bill Gates were allegedly victimized. SourceReuters, July 15, 2020.
  • How Many Twitter Accounts Were Victimized?: Hackers targeted about 130 accounts during the cyber attack this week. Twitter continues to assess whether the attackers were able to access private data of the targeted accounts. SourceReuters, July 16, 2020.
  • What did Twitter Initially Say About the Security Incident?: Twitter’s security account posted around 5:45 p.m. EDT on July 15, 2020 that the company was investigating the incident and taking steps to rectify it. Within roughly a half hour, the company took the extraordinary step of limiting posts from verified accounts with blue check marks, which Twitter generally designates for more prominent users. Twitter, late July 15, said it believed the hackers perpetrated the attack by targeting employees who had access to the company’s internal systems and tools. The hackers may have accessed information or engaged in other malicious activity, Twitter said, adding it was still investigating the incident. The company didn’t say how long the hackers had been able to access its internal systems. Twitter said it had limited access to internal systems in response to the hack and locked compromised accounts. SourceThe Wall Street Journal, July 15, 2020.
  • How is the U.S. Government Investigating the Twitter Hack?: The FBI’s San Francisco office has launched an investigation into the incident. SourceReuters, July 16, 2020.

Twitter Hacked: The Bigger Concerns

  • Why Should MSSPs Care?: At first, there was  concern that Twitter hackers may have bypassed two-factor authentication (2FA) security settings. But now, the concern has shifted to how hackers allegedly gained control of Twitter’s administration tool(s). Similarly, MSSP administration tools — including remote control and remote access software — have been popular hacker targets for infiltrating end-customer systems.
  • Why Are Regulators Concerned?: The Twitter breach raises serious questions and concerns — especially ahead of the 2020 U.S. Presidential Election. Hackers who gain control of social media administration tools can, in theory, spread misinformation that potentially manipulates financial markets, elections, international relations, protests, and overall confidence in political systems.
This remains a developing story. Check back for ongoing updates about the breach.

Google Android RCE Bug Allows Attacker Full Device Access

The vulnerability is one of 39 affecting various aspects of the mobile OS that the company fixed in a security update this week.
Google has patched a vulnerability in its Android OS that could allow attackers to completely take over someone’s device to install programs, steal or change data, or create new accounts with full privileges.
The flaw (CVE-2020-0103) was one of 39 vulnerabilities affecting Android OS builds that use older security profiles and are spread throughout various components of Android that the company fixed in its latest security patch, according to a security bulletin published Monday.
The vulnerabilities pose a high risk for consumers as well as business and government institution users, the company said. However, the most critical of these—found in the System component of Android–could allow for remote code execution (RCE), depending on the existing privileges on the device, according to Google.
“The most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process,” the company wrote in the bulletin.
However, the potential for exploitation depends on the privilege status of an application, according to the Center for Internet Security’s (CIS’s) advisory on the flaw.
“If this application has been configured to have fewer user rights on the system, exploitation of the most severe of these vulnerabilities could have less impact than if it was configured with administrative rights,” according to the post.
These vulnerabilities could be exploited through multiple methods such as email, web browsing and multimedia services (MMS) when processing media files, CIS explained in its post.
“Depending on the privileges associated with the application, an attacker could then install programs; view, change or delete data; or create new accounts with full user rights,” according to the post. However, so far none of the vulnerabilities patched in the update have been exploited in the wild, according to CIS.
The critical flaw was one of eight that Google patched for the System component of Android. The rest of the flaws were rated high-severity, except for one, which was rated moderate.
Google also patched a critical flaw in Android’s Framework component, CVE-2020-0096, that could enable a local attacker to execute arbitrary code within the context of a privileged process, the company said. The vulnerability was one of three patched in this component, the other two of which had a severity rating of high.
The only other critical vulnerability patched was a critical security vulnerability, CVE-2020-3641, found in the Qualcomm closed-source components. The flaw was one of 10 patched in these components, the rest of which were rated as high severity.
The security update also fixes four high-severity vulnerabilities in Android’s Media framework; eight high-severity vulnerabilities in Qualcomm components; four high-severity flaws in MediaTek components; and two high-severity vulnerabilities in Android Kernel components.
While the Android security platform and service protections such as Google Play Protect “reduce the likelihood that security vulnerabilities could be successfully exploited on Android,” Google recommended that Android users install the latest security patch just to be on the safe side.
Indeed, Google has historically struggled with the spread of malware via Android apps being downloaded from the Google Play store and has made a concerted effort in the last year and a half to try to stay on top of it.
Still, malware on the platform persists. Just last week researchers discovered a new Android mobile malware called EventBot that steals payment data from users of popular financial apps like PayPal, Barclays, CapitalOne and more.

Source: ThreatPost

WhatsApp MP4 Videos Flaw allows Hackers to execute Code Remotely

A new bug on Whatsapp, based on MP4 videos flaws, has been revealed by Facebook. This vulnerability could lead to denial of service attacks or remote code execution. Facebook has revealed the existence of a serious vulnerability resulting a potential remote code execution attacks in Whatsapp messaging software. Last week, the tech giant said in a security advisory that the Whatsapp bug, known as CVE-2019-11931, is a stack-based buffer overflow issue that can be triggered by attackers sending .MP4 video files to the victims.
A stack-based buffer overflow could be triggered in WhatsApp by sending a specially crafted MP4 file to a WhatsApp user. The issue was present in parsing the elementary stream metadata of an MP4 file and could result in a DoS or RCE. This affects Android versions prior to 2.19.274, iOS versions prior to 2.19.100, Enterprise Client versions prior to 2.25.3, Business for Android versions prior to 2.19.104 and Business for iOS versions prior to 2.19.100.
A stack-based buffer overflow could be triggered in WhatsApp by sending a specially crafted MP4 file to a WhatsApp user. The issue was present in parsing the elementary stream metadata of an MP4 file and could result in a DoS or RCE. This affects Android versions prior to 2.19.274, iOS versions prior to 2.19.100, Enterprise Client versions prior to 2.25.3, Windows Phone versions before and including 2.18.368, Business for Android versions prior to 2.19.104, and Business for iOS versions prior to 2.19.100.
Although there are not many technical details available, Facebook has presented this problem as being caused by the way the application parses MP4 elementary stream metadata. If exploited, the vulnerability can lead to denial of service (DoS) or remote code execution (RCE) attacks.

In October, a Awakened a cybersecurity researcher discovered a free dual vulnerability, CVE-2019-11932, that could be used in attacks to compromise chat sessions, files, and messages. This double free vulnerability in the DDGifSlurp function in decoding.c in libpl_droidsonroids_gif before 1.2.15, as used in WhatsApp for Android before 2.19.244, allows remote attackers to execute arbitrary code or cause a denial of service.
When a WhatsApp user opens Gallery view in WhatsApp to send a media file, WhatsApp parses it with a native library called to generate the preview of the GIF file. is an open-source library with source codes available at Github.
A GIF file contains multiple encoded frames. To store the decoded frames, a buffer with name rasterBits is used. If all frames have the same size, rasterBits is re-used to store the decoded frames without re-allocation. However, rasterBits would be re-allocated if one of three conditions below is met:
  • Width height > originalWidth originalHeight
  • Width - originalWidth > 0
  • Height - originalHeight > 0
Re-allocation is a combination of free and malloc. If the size of the re-allocation is 0, it is simply a free. Let say we have a GIF file that contains 3 frames that have sizes of 100, 0 and 0.
  • After the first re-allocation, we have info->rasterBits buffer of size 100.
  • In the second re-allocation of 0, info->rasterBits buffer is freed.
  • In the third re-allocation of 0, info->rasterBits is freed again.
This results in a double-free vulnerability. The triggering location can be found in decoding.c:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth;
int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight;
const uint_fast32_t newRasterSize =
        gifFilePtr->Image.Width * gifFilePtr->Image.Height;
if (newRasterSize > info->rasterSize || widthOverflow > 0 ||
    heightOverflow > 0) {
    void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize,
    if (tmpRasterBits == NULL) {
        gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM;
    info->rasterBits = tmpRasterBits;
    info->rasterSize = newRasterSize;
Another set of interesting vulnerabilities in the email application was revealed by Check Point a month ago. The set of bugs "could allow the actors of the threat to intercept and manipulate messages sent in private and group conversations," said the researchers, and could be used as a weapon to exploit the functions of the "quote" group, answers and private messages. More information about this vulnerability can be found in the article (POC) wrote by Awakened.

Users are advised to update their software versions to mitigate the risk of exploitation. However, there do not appear to be any reports of vulnerability exploited actively in the wild. Whatsapp is constantly working to improve the security of our service, said a Facebook spokesman. "We publish public reports on potential issues that we have resolved, in line with industry best practices, in which case there is no reason to believe that users have been affected," said the American giant.

Source: @neoslab

Experts: Don't reboot your computer after you've been infected with ransomware

Security experts don't recommend that users reboot their computers after suffering a ransomware infection, as this could help the malware in certain circumstances.
Instead, experts recommend that victims hibernate the computer, disconnect it from their network, and reach out to a professional IT support firm. Powering down the computer is also an alternative, but hibernating it is better because it saves a copy of the memory, where some shoddy ransomware strains may sometimes leaves copies of their encryption keys [12].
Experts are recommending against PC reboots because a recent survey of 1,180 US adults who fell victim to ransomware in the past years has shown that almost 30% of victims chose to reboot their computers as a way to deal with the infection.

Image: Simoiu et al.
But while rebooting in safe mode is a good way of removing older screenlocker types of ransomware, it is not recommended when dealing with modern ransomware versions that encrypt files.
"Generally, the [ransomware] executable that actually encrypts your data is designed to crawl through attached, mapped and mounted drives to a given machine. Sometimes it trips, or is blocked by a permission issue and will stop encrypting," Bill Siegel, CEO & Co-Founder of Coveware, a company that provides ransomware data recovery services told ZDNet in an email this week.
"If you reboot the machine, it will start back up and try to finish the job," Siegel said.
"A partially encrypted machine is only partially encrypted due to some fortunate error or issue, so victims should take advantage and NOT let the malware finish its job...don't reboot!"
Siegel told ZDNet the advice applies to both enterprise and home users alike.
Further, ransomware victims should also take note that there are two stages of a ransomware recovery process they have to go through
The first is finding the ransomware's artifacts -- such as processes and boot persistence mechanisms -- and removing them from an infected host.
Second is restoring the data if a backup mechanism is available.
Siegel warns that when companies miss or skip on the first step, rebooting the computer often restarts the ransomware's process and ends up encrypting the recently-restored files, meaning victims will have to restart the data recovery process from scratch.
In the case of enterprises, this increases downtime and costs the company operating profits.

Sleeping with the Friend-Enemy: Mobile Apps and their SDKs

Third party SDKs can undermine the security of your mobile app, all unbeknownst to you. Mobile applications, including iOS, Android, and WinMo apps, are built using native code usually written by developer teams; however, a chunk of the code is always sourced from 3rd party SDKs (commercial or open source). Leveraging external components is very normal for mobile apps, as 99% of all apps have some sort of 3rd-party commercial or open source SDK embedded in the binary. So what is the problem here? The big issue is that 3rd-party SDKs have FULL access to the app 's private data, permissions, network connections, TLS sessions, etc. There is no separation nor sandbox between the app’s internal code and the 3rd-party SDK. Once the SDK is included, the SDK *is* the app too, which includes all commercial for-profit SDKs and as well as the two-person developer projects on GitHub.
  • Okay, so yeah, what is the problem here?
The problem is that 3rd-party SDKs, an unvetted, uncontrolled, and unknown source, have:
  1. Access to the entire app *and* all its data
    1. SDKs can read, write, or delete any data located in private storage
  2. Access to the app’s TLS layer
    1. SDKs can disable TLS for the entire app (to all endpoints, not just the SDK’s)
  3. Access to the parent’s app’s existing permission
    1. SDKs can pull data from the device, including end-user
      1. Contact Lists
      2. Geo-Location
      3. SMS Logs
      4. Photos
      5. Camera
      6. Microphone
      7. [any device permission the parent app has been granted]
  4. Basically, the SDK has access to anything the app has access to
An Illustration of the Issue
Let’s take a quick look at MDLive, a popular medical app that connects doctors with end-users in need of medical assistance. MDLive has 10+ third party SDKs in its iOS mobile app, which is very normal. One of its SDKs is called TestFairy, a popular tool to help developers distribute apps to internal teams, collect logs, solicit user feedback, obtain crash reports, and record videos of end-user activity. These features help developers improve their mobile apps from one release to the next.
Well, it turns out the 3rd Party SDK (TestFairy) has an awesome "Video Recording" feature that has significant security and privacy implications. According to federal courts in the state Florida, the MDLive app was taking screenshots of real end-user activity, which includes all presented data, and sending it to a 3rd party (TestFairy). Well, what actually happened is that the TestFairy SDK was configured to collect screenshots of live user activity (it just looked like MDLive since there is no distinction from the App and its SDKs). Since the MDLive app leverages medical data, this equates to a 3rd party SDK receiving ePHI data of several thousand MDLive users (on another apps, the data could very well be credit card numbers, social security numbers, account balances, etc.).
  • So what went wrong here?
MDLive's mobile developers chose a SDK to improve their work flow, which is the right thing to do. Unfortunately, they enabled a feature from the SDK that collects end-user data from live app sessions. Did the security team know that TestFairy was being used? Did the security team know that TestFairy is collecting screenshots with live end-user data and sending it to TestFairy's headquarters, which happened to be in Israel? As a reminder, developer choose a variety of SDKs to enhance their app on an everyday basis, which is nothing new. The problem is that 1 of the 10+ SDKs had a significant security issue associated with it, which no one knew about until the federal courts got involved.
Okay, how does this issue compare to other attack classes, within mobile app security or other platforms? In our opinion, this attack surface is considerable, considering the amount of data that can be compromised. Let’s compare the major attack classes from client/server apps, web apps, and mobile apps altogether, which is shown below in Table 1.0. We will compare buffer overflows, SQL InjectionCross-Site Scripting, and Mobile SDKs.
Table 1.0
As shown above, buffer overflows still rule the Win32 world; however, attacks on windows native apps are less common (and not as sexy anymore). SQL Injection still reigns strong for web apps, but notice SDKs actually have stronger impact on data than Cross-Site Scripting. While XSS and SDKs mirror each other in terms of the full control of data, developer sourced, and customer data, SDKs can gather large volumes of data with just one attack, where reflected XSS cannot (only persistent could). Furthermore, misbehaving SDKs are a bit harder to detect as several SDKs are legitimate, not evil at all. An enemy that looks like a friend is much harder to defend against than something known to be evil.
  • Okay, so what have we learned today?
SDKs are a major blind-spot for enterprise security teams, as the emerging attack surface can destroy a mobile app’s security model with behavior that developers perform everyday. While traditional app security teams focus on security flaws within the app, rightfully so, many of them are not aware of this attack surface at all. App security teams usually have 1) no idea which commercial/open source SDKs are bundled in the app 2) nor do they know which SDKs introduce security issues to the app.
More Real-world Examples
  • Okay, so where else is this happening?
Well, all over the place. To date, Data Theorem, Google, the FTC, and Fireeye have published most of the articles on this topic. A few examples are below:
  • Kochava SDK (Android)
    • Issue: Disables TLS Certificate Validation on the entire app and its connections
    • Source: Data Theorem, Inc.
  • Silverpush
    • Issue: Tracks user habits without the user knowledge or permission
    • Source: Federal Trade Commission
  • VPon
    • Issue: Records audio, captures videos, collects geo-location & contacts
    • Source: Google, Inc.
  • iBackdoor (Not a legitimate SDK, but rather a purposely built library to steal data)
    • Issue: Collects audio, screenshots, geo-location, and accessed data in private storage/iOS keychain
    • Source: Fireeye, Inc.
Please note, these four SDKs are not exhaustive, just a small sample.
  • "What did the president know, and when did he know it"
A famous quote by Howard Baker in the middle of the Watergate scandal. Now that you know of this new class of issues, how do your apps rank? Data Theorem scans the App Store/Google Play on a daily basis, so if you have any concerns about your apps or their SDKs, please feel free to contact us and we’ll let you know either way free-of-charge. A full list of apps that have security or privacy issues sourced from a third party SDKs are listed below:
NO, the sky is not falling. Data Theorem has dynamically scanned over 10,000 SDKs and like everything else, 80% of them are just fine. 80/20 rule applies here too, where 20% of the SDKs cause 80% of the problems. Many of these SDKs introduce security issues by mistake, while others were purposely built to attack mobile apps and their data.
  • What’s next, what should I be doing?
There are a few next steps here:
  1. Visibility is critical
    1. Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s):
      1. Developers usually have a list of the SDKs somewhere, but not necessarily in a consolidated format
      2. Data Theorem provides real-time visibility for your mobile apps and it's 3rd-Party SDKs for free
  2. Continuous testing
    1. Each commercial SDK and/or open source library, and each version of it, needs to be evaluated for the following items:
      1. What data, if any, does the SDK pull from the app?
      2. What security issues, if any, does the SDK introduce to the app?
      3. If the SDK is commercial…
        1. What are the privacy terms of the SDK?
        2. What security audits have been performed?
      4. If the library is open source…
        1. Who has reviewed the code for security flaws?
As you can see from the above, this is no easy task. Item number 2 is easy on paper, but hard to implement at-scale since it needs to be continuous and completed for every app’s release. Despite the challenge, it is something that must be done, as an absence of any action could very well lead to the compromise of large volumes of data (both consume or enterprise data).

By: Data Theorem courtesy of Peerlyst