CL-UNK-1068 and LOLBINs: When Attackers Use Your Own Tools Against You

A threat actor spent years moving through aviation, energy, and government networks across South and East Asia. They stole credentials, exfiltrated databases, and harvested browser history from compromised machines. And they did most of it using tools that were already installed on the systems they compromised.

Palo Alto Networks Unit 42 published their findings on CL-UNK-1068 this week, detailing a campaign that hits every blind spot small teams tend to ignore. The group exploited web servers to drop web shells, then pivoted using a mix of custom malware and living-off-the-land binaries (LOLBINs) - legitimate system utilities repurposed for malicious activity. Their toolkit reads like a sysadmin's daily driver list: certutil for encoding, python.exe for DLL side-loading, WinRAR for archiving stolen data, and batch scripts for host enumeration.

The lesson here isn't "state-sponsored attackers are sophisticated." That's obvious. The lesson is that the techniques CL-UNK-1068 used exploit the exact monitoring and compliance gaps that most startups and small teams leave open.

How the Attack Worked

CL-UNK-1068's playbook followed a pattern that's become disturbingly common among advanced persistent threats:

Initial access: Exploitation of internet-facing web servers to deploy web shells (Godzilla and ANTSWORD). These are popular, community-shared tools - not bespoke zero-days. Your web application firewall might block known signatures, but the attackers customize headers and payloads to avoid detection.

Persistence and lateral movement: Once inside, they deployed a mix of custom and open-source tools:

Data exfiltration: This is where it gets creative. The attackers targeted specific file types - .web.config, .aspx, .dll - along with browser history, bookmarks, spreadsheets from user desktops, and database backups from MS-SQL servers. To move data out without triggering file-transfer alerts, they encoded archives as Base64 text using certutil and printed the output to their terminal session. No file upload. No suspicious network transfer. Just text on a screen.

As Unit 42 researcher Tom Fakterman put it: "Using primarily open-source tools, community-shared malware and batch scripts, the group has successfully maintained stealthy operations."

Why LOLBINs Break Your Monitoring

Living-off-the-land techniques are a nightmare for security teams because they bypass the fundamental assumption behind most monitoring: that malicious activity looks different from normal activity.

When an attacker runs certutil -encode data.rar data.txt, your endpoint detection tool sees a legitimate Windows utility performing a documented function. When they execute a Python script via python.exe, your application allowlist says "approved." When they run a batch script that enumerates hostnames and IP addresses, it looks identical to a sysadmin running diagnostics.

Traditional signature-based detection catches known malware binaries. It doesn't catch an attacker using PowerShell, certutil, and python.exe to do things those tools were designed to do.

This is the gap that behavior-based monitoring fills. Instead of asking "is this binary known-malicious?" you ask "is it normal for certutil to encode a 500MB archive at 2 AM on a production web server?" The answer requires a baseline of normal behavior, which requires continuous monitoring, which requires investment that many teams don't make until after something breaks.

If you're running security testing on a limited budget, this is exactly the kind of threat that falls through the cracks. As I wrote in my security testing budget guide, the tools that catch these patterns - EDR with behavioral analytics, SIEM with anomaly detection - are where your security dollars have the highest return. Signature scanning alone won't catch an attacker who only uses your own tools.

The Supply Chain Angle You're Missing

CL-UNK-1068 didn't need to compromise a software package registry to execute a supply chain attack. They compromised legitimate infrastructure - web servers running production applications - and used those systems as staging grounds for lateral movement.

This is supply chain risk in its broadest sense: any system your organization depends on that can be compromised and used as a pivot point. Your web servers, your CI/CD infrastructure, your cloud management consoles, your vendor integrations. The Packagist Laravel supply chain attack I covered last week showed how attackers use dependency chaining to slip malware through legitimate package registries. CL-UNK-1068 shows the other side of supply chain risk: attackers compromising your own infrastructure and turning it into the supply chain vector.

The common thread is trust. Package registries trust that uploaded packages are safe. Organizations trust that their web servers are only running authorized code. SOC 2 auditors trust that you have processes to detect unauthorized changes. Every one of those trust assumptions is a potential attack surface.

What This Means for Compliance

If you're pursuing SOC 2 or maintaining any compliance framework, CL-UNK-1068's techniques map directly to control gaps that auditors will ask about:

CC6.1 - Logical access controls. The attackers used DLL side-loading through legitimate Python executables. This means a signed, approved binary loaded a malicious DLL. If your access controls only check whether the executing binary is authorized, you have a gap. Application allowlisting needs to verify loaded libraries, not just executables.

CC7.1 - Monitoring and detection. The exfiltration technique - encoding data as text and printing to screen - specifically avoids triggering file-transfer monitoring. If your monitoring only watches for file uploads and anomalous network traffic, encoded data leaving through an interactive session is invisible. Your SOC 2 monitoring controls need to cover more than just network-level detection.

CC7.2 - Incident response. CL-UNK-1068 operated for years before detection. If your incident response plan only covers "we detected malware and removed it," you're not prepared for an adversary who uses legitimate tools and maintains persistence through web shells that survive server reboots. Your response plan needs to include threat hunting - proactively searching for indicators of compromise even when no alert has fired.

For solo developers and small teams working through compliance certifications, this might feel overwhelming. You don't have a SOC team running 24/7 threat hunts. But the compensating controls are more accessible than you'd think, and they're the same controls that satisfy auditors:

Practical Controls for Small Teams

1. Enable and review command-line logging. On Windows, enable PowerShell Script Block Logging and command-line process auditing. On Linux, configure auditd to log process execution. This creates the behavioral baseline that makes LOLBINs detectable.

2. Set up file integrity monitoring. Tools like OSSEC (free) or commercial alternatives can alert you when new files appear in web-accessible directories like wwwroot or /var/www/. A new .aspx file showing up on your IIS server at midnight is exactly how Godzilla web shells get deployed.

3. Monitor for credential access tools. Mimikatz and similar tools touch lsass.exe in ways that are detectable. Windows Credential Guard, combined with alerts for lsass.exe access by non-system processes, blocks the most common credential theft path CL-UNK-1068 used.

4. Implement egress filtering. The group used Fast Reverse Proxy (FRP) to tunnel through firewalls. If your production servers can only make outbound connections to known endpoints (your database, your CDN, your API providers), an FRP tunnel to an unknown IP gets blocked automatically. This is a network-level control that doesn't require endpoint agents.

5. Review DLL loading behavior. If you're running Python or other interpreters on production servers, audit what DLLs they load. DLL side-loading via python.exe and pythonw.exe is a well-documented technique. Application control policies that restrict DLL loading to signed, known libraries prevent this vector entirely.

The Bigger Picture: Compliance Is Continuous, Not Annual

The most important takeaway from CL-UNK-1068 isn't a specific technical control. It's that point-in-time security assessments don't catch patient adversaries.

Annual penetration tests check your defenses on the day the tester shows up. They don't catch the web shell that was deployed three months later. Annual compliance audits verify that your controls were operating on the dates in scope. They don't detect that an attacker has been quietly dumping credentials since the last audit cycle.

This is why continuous monitoring isn't just a "nice to have" for compliance - it's the difference between a framework that actually protects you and paperwork that creates a false sense of security. SOC 2 Type II requires evidence that controls operated effectively over a period, not just at a point in time. But the bar for what "monitoring" means is rising. An auditor in 2024 might accept daily log reviews. An auditor evaluating your controls after a CL-UNK-1068-style breach will ask why your monitoring didn't detect certutil encoding gigabytes of data on a web server.

The attackers are using your own tools. Your monitoring needs to be smarter than a signature match. And your compliance program needs to treat security as a continuous practice, not a checkbox exercise.

Keep reading:

• Fake Laravel Packages on Packagist Show Supply Chain Attacks Have Evolved Past Typosquatting
• Security Testing on a Budget: Penetration Testing for Developers
• Compliance Certifications for Solo Developers: What's Actually Possible

Worried about whether your monitoring would catch an attacker living off the land? Let's talk.