Listen to this Post
Project CAV3RN Evolves: Google Apps Script Becomes a Stealthy New C2 Channel for Cyberespionage
Introduction: When Trusted Cloud Services Become the Hiding Place
Cyberespionage campaigns are increasingly moving away from noisy, easily identifiable command-and-control infrastructure and toward services that defenders already trust. Instead of communicating directly with an attacker-controlled server, modern malware can hide its traffic behind legitimate cloud platforms, making malicious activity look like ordinary business traffic.
Project CAV3RN is a strong example of this evolution.
The modular cyberespionage framework has been observed targeting organizations in Israel while introducing a sophisticated command-and-control architecture that can dynamically decide how compromised systems communicate with their operators. One of its most notable additions is a Google Apps Script-based relay, allowing the malware to conceal part of its communications behind Google’s infrastructure.
The technique is particularly interesting because Google Apps Script is not being used simply as a static dead-drop location. CAV3RN uses DNS responses as a lightweight control mechanism, allowing operators to influence whether an infected machine communicates through the Google relay or connects directly to attacker-controlled HTTPS infrastructure.
That combination creates something much more dangerous than a conventional C2 channel: a communication system capable of adapting to network conditions without requiring the attackers to replace the malware itself.
The Core Threat: CAV3RN Is Built for Flexibility
Project CAV3RN appears to have been designed around modularity and operational resilience. Rather than placing every capability into one monolithic executable, the framework can load, manage, and update individual components while the compromised system remains active.
At the center of the newly identified communication architecture is GoogleService.dll, a 64-bit .NET 8 NativeAOT module.
NativeAOT is significant from a defensive perspective because it compiles .NET applications into native executables rather than relying on the traditional managed runtime model. In an offensive framework, this can complicate analysis and create a communication component that behaves more like a conventional native binary.
CAV3RN also uses a local DLL broker that acts as a management layer for the framework’s components. This allows operators to load modules, maintain them, and potentially replace or upgrade individual capabilities without rebuilding the entire implant.
The result is an architecture designed around persistence and adaptability rather than simplicity.
DNS Is More Than DNS in This Campaign
One of the most fascinating elements of the CAV3RN communication system is the way it abuses DNS responses as instructions.
Before checking for commands or transmitting information, GoogleService.dll performs a DNS query against a subdomain associated with studiotikva[.]com.
The request itself contains several pieces of information, including a randomly generated value, the malware’s current error state, and a hexadecimal representation of the victim identifier.
At first glance, this may look like ordinary DNS activity.
It is not.
The response is effectively interpreted as a small command from the operator-controlled infrastructure.
The Final IP Octet Becomes a Control Signal
CAV3RN examines the final octet of an IPv4 address returned by the DNS server.
Different values correspond to different communication decisions.
A response ending in 120 can cause the malware to select either the Google Apps Script route or direct HTTPS communication, with the decision influenced by the previous failure state.
A response ending in 130 generally directs the implant toward direct HTTPS communication.
A response ending in 140 forces an exception.
Other values generally cause CAV3RN to favor the Google Apps Script communication channel.
This is an elegant example of turning an otherwise ordinary network protocol into a command channel.
The attackers do not necessarily need to send a conventional command such as “use Google.” Instead, they can encode operational decisions inside DNS infrastructure that the malware already expects to query.
Why This Design Is Dangerous for Defenders
The value of this architecture lies in its ability to separate the implant from the infrastructure used to control it.
If defenders block the direct C2 server, the operators can redirect compromised systems toward Google Apps Script.
If the Google relay becomes unusable, DNS can steer the malware back toward direct HTTPS.
That means the attacker does not necessarily need to push a new malware version every time infrastructure changes.
The DNS layer becomes a remote traffic-management mechanism.
From a defensive perspective, this creates an important challenge: blocking one destination may not be enough to eliminate the underlying communication capability.
Google Apps Script Becomes a Relay
When DNS selects the Google communication mode, CAV3RN constructs a URL following the general Google Apps Script deployment structure:
https://script.google.com/macros/s/{deployment-ID}/exec
The implant sends a POST request to the Apps Script deployment.
The interesting part comes next.
According to the reported analysis, the Google Apps Script component acts as a relay. The request instructs the script to make a GET request toward the upstream command-and-control server.
This creates an additional layer between the infected machine and the actual attacker infrastructure.
Instead of:
Victim → Attacker C2
the communication can become:
Victim → Google Apps Script → Attacker C2
That distinction matters.
The Google Layer Creates Operational Cover
A direct connection to a suspicious IP address can be relatively easy for a security team to investigate.
Traffic involving a major cloud provider is different.
Large organizations generate enormous quantities of legitimate traffic toward Google’s infrastructure every day. Security teams therefore cannot simply block every connection involving Google without causing substantial operational disruption.
The attackers can exploit that trust boundary.
The objective is not necessarily to make malicious traffic completely invisible. Instead, the objective is to make it blend into an environment where legitimate traffic is already abundant.
That is a recurring pattern in modern cyberespionage: attackers increasingly hide inside trusted infrastructure rather than attempting to build infrastructure that looks trustworthy.
CAV3RN Can Rotate Its Google Relay
The Google Apps Script deployment identifier is not treated as permanent.
CAV3RN periodically checks whether the deployment ID stored by the implant is still valid.
The malware compares a portion of an MD5 hash derived from its stored deployment ID with bytes contained in another DNS A-record response.
If the values do not match, the implant begins a recovery process.
Rather than downloading an entire replacement configuration from a single location, CAV3RN can obtain a replacement deployment ID through a sequence of DNS queries.
The information is recovered in small pieces.
The new identifier can then be written back into the local configuration.
Why Replaceable Infrastructure Matters
This mechanism gives the operators another layer of resilience.
Suppose a Google Apps Script deployment is identified and taken down.
A conventional malware family might require an updated configuration file or a new payload.
CAV3RN can instead use its DNS infrastructure to distribute a replacement deployment identifier.
The compromised host remains infected.
The core communication component remains installed.
Only the relay destination changes.
This is precisely the kind of architecture defenders increasingly need to consider when investigating modular implants.
DNS Becomes a Lightweight Command Plane
The most important conceptual takeaway is that CAV3RN is not simply using DNS for domain resolution.
DNS effectively functions as a lightweight command-and-control decision plane.
The malware asks the DNS infrastructure a question.
The response contains information.
The implant interprets that information.
The result determines how the next communication stage should behave.
This is a clever approach because DNS is fundamental to almost every modern network environment. Organizations cannot realistically eliminate DNS traffic altogether.
That makes the protocol attractive for attackers seeking a reliable control mechanism.
The Failure State Adds Another Layer of Intelligence
CAV3RN’s routing decisions are also influenced by previous communication failures.
This means the implant does not necessarily treat each DNS response as an isolated instruction.
Its historical state can influence what happens next.
An attacker can therefore maintain a rudimentary fallback mechanism in which communication changes depending on whether the previous channel succeeded or failed.
That makes the framework more resilient than malware that relies on a single hard-coded C2 address.
The Modular Architecture Makes CAV3RN Harder to Remove
The use of a local DLL broker is another important architectural decision.
Instead of treating the implant as one fixed program, CAV3RN can manage individual components.
This gives operators greater flexibility.
A communication component can potentially be updated independently.
A new capability can potentially be loaded without replacing the entire framework.
A compromised component can potentially be removed or upgraded while the broader implant continues running.
From an incident-response perspective, this means deleting one suspicious DLL may not necessarily remove the complete threat.
NativeAOT Adds an Additional Analysis Challenge
GoogleService.dll is described as a 64-bit .NET 8 NativeAOT module.
That detail deserves attention.
Traditional .NET malware can often expose useful metadata and managed structures that help reverse engineers understand its behavior.
NativeAOT changes that analysis workflow because managed code is compiled into native machine code.
This does not make the malware impossible to analyze.
It does, however, alter the tooling and investigative process required to understand the module.
Security teams should therefore avoid assuming that every .NET component can be investigated using exactly the same techniques.
Deep Analysis: Investigating the C2 Architecture
DNS Investigation
Security teams investigating suspected CAV3RN activity should begin by examining DNS telemetry.
A useful first step on a Linux investigation host is:
dig +short suspicious-subdomain.studiotikva[.]com A
Because the domain in public reporting is intentionally defanged, investigators should use the correctly re-fanged indicator only inside an authorized and controlled environment.
For Windows environments, defenders can inspect DNS resolution behavior with:
Resolve-DnsName suspicious-domain.example -Type A
The objective is not simply to identify the resolved IP address.
Investigators should examine the response patterns and determine whether the final octet appears to correlate with different malware behaviors.
Search DNS Logs for Unusual Patterns
A SIEM query can be used to identify repeated DNS requests from the same workstation:
dns.query IN (.studiotikva[.]com)
| stats count, values(dns.answer) by src_ip, dns.query
The exact syntax will depend on the SIEM platform.
The important investigative principle is to correlate the queried hostname, source host, timestamp, response address, and subsequent network connection.
Look for Google Apps Script Traffic
Defenders should also examine outbound requests involving:
script.google.com
A connection to Google Apps Script alone is not proof of compromise.
Legitimate organizations use Google services extensively.
The stronger signal is the combination of unusual DNS activity, suspicious process behavior, an unexpected native .NET module, and HTTP POST requests to Apps Script followed by unusual external communication.
Investigate the DLL
If a suspicious GoogleService.dll is discovered, defenders should collect the file before deleting it.
On Windows, basic file investigation can begin with:
Get-FileHash .\GoogleService.dll -Algorithm MD5 Get-FileHash .\GoogleService.dll -Algorithm SHA256
The MD5 value reported for CommunicationUxTheme.dll is:
904784c9943d019da332bea2cd03996f
Another reported MD5 indicator associated with net.dll is:
f9156d42410c8a5429dec43329bd72e0
These indicators should be treated as starting points rather than definitive proof of compromise.
Check File Metadata
Investigators can examine suspicious files using PowerShell:
Get-Item .\GoogleService.dll | Format-List
For deeper analysis, defenders can inspect PE headers, imports, embedded strings, digital signatures, compilation characteristics, and network-related functions using their approved malware-analysis tooling.
Examine Active Network Connections
On a potentially compromised Windows host, defenders can review active connections with:
Get-NetTCPConnection | Sort-Object RemoteAddress |
Format-Table -AutoSize
Older environments can also use:
netstat -ano
The goal is to correlate suspicious network destinations with the process responsible for generating them.
Map the Process to the Connection
Once a suspicious connection is identified, investigators can map it to a process:
Get-NetTCPConnection -State Established | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess
Then:
Get-Process -Id <PID>
This can help determine whether the traffic originates from a legitimate browser, an expected enterprise application, or a suspicious framework component.
Monitor the DNS-to-HTTPS Sequence
One of the strongest behavioral detections may come from sequence analysis.
Look for a pattern similar to:
DNS request
↓
A-record response
↓
Routing decision
↓
HTTPS request
↓
Google Apps Script or direct C2
Behavioral detections are particularly valuable when attackers rotate domains, IP addresses, or deployment identifiers.
Detection Should Focus on Behavior, Not Just Indicators
Static indicators are useful, but
An IP address can change.
A domain can change.
A Google Apps Script deployment can be replaced.
A malware component can be renamed.
A DNS response can redirect the victim somewhere else.
The behavioral pattern is much harder for an attacker to replace.
Security teams should therefore combine DNS telemetry, endpoint telemetry, process activity, HTTP metadata, file analysis, and threat-intelligence indicators.
Why Google Apps Script Is an Attractive Choice
Google Apps Script offers attackers something valuable: legitimate cloud infrastructure with globally distributed availability and a familiar domain.
The attacker does not need to convince the victim’s network that an unknown domain is safe.
Instead, the malware communicates with infrastructure associated with a widely used technology ecosystem.
This does not make the traffic inherently malicious.
It makes contextual analysis more important.
The Broader Trend: Living Inside Trusted Infrastructure
CAV3RN fits into a much larger trend in cyber operations.
Attackers increasingly abuse legitimate platforms as infrastructure.
Cloud storage services, collaboration platforms, code repositories, public content delivery networks, messaging services, DNS providers, and serverless functions can all become components in an attack chain.
The strategic advantage is simple.
Defenders are often much more willing to permit communication with trusted infrastructure than with newly registered or obviously malicious domains.
The Security
Blocking Google Apps Script across an enterprise may not be practical.
It could interfere with legitimate automation and business applications.
Blocking DNS is even less realistic.
The correct response is therefore not necessarily to block every service abused by attackers.
Instead, defenders need to identify suspicious combinations of behavior.
A workstation suddenly querying an unusual domain, loading an unexpected native module, contacting Google Apps Script, and then communicating with an obscure external server is far more suspicious than any individual event.
What Organizations Should Monitor
Organizations should prioritize several telemetry sources.
DNS logs should record both queries and answers.
Proxy logs should retain destination hostnames and request metadata.
Endpoint detection platforms should monitor unexpected DLL loading and unusual process execution.
Network monitoring should identify suspicious transitions between cloud services and external infrastructure.
File-integrity monitoring can help detect newly introduced modules.
SIEM correlation rules should connect these events instead of analyzing each one independently.
What Makes the CAV3RN Technique Particularly Interesting
The most impressive aspect of this campaign is not any single component.
It is the interaction between them.
DNS provides control.
Google Apps Script provides a relay.
HTTPS provides encrypted transport.
The DLL broker provides modularity.
NativeAOT provides a different reverse-engineering profile.
The deployment-ID recovery mechanism provides infrastructure rotation.
Together, these features form a communication system designed to survive individual defensive actions.
What Happens If One Channel Is Blocked?
The architecture appears designed around the assumption that defensive controls will eventually disrupt something.
That assumption is important.
Instead of relying on a perfect connection, CAV3RN incorporates alternative communication routes.
If Google-based communication becomes unavailable, DNS can influence the implant toward direct HTTPS.
If a Google Apps Script deployment becomes invalid, the malware can retrieve a replacement identifier.
If infrastructure changes, the operators do not necessarily need to distribute a new implant.
This is resilience by design.
Incident Response Implications
If CAV3RN is suspected, organizations should avoid immediately wiping the first infected machine without collecting evidence.
The initial system may contain valuable configuration data, deployment identifiers, DNS artifacts, timestamps, loaded modules, and other evidence that can help identify additional compromised hosts.
Memory acquisition may also be valuable when permitted by the organization’s incident-response procedures.
Investigators should then pivot from the original endpoint to DNS activity and identify other machines making similar requests.
Hunt for the Infrastructure, Not Just the Malware
A single infected host is an endpoint problem.
A recurring DNS pattern across multiple systems may reveal the campaign.
Security teams should therefore perform retrospective hunting across available logs.
Look for unusual DNS subdomains, repeated queries from otherwise unrelated endpoints, unexpected Google Apps Script access, and suspicious outbound connections immediately following DNS resolution.
The objective is to reconstruct the communication graph.
The Value of Threat Hunting
Threat hunting is particularly important in campaigns that use legitimate infrastructure.
Traditional blocklists may fail because the malicious infrastructure is mixed with legitimate services.
A hunt based on process behavior and communication sequences can identify the attack even when the destination itself is not classified as malicious.
This is one of the strongest lessons from CAV3RN.
Indicators of Compromise
Reported MD5 indicators include:
CommunicationUxTheme.dll
904784c9943d019da332bea2cd03996f
net.dll
f9156d42410c8a5429dec43329bd72e0
The reported infrastructure includes the intentionally defanged domain:
studiotikva[.]com
Organizations should keep these indicators defanged in documentation and threat-intelligence systems unless they are being handled inside a controlled analysis environment.
What Undercode Say:
1. CAV3RN Shows Where C2 Is Heading
The most important lesson from this campaign is that command-and-control infrastructure is becoming increasingly modular.
- DNS Is Being Turned Into an Operational Control Layer
CAV3RN demonstrates that DNS can carry more than simple resolution information.
- The IP Address Can Become a Command
The final octet of a DNS response can effectively act as a small instruction set.
4. That Is Extremely Efficient
The malware does not need to download a large configuration file simply to change communication behavior.
- Google Apps Script Provides a Valuable Cover
Attackers can place a legitimate cloud provider between the infected machine and their infrastructure.
- Trust Becomes Part of the Attack Surface
Defenders often trust major cloud platforms because blocking them would damage legitimate business operations.
7. CAV3RN Exploits That Reality
The attackers are not necessarily hiding inside an unknown network.
They are hiding inside infrastructure that defenders already recognize.
- But Cloud Services Are Not Automatically Safe
A legitimate platform can still be abused for malicious purposes.
9. Context Is Everything
The question is not simply whether a machine contacted Google.
The question is why it contacted Google, which process initiated the connection, and what happened immediately afterward.
10. The DNS Layer Deserves More Attention
Many organizations collect DNS logs but do not use them aggressively for threat detection.
11. That Is a Missed Opportunity
DNS can reveal attacker-controlled infrastructure even when the final C2 connection is encrypted.
12. CAV3RN Makes This Especially Clear
The
13. Modularity Changes Incident Response
Security teams should not assume that removing one DLL eliminates a modular implant.
- The DLL Broker Is a Strategic Feature
It gives the operator a mechanism for maintaining components while the host remains active.
15. NativeAOT Should Also Be On
The technology is legitimate, but its presence inside an unexpected component deserves investigation.
16. Infrastructure Rotation Is Becoming Normal
Attackers increasingly assume that defenders will discover their infrastructure.
17. Their Goal Is Resilience
The objective is not to maintain one perfect server forever.
- The Objective Is To Keep Communication Alive
CAV3RN’s Google relay replacement mechanism demonstrates that philosophy.
19. DNS Can Help Them Pivot
The attacker can change the communication destination without necessarily changing the implant.
20. That Reduces Operational Friction
Infrastructure changes become configuration problems rather than malware-development problems.
21. Defenders Need Equivalent Flexibility
Detection systems should be capable of identifying behavior even when individual indicators change.
22. Static IOCs Are Still Useful
Hashes and domains remain valuable starting points for investigation.
- But They Should Not Be the Final Detection Layer
An attacker can replace a file or infrastructure much faster than an organization can rebuild its entire detection strategy.
24. Behavioral Detection Is More Durable
The sequence of DNS resolution, module loading, and unusual outbound communication can remain recognizable.
25. Cloud-Based C2 Requires Better Correlation
Endpoint, DNS, proxy, and network data should be correlated.
- One Log Source Rarely Tells the Full Story
The malicious behavior becomes clearer when events are connected.
- Google Apps Script Is Not the Enemy
Legitimate services should not automatically be blocked simply because attackers abuse them.
28. The Real Problem Is Malicious Context
Security controls should distinguish ordinary business automation from suspicious implant behavior.
- This Is a Growing Enterprise Security Challenge
As more services move into the cloud, attackers gain more legitimate infrastructure to abuse.
30. Serverless Platforms Are Particularly Interesting
They can provide lightweight, flexible infrastructure without the attacker maintaining a traditional server.
31. That Can Reduce Infrastructure Exposure
A conventional C2 server can expose IP addresses, hosting providers, and operational fingerprints.
32. A Relay Can Obscure That Relationship
The infected endpoint may communicate with an intermediary rather than directly with the operator’s infrastructure.
33. CAV3RN Demonstrates Layered Evasion
No single trick provides the entire advantage.
The strength comes from combining several ordinary technologies.
- This Is What Modern Espionage Malware Looks Like
The most sophisticated implants increasingly resemble distributed software systems rather than simple malicious executables.
35. Defenders Should Think Like System Architects
Understanding how the malware is designed can reveal more than simply cataloging its indicators.
36. Ask What Can Change Remotely
In
37. Ask What Cannot Change Easily
The underlying behavioral architecture is much harder to replace.
38. That Is Where Detection Should Focus
Security teams should hunt for the
- CAV3RN Is a Warning About Trusted Infrastructure
The next generation of cyberespionage may increasingly operate through services that defenders cannot simply block.
40. The Defensive Advantage Is Still Available
Organizations that combine DNS visibility, endpoint telemetry, behavioral analytics, and disciplined threat hunting can detect this type of activity before a trusted cloud service becomes a blind spot.
✅ The CAV3RN Framework Uses a Modular Architecture
The supplied reporting describes GoogleService.dll as a 64-bit .NET 8 NativeAOT communication component and identifies a local DLL broker capable of managing framework components. This supports the assessment that modularity is a core part of the framework’s design.
✅ DNS Responses Are Used for Routing Decisions
The reported CAV3RN behavior uses DNS A-record responses as a control mechanism, with specific final-octet values influencing whether communication uses Google Apps Script, direct HTTPS, or an exception path. This is a significant technical detail rather than ordinary DNS resolution.
✅ Google Apps Script Is Used as a Relay
The described communication chain has the malware send a POST request to a Google Apps Script deployment, which then makes a GET request toward upstream C2 infrastructure. This creates an intermediary relay between the compromised endpoint and the attacker’s server.
⚠️ Google Traffic Alone Is Not Evidence of CAV3RN
Connections to script.google.com are common in legitimate environments. A detection rule based solely on Google Apps Script access would likely generate substantial false positives and should instead be combined with endpoint, DNS, process, and network telemetry.
⚠️ The Reported MD5 Hashes Should Be Treated as Supporting Indicators
File hashes can be useful for identifying known samples, but they do not establish that every file with a similar name is malicious. Defenders should combine hashes with behavioral and contextual evidence.
Prediction
(+1) CAV3RN-Style Cloud Relays Will Become More Common
The use of trusted cloud services as C2 intermediaries is likely to continue growing as attackers look for infrastructure that is difficult for organizations to block outright.
(+1) DNS Will Remain an Important Covert Control Mechanism
DNS is too fundamental to enterprise networking to disappear, making it an attractive protocol for lightweight routing decisions, infrastructure discovery, and fallback control.
(+1) Modular Malware Will Put More Pressure on Incident Response
Future espionage frameworks are likely to continue separating communication, execution, persistence, and update mechanisms so that attackers can replace individual components without rebuilding the entire implant.
(-1) Simple IOC-Based Defenses Will Become Less Effective
As attackers increasingly rotate domains, cloud deployments, hashes, and relay infrastructure, organizations that depend heavily on static indicators may struggle to detect the next generation of campaigns.
(+1) Behavioral Detection Will Become the Stronger Defensive Strategy
The most resilient defense against campaigns like CAV3RN will be the ability to recognize suspicious sequences: unusual DNS behavior, unexpected module loading, cloud-service communication, and anomalous outbound connections.
Final Thoughts: The Real Battle Is Over Trust
Project CAV3RN is a reminder that the modern command-and-control battlefield is no longer limited to suspicious servers and obviously malicious domains.
The more important question is becoming: which legitimate services can attackers turn into infrastructure?
CAV3RN’s use of DNS-controlled routing and Google Apps Script demonstrates how several ordinary technologies can be combined into a highly adaptable communication architecture.
The attackers gain flexibility without constantly changing the implant.
They can switch communication routes.
They can replace a cloud relay.
They can use DNS as a control plane.
They can place trusted infrastructure between the victim and the real C2.
For defenders, that changes the equation.
Blocking a single IP address is no longer enough.
Blocking a domain is no longer enough.
Even blocking a specific cloud endpoint may only solve one part of the problem.
The stronger strategy is to understand the behavior connecting all these components.
When a suspicious module appears on an endpoint, DNS begins making unusual queries, Google Apps Script suddenly becomes part of the communication chain, and external HTTPS traffic follows the DNS decision, those events should not be viewed independently.
Together, they can reveal the architecture of an intrusion.
That is ultimately what makes CAV3RN important.
It is not simply another malware family with another C2 server.
It represents a broader evolution in cyberespionage: attackers are learning to build communication systems that adapt faster than defenders can block individual indicators.
And as trusted cloud infrastructure continues to become part of everyday enterprise operations, the ability to distinguish legitimate cloud activity from malicious use of the cloud will become one of the defining challenges of modern cybersecurity.
▶️ Related Video (80% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.instagram.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
