Detect Motex LANSCOPE Endpoint Manager - Improper Verification of Communication Channel Source (CVE-2025-61932) in Splunk
CVE-2025-61932 is an Improper Verification of Source of a Communication Channel (CWE-940) vulnerability in Motex LANSCOPE Endpoint Manager. This flaw allows an attacker to send commands or data through a communication channel without proper verification of the channel's origin, potentially enabling unauthorized control over managed endpoints. The vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog, indicating active exploitation in the wild. Attackers may abuse this to impersonate the LANSCOPE management server and push malicious instructions to endpoint agents.
MITRE ATT&CK
- Tactic
- Initial Access Lateral Movement Impact
SPL Detection Query
index=endpoint OR index=network sourcetype IN ("WinEventLog:Security", "xmlwineventlog", "sysmon", "crowdstrike:events:sensor")
| eval process_lower=lower(process_name)
| where like(process_lower, "%lanscope%") OR like(process_lower, "%lsepagent%") OR like(process_lower, "%epagent%") OR like(process_lower, "%lsep%")
| eval dest_port=coalesce(dest_port, DestinationPort)
| eval dest_ip=coalesce(dest_ip, DestinationIp, dest)
| where dest_port IN ("80", "443", "8080", "8443")
| stats count as connection_count, values(dest_ip) as dest_ips, values(dest_port) as dest_ports, dc(dest_ip) as unique_dest_ips by host, process_name, user, _time
| where unique_dest_ips > 0
| eval risk_score=case(unique_dest_ips > 5, "high", unique_dest_ips > 2, "medium", true(), "low")
| table _time, host, user, process_name, dest_ips, dest_ports, connection_count, unique_dest_ips, risk_score
| sort -connection_countIdentifies LANSCOPE agent processes making outbound network connections, particularly to multiple or unexpected destinations that may represent rogue management servers exploiting CVE-2025-61932.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate multi-site LANSCOPE deployments with multiple management servers across regions
- LANSCOPE agents communicating with update servers or cloud telemetry endpoints
- Proxy or gateway infrastructure presenting varied destination IPs for the same logical server
- Lab or test environments with non-standard LANSCOPE configurations
Other platforms for CVE-2025-61932
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate LANSCOPE Agent Connection to Rogue Management Server
Expected signal: DeviceNetworkEvents showing outbound connection to 192.0.2.100:8443 from powershell.exe; Sysmon Event ID 3 network connection; Windows Firewall log entry for outbound blocked/allowed connection
- Test 2LANSCOPE Agent Configuration Tampering via Registry
Expected signal: Sysmon Event ID 13 (Registry value set) for HKCU\SOFTWARE\TestLANSCOPE keys; Windows Security Event ID 4657 (registry value modified) if audit registry is enabled; EDR registry modification alert
- Test 3DNS Query to Suspicious LANSCOPE Management Domain
Expected signal: DNS query logs showing resolution attempt for test-mgmt.example-lab.local; network connection attempt to port 8080; process execution logs showing nslookup/dig/curl invocation; endpoint network telemetry from EDR
Response Playbook
Triage
- Confirm the affected host has LANSCOPE Endpoint Manager installed and identify the installed version. Cross-reference with vendor advisory at https://www.motex.co.jp/news/notice/2025/release251020/ to determine if the version is vulnerable.
- Review network logs for LANSCOPE agent processes (lsepagent.exe, epagent.exe, or lanscope*.exe) and document all destination IPs and ports contacted within the past 72 hours. Compare against the known-good list of authorized LANSCOPE management server addresses.
- Check for anomalous commands, configuration changes, or software deployments that originated from the LANSCOPE management channel after the CVE disclosure date (2025-10-22). Investigate any policy pushes or agent actions that cannot be attributed to legitimate administrator activity.
- Determine the blast radius: identify all endpoints managed by potentially compromised LANSCOPE infrastructure and assess whether rogue management commands were distributed to multiple hosts.
Containment
- Isolate the affected endpoint from the network if active exploitation is confirmed or strongly suspected. If LANSCOPE agent cannot be trusted as a containment vector, use out-of-band network controls (firewall ACLs, VLAN isolation, or EDR network containment) to block the host.
- Block network access from LANSCOPE agents to any management server IPs that are not on the authorized allowlist at the perimeter firewall and on host-based firewalls. Disable or quarantine the LANSCOPE agent service on affected hosts pending patch validation.
Evidence Collection
- Capture full network flow data for all LANSCOPE agent communications in the 30 days prior to detection, preserving source/destination IPs, ports, byte counts, and timestamps. Export from SIEM or NDR platform in a forensically sound format.
- Collect memory dump from affected LANSCOPE agent processes and relevant parent processes on impacted hosts to identify injected code, malicious modules, or in-memory indicators of rogue command execution. Preserve Windows Event Logs (Security, System, Application) and Sysmon logs from affected endpoints.
Escalation Criteria
- !Escalate immediately if rogue management commands have been confirmed to have executed on multiple endpoints, indicating lateral movement or mass deployment of malicious payloads via the compromised LANSCOPE channel.
- !Escalate to incident response leadership and notify the security operations manager if the LANSCOPE management server itself shows signs of compromise, unauthorized access, or if threat actor infrastructure has been positively identified in network logs.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
LANSCOPE agent configuration files and cached management server addresses stored in the agent installation directory (typically C:\Program Files\LANSCOPE\ or platform equivalent) - >
Windows Registry keys under HKLM\SOFTWARE\Motex\ or HKLM\SOFTWARE\LANSCOPE\ containing management server configuration, agent state, and received policy data - >
Network capture files (PCAP) showing LANSCOPE management protocol traffic, particularly TLS certificate details for management server connections that can be compared against legitimate server certificates - >
Windows Event Log entries (Event ID 4688 process creation, 5156 network connection) and Sysmon Event ID 3 (network connection) for LANSCOPE agent processes during the suspected exploitation window
Tuning Guidance
Build and maintain an allowlist of authorized LANSCOPE management server IP addresses and FQDNs in your SIEM. Use this allowlist to filter true positives from noise in the network connection queries. Additionally, baseline the normal check-in frequency for LANSCOPE agents in your environment — agents connecting significantly more frequently than baseline may indicate active command polling from a rogue server. Consider deploying TLS inspection on LANSCOPE management traffic to validate server certificate authenticity, and alert on certificate mismatches as a high-fidelity signal. Suppress alerts for hosts in known-good patched state once the vendor patch is applied and verified.
Hunting Queries
Threat hunting query to enumerate all LANSCOPE agent process executions across the environment over the past 30 days, identifying unusual parent processes, unexpected installation paths, or recently introduced binaries that may indicate tampering or rogue agent deployment as part of CVE-2025-61932 exploitation.
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where FileName has_any ("lanscope", "lsepagent", "epagent")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), CommandLines=make_set(ProcessCommandLine), ParentProcessNames=make_set(InitiatingProcessFileName) by DeviceName, FileName, FolderPath, SHA256
| extend DaysSinceFirstSeen = datetime_diff('day', now(), FirstSeen)
| where DaysSinceFirstSeen < 30
| order by FirstSeen descindex=endpoint sourcetype=sysmon EventCode=1
| where like(lower(Image), "%lanscope%") OR like(lower(Image), "%lsepagent%") OR like(lower(Image), "%epagent%")
| eval age_days=round((now()-strptime(first_seen, "%Y-%m-%dT%H:%M:%S"))/86400, 1)
| stats count, values(CommandLine) as command_lines, values(ParentImage) as parent_processes, min(_time) as first_seen, max(_time) as last_seen by Computer, Image, MD5, SHA256
| sort -countAtomic Red Team Tests
Simulates the network behavior of a LANSCOPE agent connecting to an unauthorized management server to test whether detection rules trigger on unexpected management channel connections. Uses curl to mimic HTTP-based management protocol traffic.
Command
# LAB ONLY - Simulates outbound connection from a process named to match LANSCOPE patterns
$processName = "lsepagent_test"
$rogueServer = "192.0.2.100" # RFC 5737 TEST-NET - replace with lab server in real test
$port = 8443
Write-Host "[Atomic Test] Simulating LANSCOPE agent connection to rogue management server"
Start-Process -FilePath "powershell.exe" -ArgumentList "-Command Invoke-WebRequest -Uri 'https://${rogueServer}:${port}/api/management' -UseBasicParsing -TimeoutSec 5 -SkipCertificateCheck" -PassThru
Write-Host "[Atomic Test] Connection attempt initiated to ${rogueServer}:${port}"Cleanup
Stop-Process -Name "powershell" -ErrorAction SilentlyContinue; Write-Host "Cleanup complete"Expected Telemetry
DeviceNetworkEvents showing outbound connection to 192.0.2.100:8443 from powershell.exe; Sysmon Event ID 3 network connection; Windows Firewall log entry for outbound blocked/allowed connection
Expected Detection
KQL and SPL queries should alert on the outbound connection from a LANSCOPE-pattern process name to an unlisted management server IP
Simulates modification of LANSCOPE management server configuration in the Windows Registry, as an attacker exploiting CVE-2025-61932 might redirect agents to rogue infrastructure by altering stored server addresses.
Command
# LAB ONLY - Modifies registry keys that would store LANSCOPE management server config
$regPath = "HKCU:\SOFTWARE\TestLANSCOPE"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "ManagementServer" -Value "192.0.2.100" -Type String
Set-ItemProperty -Path $regPath -Name "ManagementPort" -Value "8443" -Type DWord
Set-ItemProperty -Path $regPath -Name "LastModified" -Value (Get-Date -Format "yyyy-MM-ddTHH:mm:ss") -Type String
Write-Host "[Atomic Test] Registry keys set to simulate management server redirection"Cleanup
Remove-Item -Path "HKCU:\SOFTWARE\TestLANSCOPE" -Recurse -Force -ErrorAction SilentlyContinue; Write-Host "Registry cleanup complete"Expected Telemetry
Sysmon Event ID 13 (Registry value set) for HKCU\SOFTWARE\TestLANSCOPE keys; Windows Security Event ID 4657 (registry value modified) if audit registry is enabled; EDR registry modification alert
Expected Detection
Registry modification hunting queries and EDR registry alerts should flag modification of LANSCOPE-related registry paths containing management server addresses
Simulates a DNS lookup that a compromised LANSCOPE agent might perform when directed to resolve a rogue management server hostname, enabling detection via DNS monitoring.
Command
# LAB ONLY - Simulates DNS resolution that a LANSCOPE agent might perform for rogue server
# Replace with a lab-controlled domain in real testing
echo "[Atomic Test] Simulating LANSCOPE agent DNS lookup for management server"
SCRIPT_NAME="lanscope_agent_test"
export LANSCOPE_MGMT_HOST="test-mgmt.example-lab.local"
nslookup "${LANSCOPE_MGMT_HOST}" 2>/dev/null || true
dig "${LANSCOPE_MGMT_HOST}" +short 2>/dev/null || true
curl --connect-timeout 3 --silent "http://${LANSCOPE_MGMT_HOST}:8080/api/v1/check-in" 2>/dev/null || echo "Connection failed as expected in lab"Cleanup
unset LANSCOPE_MGMT_HOST; echo "Environment cleanup complete"Expected Telemetry
DNS query logs showing resolution attempt for test-mgmt.example-lab.local; network connection attempt to port 8080; process execution logs showing nslookup/dig/curl invocation; endpoint network telemetry from EDR
Expected Detection
DNS-based hunting queries and network connection detections should flag LANSCOPE-associated processes (or scripts named to match) querying unexpected management server hostnames