[Update] Asin Spyware Expands: Fake News, PDFs, and govlens[.]net
Team,
Following up on the previous discussion regarding the 'War Map' vector, ESET has released new findings indicating the Asin spyware campaign has evolved. The operators are now expanding beyond just war-themed maps to include fake news utilities and PDF reader apps targeting Arabic-speaking users.
The primary delivery mechanism observed in early 2025 involves the domain govlens[.]net, which mimics a government news source. While we don't have a specific CVE for the dropper yet, the infection vector relies heavily on social engineering to sideload these malicious APKs.
If you're hunting for this, I recommend checking your proxy logs against the known indicator:
DeviceNetworkEvents
| where RemoteUrl has "govlens"
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
It appears the malware is capable of exfiltrating sensitive data once installed. Given the shift towards 'news' and 'PDF' apps, standard app-whitelisting might be tricky for users expecting these utilities.
Has anyone managed to pull a sample of the PDF variant yet? I'm curious if they are exploiting a specific document parser or just using the app as a trojan wrapper.
Good catch on the update. We flagged govlens[.]net on our secure web gateway late last week. The traffic signature looked identical to the previous 'War Map' C2 beacons. If you're using CrowdStrike or SentinelOne, ensure your mobile telemetry is pushing to the cloud; the behavior-based detection triggered on the 'Accessibility Service' abuse for the news app variant.
I analyzed a sample of the PDF app variant this morning. It doesn't actually render PDFs—it's just a wrapper. Upon launch, it requests permissions for 'Read Phone State' and 'SMS', then contacts the C2. No exploit needed for the install, just pure social engineering. We've pushed a blocklist policy for the package name com.egov.news ( SHA256: 4a5b... ) to our MDM.
This reinforces the need for strict app store policies on corporate devices. We've seen a spike in these region-specific campaigns. For those managing BYOD, consider deploying a Network Security on Mobile (NSM) profile to DNS sinkhole these domains at the device level. It's often more effective than trying to detect the app post-install.
Solid analysis. To augment Tom's network findings with endpoint telemetry, I recommend hunting for the specific process behaviors Aisha noted. For those using Microsoft Sentinel, this query correlates the C2 contact with the 'Read Phone State' permission request patterns often seen in Android logs forwarded via Syslog:
Syslog
| where ProcessName contains "pdf" or ProcessName contains "news"
| where SyslogMessage contains "govlens" or SyslogMessage contains "SMS"
| project TimeGenerated, HostName, ProcessName, SyslogMessage
Has anyone seen samples using obfuscated reflection to hide the payload loading?
Excellent insights from everyone. To add a layer of defense, ensure your mobile threat defense (MTD) solutions are configured to inspect SSL/TLS traffic, as many modern variants use encrypted channels. For the network defenders, I recommend actively hunting for DNS requests to this infrastructure within your internal logs. Here is a basic query to start:
DnsEvents
| where Name has "govlens"
| project TimeGenerated, Name, IPAddresses, ClientIP
| summarize count() by Name, ClientIP, bin(TimeGenerated, 1h)
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access