Detect Motex LANSCOPE Endpoint Manager - Improper Verification of Communication Channel Source (CVE-2025-61932) in Microsoft Sentinel
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
KQL Detection Query
let lanscope_ports = dynamic(["8080", "8443", "443", "80"]);
let known_mgmt_servers = dynamic([]);
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName has_any ("lanscope", "lsepagent", "lsep", "epagent")
| where RemotePort in (lanscope_ports)
| where isnotempty(RemoteIP)
| extend IsTrustedServer = RemoteIP in (known_mgmt_servers)
| where IsTrustedServer == false
| summarize ConnectionCount=count(), RemoteIPs=make_set(RemoteIP), Ports=make_set(RemotePort) by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, bin(TimeGenerated, 1h)
| where ConnectionCount > 0
| extend AlertTitle = "LANSCOPE Agent Communicating with Unrecognized Management Server"
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, RemoteIPs, Ports, ConnectionCount, AlertTitleDetects LANSCOPE Endpoint Manager agent processes connecting to unrecognized management servers, which may indicate exploitation of CVE-2025-61932 where a rogue server impersonates legitimate LANSCOPE infrastructure.
Data Sources
Required Tables
False Positives & Tuning
- New legitimate LANSCOPE management server IPs not yet added to the allow-list
- Network topology changes causing agents to connect through new relay or proxy addresses
- LANSCOPE version upgrades that temporarily change communication endpoints during rollout
- NAT or load balancer changes presenting new external IPs for the same management infrastructure
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