Search This Blog

Powered by Blogger.

Blog Archive

Labels

About Me

Showing posts with label TLS. Show all posts

New Android Threat Raises Concern Over NFC Relay Attack Vulnerabilities

 


In recent times, there has been considerable concern with regards to some newly uncovered Android-based malware-as-a-service (Maas) platforms, particularly those based on Android and known as SuperCard X. This is because this platform was able to execute these attacks in near-field communication (NFC). A sophisticated tool such as this enables threat actors to make unauthorised contactless payments, allowing them to withdraw money without requiring direct physical access to their cards. 

Through advanced near-field communication (NFC) relay techniques, this malware is able to allow threat actors to authorize illicit transactions at contactless-enabled ATMs and Point-of-Sale (POS) terminals without actually requiring the victim to give them their card details. Using such methods, the attacker deceives users into installing a malicious Android application, during which their payment cards are tapped against their compromised devices. 

The sensitive data from the NFC tags is intercepted and relayed in real time to the attacker-controlled infrastructure while the attack is taking place. It appears that the platform has been part of a Malware-as-a-Service MaasS) ecosystem for Chinese-speaking users. In addition, it appears to have a significant amount of code overlap with NGate, a malicious NFC toolkit that was previously documented by ESET in 2024. The campaign has had a wide-reaching impact on not only banking customers but also credit card issuers and payment processors as well. 

With the help of widely adopted contactless payment technologies, attackers are able to devise an extremely effective means of executing an unauthorised cashout, especially if they trick the user into disabling transaction limits. This campaign's success has been attributed to its combination of streamlined malware and persuasive social engineering, a development that signals a significant change in the tactics used by mobile threat actors in the future.

Apparently, the current campaign appears to be primarily targeting Italian bank customers and cardholders, according to recent research conducted by the fraud prevention firm Cleafy. It is reported that the attackers intend to collect sensitive payment card data through a methodical and layering approach in a very systematic way. Several analysts, including Federico Valentini, Alessandro Strino, and Michele Roviello, have concluded that SuperCard X uses a multiphase strategic attack method. 

Social engineering tactics are used to lure victims into installing malicious Android applications, which can intercept NFC data that has been compromised from a compromised device. This can include SMS-based phishing (smishing) as well as deceptive phone calls that lure victims into installing malicious Android applications. Additionally, preliminary findings indicate that the service is actively promoted on Telegram channels, which suggests that the tool’s distribution and monetisation are being supported by a larger underground network. 

The campaign's focus is on covert data harvesting and real-time exploitation of data, a trend which highlights the importance of mobile devices as a critical point of entry for financial fraudsters. A growing number of mobile payments is highlighting a need for enhanced awareness of users, robust security protocols, and real-time threat intelligence to combat the ever-increasing number of mobile-focused cyberattacks. As far as the malware's operational architecture is concerned, it displays a clever combination of sophistication and subtlety. 

To keep the component known as "Reader" from being detected by security platforms that are based on heuristics or signature-based and signature-driven algorithms, such as VirusTotal, the component is intentionally designed to only ask for basic system permissions as well as some NFC permissions, an intentional design choice. The technical findings of Cleafy indicate significant code reuse from the open-source relay toolkit NFCGate and the malicious variant NGate, both of which were identified by ESET in 2024. 

Using publicly available frameworks has probably accelerated development and led to a quicker onboarding process for new threat actor affiliates because it allows development to take place faster. When victims are coerced into tapping their credit or debit cards against a compromised device, they are silently captured, including low-level smart card responses such as the Answer To Reset (ATR) messages, from the compromised device. This is often done through social engineering.

Data such as this is sent instantly through a command-and-control network that is based on HTTP and protected with mutually negotiated TLS authentication, which limits communication to validated client instances and reduces the probability of external intrusion. During the same time, a secondary application on a separate attacker-controlled Android device called the "Tapper" is played that simulates the victim's card at a payment terminal or contactless ATM by using Host-Based Card Emulation (HCE). 

With a combination of disabling the card spending limits for the victim, this tactic can ensure that the maximum number of fraudulent withdrawals are made while remaining virtually undetectable by standard mobile security solutions. As a result of Cleafy's analysis, SuperCard X is designed to be stealthy, and it has remained undetected by all antivirus solutions listed on VirusTotal until today. 

Having such a restricted permission model, as well as the absence of overtly malicious behaviours, such as screen overlays and intrusive access requests, which are commonly flagged by heuristic-based security engines, contributes greatly to this success. There is an evident high level of technical competence among the threat actors behind SuperCard X, particularly in the implementation of an ATR-based (Answer to Reset) card emulation system, which demonstrates a high level of technical competence. 

A malware program that replicates the initial response sequence of the smartcard convincingly allows fraudulent transactions to be processed without raising suspicions at a payment terminal by convincingly mimicking authentic smartcard behaviour. In addition to this, users have built a command-and-control infrastructure with mutual Transport Layer Security (MTLS), which ensures that no client devices are permitted to communicate unless they are authenticated. 

A certificate-based verification ensures that not only is data integrity protected, but the network traffic analysis process is hindered significantly by security researchers and law enforcement agencies due to the fact that this certificate is based on verification. Together, these technical safeguards ensure that this malware does not leave a large footprint on the networks and demonstrate how mature the campaign is operationally. 

There is some evidence that the activity associated with SuperCard X is currently restricted to Italy geographically, although Cleafy's report cautions that the threat could rapidly escalate on a global scale if the problem is not addressed promptly. Cybercriminals can acquire and deploy malware-as-a-service (MaaaS) tools on dark web marketplaces that are readily available, which makes it easy for them to acquire and deploy malware against targets from any region. This raises concerns about possible expansion into broader markets, including those in North America and Europe. 

Using convincing social engineering tactics, such as urgent text messages masquerading as official communication from financial institutions, the campaign leverages persuasive social engineering techniques. The messages are designed in such a way that they cause panic in users and prompt them to immediately act, such as clicking on malicious links or downloading unauthorised applications, in order to generate immediate results. 

Individuals should ensure that they verify such messages independently by contacting their financial providers directly through trusted channels in cases where the sender's number matches the victim's actual bank number, especially if the sender's number has been spoofed to match that number. Whenever users receive a request to download an application through an external link, they should be aware that it is a red flag. No legitimate bank would ever ask users for this type of request. 

The user should only install applications from verified sources, such as the Google Play Store, which offer banking apps. It is essential to maintain the functionality of built-in security features on users' Android device, such as Google Play Protect, to mitigate the risk of exposure to threats like SuperCard X. This service continuously scans every application users install and any new applications they download for malicious behavior. 

There are a few things users should consider, such as installing a third-party mobile security solution, as well as awareness and good cyber hygiene practices. As this malware continues to circulate in the wild, awareness and good cyber hygiene are the two best ways to combat the increasing number of mobile malware threats.

NCSC Unveils “Pigmy Goat” Malware Targeting Sophos Firewalls in Advanced Chinese Cyberattack

 

The National Cyber Security Centre (NCSC) recently disclosed the presence of a Linux malware, “Pigmy Goat,” specifically designed to breach Sophos XG firewall devices. This malware, allegedly developed by Chinese cyber actors, represents a significant evolution in network infiltration tactics due to its complexity and advanced evasion methods. 

This revelation follows Sophos’ recent “Pacific Rim” reports, which detail a five-year campaign involving Chinese threat actors targeting network devices at an unprecedented scale. Among the identified tools, “Pigmy Goat” stands out as a rootkit crafted to resemble legitimate Sophos product files, making it challenging to detect. This strategy is known to use stealth by masking its identity within commonly named system files to evade basic detection protocols. “Pigmy Goat” enables threat actors to establish persistent, unauthorized access to the target’s network. Using the LD_PRELOAD environment variable, it embeds itself in the SSH daemon (sshd), allowing it to intercept and alter incoming connections. 

The malware seeks specific sequences called “magic bytes” to identify backdoor sessions, which it redirects through a Unix socket, thereby concealing its presence from standard security monitoring. Once a connection is established, it communicates with command and control (C2) servers over TLS. The malware cleverly mimics Fortinet’s FortiGate certificate, blending into networks where Fortinet devices are prevalent, to avoid suspicion. This backdoor offers threat actors multiple capabilities to monitor, control, and manipulate the network environment. Through commands from the C2, attackers can remotely open shell access, track network activity, adjust scheduled tasks, or even set up a SOCKS5 proxy, which helps them remain undetected while maintaining control over the network. These actions could allow unauthorized data access or further exploitation, posing significant threats to organizational cybersecurity. 

The NCSC report aligns “Pigmy Goat” with tactics used in “Castletap” malware, which cybersecurity firm Mandiant has linked to Chinese nation-state actors. The report’s insights reinforce concerns over the evolving sophistication in state-sponsored cyber tools aimed at infiltrating critical network infrastructure worldwide. Detection and prevention of “Pigmy Goat” are crucial to mitigating its impact. The NCSC report provides tools for identifying infection, including file hashes, YARA rules, and Snort rules, which can detect specific sequences and fake SSH handshakes associated with the malware. 

Additionally, monitoring for unusual files and behaviours, such as encrypted payloads in ICMP packets or the use of ‘LD_PRELOAD’ within the sshd process, can be effective. These insights empower network defenders to recognize early signs of compromise and respond swiftly, reinforcing defences against this sophisticated threat.

WeChat's Updated Encryption System Prone to Threats for its Users

 




More than a billion people send messages over WeChat and as per a new study recently, it discovered some security flaws in terms of the encryption system. While some applications use end-to-end encryption to prevent secret conversations from being read, WeChat's messages can be viewed by its servers. Researchers now find some vulnerability in WeChat's customised encryption that could leave users vulnerable to threats.


Weakened Encryption in WeChat

Scientists at the Citizen Lab of University of Toronto have established that WeChat is using a variation of the general security protocol named Transport Layer Security, or TLS 1.3. The new version of it is called MMTLS and it is actually made up of another layer of encryption called "Business-layer encryption," which encrypts messages right before they are going to be sent.

While this does mean that there is extra security placed on this system, it does not have weaknesses in the design. The inner Business-layer encryption does not protect critical information, including user IDs and request information. MMTLS also uses predictable patterns of a type of deterministic initialization vectors (IVs) that can lead to compromised encryption security overall.


Missing Forward Secrecy

Another weakness with WeChat's encryption is a lack of "forward secrecy." Forward secrecy helps to secure later communications in cases where old encryption keys are compromised. In the absence of this feature, if the attackers get hold of those encryption keys, they can decrypt old messages, compromising the users' long-term privacy.

Even before 2016, WeChat was employing the Business-layer encryption. This has made WeChat vulnerable to attacks since it had nearly no defences.

With the implementation of MMTLS, security becomes even enhanced with an added layer of protection that is acquired in the process. However, the changes are not yet at extreme conditions expected for the size of users in an app.


Improvements But Still Some Concerns

Though the security has been increased in WeChat, researchers could not break through the encryption layer that is currently used. The new MMTLS layer does hide the older, weaker encryption layer and offers protection from it. Still, the modifications to the protocol of TLS remain a security liability .


Chinese Apps Custom Security Practices

Problems with encryption form part of a broader problem about Chinese apps. Increasingly, app developers in all parts of China do not depend on widely trusted international standards but instead come up with their own custom solutions. For Citizen Lab, this forms a worrisome trend, since their homemade security solutions are nothing close to the generally recognized methods.

For instance, some Chinese apps utilise proprietary processing of DNS hijacking, and many rely on open-source software, as used in the case of Tencent Mars, and thus not all such applications or software will maintain stringent security levels or best practices for security.


WeChat Needs Stronger Encryption

Hence, although WeChat has become far safer lately, it is far from perfect. Users may have weak encryption methods that could expose their private data to possible threats. Such an application with thousands of users worldwide should deploy better standards of encryption to protect conversation among its users.


Domain Validation Bug: DigiCert Revokes TLS Certificates


In a major development in the tech landscape, SSL/TLS certificate provider "DigiCert" recently announced that it will be revoking around 83,267 certificates. This big step was taken due to a bug in their domain validation process, which dented the integrity of the affected certificates. The incident underscores the need for strong domain validation mechanisms and is a prompt reminder of the possible loopholes in cyberspace. 

“Recently, we learned that we did not include the underscore prefix with the random value used in some CNAME-based validation cases. This impacted approximately 0.4% of the applicable domain validations we have in effect. Under strict CABF rules certificates with an issue in their domain validation must be revoked within 24 hours, without exception,” said DigiCert in a statement.

The DigiCert incident

The main reason for the mass revocation exists within DigiCert's Domain Control Validation (DCV) process. The bug contained a missing underscore in the DNS CNAME entry, an important component to verify domain ownership. Due to the oversight, the certificates were issued without validation, undermining their credibility.

Domain validation is a basic step for issuing SSL/TLS certificates, it ensures the legitimacy of the entity requesting the certificate, to check if it's legit or not. In case of failure to validate domain ownership can be a security hazard. This includes man-in-the-middle attacks, where the threat actors intercept and manipulate communication between users and websites.

The impact

The impacted bug resulted in the potential exposure of various websites to security flaws. DigiCert acted promptly to contain the damage, issuing notice to the affected customers and giving a 24-hour wind to reissue certificates. But mass revocation also had repercussions for the affected organizations. Reissuing certificates on such massive scales required constant effort and coordination, especially for businesses with deep digital infrastructures.

Lessons for the future

1. Communications and transparency: DigiCert's swift response to impacted customers was crucial in addressing the bug. Being transparent with your customers becomes paramount, encouraging trust between both parties.

2. Rigorous testing and quality assurance: DigiCert's DCV process bug shows how a minor oversight can cause major disruptions.

3. Proactive, not just preventive measures: An important measure for tracking and addressing flaws before threat actors can exploit them. Frequent audits, auto-testing, and constant monitoring will help.

Microsoft and Google's Approach to Replace Obsolete TLS Protocols

Tech behemoths Microsoft and Google have teamed up to phase out outmoded TLS (Transport Layer Security) protocols in a decisive drive to strengthen online security. TLS protocols are essential for protecting internet connections because they guarantee that data is kept private and unchanged while in transit. Older TLS versions are now vulnerable to attacks as cyber threats advance, which has sparked a move toward more see-cure alternatives.

Microsoft, in a recent announcement, emphasized the importance of migrating away from TLS 1.0 and 1.1. As per their advisory, support for these outdated protocols will be disabled in the upcoming Windows updates. Jeff Jones, Senior Director at Microsoft, stated, "Continued use of these older protocols leaves systems open to numerous known vulnerabilities and attacks." This proactive measure is aimed at safeguarding users against potential security breaches.

Google has echoed this sentiment, highlighting the necessity for a collective industry effort to deprecate obsolete TLS versions. The company has already taken steps towards this goal, gradually phasing out support for TLS 1.0 and 1.1 across its products and services. A spokesperson from Google emphasized, "It's crucial for the entire ecosystem to move towards more secure protocols to ensure a safer online experience for everyone."

The move towards more advanced TLS protocols is a critical step in fortifying cybersecurity in an age of increasingly sophisticated cyber threats. TLS 1.0, introduced over two decades ago, and TLS 1.1, which followed shortly after, have shown their age. Security experts have identified vulnerabilities that make them susceptible to various attacks, including the notorious BEAST and POODLE exploits.

This joint effort by Microsoft and Google serves as a powerful catalyst for industry-wide change. It sends a clear message to developers, businesses, and users alike that embracing modern TLS protocols is essential for maintaining a secure online environment. As the transition gains momentum, organizations are encouraged to update their systems and applications to support TLS 1.2 and 1.3, which offer significantly improved security features.

Microsoft and Google's joint initiative to phase out antiquated TLS protocols represents a big step towards a more secure digital environment. This move not only improves the security of their individual ecosystems but also establishes an important standard for the larger tech community. The adoption of contemporary TLS protocols is a critical step in the direction of evolving defenses against cyber attacks to keep pace with the digital world.




Must Follow Guidelines for API Security

An online store can collect payments via the PayPal API, for instance, rather than developing their own payment gateway. APIs serve the required function while sparing business time and effort, which is why it is evident they are useful. 

Protecting these APIs from security risks and breaches entails securing them together with all linked apps and users. 

APIs are used by businesses to link services and move data. Major data breaches are caused by compromised, broken, or exposed APIs. They make private and delicate financial, medical, and personal information available to the public. However, not all data is created equal, and not all data should be safeguarded in the same way. The type of data being exchanged will determine how you should approach API security. 

In the last 12 months, 95% of firms encountered an API security issue, according to the most recent Salt Labs State of API Security report. Additionally, during the past year, a variety of businesses—including Facebook, Experian, Starbucks, and Peloton—have experienced public API problems. Clearly, APIs need more protection against intrusions than the present crop of application security approaches can provide.

Security leaders need to carefully examine the way they are currently approaching API security to fix the issue. Understanding how a third-party application is sending data back to the internet is important if user API connects to one. 

Strategies for API Security

  1.  Put a secure authentication and authorization protocol into action: The first stage in an API security approach is authenticating and authorizing the appropriate users.
  2. Implement the "Least Privilege" Principle: The attack surface is decreased by restricting access to only essential tasks, which helps reduce the exposure to security breaches.
  3.  Constrain Data Sharing: To find weak spots, keep track of the data shared between apps, APIs, and users, and then secure them by restricting the shared data.
  4. Not utilize HTTPS: In order to communicate data securely, APIs employ HTTP connections and require Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption.
  5.  Implement a policy of zero trust: We can leave out the zero-trust policy when discussing API security advice. It operates under the premise that no user, device, or server should be trusted until proven otherwise.
  6. Implement data logging: Logs provide admins with a wealth of information that can be utilized to enhance API security and assist with manual inspection and monitoring.
Security requires ongoing work in the age of technology and the internet. Unfortunately, security problems would not disappear, and as IoT technology grows more widespread, the dangers and vulnerabilities will only become worse. Beware of such ineffective strategies for API security. The security strategy must broaden to keep up with attackers' growing skill sets. 

Being proactive is vital, which means keeping an eye on current technology, patching up any flaws, and implementing cutting-edge cybersecurity measures.

AnchorDNS Loophole of a TrickBot Spyware Upgraded to AnchorMail

 

Even after the TrickBot infrastructure was shut down, the malware's operators continued to improve and retool its arsenal in preparation for attacks which ended in the distribution of the Conti ransomware. The new, improved edition of the criminal gang's AnchorDNS backdoor was called AnchorMail by IBM Security X-Force, which discovered it. 

According to IBM's malware reverse researcher Charlotte Hammond, AnchorMail "uses an email-based [command-and-control] server with which it connects using SMTP and IMAP protocols over TLS." "AnchorMail's behavior is essentially similar to vs its AnchorDNS predecessor, excluding the redesigned C2 communication method." 

The Trickbot Group, also known as ITG23 on X-Force, is a cybercriminal group best known for creating the Trickbot financial Trojan. Originally discovered in 2016, it was used to aid online banking fraud, initially. The gang adapted to the ransomware economy by gaining a footing for ransomware assaults utilizing its Trickbot and Bazarloader payloads, a tight partnership with both the Conti ransomware-as-a-service provider (RaaS). 

ITG23 is also known for creating the Anchor malware framework, which includes the AnchorDNS variant. In 2018 various high-profile targets were being infected with Trickbot or Bazarbackdoor, another ITG23 backdoor. AnchorDNS is known for using the DNS protocol to communicate with its Command and Control (C2) server. The improved backdoor, dubbed AnchorMail or Delegatz by IBM Security X-Force researchers, now communicates with an email-based C2 server through SMTP and IMAP protocols via TLS. AnchorMail's functionality is essentially similar to its AnchorDNS predecessor for most of its part, with the exception of the redesigned C2 communication mechanism. 

The uncovering of this updated Anchor variant adds an extra inconspicuous backdoor during ransomware assaults, demonstrating the group's drive to continually improve its malware. AnchorMail provides a scheduled job for persistence after execution, which is set to execute every 10 minutes. It then gathers basic system data, registers with its C2, and enters a loop of monitoring for and executing commands received. 

The command structure of the backdoor and AnchorDNS appear to be fairly similar, and both forms appear to accept the same set of control codes, which allow a variety of various possibilities for processing orders and payloads received from the C2. The commands include the ability to run binaries, DLLs, and shellcode downloaded from a remote server, as well as launch PowerShell commands and erase themselves from infected PCs. 

"The revelation of this new Anchor version adds a new covert gateway used during ransomware assaults, AnchorMail has only been seen to target Windows PCs so far. However, given the AnchorDNS has been adapted to Linux, a Linux-based version of AnchorMail appears inevitable," said Charlotte Hammond, BM's malware reverse engineer.

SSRF Attacks can be Used to Compromise Java RMI Services

 

According to a detailed analysis of the problem by security researcher Tobias Neitzel, Java RMI services can be targeted using server-side request forgery (SSRF) attacks. Server-side request forgery (SSRF) is a type of attack that allows attackers to send fraudulent requests to other systems by exploiting a vulnerable web server. 

Requests between HTTP servers can be initiated by web applications. These are commonly used to retrieve remote resources such as software updates or to import metadata from a URL or another web application. Such inter-server requests are not inherently harmful, but if not performed correctly, they can expose a server to server-side request forgery. When user-controllable data is utilized to construct the target URL, an SSRF vulnerability is introduced. An attacker can then use an SSRF attack to initiate or control requests from the vulnerable server by changing a parameter value in the vulnerable web application.

Java RMI is an object-oriented Remote Procedure Call (RPC) mechanism that is included in the vast majority of Java installations. The technology can be used by software developers to make functionality available through a network. Java RMI relies on serialized Java objects for communication, a mechanism that attackers can exploit despite the fact that the technology has been hardened and tempered in recent years, according to Neitzel.

“As with all SSRF techniques, the major problem is that attackers may be able to attack RMI services that are supposed to only be accessed from trusted networks,” Neitzel explained. “Securing RMI properly is not that intuitive and there is a lot of hidden attack surface. Instead of configuring it properly, administrators often take the easy route and only allow access from trusted networks or clients.” 

JMX is the most often utilized RMI service. Neitzel demonstrated that SSRF can be used to compromise a backend JMX service, but only if the system delivers responses from the backend service and accepts arbitrary bytes inside them. Similarly, SSRF-based attacks on default RMI components like the RMI registry are conceivable, but only if the system enables arbitrary bytes to be delivered to the backend service. 

The German researcher goes on to list security best practices and counter-measures for RMI services against potential attacks in his blog post. These include enabling TLS-enabled communication for all RMI endpoints, employing deserialization filters, and implementing stricter authentication controls.