![\"CryptoWall1\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/08\/CryptoWall1.png\")
<\/a><\/p>\nThe querymem function it refers to is just a wrapper for ZwQueryVirtualMemory, and the rest is I hope self-explanatory (btw. the code is position independent so you see reference to getAPITableOffset which is basically a\u00a0 function returning a pointer to the sample’s import table allocated somewhere in memory).<\/p>\n
There are a few interesting things here:<\/p>\n This highlights not only the fact that some malware authors are seasoned developers, but also the fact they pay more and more attention to memory artifacts – buffers allocated by malware during run-time are full of juicy information and often contribute to finding a smoking gun or help in accessing unprotected\/unencrypted code and data (e.g. configs) directly from memory. Limiting exposure of such artifacts is a direct challenge to the Locard’s Exchange Principle. It also makes life hard for forensic analysts – relying on dynamic analysis is obviously a daily bread for all of us, but it is simply not enough.<\/p>\n","protected":false},"excerpt":{"rendered":" I recently spent some time analysing one of the ransomware samples (CryptoWall, md5=73a9ab2ea9ec4eaf45bce88afc7ee87e; thx to Kernelmode.info guys). Looking at the code I came across an interesting routine that the malware author crafted to release memory allocated by malware during run-time. … Continue reading <\/a><\/p>\n\n
\n