{
	"id": "47fcf7de-fb00-477d-b23f-1e5abb441a8f",
	"created_at": "2026-04-06T00:07:40.162345Z",
	"updated_at": "2026-04-10T03:23:52.305911Z",
	"deleted_at": null,
	"sha1_hash": "2c75509aeb18a5149c07ff6ac15d02e00d7d154a",
	"title": "Virtual Private Keylogging: Cisco Web VPNs Leveraged for Access and Persistence",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 398517,
	"plain_text": "Virtual Private Keylogging: Cisco Web VPNs Leveraged for Access\r\nand Persistence\r\nBy mindgrub\r\nPublished: 2015-10-07 · Archived: 2026-04-05 23:13:00 UTC\r\nIn the world of information security, there is never a dull moment. Part of the fun of working in this space is that\r\nyou always get to see attackers do something new or put a new spin on something old. Last month at the CERT-EU Conference in Brussels, Belgium, Volexity gave a presentation on a recent evolution in how attackers are\r\nmaintaining persistence within victim networks. The method, which involves modifying the login pages to Cisco\r\nClientless SSL VPNs (Web VPN), is both novel and surprisingly obvious at the same time. Attackers have been\r\nable to successfully implant JavaScript code on the login pages that enables them to surreptitiously steal employee\r\ncredentials as they login to access internal corporate resources.\r\nWhether you are proactively monitoring your network or reactively undergoing an incident response, one of the\r\nlast places you might examine for backdoors are your firewalls and VPN gateway appliances. As the industry is\r\nlearning, firewalls, network devices, and anything else an attacker might be able to gain access to should be\r\nscrutinized just as much as any workstation or server within an organization. Having your own devices turned\r\nagainst you can make for a bad week. This represents yet another way attackers are taking credential theft and\r\nnetwork persistence to the next level.\r\nCisco Clientless SSL VPN (Web VPN)\r\nThe Cisco Clientless SSL VPN (Web VPN) is a web-based portal that can be enabled on an organization’s Cisco\r\nAdaptive Security Appliance (ASA) devices. The Cisco Web VPN does not require a thick client and is accessed\r\nentirely through a web browser by end users. Once a user is authenticated to the Web VPN, based on the\r\npermissions the user has, they may be able to access internal web resources, browse internal file shares, and\r\nlaunch plug-ins that allow them to telnet, ssh, or VNC to internal resources. The average user would interface with\r\ntheir organization’s Cisco Web VPN via a screen similar to the one show in Figure 1 below.\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 1 of 9\n\nFigure 1. Cisco Clientless SSL VPN Login Page\r\nThis is certainly not a resource to which you want an attacker to gain access. Unfortunately, Volexity has found\r\nthat several organizations are silently being victimized through this very login page. This begs the question: How\r\nare the attackers managing to pull this off? It turns out it’s possible through a couple different methods. The first\r\nmethod involves an exploit and the second requires good old fashion administrative access.\r\nCVE-2014-3393: Security Appliance Turned Security Risk\r\nVolexity has been able to track its earliest known abuse of Cisco Web VPN login pages back to November 2014. It\r\nappears to have started with CVE-2014-3393, a vulnerability in, you guessed it, the Cisco Clientless SSL VPN\r\nportal. This issue was initially reported by Alec Stuart-Muirk and was covered by Cisco Advisory ID: cisco-sa-20141008-asa on October 8, 2014. Cisco also released a notice about public exploitation of the vulnerability on\r\nFebruary, 18, 2015. An excerpt from the original advisory describing the vulnerability is shown below.\r\nA vulnerability in the Clientless SSL VPN portal customization framework could allow an\r\nunauthenticated, remote attacker to modify the content of the Clientless SSL VPN portal, which could\r\nlead to several attacks including the stealing of credentials, cross-site scripting (XSS), and other types\r\nof web attacks on the client using the affected system.\r\nThe vulnerability is due to a improper implementation of authentication checks in the Clientless SSL\r\nVPN portal customization framework. An attacker could exploit this vulnerability by modifying some\r\nof the customization objects in the RAMFS cache file system. An exploit could allow the attacker to\r\nbypass Clientless SSL VPN authentication and modify the portal content.\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 2 of 9\n\nFigure 2. The lizard that could\r\nLater in the same month at Ruxcon 2014, Stuart-Murik further detailed the Cisco Clientless SSL VPN\r\nvulnerability in a presentation titled “Breaking Bricks and Plumbing Pipes: Cisco ASA a Super Mario Adventure“.\r\nCoinciding with his presentation, a Metasploit module was released that could be leveraged to exploit vulnerable\r\nservers.\r\nExploitation in the Wild\r\nWhile Cisco provided updated software to address the vulnerability, attackers were already off to the races.\r\nVulnerable organizations that were slow to update may have received an unwelcome addition to the source of their\r\nlogon.html file. Figure 3 below shows malicious JavaScript, as seen from the source of an impacted organizations\r\nCisco Web VPN login page.\r\nFigure 3. Malicious JavaScript on Cisco Web VPN\r\nWhile not visible due to URL obfuscation, the file 1.js was hosted on the compromised website of a legitimate\r\nNGO. This website also leveraged a valid SSL certificate, which kept all communications encrypted. The file 1.js\r\nwas a variant of an online script called “xss.js” that was designed to steal form data. Victim organizations\r\neffectively had their Cisco Web VPN devices turned into credential collectors for the attackers. This particular\r\nround of attacks appears to have compromised several organizations around the globe. Volexity observed this\r\ncampaign successfully compromising the following verticals:\r\nMedical\r\nThink Tank / NGO\r\nUniversity and Academic Institutions\r\nMulti-national Electronics / Manufacturing\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 3 of 9\n\nVolexity also observed a number of other compromises that appear to have occurred later on. In another case, the\r\nattackers compromised a different legitimate NGO to host their malicious JavaScript. In that case, Volexity was\r\nnot able to obtain a copy of the code as it had been taken down already. The table below contains additional details\r\non exploit URLs that Volexity observed being used in the wild to exploit the organization’s Cisco Web VPNs.\r\nURL Notes\r\nhttps://103.42.181.84/2/css.js\r\nThis IP no longer appears to host a malicious JavaScript file. The domain\r\ncscoelab.com previously resolved to the IP address 103.42.181.84. Note:\r\ncscoelab.com currently resolves to 43.251.116.175.\r\nhttp://webxss.cn/mu5AOh?\r\n1440094244\r\nwebxss.cn has been down in every instance Volexity tried to connect to it.\r\nIt appears the website likely allowed users to upload and host their own\r\nJavaScript. The epoch timestamp appending to the end of URI may\r\nindicate the URL was created on August 20, 2015.\r\nAdministratively Compromised\r\nIn several other cases involving breaches to the Cisco Web VPN, it is unclear if an exploit was leveraged or if the\r\nattackers actually already had sufficient credentials to directly modify the login page through administrative\r\naccess. Volexity has worked on several past intrusions where attackers have thoroughly breached an organization\r\nand have been able to gain access to security devices, networking equipment, and other critical information\r\ntechnology resources. Attackers are typically able to gain “legitimate” access throughout a victim organization’s\r\nenvironment by installing keyloggers, dumping credentials from systems, exfiltrating documents (spreadsheets)\r\nthat contain password lists, and identifying passwords that are commonly reused by administrators. Once armed\r\nwith these credentials, an attacker with access to a victim’s network can typically perform the same functions as\r\nany administrator or highly-privileged individual within the company.\r\nVolexity knows it is 100% possible and surmises it may be likely in some cases that the attackers leveraged\r\ncredentialed administrative access to a Cisco ASA appliance in order to modify the login page. This can be done\r\nvia the Cisco Adaptive Security Device Manager (ASDM), a Java administrative interface for Cisco firewalls that\r\ncan be accessed via a web browser. Access to the devices ASDM should be restricted through access control lists\r\n(ACLs) as tightly as possible. At minimum, this is not an interface that should be open to the Internet. Attackers\r\nthat are able to access this interface by having access to a victim’s environment or due to an ACL misconfiguration\r\ncan easily modify code that is loaded via the Cisco Web VPN login page.\r\nOrganizations can also examine the settings for the Clientless SSL VPN from within the ASDM to verify that\r\nnothing is out of the ordinary. In order verify the Web VPN settings, you must first be logged into the ASDM.\r\nThen you can navigate to the following: Remote Access VPN -\u003e Clientless SSL VPN Access -\u003e Portal -\u003e\r\nCustomization. Once at this screen, you can load the various components of the Portal Page. Below is an example\r\nof the default view of the Title Panel settings for the Logon Page. This is the most commonly modified area of the\r\nWeb VPN that’s been observed by Volexity thus far.\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 4 of 9\n\nFigure 4. Cisco Web VPN Customization\r\nAll an attacker has to do to modify this page to display malicious code is to add JavaScript/HTML anywhere in\r\nthe text field. It is also possible for an attacker to upload their own JavaScript file to the Cisco Web VPN.\r\nJapanese Government and High-Tech Industries Targeted\r\nOne of the most targeted series of attacks that Volexity has observed leveraging these techniques has been against\r\nthe Japanese Government and High-Tech industries. In these attacks, multiple Japanese organizations were\r\ncompromised and had their Cisco Web VPN portals modified to load additional JavaScript code. The URL format\r\nof the JavaScript code, that was inserted into the source look familiar to some blog readers.\r\nFigure 5. Scanbox on Cisco Web VPN\r\nThe JavaScript in these attacks links back to a JavaScript profiling and exploitation framework called Scanbox.\r\nThe framework has been observed in use primary by Chinese APT groups since at least June 2014. Scanbox is\r\noften used to gather information about users visiting a compromised site. In particular, by gathering information\r\nabout a user’s browser and software installed on the system, the framework can be leveraged to launch attacks\r\nagainst interesting targets and specific vulnerable software. One of Scanbox’s additional features, capturing\r\nkeystrokes and cookie data, comes in handy when an employee is attempting to access their Web VPN. The\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 5 of 9\n\nimages below are taken from other Scanbox components loaded via accounts.nttdocomo.mailsecure.cc later in\r\nthe redirection chain.\r\nFigure 6. Scanbox Keylogger\r\nFigure 7. Keylog and Cookie Reporting URL\r\nThe code shown in Figures 6 and 7 are just a small excerpt of the Scanbox keylogger plugin. Other functions that\r\nfacilitate building the URI associated with captured keystrokes are not shown. The Scanbox code on the Japanese\r\nGovernment and High-Tech Cisco Web VPNs were being used to record data on users accessing the services. This\r\nallowed the attackers to steal credentials in real-time and maintain persistent access to the networks of the victim\r\norganizations. Volexity worked with JP-CERT in June of this year to share relevant information on this threat.\r\nAdditional Hostnames and Domains\r\nDigging into the attacker controlled domain mailsecure.cc turns up a few more interesting hosts.\r\naccount.mhi.co.jp.mailsecure.cc\r\nbooking.elinn-kyoto.com.mailsecure.cc\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 6 of 9\n\nwww.jimin.jp.mailsecure.cc\r\nFollowing the theme of accounts.nttdocomo.mailsecure.cc are hostnames of other popular Japanese companies\r\nand websites. Volexity did not observe this round of attacks associated with any of the organizations from the\r\nsubdomain. It appears the attackers are using the names of legitimate Japanese companies and websites in an\r\neffort to make the traffic blend in with legitimate traffic. Digging into the e-mail address on the WHOIS\r\nregistration for mailsecure.cc, westlife678s@hotmail.com, leads to several other domains owned by the attackers.\r\nDomain Creation Date Expiration Date E-mail\r\ngooglecontent.cc 2015-04-21 2016-04-21 westlife678s@hotmail.com\r\ngoogleupmail.com 2014-07-31 2015-07-31 westlife678s@hotmail.com\r\ngoogleusercontent.cc 2014-12-16 2015-12-16 westlife678s@hotmail.com\r\ngovmailserver.com 2014-11-26 2015-11-26 westlife678s@hotmail.com\r\nmailsecure.cc 2015-01-19 2016-01-19 westlife678s@hotmail.com\r\nnovartis-it.com 2014-12-16 2015-12-16 westlife678s@hotmail.com\r\nsymantecse.com 2014-12-11 2015-12-11 westlife678s@hotmail.com\r\nFurther research into these domains also yields interesting subdomains. A few of the themes appear to look similar\r\nto valid Google hosts and others, once again, have a Japanese oriented theme to them.\r\naccount.googlecontent.cc\r\naccounts.googlecontent.cc\r\nbak.googleupmail.com\r\ndocomo.symantecse.com\r\nimage.googleusercontent.cc\r\nja.googleupmail.com\r\njapanese.symantecse.com\r\njp.googleupmail.com\r\njp.govmailserver.com\r\njpa.googleupmail.com\r\nlh4.googleusercontent.cc\r\nmail.googlecontent.cc\r\nsecure.symantecse.com\r\nsecurity.symantecse.com\r\nserves.googlecontent.cc\r\nservice.googlecontent.cc\r\nservice.googleupmail.com\r\nwebmail.nira.or.jp.symantecse.com\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 7 of 9\n\nwww.googleupmail.com\r\nwww.govmailserver.com\r\nInterestingly, Novartis AG filed a complaint about the domain novartis-it.com with the World Intellectual Property\r\nOrganization (WIPO). In a decision made on September 7, 2015, it was determined the domain should be\r\ntransferred to Novartis. As a result, this domain may not be under attacker control for much longer.\r\nThe Malware Connection: PlugX\r\nUntil recently, Volexity did not have the above threat activity tied to specific malware or another known threat\r\ngroup. Several of the above hostnames were leveraging the IP address 255.255.0.0 when parked or not in use.\r\nVolexity tracks a threat group that also uses this IP when inactive, but this was not enough to definitively link the\r\ntwo. However, on July 31 and August 18 of this year, multiple hostnames from the aforementioned list and\r\nhostnames tied to PlugX malware overlapped on the IP addresses 108.61.222.27 and 104.207.142.124. The\r\nfollowing hostnames, not previously confirmed as connected to the list above, were now on overlapping\r\ninfrastructure:\r\nbeservices.googlemanage.com\r\ngoogleze.googlemanage.com\r\nhelp.googlemanage.com\r\nhelp.operaa.net\r\nhelpze.operaa.net\r\nmicrosoft.operaa.net\r\nmicrosofthy.operaa.net\r\nmicrosoftno.operaa.net\r\nmicrosoftoldcl.operaa.net\r\nmicrosoftze.operaa.net\r\nrenkneu.operaa.net\r\nservices.googlemanage.com\r\nservices.operaa.net\r\nsiling.operaa.net\r\nzeservices.googlemanage.com\r\nIn particular, a public report (TR-24) from the Computer Incident Response Center Luxembourg (CIRCL)\r\ndescribes a PlugX variant that communicates with microsoft.operaa.net and microsoftno.operaa.net. Also,\r\nprevious but now defunct hostnames associated with this threat actor shows an affinity for Novartis. The following\r\nhostnames can be found online and in passive DNS:\r\nalconnet.eu.novartis.googlemanage.com\r\nphusau-l00310.eu.novartis.operaa.net\r\nThe list below contains active non-parking IP resolutions and ASN information for this groups various hostnames:\r\nIP Address ASN Information\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 8 of 9\n\n103.243.25.72\r\n133731 | 103.243.24.0/22 | TOINTER-AS | CN | – | Shanghai Fanyun software\r\nCo.LTD\r\n104.207.142.124 20473 | 104.207.136.0/21 | AS-CHOOPA | US | vultr.com | Vultr Holdings LLC\r\n157.7.221.152 7506 | 157.7.128.0/17 | INTERQ | JP | gmo.jp | GMO Internet Inc.\r\nTwo-Factor Authentication (2FA)\r\nAn obvious question and concern is whether or not two-factor authentication (2FA) mitigates the risks in the\r\nabove scenarios. The short answer is no. Volexity always recommends that organizations of all sizes implement\r\n2FA for all remote network access. This can go a long way to preventing a stolen username and password from\r\ngiving an attacker keys to the kingdom. However, in this particular scenario, if an attacker is able to load\r\nmalicious JavaScript through the Cisco Web VPN portal, it would be trivial for them to modify the code to do one\r\nof two things:\r\n1. Session Cookie Theft: The malicious code could be modified to specifically steal session cookies after a\r\nuser has established an authenticated session. In Volexity’s testing, it was possible to have two\r\nsimultaneous Cisco Web VPN sessions using the same session cookies. This means an attacker could\r\nleverage the same session as an active legitimate user without either of them being disconnected.\r\n2. Token Theft and Reuse: Assuming a user’s 2FA leverages a numeric token (or similar), an attacker could\r\npotentially hijack the user’s initial authentication attempt and quickly reuse that token to access the victim\r\ninfrastructure. This would prevent the user from initially logging into their own infrastructure. However,\r\nthe attacker could then set a cookie to prevent subsequent authentication attempts from being hijacked.\r\nPreventing the user from ever authenticating would raise many flags, whereas only interfering with a single\r\nlogin attempt is less likely to result in discovery.\r\nLeveraging 2FA on VPNs is a must for organizations. However, it should not be seen as bullet proof. Users are\r\nstill susceptible to being phished or otherwise having their authentication attempts hijacked. The attackers are\r\nfairly ingenious and will likely find a way to gain access, if they are motivated enough.\r\nConclusion\r\nAttackers are continuing to find new ways to use and abuse systems for long term persistent access to networks\r\nand systems of interest. This problem is not remotely unique to Cisco Web VPNs. Any other VPN, web server, or\r\nappliance that an attacker can gain administrative access to or otherwise customize/modify will potentially present\r\nsimilar risks. As recently made apparent through public disclosures of various backdooring methods, such as\r\nSYNful Knock, no device within a network is off-limits to motivated attackers. When proactively hunting for\r\nthreat activity on your network and, in particular, when conducting an incident response to an active intrusion, be\r\nsure to leave no stone left unturned.\r\nSource: https://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nhttps://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.volexity.com/blog/2015/10/07/virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence/"
	],
	"report_names": [
		"virtual-private-keylogging-cisco-web-vpns-leveraged-for-access-and-persistence"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434060,
	"ts_updated_at": 1775791432,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2c75509aeb18a5149c07ff6ac15d02e00d7d154a.pdf",
		"text": "https://archive.orkl.eu/2c75509aeb18a5149c07ff6ac15d02e00d7d154a.txt",
		"img": "https://archive.orkl.eu/2c75509aeb18a5149c07ff6ac15d02e00d7d154a.jpg"
	}
}