Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Malicious Codes. Show all posts

GootLoader Malware Uses Malformed ZIP Archives to Evade Detection

 

A fresh tactic has emerged among cybercriminals using GootLoader, a JavaScript-driven malware installer. Instead of standard compression, they now distribute broken ZIP files designed to slip past digital defenses. These flawed archives exploit differences across decompression programs - some fail to process them, others do so partially. This mismatch lets malicious code stay concealed during scans yet run normally when opened by users. Findings detailed by Expel show that inconsistent parsing logic in software plays right into attacker hands. Hidden scripts activate only when handled by specific tools found on typical machines. 

Starting with a strange structure, these harmful ZIP files combine around 500 to 1,000 smaller archives into one large package. Because of this layered setup, standard programs like WinRAR or 7-Zip cannot properly read them - tools often relied on during malware checks. Due to the confusion they create, automatic detection systems frequently skip examining what's inside. Yet, when opened through Windows’ own built-in decompression feature, the file works without issue. 

That smooth operation lets victims unknowingly unpack dangerous content. Since 2020, GootLoader has maintained a presence among cyber threats, primarily spreading via manipulated search results and deceptive online ads. People looking for official forms or corporate paperwork may unknowingly land on hacked WordPress sites offering infected files. These corrupted archives, once opened, trigger the payload delivery mechanism embedded within the software. Acting as a gateway tool, it paves the way for additional harmful programs - ransomware being one frequent outcome. 

The chain of infection begins quietly, escalating quickly under the radar. By late 2025, Expel researchers noticed subtle upgrades, showing how the attack method keeps shifting. Instead of just stacking archives, hackers shorten key metadata inside ZIP structures - especially tampering with the end of central directory entries. That tweak triggers failures in numerous analysis programs, yet files still open in Windows Explorer. 

Inside the package, unimportant sections get scrambled too, throwing off predictable reading patterns and making automated inspection harder. Researchers refer to this method as "hashbusting," delivering a distinct ZIP file to each target. Every time someone downloads it, differences in the archive's layout and data prevent standard hash checks from working. Even the JavaScript inside changes form with each instance. Detection systems relying on repeated patterns struggle as a result. 

 What makes the delivery hard to catch lies in its method. Rather than sending a typical ZIP archive, attackers transmit the malicious code as an XOR-encrypted flow of data, rebuilt only after reaching the target's browser. It grows by adding copies of itself over and over, expanding until it meets a specific volume - this skirts detection meant for compressed files. After launch, the script runs using built-in Windows tools, skipping any need to unpack completely, so the attack unfolds without drawing attention. 

Once active, it stays on the machine by placing shortcuts into the Windows Startup directory - then triggers further scripts through native utilities like cscript or PowerShell. From there, data collection begins: details about the system get pulled and sent back to distant servers that control the attack, setting up what comes next without delay. 

Although often overlooked, limiting access to built-in tools such as wscript.exe helps block common attack paths. Instead of running scripts automatically, setting systems to display code in basic viewers adds another layer of protection. As seen with GootLoader’s shifts over time, attackers now twist everyday OS functions into stealthy weapons, staying active even when defenses improve.

AWS CodeBuild Misconfiguration Could Have Enabled Full GitHub Repository Takeover

 

One mistake in how Amazon Web Services set up its CodeBuild tool might have let hackers grab control of official AWS GitHub accounts. That access could spill into more parts of AWS, opening doors for wide-reaching attacks on software supplies. Cloud security team Wiz found the weak spot and called it CodeBreach. They told AWS about it on August 25, 2025. Fixes arrived by September that year. Experts say key pieces inside AWS were at stake - like the popular JavaScript SDK developers rely on every day. 

Into trusted repositories, attackers might have slipped harmful code thanks to CodeBreach, said Wiz team members Yuval Avrahami and Nir Ohfeld. If exploited, many apps using AWS SDKs could face consequences - possibly even disruptions in how the AWS Console functions or risks within user setups. Not a bug inside CodeBuild caused this, but gaps found deeper in automated build processes. These weak spots lived where tools merge and deploy code automatically. 

Something went wrong because the webhook filters had been set up incorrectly. They’re supposed to decide which GitHub actions get permission to start CodeBuild tasks. Only certain people or selected branches should be allowed through, keeping unsafe code changes out of high-access areas. But in a few open-source projects run by AWS, the rules meant to check user IDs didn’t work right. The patterns written to match those users failed at their job. 

Notably, some repositories used regex patterns missing boundary markers at beginning or end, leading to incomplete matches rather than full validation. This gap meant a GitHub user identifier only needed to include an authorized maintainer's number within a larger sequence to slip through. Because GitHub hands out IDs in order, those at Wiz showed how likely it became for upcoming identifiers to accidentally align with known legitimate ones. 

Ahead of any manual effort, bots made it possible to spam GitHub App setups nonstop. One after another, these fake apps rolled out - just waiting for a specific ID pattern to slip through broken checks. When the right match appeared, everything changed quietly. A hidden workflow fired up inside CodeBuild, pulled from what should have stayed locked down. Secrets spilled into logs nobody monitored closely. For aws-sdk-js-v3, that leak handed total control away - tied straight to a powerful token meant to stay private. If hackers gained that much control, they might slip harmful code into secure branches without warning. 

Malicious changes could get approved through rigged pull requests, while hidden data stored in the repo gets quietly pulled out. Once inside, corrupted updates might travel unnoticed through trusted AWS libraries to users relying on them. AWS eventually confirmed some repos lacked tight webhook checks. Still, they noted only certain setups were exposed. 

Now fixed, Amazon says it adjusted those flawed settings. Exposed keys were swapped out, safeguards tightened around building software. Evidence shows CodeBreach wasn’t used by attackers, the firm added. Yet specialists warn - small gaps in automated pipelines might lead to big problems down the line. Now worries grow around CI/CD safety, a new report adds fuel. 

Lately, studies have revealed that poorly set up GitHub Actions might spill sensitive tokens. This mistake lets hackers gain higher permissions in large open-source efforts. What we’re seeing shows tighter checks matter. Running on minimal needed access helps too. How unknown data is processed in builds turns out to be critical. Each step shapes whether systems stay secure.

Hackers Exploit WordPress Logins, Secretly Run Codes

Hackers Exploit WordPress Logins, Secretly Run Codes

Threat actors are exploiting the Wordpress mu-plugins ("Must-Use Plugins") directory to secretly execute malicious code on each page while avoiding detection. 

The technique was first observed by security researchers at Sucuri in February 2025, but adoption rates are on the rise, with threat actors now utilizing the folder to run three distinct types of malicious code.

Talking about the increase in mu-plugins infections, Sucuri's security analyst Puja Srivastava said, “attackers are actively targeting this directory as a persistent foothold.”

About "Must-have" malware

Must-Use Plugins are a kind of WordPress plugin that automatically runs on every page load without the need to be activated in the admin dashboard.  Mu-plugins are files stored in the 'wp-content/mu-plugins/' and are not listed in the regular “Plugins” admin page, except when the “Must-Use” filter is checked. 

They have genuine use cases like implementing site-wide functionality for custom security rules, dynamically changing variables/codes, and performance tweaks. But as these plugins run every page load and aren’t shown in the standard plugin list, hackers can exploit them to secretly run a variety of malicious activities like injecting malicious code, changing HTML output, or stealing credentials. 

Sucuri found three payloads that hackers are deploying in the mu-plugins directory, suspected to be a part of a larger money aimed campaign.

According to Sucuri, these include:

Fake Update Redirect Malware: Detected in the file wp-content/mu-plugins/redirect.php, this malware redirected site visitors to an external malicious website.

Webshell: Found in ./wp-content/mu-plugins/index.php, it allows attackers to execute arbitrary code, granting them near-complete control over the site.

A spam injector: a spam injection script located in wp-content/mu-plugins/custom-js-loader.php. This script was being used to inject unwanted spam content onto the infected website, possibly to boost SEO rankings for malicious actors or promote scams.

How do you spot it?

A few obvious signs can help to spot this malware. One unusual behavior on the site is unauthorized user redirections to external malicious websites. Secondly, malicious files with weird names appear inside the mu-plugins directory, spoofing real plugins. Third, site admins may observe “elevated server resource usage with no clear explanation, along with unexpected file modifications or the inclusion of unauthorized code in critical directories,” according to Sucuri.

Adopting ChatGPT Securely: Best Practices for Enterprises

As businesses continue to embrace the power of artificial intelligence (AI), chatbots are becoming increasingly popular. One of the most advanced chatbots available today is ChatGPT, a language model developed by OpenAI that uses deep learning to generate human-like responses to text-based queries. While ChatGPT can be a powerful tool for businesses, it is important to adopt it securely to avoid any potential risks to sensitive data.

Here are some tips for enterprises looking to adopt ChatGPT securely:
  • Conduct a risk assessment: Before implementing ChatGPT, it is important to conduct a comprehensive risk assessment to identify any potential vulnerabilities that could be exploited by attackers. This will help organizations to develop a plan to mitigate risks and ensure that their data is protected.
  • Use secure channels: To prevent unauthorized access to ChatGPT, it is important to use secure channels to communicate with the chatbot. This includes using encrypted communication channels and secure APIs.
  • Monitor access: It is important to monitor who has access to ChatGPT and ensure that access is granted only to authorized individuals. This can be done by implementing strong access controls and monitoring access logs.
  • Train employees: Employees should be trained on the proper use of ChatGPT and the potential risks associated with its use. This includes ensuring that employees do not share sensitive data with the chatbot and that they are aware of the potential for social engineering attacks.
  • Implement zero-trust security: Zero-trust security is an approach that assumes that every user and device on a network is a potential threat. This means that access to resources should be granted only on a need-to-know basis and after proper authentication.
By adopting these best practices, enterprises can ensure that ChatGPT is used securely and that their data is protected. However, it is important to note that AI technology is constantly evolving, and businesses must stay up-to-date with the latest security trends to stay ahead of potential threats.

Does ChatGPT Bot Empower Cyber Crime?

Security experts have cautioned that a new AI bot called ChatGPT may be employed by cybercriminals to educate them on how to plan attacks and even develop ransomware. It was launched by the artificial intelligence r&d company OpenAI last month. 

Computer security expert Brendan Dolan-Gavitt questioned if he could command an AI-powered chatbot to create malicious code when the ChatGPT application first allowed users to communicate. Then he gave the program a basic capture-the-flag mission to complete.

The code featured a buffer overflow vulnerability, which ChatGPT accurately identified and created a piece of code to capitalize it. The program would have addressed the issue flawlessly if not for a small error—the number of characters in the input. 

The fact that ChatGPT failed Dolan Gavitt's task, which he would have given students at the start of a vulnerability analysis course, does not instill trust in massive language models' capacity to generate high-quality code. However, after identifying the mistake, Dolan-Gavitt asked the model to review the response, and this time, ChatGPT did it right. 

Security researchers have used ChatGPT to rapidly complete a variety of offensive and defensive cybersecurity tasks, including creating refined or persuading phishing emails, creating workable Yara rules, identifying buffer overflows in code, creating evasion code that could be utilized by attackers to avoid threat detection, and even writing malware. 

Dr. Suleyman Ozarslan, a security researcher and co-founder of Picus Security, claimed that he was able to program the program to carry out a variety of aggressive and defensive cybersecurity tasks, like the creation of a World Cup-themed email in perfect English and the generation of both evasion code that can get around detection rules as well as Sigma detection rules to find cybersecurity anomalies. 

Reinforcement learning is the foundation of ChatGPT. As a result, it acquires new knowledge through interaction with people and user-generated prompts. Additionally, it implies that over time, the program might pick up on some of the tricks researchers have employed to get around its ethical checks, either through user input or improvements made by its administrators. 

Multiple researchers have discovered a technique to get beyond ChatGPT's limitations, which stops it from doing things that are malicious, including providing instructions on how to make a bomb or writing malicious code. For the present term, ChatGPT's coding could be more optimal and demonstrates many of the drawbacks of relying solely on AI tools. However, as these models develop in complexity, they are likely to become more crucial in creating malicious software. 

In 2021, Ransomware Threats were Self-Installed

 

According to Expel, a managed detection and response (MDR) company, the majority of ransomware assaults in 2021 were self-installed. The revelation was made in the annual report on cybersecurity trends and predictions, 'Great eXpeltations'. 

Eight out of ten ransomware outbreaks were caused by victims unintentionally opening a zipped file containing malicious code. While, 3% of all ransomware cases were produced via abusing third-party access, and some 4% were caused by exploiting a software weakness on the perimeter. 

Ransomware is a sort of software that locks users out of the computer and demands payment in exchange for access. The data on the computer could be stolen, destroyed, or hidden, or the computer itself could be locked; some ransomware may try to infect other computers on the network.

BEC (business email compromise) efforts accounted for 50% of cases, with SaaS apps being the most common target. More than 90% of the attacks targeted Microsoft Office 365, with attacks against Google Workspace accounting for less than 1% of all events. Okta was the objective of the remaining 9%. 

Ransomware was responsible for 13% of all opportunistic attacks. Legal services, communications, financial services, real estate, and entertainment were the top five industries attacked. Furthermore, Expel discovered that 35 percent of web app hacks resulted in the deployment of a crypto miner.

Is the user at risk of being a victim of a ransomware assault due to security flaws?

  • The device in use is no longer cutting-edge. 
  • The device's software is out of date. 
  • No longer are browsers and/or operating systems patched. 
  • There is no suitable backup plan in place. 
  • Cybersecurity has received insufficient attention, and no solid plan has been put in place. 

How to Protect Oneself against Ransomware: 

  • Set up a firewall.
  • Have immutable backups. 
  • Staff Awareness Through Network Segmentation. 
  • Password Strengthening.
  •  Security Enhance Endpoint Security. 
  • Increase the Security of Your Email.
  • Use the Least Privilege Principle. 
  • Install ad blockers.

When it comes to combating ransomware, caution and the deployment of effective protection software, like with other forms of malware, are a good start. The development of backups is especially important when dealing with this form of malware, as it allows users to be well prepared even in the worst-case scenario.

Experts Reported Data Theft in Dozens of Companies Through Modified 1C Modules

 

RTM Group found the malicious code in the finalized 1C software by outsourced programmers. Experts estimate that with its help the fraudsters could steal the data of several dozens of companies. 1C called the described scheme technically imperfect and recognized that the platform modules can be finalized by third-party specialists and subsequently used by criminals. 

A representative of the information security company RTM Group said that the data of several dozen companies were stolen through malicious code in 1C modules, which were being finalized by programmers on outsourcing. 

According to him, at least a third of 1C users order the completion of some modules from third-party programmers who can embed malicious code in them. As a result, such modules, when checking the license key, send the data available in them about customers, payments, and potential contracts to an email address that is pre-registered. 

The victims of the scheme were several dozen companies engaged in the trade or distribution of software. The representative of the RTM Group noted that the materials were sent to law enforcement agencies. 

The representative of 1C called the described scheme technically imperfect since the license check is performed at the "core" level of the system, the code of which is closed. At the same time, he acknowledged that the platform modules can be modified by third-party specialists and used by attackers in the future. 

According to IDC, the share of 1C software in the corporate market in Russia in 2020 was 39.2%. Small and medium-sized businesses, which do not have money for their own IT departments, and they turn to small firms, are at risk of getting to scammers first of all.

“There are hundreds of thousands of 1C programmers in Russia, some of them can really be intruders, especially in the current deteriorating economic environment,” explained Pavel Korostelev, head of the Security Code company’s product promotion department. 

Alexander Dvoryansky, Director of Strategic Communications at Infosecurity a Softline Company, noted that such incidents do not always occur maliciously, as programmers when finalizing the module may use third-party or free software, the source code of which already contains malicious code.

DoppelPaymer Searches for and Terminates Windows Processes

 

Crowdstrike Intelligence claimed in a July 2019 blog post on DoppelPaymer that ProcessHacker was being hijacked to terminate a list of targeted processes and obtain access, providing a "critical hit." DoppelPaymer is a descendant of the BitPaymer ransomware and a member of the Dridex malware family. It's presently being delivered in a variety of ways, including phishing or spam emails with attachments containing malicious code - either JavaScript or VBScript. 

DoppelPaymer places the ProcessHacker executable, the KProcessHacker driver, and the malicious stager DLL under a subdirectory of %APPDATA% to start ProcessHacker. The subdirectory name, as well as the executable and driver file names, are all a unique string of alphanumeric characters. Following the creation of those two files, one of the DLLs loaded by ProcessHacker must be hijacked using a technique known as "DLL search order hijacking."

DoppelPaymer sends the ProcessHacker process two arguments: the name of the KProcessHacker.sys driver and an integer that will be used for inter-process communication (IPC) between the DoppelPaymer and ProcessHacker processes.

DoppelPaymer, like Dridex, exploits DLL search order hijacking to exploit the DLL loading behavior of Windows programs. When the operating system PE loader loads a binary, it must also load the DLL files needed for the PE to function. When seeking for DLL files to load, MS Windows takes a certain path by default. Before checking the Windows system directories, Windows looks for Windows system DLLs in the same directory as the target program. In this situation, DoppelPaymer, a malicious process, can drop a malicious version of a DLL in that directory, which will be loaded by the target application. 

DoppelPaymer searches the module name list in the ProcessHacker binary's Import Address Table (IAT) to decide which DLL to hijack. Each name is hashed using the CRC32 algorithm and compared to a hardcoded list of hashes, if a match is found, the name is added to a list data structure. To select one of the three names from the list, a random number generator is employed. 

After selecting a DLL, the authentic Windows version of the DLL is read into a memory buffer. This DLL serves as a template for creating the malicious stager DLL. The file is saved in the same folder as the ProcessHacker executable and has the same name as the hijacked DLL.