برچسب: Scripts

Malware Campaign Leverages SVGs, Email Attachments, and CDNs to Drop XWorm and Remcos via BAT Scripts

Table of Content:

Introduction
Infection Chain
Process Tree
Campaign 1:
– Persistence
– BATCH files
– PowerShell script
– Loader
– Xworm/Remcos
Campaign 2
Conclusion
IOCS
Detections
MITRE ATTACK TTPs

Introduction:

Recent threat campaigns have revealed an evolving use of BAT-based loaders to deliver Remote Access Trojans, including XWorm and Remcos. These campaigns often begin with a ZIP archive, typically hosted on trusted looking platforms such as ImgKit, and are designed to appear as legitimate content to entice user interaction.

Upon extraction, the ZIP file contains a highly obfuscated BAT script that serves as the initial stage of the infection chain. These BAT files use advanced techniques to evade static detection and are responsible for executing PowerShell based loaders that inject the RAT payload directly into memory. This approach enables fileless execution, a growing trend in modern malware to bypass endpoint defences.

A notable development in this campaign is the use of SVG files to distribute the malicious BAT scripts. These SVGs contain embedded JavaScript that triggers the execution chain when rendered in vulnerable environments or embedded in phishing pages. This technique highlights a shift toward using non-traditional file formats for malware delivery, exploiting their scripting capabilities to evade detection.

Infection Chain:

Process Tree:

Fig: Process Tree

Campaign 1:

During the analysis Campaign 1, we identified multiple BAT scripts associated with the campaign, indicating an evolving threat landscape. Some of these scripts appear to be in active development, containing partial or test-stage code, while others are fully functional and capable of executing the complete attack chain, including payload download, execution.

The image below showcases two BAT files:

Method 1: Delivered directly as an attachment via EML (email file).
Method 2: Downloaded via a URL hosted on the ImageKit platform.

This variation in delivery methods suggests that the threat actors are experimenting with different approaches to improve infection success rates and evade detection mechanisms.

Persistence:

The malware achieves persistence by creating a BAT file in the Windows Startup folder. This ensures that the malicious script is automatically executed whenever the user starts the system or logs into their account.

BATCH files:

The figure below displays the BAT script in its obfuscated form alongside its de obfuscated version.

Fig: Obfuscated and deobfuscated bat files

PowerShell script:

Below, the figure shows the PowerShell process window and the command-line arguments used during execution. This provides insight into how the malware leverages PowerShell for in-memory payload delivery. We will analyze the PowerShell script in detail in the following sections to understand its role in the deployment of XWorm.

Fig: Process window of PWERSHELL with argument as PS script

Fig: Obfuscated Poershell script as an argument

This PowerShell command runs the script by decoding a Base64 encoded string and executing it in the memory. It uses -nop to avoid loading the user profile, -w hidden to hide the window, and iex (Invoke-Expression) to run the decoded content.

Deobfuscated Script:

We divided the deobfuscated script into two parts. In first part of the PowerShell script; it is designed to locate and execute an obfuscated code embedded within a batch file (aoc.bat) located in the current user’s profile directory. Firstly, It retrieves the username from the environment variables to construct the full path to aoc.bat. It reads all lines using UTF-8 encoding and iterates through each line, specifically looking for lines that begin with a triple-colon comment prefix (:::), followed by a Base64-encoded string. Upon finding such a line, it attempts to decode the Base64 string into a byte array, then converts it into a Unicode string assigned to the variable $ttzhae. This decoded string ($ttzhae) contains an additional layer of PowerShell script, which is then executed in memory using Invoke-Expression. This allows the attacker to embed and execute complex or multi-stage malicious PowerShell logic covertly within a seemingly benign batch file comment, enabling stealthy and fileless execution.

The script programmatically disables two key Windows security mechanisms AMSI (Antimalware Scan Interface) and ETW (Event Tracing for Windows) to evade detection. It leverages .NET reflection and dynamic delegate creation to resolve native functions such as GetProcAddress, GetModuleHandle, VirtualProtect, and AmsiInitialize. Using these, it locates and patches the AmsiScanBuffer function in memory with a instructions (mov eax, 0; ret), effectively bypassing AMSI scanning. Similarly, it disables event tracing by overwriting the beginning of EtwEventWrite with a return instruction. These in-memory modifications allow malicious PowerShell activity to execute stealthily, without being logged or scanned by endpoint protection solutions.

In the second part of the PowerShell script, it first retrieves the current user’s name from the environment and constructs the path to a file named aoc.bat located in the user’s profile directory. It proceeds to execute payloads embedded as encrypted and compressed .NET assemblies hidden within this batch file. The script specifically searches for a comment line prefixed with ::, which contains a Base64-encoded payload string. This string is then split into two parts using the backslash (\) as a delimiter. Each part undergoes Base64 decoding, AES decryption using a hardcoded key and IV (in CBC mode with PKCS7 padding), followed by GZIP decompression as illustrated in the accompanying figures. The result is two separate .NET assemblies, both loaded and executed directly in memory. The first assembly is invoked without any arguments, while the second is executed with ‘%*’ passed as a simulated command-line input.

Fig: Second Part of Script_ encryption function

The second payload plays a more critical role. it functions as a loader responsible for executing the final malware. which is XWorm remote access trojan (RAT).

Fig: Second Part of Script_ call to encryption function

Loader

The loader is designed to evade detection, disable event logging, and execute embedded payloads directly in the memory. It achieves this by either decrypting and running .NET executables via Assembly.Load or executing decrypted shellcode using VirtualProtect and delegates.

Fig: Encrypted Resource containing XWorm/remcos

Loader Capabilities:

Extract and execute embedded payloads

Here, we identified multiple loaders that utilize in-memory execution techniques to evade detection and persist stealthily. Some of these loaders contain encrypted .NET executables, which are decrypted at runtime and executed directly from memory using Assembly.Load followed by .EntryPoint. Invoke, allowing the loader to run managed code without writing the executable to disk.

In contrast, other variants have encrypted shellcode instead of a binary. These variants decrypt the shellcode, modify the memory protections using VirtualProtect to make it executable, and then execute it using a delegate created via Marshal.GetDelegateForFunctionPointer. As shown in below figures,

Xworm

We have previously reported on XWorm and Remcos earlier this year, providing an in-depth analysis of its core functionality, advanced capabilities such as keylogging, remote command execution, data exfiltration, and its methods of persistence and evasion.

In addition to XWorm, several variants in the same campaign also utilized Remcos, a widely known commercial Remote Access Trojan (RAT) that offers a range of capabilities, including remote desktop access, keylogging, command execution, file manipulation, screenshot capture, and data exfiltration.

Campaign 2:

Campaign 2 introduces a notable shift in malware delivery by leveraging SVG (Scalable Vector Graphics) files embedded with JavaScript, which are primarily used in phishing attacks. These malicious SVGs are crafted to appear as legitimate image files and are either rendered in vulnerable software environments (such as outdated image viewers or email clients) or embedded within phishing web pages designed to lure unsuspecting users. Now, the embedded JavaScript within the SVG file acts as a trigger mechanism, initiating the automatic download of a ZIP archive when the SVG is opened or previewed.

This downloaded ZIP archive contains an obfuscated BAT script, which serves as the initial access vector for the malware. Once the BAT script is executed either manually by the user or through social engineering tactics, it initiates a multi-stage infection chain similar to that observed in Campaign 1. Specifically, the BAT script invokes PowerShell commands to decode and execute a loader executable (EXE) directly in memory. This loader is responsible for decrypting and deploying the final payload, which in this campaign is the XWorm Remote Access Trojan (RAT).

The use of SVG as a delivery mechanism represents a noteworthy evolution in attack methodology, as image files are typically considered benign and are often excluded from deep content inspection by traditional security tools. By exploiting the scripting capabilities of SVGs, threat actors can effectively bypass perimeter defences and deliver malicious payloads in a fileless, stealthy manner.

Conclusion:

These campaigns highlight a growing trend in the use of obfuscated scripts, fileless malware, and non-traditional file formats like SVGs to deliver Remote Access Trojans such as XWorm and Remcos. By embedding payloads in BAT files and executing them via PowerShell, attackers effectively bypass static defences. The shift from using SVGs in phishing attacks to malware delivery further emphasizes the need for behavioural detection, content inspection, and improved user awareness to counter such evolving threats.

IOCS:

MD5	File
EDA018A9D51F3B09C20E88A15F630DF5	BAT
23E30938E00F89BF345C9C1E58A6CC1D	JS
1CE36351D7175E9244209AE0D42759D9	LOADER
EC04BC20CA447556C3BDCFCBF6662C60	XWORM
D439CB98CF44D359C6ABCDDDB6E85454	REMCOS

Detections:

Trojan.LoaderCiR

Trojan.GenericFC.S29960909

MITRE ATTACK TTPs:

Tactic	Technique ID & Name	Description
Execution	T1059.001 – Command and Scripting Interpreter: PowerShell	PowerShell is used to interpret commands, decrypt data, and invoke payloads.
	T1106 – Execution Through API	The script uses .NET APIs (e.g., Assembly.Load, Invoke) to execute payloads in memory.
Defense Evasion	T1027 – Obfuscated Files or Information	Payloads are Base64 encoded, AES-encrypted, and compressed to bypass static detections.
	T1140 – Deobfuscate/Decode Files or Information	The script decodes and decompresses payloads before execution.
	T1055.012 – Process Injection: .NET Assembly Injection	Payloads are loaded into memory
	T1036 – Masquerading	The malicious content is hidden in batch file.
Persistence	T1053 – Scheduled Task/Job	Establish persistence through strartup menu.
Initial Access	T1204 – User Execution	Execution depends on a user manually running the batch file
Command and Control	T1132 – Data Encoding	Base64 and encryption are used to encode commands or payloads.
	T1219 – Remote Access Software	Xworm provides full remote access and control over the infected host.
Credential Access	T1056.001 – Input Capture: Keylogging	XWorm includes keylogging functionality to steal user input and credentials.
Exfiltration	T1041 – Exfiltration Over C2 Channel	Stolen data is exfiltrated via the same C2 channel used by Xworm.

Source link

سپتامبر 11, 2025

How Seqrite Endpoint Protection Blocks Bots, Scripts, and Malware

In today’s hyper-connected digital world, the cybersecurity landscape is shifting dramatically. Gone are the days when cyberattacks primarily relied on human intervention. We’re now facing a new breed of silent, swift adversaries: non-human threats. These automated entities—bots, malicious scripts, and sophisticated malware—are designed to operate at machine speed, exploiting vulnerabilities, bypassing traditional defenses, and often remaining undetected until significant damage has occurred. So, how do you defend against something you can’t see, something that moves faster than human reaction? The answer lies in intelligent, automated endpoint security. Enter Seqrite Endpoint Protection (EPP), your robust shield against these invisible invaders. Available for both cloud-based and on-premise deployments, Seqrite EPP is engineered with cutting-edge technologies specifically designed to identify and neutralize these stealthy, non-human threats.

Understanding the Enigma: What Exactly Are Non-Human Cyber Threats?

When we talk about “non-human cyber threats,” we’re referring to automated programs and code snippets that launch attacks without requiring direct human interaction. These include:

Bots: Automated programs designed to perform repetitive tasks at scale. Think credential stuffing attacks where bots try thousands of username/password combinations, or Distributed Denial of Service (DDoS) attacks that flood a server with traffic.
Malicious Scripts: These are pieces of automated code, often hidden within legitimate-looking files or web pages, designed to exploit system weaknesses, exfiltrate sensitive data, or spread malware across your network.
Exploit Kits: These are sophisticated toolkits that automatically scan systems for unpatched vulnerabilities and then deploy exploits to gain unauthorized access or deliver payloads like ransomware.

The key characteristic of these threats is their autonomy and speed. They operate under the radar, making traditional, reactive security measures largely ineffective. This is precisely why proactive, automated detection and prevention mechanisms are absolutely critical for modern businesses.

Seqrite Endpoint Protection: Your Multi-Layered Defense Against Automation

Seqrite’s EPP doesn’t just offer a single line of defense; it deploys a comprehensive, multi-layered security framework. This framework is specifically engineered to detect and block automation-driven threats using a powerful combination of intelligent rule-based systems, behavioral analysis, and advanced AI-powered capabilities.

Let’s dive into the key features that make Seqrite EPP a formidable opponent against non-human threats:

Advanced Device Control: Many non-human threats, especially scripts and certain types of malware, are delivered via external devices like USB drives. Seqrite’s Advanced Device Control enforces strict usage policies, allowing you to define what devices can connect to your endpoints and how they can be used. By controlling storage, network, and wireless interfaces, you effectively close off a major entry point for automated attacks.
Application Control with Zero Trust: Imagine only allowing approved applications and scripts to run on your systems. That’s the power of Seqrite’s Application Control. By implementing a Zero Trust model, it blocks unknown or unapproved applications and scripts from executing. Through meticulous allowlisting and blocklisting, only trusted applications can operate, making it incredibly effective against stealthy automation tools that attempt to execute malicious code.
Behavior-Based Detection (GoDeep.AI): This is where Seqrite truly shines. Leveraging cutting-edge AI and machine learning, GoDeep.AI continuously monitors endpoint activity to identify abnormal and suspicious behaviors that indicate a non-human threat. This includes detecting:
- Repetitive access patterns: A hallmark of bots attempting to brute-force accounts or scan for vulnerabilities.
- Scripted encryption behavior: Instantly flags the tell-tale signs of ransomware encrypting files.
- Silent data exfiltration attempts: Catches automated processes trying to siphon off sensitive information. The system doesn’t just detect; it actively stops suspicious activity in its tracks before it can cause any harm.
Intrusion Detection & Prevention System (IDS/IPS): Seqrite’s integrated IDS/IPS actively monitors network traffic for known exploit patterns and anomalous behavior. This robust system is crucial for blocking automation-based threats that attempt to infiltrate your network through known vulnerabilities or launch network-based attacks like port scanning.
File Sandboxing: When a suspicious file or script enters your environment, Seqrite doesn’t let it run directly on your system. Instead, it’s whisked away to a secure, isolated virtual sandbox environment for deep analysis. Here, the file is allowed to execute and its behavior is meticulously observed. If it exhibits any malicious traits—like attempting to mimic user behavior, access restricted resources, or encrypt files—it’s immediately flagged and stopped, preventing any potential damage to your actual endpoints.
Web Protection & Phishing Control: Many non-human threats, particularly bots and sophisticated malware, rely on communication with remote command-and-control (C2) servers. Seqrite’s Web Protection proactively blocks:
- Access to known malicious domains.
- Phishing sites designed to steal credentials.
- Unauthorized web access that could lead to malware downloads.
- Crucially, it cuts off botnet callbacks, effectively severing the communication lines between bots and their command centers, rendering them inert.

Enhancing Your Defense: Essential Supporting Features

Beyond its core capabilities, Seqrite Endpoint Protection is bolstered by a suite of supporting features that further strengthen your organization’s resilience against non-human threats and beyond:

Feature	Benefit
Patch Management	Automatically identifies and fixes software vulnerabilities that bots and scripts often exploit to gain entry. Proactive patching is key to prevention.
Firewall	Provides a critical layer of defense by filtering unauthorized network traffic and blocking communication with known botnet IP addresses.
Data Loss Prevention (DLP)	Prevents automated data theft by monitoring and controlling data in transit, ensuring sensitive information doesn’t leave your network without authorization.
Centralized Log Management	Offers a unified view of security events, allowing for rapid detection and auditing of unusual or suspicious behaviors across all endpoints.
Disk Encryption Management	Safeguards your data by encrypting entire disks, stopping automated decryption attempts even if data is stolen, and protecting against ransomware.

The Future of Endpoint Security: Why Non-Human Threat Detection is Non-Negotiable

As we move deeper into 2025 and beyond, cyber threats are becoming increasingly automated, sophisticated, and often, AI-driven. Relying on traditional, signature-based security solutions is no longer enough to match the speed, stealth, and evolving tactics of automation-based attacks.

Seqrite Endpoint Protection is built for this future. It leverages intelligent automation to effectively combat automation—blocking bots, malicious scripts, advanced ransomware, and other non-human threats before they can execute and wreak havoc on your systems and data.

Final Takeaway: Don’t Let Invisible Threats Compromise Your Business

In a world where cyberattacks are increasingly executed by machines, your defense must be equally advanced. With its comprehensive suite of features—including cutting-edge device and application control, AI-driven behavioral detection (GoDeep.AI), robust network-level protection, and secure sandboxing—Seqrite Endpoint Protection ensures your endpoints remain locked down and secure.

Whether your organization operates with a cloud-first strategy or relies on a traditional on-premise infrastructure, Seqrite provides the adaptable and powerful security solutions you need.

Ready to Fortify Your Defenses?

It’s time to upgrade your endpoint security and protect your organization from both human-initiated and the ever-growing wave of non-human cyber threats.

Explore how Seqrite can secure your business today. Request a Free Trial or Schedule a Demo.

Source link

ژوئن 9, 2025

Postman's pre-request scripts: how to perform HTTP POST requests (with JSON body) and how to set Cookie authentication.
In Postman, you can define scripts to be executed before the beginning of a request. Can we use them to work with endpoints using Cookie Authentication?

Table of Contents

Just a second! 🫷
If you are here, it means that you are a software developer.
So, you know that storage, networking, and domain management have a cost .

If you want to support this blog, please ensure that you have disabled the adblocker for this site.
I configured Google AdSense to show as few ADS as possible – I don’t want to bother you with lots of ads, but I still need to add some to pay for the resources for my site.

Thank you for your understanding.
– Davide

Nowadays, it’s rare to find services that use Cookie Authentication, yet they still exist. How can we configure Cookie Authentication with Postman? How can we centralize the definition using pre-request scripts?

I had to answer these questions when I had to integrate a third-party system that was using Cookie Authentication. Instead of generating a new token manually, I decided to centralize the Cookie creation in a single place, making it automatically available to every subsequent request.

In order to generate the token, I had to send a request to the Authentication endpoint, sending a JSON payload with data coming from Postman’s variables.

In this article, I’ll recap what I learned, teach you some basics of creating pre-request scripts with Postman, and provide a full example of how I used it to centralize the generation and usage of a cookie for a whole Postman collection.

Introducing Postman’s pre-request scripts

As you probably know, Postman allows you to create scripts that are executed before and after an HTTP call.

These scripts are written in JavaScript and can use some objects and methods that come out of the box with Postman.

You can create such scripts for a single request or the whole collection. In the second case, you write the script once so that it becomes available for all the requests stored within that collection.

The operations defined in the Scripts section of the collection are then executed before (or after) every request in the collection.

Here, you can either use the standard JavaScript code—like the dear old console.log— or the pm object to reference the context in which the script will be executed.

For example, you can print the value of a Postman variable by using:
const tokenUrl = pm.variables.get("TokenUrl") console.log(tokenUrl)
How to send a POST request with JSON body in Postman pre-request scripts

How can we issue a POST request in the pre-request script, specifying a JSON body?

Postman’s pm object, along with some other methods, exposes the sendRequest function. Its first parameter is the “description” of the request; its second parameter is the callback to execute after the request is completed.
pm.sendRequest(request, (errorResponse, successfulResponse) => { // do something here })
You have to carefully craft the request, by specifying the HTTP method, the body, and the content type:
var authenticationBody = { UserName: username, Password: password, } const request = { method: "POST", url: tokenUrl, body: { mode: "raw", raw: JSON.stringify(authenticationBody), options: { raw: { language: "json", }, }, }, }
Pay particular attention to the options node: it tells Postman how to treat the body content and what the content type is. Because I was missing this node, I spent too many minutes trying to figure out why this call was badly formed.
options: { raw: { language: "json" } }
Now, the result of the operation is used to execute the callback function. Generally, you want it to be structured like this:
pm.sendRequest(request, (err, response) => { if (err) { // handle error } if (response) { // handle success } })
Storing Cookies in Postman (using a Jar)

You have received the response with the token, and you have parsed the response to retrieve the value. Now what?

You cannot store Cookies directly as it they were simple variables. Instead, you must store Cookies in a Jar.

Postman allows you to programmatically operate with cookies only by accessing them via a Jar (yup, pun intended!), that can be initialized like this:
const jar = pm.cookies.jar()
From here, you can add, remove or retrieve cookies by working with the jar object.

To add a new cookie, you must use the set() method of the jar object, specifying the domain the cookie belongs to, its name, its value, and the callback to execute when the operation completes.
const jar = pm.cookies.jar() jar.set( "add-your-domain-here.com", "MyCustomCookieName", newToken, (error, cookie) => { if (error) { console.error(`An error occurred: ${error}`) } else { console.log(`Cookie saved: ${cookie}`) } } )
You can try it now: execute a request, have a look at the console logs, and…

We’ve received a strange error:

An error occurred: Error: CookieStore: programmatic access to “add-your-domain-here.com” is denied

Wait, what? What does “programmatic access to X is denied” mean, and how can we solve this error?

For security reasons, you cannot handle cookies via code without letting Postman know that you explicitly want to operate on the specified domain. To overcome this limitation, you need to whitelist the domain associated with the cookie so that Postman will accept that the operation you’re trying to achieve via code is legit.

To enable a domain for cookies operations, you first have to navigate to the headers section of any request under the collection and click the Cookies button.

From here, select Domains Allowlist:

Finally, add your domain to the list of the allowed ones.

Now Postman knows that if you try to set a cookie via code, it’s because you actively want it, allowing you to add your cookies to the jar.

If you open again the Cookie section (see above), you will be able to see the current values for the cookies associated with the domain:

Further readings

Clearly, we’ve just scratched the surface of what you can do with pre-request scripts in Postman. To learn more, have a look at the official documentation:

🔗 Write pre-request scripts to add dynamic behavior in Postman | Postman docs

This article first appeared on Code4IT 🐧

If you want to learn more about how to use the Jar object and what operations are available, you can have a look at the following link:

🔗 Scripting with request cookie | Postman docs

Wrapping up (with complete example)

In this article, we learned what pre-request scripts are, how to execute a POST request passing a JSON object as a body, and how to programmatically add a Cookie in Postman by operating on the Jar object.

For clarity, here’s the complete code I used in my pre-request script.
const tokenUrl = pm.variables.get("TokenUrl") const username = pm.variables.get("ClientID") const password = pm.variables.get("ClientSecret") var authBody = { UserName: username, Password: password, } const getTokenRequest = { method: "POST", url: tokenUrl, body: { mode: "raw", raw: JSON.stringify(authBody), options: { raw: { language: "json", }, }, }, } pm.sendRequest(getTokenRequest, (err, response) => { if (err) { throw new Error(err) } if (response) { var jresponse = response.json() var newToken = jresponse["Token"] console.log("token: ", newToken) if (newToken) { const jar = pm.cookies.jar() jar.set( "add-your-domain-here.com", "MyCustomCookieName", newToken, (error, cookie) => { if (error) { console.error(`An error occurred: ${error}`) } else { console.log(`Cookie saved: ${cookie}`) } } ) } else { throw new Error("Token not available") } } })
Notice that to parse the response from the authentication endpoint I used the .json() method, that allows me to access the internal values using the property name, as in jresponse["Token"].

I hope you enjoyed this article! Let’s keep in touch on Twitter or LinkedIn! 🤜🤛

Happy coding!

🐧
Source link
می 21, 2025
Automating Your DevOps: Writing Scripts that Save Time and Headaches | by Ulas Can Cengiz

Or, how scripting revolutionized my workflow

Photo by Stephen Dawson on Unsplash

Imagine a time when factories were full of life, with gears turning and machines working together. It was a big change, like what’s happening today with computers. In the world of creating and managing software, we’re moving from doing things by hand to letting computers do the work. I’ve seen this change happen, and I can tell you, writing little programs, or “scripts,” is what’s making this change possible.

Just like factories changed how things were made, these little programs are changing the way we handle software. They’re like a magic trick that turns long, boring tasks into quick and easy ones. In this article, I’m going to show you how these little programs fit into the bigger picture, how they make things better and faster, and the headaches they can take away.

We’re going to go on a trip together. I’ll show you how things used to be done, talk about the different kinds of little programs and tools we use now, and share some of the tricks I’ve learned. I’ll tell you stories about times when these little programs really made a difference, give you tips, and show you some examples. So, buckle up, and let’s jump into this world where making and managing software is not just a job, but something really special.

Source link

می 2, 2025