{ "id": "4e8fb066-c6ad-44cf-b91f-29e8e5a8c1db", "created_at": "2026-04-06T00:14:06.151049Z", "updated_at": "2026-04-10T13:11:43.08575Z", "deleted_at": null, "sha1_hash": "006924f76175f56ed914322bc87855912b98b7ef", "title": "Cridex Analysis using Volatility", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1075479, "plain_text": "Cridex Analysis using Volatility\r\nArchived: 2026-04-05 14:38:34 UTC\r\nUpdate 1 -  August 5, 2012 - located at end of post\r\nUpdate 2 -  August 7, 2012 - located at end of post\r\nI had read previous analysis reports about Cridex from various sites as M86 Security and Kahu Security. At the\r\ntime, I filed this under \"another banking trojan\" to track, and moved on to to other things.  However Cridex once\r\nagain piqued my interest when I saw an excellent analysis by Kimberly at StopMalvertising.  I took particular\r\nattention to her listing of the Cridex C\u0026C servers she observed, as several of these IP blocks were familiar to me.\r\nMore on this later.   Having obtained the same Cridex sample analyzed by Kimberly,  I was interested to see how\r\nVolatility could be used to analyze it.  This Cridex sample had MD5 hash, 734aadd62d0662256a65510271d40048.\r\nI executed the sample and dumped the memory for analysis.  A copy of this memory dump is linked at the bottom\r\nof this post.\r\nUsing the Volatility 'plist' command, we can see a list of the running processes. However it's instructive to use this\r\nin conjunction with the 'psscan' command in order to see those processes that have terminated, are unlinked, or\r\nhidden.  In this case, no discrepancies between the two commands jump out at me, but I do notice a couple of\r\nthings.   First, I see a process, reader_sl.exe, PID1640 start exactly at the same time as its parent process,\r\nexplorer.exe, PID1484.  I see that the parent process ID for explorer.exe is 1464, which is not listed in either\r\n'pslist' or 'psscan'.  reader_sl.exe is a supposedly a safe process, associated with Adobe Speed Launcher, but the\r\nlaunch chain for this seems odd, so I'll keep note of this for now. Next, I see a second wuauclt.exe process start\r\nabout 15 seconds after the first.  This isn't a major flag, but just something to note.\r\npslist command\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 1 of 10\n\npsscan command\r\nThe next useful Volatility command that I use for malware analysis is the 'connections' and the 'connscan'\r\ncommands. Again, running both of these will allow you to see variances, as 'connscan' will show artifacts from\r\nprevious connections.\r\nconnections \u0026 connscan commands\r\nNote that 'connections' shows that PID 1484, explorer.exe had an active connection to remote IP\r\naddress 41.168.5.140 on port 8080.  'connscan' shows an artifact of a previous connection by PID 1484 to remote\r\nIP address 125.19.103.198, also on port 8080.  A quick 'whois' shows:\r\n41.168.5.140\r\nnetname: NEOTEL\r\ndescr: NEOTEL PTY LTD\r\ncountry: ZA\r\n125.19.103.198\r\ndescr: Bharti Tele-Ventures Limited\r\ndescr: NEW DELHI\r\ncountry: IN\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 2 of 10\n\nNext, running 'sockets' and 'sockscan' will show any listening sockets that may have been initiated by a running\r\nprocess. As in 'conscan', 'sockscan' will show any detected artifacts from previous sockets.  In this case, we see\r\nthat PID 1484, explorer.exe, opened a listening socket on port 1038 approx. 2 minutes after PID 1484 was\r\ncreated. \r\nsockets and sockscan commands\r\nRunning the 'malfind' command against our two suspect processes yields the following:\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 3 of 10\n\nmalfind command on PID 1484 \u0026 1640\r\nIn this output, we see that the explorer.exe, PID1484 and reader_sl.exe, PID1640 processes have a PE section\r\nlocated at 0x1460000 and 0x3d0000 respectively.  By using the \"-D\" switch, 'malfind' can dump those identified\r\nsegments to a dump directory for further analysis. \r\nWe now enumerate the mutant/mutex objects for the two processes under review.  Note that I used the Volatility\r\n'handles' command, with a subtype selection of \"Mutant\" in order to specifically select the mutant/mutexes\r\nassociated with PID 1484 and 1640.  The 'mutantscan' command will give additional information such as its\r\nsignaled state, its client ID, and which thread acquired the mutant.\r\nprocess mutexes for PID 1484 \u0026 1640\r\nVia some Google queries, we learn that several of these mutex objects have been seen in other malware, notably:\r\n746bbf3569adEncrypt\r\n_SHuassist.mtx\r\nSHIMLIB_LOG_MUTEX\r\nXMR8149A9A8\r\nNext, we'll dump the VAD segments of each of these processes, run 'strings',  and look for anything interesting. \r\nvaddump command\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 4 of 10\n\n'strings' output section from PID 1484, explorer.exe\r\n'strings' output section from PID 1640, reader_sl.exe\r\nNote the advantage of dumping the VAD segments as opposed to the entire process memory is that you can see\r\nwhich VAD node section the 'strings' hit was located.  In this section, we find a list of banks and financial\r\ninstitutions.   Here is the contents of the Cridex configuration specifically containing references to\r\nfinancial institutions. \r\nIn addition to the list above, examining these VAD dumps also shows HTML code referencing or representing\r\nweb pages of various financial organizations.  The code seems to indicate that these sections are part of the web\r\ninjection code that is used to obtain personal information from the banking customer.  In my test of Cridex, I did\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 5 of 10\n\nnot launch a web browser or continue additional interaction with my infected host.  If I had visited a URL\r\ncontaining these strings, it is believed that Cridex would attempt to log or capture my input, and redirect that\r\npersonal information back to the controller.\r\nWhile we're looking for strings, let's see what shows up for the IP addresses 41.168.5.140 \u0026 125.19.103.198 that\r\nwere seen in the Volatility \"connscan\" command.\r\nSearching for the directory path after the IP addresses gives us another related IP address, 188.40.0.138:\r\nSo via various string searches and some grepping in the VAD dump directory for PID1484 \u0026 PID1640 we find\r\nthese IP addresses of interest:\r\n190.81.107.70\r\n41.168.5.140\r\n85.214.204.32\r\n210.56.23.100\r\n211.44.250.173\r\n125.19.103.198\r\n188.40.0.138\r\nMaltego lets me draw a pretty picture of the IPs, country of registration, and ASN.\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 6 of 10\n\nCridex IP addresses, ASN, and country of registration.\r\nDoing some additional research, I noted that at one time or another, several domain names (now suspended)\r\nutilized all of the above listed Cridex IPs (except for 188.40.0.138). In fact, these domains each utilized the same\r\n11 to 14 IP addresses, including the Cridex IPs for their DNS \"A\" records during their brief activity.  Looking at\r\nthe 'whois' for a sample of these domains shows an entirely different set of IPs used for their NS records... but I\r\ndigress.\r\ndomain:        VALIDATORONMEE.RU\r\nnserver:       ns1.validatoronmee.ru. 62.213.64.161\r\nnserver:       ns2.validatoronmee.ru. 195.62.52.69\r\nnserver:       ns3.validatoronmee.ru. 62.76.191.172\r\nnserver:       ns4.validatoronmee.ru. 41.66.137.155\r\nnserver:       ns5.validatoronmee.ru. 83.170.91.152\r\nnserver:       ns6.validatoronmee.ru. 85.214.204.32\r\nstate:         REGISTERED, NOT DELEGATED, UNVERIFIED\r\nperson:        Private Person\r\nregistrar:     NAUNET-REG-RIPN\r\nadmin-contact: https://client.naunet.ru/c/whoiscontact\r\ncreated:       2012.04.10\r\npaid-till:     2013.04.10\r\ndomain:        POLUICENOTGO.RU\r\nnserver:       ns1.poluicenotgo.ru. 62.76.41.3\r\nnserver:       ns2.poluicenotgo.ru. 62.213.64.161\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 7 of 10\n\nnserver:       ns3.poluicenotgo.ru. 195.88.242.10\r\nnserver:       ns4.poluicenotgo.ru. 41.66.137.155\r\nnserver:       ns5.poluicenotgo.ru. 83.170.91.152\r\nnserver:       ns6.poluicenotgo.ru. 85.214.204.32\r\nstate:         REGISTERED, NOT DELEGATED, UNVERIFIED\r\nperson:        Private Person\r\nregistrar:     NAUNET-REG-RIPN\r\nadmin-contact: https://client.naunet.ru/c/whoiscontact\r\ncreated:       2012.04.15\r\npaid-till:     2013.04.15\r\ndomain:        VITALITYSOMER.RU\r\nnserver:       ns1.vitalitysomer.ru. 62.213.64.161\r\nnserver:       ns2.vitalitysomer.ru. 195.62.52.69\r\nnserver:       ns3.vitalitysomer.ru. 62.76.191.172\r\nnserver:       ns4.vitalitysomer.ru. 41.66.137.155\r\nnserver:       ns5.vitalitysomer.ru. 83.170.91.152\r\nnserver:       ns6.vitalitysomer.ru. 85.214.204.32\r\nstate:         REGISTERED, NOT DELEGATED, UNVERIFIED\r\nperson:        Private Person\r\nregistrar:     NAUNET-REG-RIPN\r\nadmin-contact: https://client.naunet.ru/c/whoiscontact\r\ncreated:       2012.04.10\r\npaid-till:     2013.04.10\r\nThere is much more that you can do with this Cridex memory dump. For example, you can use 'apihooks' on the\r\ntwo processes, then drop into 'volshell' and browse through the pages. You could find the loaded DLLs, or extract\r\na process of interest.  \r\nFor your added research, I've posted a link to the Cridex memory image below.  I didn't extract other forensic\r\nobjects for this sample, but as I mentioned in my last post, I plan to do that for other samples going forward.\r\n-------------------------------------------------------------------------------------------------------------------------------\r\nUpdate 1 - August 5, 2012\r\nIn the comments section, Tamer Hassan posted a question referencing PID 1464. That PID is most likely a\r\nterminated process where 'psscan' didn't find any associated remnants. However it might be interesting to search\r\nfor references to executable files.  Since we know that PID 1464 was the parent to PID 1484, it's worth looking for\r\nregistry artifacts typically used by malware.  Volatility allows you to carve through the the registry that is resident\r\nin memory and display subkeys, values, and data. In this example, I looked for keys and values associated with\r\n\"Software\\Microsoft\\Windows\\CurrentVersion\\Run\" This is accomplished via the 'printkey' command:\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 8 of 10\n\npython vol.py -f /home/ezio77/cridex.vmem --profile=WinXPSP2x86 printkey -K\r\n\"Software\\Microsoft\\Windows\\CurrentVersion\\Run\"\r\nSince 'printkey' will go through all hives, you will get multiple hits related to the key in your search.  After\r\ndisplaying multiple hives each with a Last Update date of either 2012-04-12 or 2012-04-13,  you'll see the\r\nfollowing:\r\nRegistry: \\Device\\HarddiskVolume1\\Documents and Settings\\Robert\\NTUSER.DAT\r\nKey name: Run (S)\r\nLast updated: 2012-07-22 02:31:51 \r\nSubkeys:\r\nValues:\r\nREG_SZ        KB00207877.exe  : (S) \"C:\\Documents and Settings\\Robert\\Application Data\\KB00207877.exe\"\r\nPerhaps KB00207877.exe was PID 1464?  It's not clear via Volatility at this point, but it's most likely just a copy\r\nof the original with an updated registry key. Referring to Microsoft's encyclopedia entry for\r\n\"Worm:Win32/Cridex.G\", they reference:\r\nsubkey: HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\r\nSets value: \"KB\u003ceight-digit number\u003e.exe\"\r\nWith data: \"%AppData%\\KB\u003ceight-digit number\u003e.exe\"\r\nAdditionally, the VirusTotal analysis for this sample shows references to this naming convention as well. (Scroll to\r\nbottom and select \"Additional Information\")\r\nIn any case, it's good info for further analysis, including examining other registry hives.\r\n-------------------------------------------------------------------------------------------------------------------------------\r\nUpdate 2 - August 7, 2012\r\nMichael Ligh, was kind enough to drop me a note about the parent of 'explorer.exe'. Michael is one of the key\r\ncontributors to the Volatility project, as well as one of the authors of the \"Malware Analyst's Cookbook and\r\nDVD\" . He referenced an excerpt from his book where it explains that the parent of 'explorer.exe' is 'userinit.exe',\r\nwhich upon completion, will terminate, leaving 'explorer.exe' without a parent.  From the \"Malware Analyst's\r\nCookbook\", pg 585:\r\nDetails aren’t available for the process with Pid 1536 (which appears to have created\r\nexplorer.exe). However, based on what you know about the boot sequence,\r\nPid 1536 probably belonged to userinit.exe—but it has since exited. Winlogon.exe\r\nlaunches userinit.exe, which in turn launches explorer.exe. Once userinit.exe is\r\nfinished, it terminates, leaving explorer.exe without a parent process. It is still possible\r\nto determine a process’s parent, even after the parent exits, by looking at the\r\n_EPROCESS.InheritedFromUniqueProcessId field.\r\nMany thanks Michael! \r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 9 of 10\n\n-------------------------------------------------------------------------------------------------------------------------------\r\ncridex_memdump.zip (40MB)\r\n-------------------------------------------------------------------------------------------------------------------------------\r\nSource: http://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nhttp://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "origins": [ "web" ], "references": [ "http://www.sempersecurus.org/2012/08/cridex-analysis-using-volatility.html" ], "report_names": [ "cridex-analysis-using-volatility.html" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434446, "ts_updated_at": 1775826703, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/006924f76175f56ed914322bc87855912b98b7ef.pdf", "text": "https://archive.orkl.eu/006924f76175f56ed914322bc87855912b98b7ef.txt", "img": "https://archive.orkl.eu/006924f76175f56ed914322bc87855912b98b7ef.jpg" } }