Forensic Blogs

An aggregator for digital forensics blogs

January 31, 2017 by Harlan Carvey

Tools

Tools
Memory Analysis
When I've had the opportunity to conduct memory analysis, Volatility and bulk_extractor have been invaluable.

Back when I started in the industry, oh, lo so many years ago, 'strings' was pretty much the tool for memory "analysis".  Thanks to Volatility's strings plugin, there's so much more you can do; run 'strings' (I use the one from SysInternals) with the "-o" switch, and parse out any strings of interest.  From there, using the Volatility strings plugin lets you see where those strings of interest are located within the memory sample, providing significant context.

I've run bulk_extractor across memory samples, and been able to get pcap files that contained connections not present in Volatility's netscan plugin output.  That is not to say that one tool is "better" than the other...not at all.  Both tools do something different, and look for data in different ways, so using them in conjunction provides a more comprehensive view of the data.

If you do get a pcap file (from memory or any other data source), be sure to take a look at Lorna's ISC handler diary entry regarding packet analysis; there are some great tips available.  When conducting packet analysis, remember that besides WireShark, you might also want to take a look at the free version of NetWitness Investigator.

Carving
Like most analysts, I've needed to carve unallocated space (or other data blobs) for various items, including (but not limited to) executable images.  Carving unallocated space, or any data blob (memory dump, pagefile, etc.) for individual records (web history, EVT records, etc.) is pretty straight forward, as in many cases, these items fit within a sector.

Most analysts who've been around for a while are familiar with foremost (possible Windows .exe here) and scalpel as carving solutions.  I did some looking around recently to see if there were any updates on the topic of carving executables, and found Brian Baskin's pe_carve.py tool.  I updated my Python 2.7 installation to version 2.7.13, because the pip package manager became part of the installation package as of version 2.7.9.  Updating the installation so that I could run pe_carve.py was as simple as "pip install bitstring" and "pip install pefile".  That was it.  From there, all I had to do was run Brian's script.  The result was a folder with files that had valid PE headers, files that tools such as PEView parsed, but there were sections of the files that were clearly not part of the file.  But then, such is the nature of carving files from unallocated space.

Addendum, 1 Feb: One of the techniques I used to try to optimize analysis was to run 'strings' across the carved PE files, in hopes of locating .pdb strings or other indicators.  Unfortunately, in this case, I had nothing to go on other than file names.  I did find several references to the file names, but those strings were found in the files that were clearly part of the sectors included in the file that likely had little to do with the original file.

Also, someone on Twitter recommended FireEye's FLOSS tool, something you'd want to use in addition to 'strings'.

Hindsight
Hindsight, from Obsidian Forensics, is an awesome tool for parsing Chrome browser history.  If you haven't tried it, take a look.  I've used it quite successfully during engagements, most times to get a deeper understanding of a user's browsing activity during a particular time frame.  However, in one instance, I found the "smoking gun" in a ransomware case, where the user specifically used Chrome (was also using IE on a regular basis) to browse to a third-party email portal, download and activate a malicious document, and then infect their system with ransomware.  Doing so by-passed the corporate email portal protections intended specifically to prevent systems from being infected with...well...ransomware.  ;-)

Hindsight has been particularly helpful, in that I've used it to get a small number of items to add to a timeline (via tln.pl/.exe) that provide a great deal of context.

Shadow Copies
Volume shadow copies (VSCs) and how DFIR analysts take advantage of them is something I've always found fascinating.  Something I saw recently on Twitter was a command line that can be used to access files within Volume Shadow Copies on live systems; the included comment was, "Random observation - if you browse c$ on a PC remotely and add @TIMEZONE-Snapshot-Time, you can browse VSS snapshots of a PC."

An image included within the tweet chain/thread appeared as follows:

Source: Twitter









I can't be the only one that finds this fascinating...not so much that it can be done, but more along the lines of, "...is anyone doing this on systems within my infrastructure?"

Now, I haven't gotten this to work on my own system.  I am on a Windows 10 laptop, and can list the available shadow copies, but can't copy files using the above approach.  If anyone has had this work, could you share what you did?  I'd like to test this in a Win7 VM with Sysmon running, but I haven't been able to get it working there, either.

Addendum, 1 Feb: Tun provided a tweet to Dan's blog post that might be helpful with this technique.  Another "Dan" said on Twitter that he wasn't able to get the above technique to work.

As a side note to this topic, remember this blog post?  Pretty sneaky technique for launching malware.  What does that look like, and how do you hunt for it on your network?

Windows Event Logs
I recently ran across a fascinating MSDN article entitled, "Recreating Windows Event Log Files"; kind of makes you wonder, how can this be used by a bad guy, and more importantly, has it?

Maybe the real question is, are you instrumented to catch this happening on endpoints in your environment?  I did some testing recently, and was simply fascinated with what I saw in the data.

Read the original at: Windows Incident ResponseFiled Under: Digital Forensics Tagged With: bulk_extractor, hindsight, pe_carve, Volatility, VSC, Windows Event Logs

May 17, 2014 by Little Mac

Sweet Child o’ LSASS

Recently, I was channeling my inner rock star, and thought I'd share a finding regarding "normal" occurrences.  You're probably all familiar with LSASS.exe, the "Local Security Authentication Subsystem Server" process, and you might also know that it doesn't have any children.  Poor thing; children are truly a gift (and a challenge, but that's a different topic).  Anyhow, as noted in the SANS DFIR "Find Evil" poster, if LSASS spawns a child process, it bears looking into - and that's exactly what I was doing.  

Given that I think it's important to be as proactive as possible with regard to incident response, I am always looking for ways to spot potential problems.  Now, the SANS poster showcases things to watch for when doing memory analysis, but if you're parsing all executable activity in real time and storing that data in a way it can be queried at will (kind of like Sysinternals procmon on steroids), then why not apply the same principle and see what can be found?  Yes, yes, I'm talking about CarbonBlack (now part of Bit9), which is (in my opinion) an awesome endpoint monitoring platform.  However, while this post will make use of that technology, don't think of it as being about Cb, but rather about the hunt, what's found, and how that informs the bigger picture (and may change some of what's considered "normal").  Keep in mind there are other tools that can help accomplish the same goal, and as noted, memory analysis (with tools like Volatility, Rekall, and Mandiant Redline) is at the forefront - so don't get hung up on the tool; it's the investigator that makes the difference in the long run. 
With that, I'd like to tell you a story about the hunt for spawn of LSASS, and how it started with a simple little query, as shown below; basically, any process for which LSASS.exe showed up as the parent...





Right away we see that there's one sweet child o' lsass, on 37 endpoints, with two different hashes showing up.  Okay, so two different binaries or versions, then.  Let's keep digging, starting with a listing of the search results.


A couple things stand out; namely that each process is associated with six (6) filemods (such as create/modify/delete a file) and two (2) netconns (could be browsing to a website, IP address, hostname), while related activities for registry (regmods) and other processes/binaries (modloads) are similar in count but different.  If you're the type (and I am) that likes to review data offline to filter, sort, search, and so on, you can download a CSV that looks a little something like what's below.  If you have oddball md5 values, abnormal paths, or process names that stand out, it's sometimes easier to focus in on (at least for me).  With this, the "start" value is the time the current instance of the process ran, and "last_update" is the most recent time it actually did something as it applies to the query at hand.


I mentioned oddball md5 values, right?  And we know we have two different ones at play here, and 37 total processes, so what's the breakdown?  Funny you should ask (well, I asked, but it was kind of rhetorical anyway - just work with me...)

So apparently two out of the 37 are the "f17e" hashes, with the remainder being "bcb8."  And yes, that can be identified using the GUI, but I like to see things with my own two eyes and plus this is an offline record in case I ever need it.  No abnormal paths were noted.
Anyway, since there's consistency with filemods and netconns, that's a good place to start looking, but first, I'd like to know a little more - high level - about these processes.  From a tool standpoint, Cb has a "preview" feature, and so to take a peek at the different binaries involved here (remember, two different hash values)...



First we had "Mr. Popularity," the "bcb8" version, followed up by the indomitable "f17e."  In either case, the command line parameters are the same:  "/efs /enroll /setkey."  If you had not already, you're probably running out and searching teh intarwebs for this executable, EFS, and whatever else might give some insight, since it appears to be from Microsoft (R) and might be legit (but you never know, right?).  If that's what you're doing, no worries, I was in the same boat.  I even reached out to the SANS DFIR email list to see if anyone else had encountered this, since all know that "normal" means LSASS doesn't have kids.  No children.  Nada.  Zip.  Zilch.  Carlos Marins pointed me to the following MS document (link is direct download) http://download.microsoft.com/download/9/8/2/98207DD4-7D2C-4EF6-9A9F-149C179D053E/CommercialOSSecFunReqsPublicV2Mar09.docx, which was very helpful in understanding some of the things I would subsequently find.  Chris Pogue asked a few questions and reminded me about checking the hash with Bit9 File Advisor.  
Speaking (er, well, writing) of hash, we'll go ahead and knock that out.  VirusTotal and File Advisor both came up clean:





Alright, now back to the fun stuff - filemods and netconns for this sweet child o' lsass.  Oh, first - this'll be quick, I promise - we can take a look at more details about the two binaries in question (as binaries, not as the named processes).



In addition to a few more details, this will show how many times that particular binary has been seen in action, without any time or other filtration (such as by parent process).  In addition, using the aptly-labeled "Download" button, I can extract a copy of the raw binary for additional analysis, reverse-engineering, and so forth, offline.  More on that later, as I said this would be quick.  Now, back to the rest!
Here's a quick look at each of the processes for analysis:

You can see that the relationship between wininit.exe and lsass.exe is as expected.  It's just that the latter spawns efsui.exe as a process (which of course we already knew by this time).  We see the commandline parameters again, and the fact that it's signed by MS.  What's new here is that the username (obfuscated) is the domain account of the actual end-user; it's not System or other non-human (actually, it's in the binary preview window as well, but I really just wanted to call it out here, rather than there).  Also, pay attention to the "Export events to CSV" button in the top right (more on that later as well).  And, more of the same from the other version of the process...

We were going to look into filemods and netconns if I recall correctly (and of course I do), so don't stop now...
You can't see the whole screen above, but just underneath the process map, there are some "facets" to speed up queries/drills/searches based on different criteria (of course, we're going to look at filemods and netconns - aren't you just tired of hearing about how we're "going" to do that?).  


Clicking on filemods highlights some other areas within that category of activity, and also focuses our results on just those.  Thus, we can see that the actions are broken down equally between creation and first write, and that only three directories were utilized, all within the user profile under AppDataRoaming (clicking on any of those would highlight only those pieces of information, thus narrowing the search further).  Next up are the event details.


Here, in timeline fashion, we get to see file creation, first write (if there were any file deletes, we would see those too), and some details associated with each.  The expanding arrow (as shown on the top entry) shows frequency information (singular in this instance because of the nature of the path), and the "Search" (in blue) will take us to those results (for instance if there were multiple systems instead of just one, we'd get to see what those all were).  The "Search" box at the top right of the event list allows us to find any search string in the results (such as username, filename, part of the path, etc), if we had something we wanted to jump to quickly (or even just see if it was present).  What's of interest here are the paths involved, which start to make sense in light of the MS document I mentioned earlier (same for regmods, but I'm not going to go into those for the sake of brevity).
Clicking on filemod in the facets again clears that drill, and we can switch over to netconns.

Basically, the two netconns were pointing to domain controllers, and as can be seen from the frequency information, those DCs are quite common from a connectivity perspective (as one would expect, being DCs).  The interesting thing here are the ports involved, which makes it look like LDAP is involved.  
Okay, we're getting down to the wrap-up stage (thanks for sticking with me this far, I know it's been a lengthy post/novella at this point).  What it appears we have are known, signed, MS executables associated with the Encrypting File System (EFS) for transparent file encryption, reaching out as the logged-in user to domain controllers for authentication, using LDAP.  But is that really truly what's going on?  Do we know enough to say that at this point?  Are there any additional checks we could do, ways to validate/verify this theory?  What about looking at other activity on the system for suspicious processes, network communications, or known malware?  Any evidence to suggest that EFSUI.exe had been injected with other code after it started running?  What about packet captures for these LDAP connections - are they really normal authentication for the process?  Any corroborating logs from firewalls, the DCs, etc?  Is EFS used in the environment, or is the user known to do so specifically?  What about the binaries involved - does reverse engineering (RE) indicate any oddities or abnormalities?  
Do you remember that there is the ability to extract a binary for offline analysis?  So RE is definitely a possibility.  Firewall and DC event logs should be reasonable to expect (although not necessarily a given).  Packet captures from the time of the event (in the past) would require some dedicated NSM for streaming pcaps, but would be a really good way to help determine what's going on inside those netconns.  And we can certainly dig into the more detailed process and binary analysis on the hosts in question.  That "Export events to CSV" button I mentioned earlier?  Gives output like this, with a CSV for each "type" of activity, and will also include child processes if available (there weren't any for efsui):
Note:  The "Summary" text file gives some info about the process or binary being analyzed (name, hash, path, etc).
These spreadsheets provide a veritable plethora of information about the process or binary being analyzed.  Don't know if you noticed, but there was a section on the analysis page, referencing "Alliance Feeds" - this provides info about matches to Virus Total, known bad domains, and other "intel" related to activity that might be full of evil.  Rather than a specific process to search for, you could also start with a given endpoint/host, any of these threat feeds, or some custom query for known indicators (based on firewall, IPS, or other threat "intel" you have).  Anyway, all that to say that if you wanted to correlate the activity from EFSUI.exe as a child process of LSASS.exe, to any other activity to help determine whether this benign or the most evil thing on the planet, there's a lot you can do.  And again, not just with CarbonBlack - you can set up a packet capture for a period of time (host, router, switch, firewall, etc), perform memory analysis, targeted triage (such as popularized by Harlan Carvey, Corey Harrell, and Chris Pogue to name a few key folks), or even (gasp!) a full disk image with timeline and analysis galore! 
Maybe the information here is enough to make a determination and speak authoritatively about what happened, and whether there are any unremediated or ongoing risks.  However, it's really ultimately about those risks, and as investigators we may not be the decision-makers (in fact, most likely are not).  We can inform the decision-makers of our findings and recommendations, but we also have to be honest and explain what options are available, what those options would provide (and at what cost), and what potential risks could be incurred (and the probability thereof) by not pursuing the aforementioned options.  Want to know more on this subject?  Come to my talk at the SANS DFIR Summit in June - To Silo, or Not to Silo: That is the Question.  More info is available about the Summit here.
Thanks again for "listening" to my tale about the sweet child o' lsass, and remember ... you may know that lsass doesn't have any child processes, but if you don't verify or validate that, you might just reach the wrong conclusions, and that probably wouldn't be good in a "real life" scenario. 
Happy Hunting!

Read the original at: Forensicaliente - because digital forensics is 'hot'Filed Under: Uncategorized Tagged With: Bit9, CarbonBlack, DFIRSummit, EFS, EFSUI, Finding Evil, Incident Response, LSASS, Redline, Rekall, sniper forensics, triage, Virus Total, Volatility

February 15, 2013 by Mila

Manipulating Memory for Fun and Profit by Frédéric Bourla – High-Tech Bridge

Manipulating Memory for Fun and Profit by Frédéric Bourla  – High-Tech Bridge
I am sure you remember excellent reverse engineering presentations by High-Tech Bridge experts I posted earlier.  High-Tech Bridge presented  at the ISACA event in Luxembourg and you can download their detailed and very interesting presentation:  “Manipulating Memory for Fun and Profit".
The presentation includes detailed memory forensics process using Volatility

by Frédéric BOURLA
Chief Security Specialist
Head of Ethical Hacking & Computer Forensics Departments
High-Tech Bridge SA


Table of Contents
0x00 - About me
0x01 - About this conference
0x02 - Memory introduction
0x03 - Memory manipulation from an offensive angle
0x04 - Memory manipulation from a defensive angle
0x05 - Conclusion


Download the full presentation in PDF 

The text of the presentation (for Google search and to get an idea about the contents:)




========================
Manipulating Memory for Fun & Profit
6 February 2013
Frédéric BOURLA
Chief Security Specialist
========================
# readelf prez
*   Slides & talk in English.
*   Native French speaker, so feel free to send me an email in French if case of question.
*   Talk focused on Memory Manipulation, from both offensive and defensives angles.
*   1 round of 45’.
*   Vast topic, lots of issues to address, and lots of slides so that the most technical of you can come back later to remember commands.
*   Therefore some slides [specially the beginning] will be fast, but everything is summarized in demos.
*   No need to take notes, the whole slides and demos will be published on High-Tech Bridge website.
========================
# readelf prez
*   Despite its name, this talk will not deal with Total Recall or any other human memory manipulation based movie.
*   Nor will it deal with classical binary exploitation, such as Stack based Buffer Overflows or Heap Spraying. I strongly advice to read corelanc0d3rs’ papers on corelan.be to learn more regarding Exploit Writing.
========================
Table of contents
0x00 - About me
0x01 - About this conference
0x02 - Memory introduction
0x03 - Memory manipulation from an offensive angle
0x04 - Memory manipulation from a defensive angle
0x05 - Conclusion
========================
# man mem
*   RAM (Random Access Memory) is a temporary memory accessible by the CPU in order to hold all of the program code and data that is processed by the computer.
*   It is called “random” because the system can directly access any of the memory cells anywhere on the RAM chip if it knows its row (i.e. “address”) and its column (i.e. “data bit”).
*   It is much faster to access data in RAM than on the hard drive.
*   CPU and OS determine how much and how the available memory will be used.
========================
# man mem
*   In other words, most users do not have any control on memory, which makes RAM a target of choice.
*   First systems were arbitrary limited to 640Kb RAM. Bill Gates once declared that “640K ought to be enough for anybody”.
*   At this time it was far enough… But today the OS itself can consume 1 Gb. We therefore use much more memory.
*   On a 32 bits Windows system, OS can directly address 2^32 cells, and is therefore mathematically limited to 4 Gb memory.
========================
# man mem
*   Contrary to popular assumption, RAM can retain its content up to several minutes after a shutdown.
*   Basically RAM is everywhere nowadays. Printers, fax, VoIP phones, GPS and smartphones are good examples.
*   This provide some opportunities to security professionals [and also to bad guys]. Some points of this talk can be applied to various targets and may not be limited to Windows systems, even if since now we will deal with a classical Microsoft host.
========================
# man mem
*   Upon process instantiation, the code is mapped in memory so that the CPU can read its instructions, and each process has his own virtual memory.
*   OS relies on page table structures to map transparently each virtual memory address to physical memory.
*   But most importantly, any program [including both its data and its instructions] must first be loaded into memory before being run by the processor.
========================
# man mem
*   For example, FUD Trojans which highly rely on Packers & Crypters can be quickly uncovered through memory analysis.
*   The same principle applies to OFTE. Memory Analysis can save your investigator's life, should you be facing a drive with On The Fly Encryption capabilities. To be efficient, transparent and usable, the [encrypted] key should be somewhere in memory.
========================
Table of contents
0x00 - About me
0x01 - About this conference
0x02 - Memory introduction
0x03 - Memory manipulation from an offensive angle
0x04 - Memory manipulation from a defensive angle
0x05 - Conclusion
========================
Post keylogging capacities
*   A colleague just used your laptop to access a restricted page, and you regret you didn’t have time to run your favourite keylogger? :-]
========================
Post keylogging capacities
*   No a problem, you may be able to browse the Internet browser’s memory to grab his credentials.
========================
Post keylogging capacities
*   Besides this joke, have you ever wished you had saved your new email before a touchpad problem occurs and make you loose 30 minutes?
========================
Post keylogging capacities
*   But you may not be obliged to restart writing everything from scratch if you browse the process memory shortly.
========================
Stars revelation
*   In a pivoting attack, it can be very useful to reveal what’s behind the stars... Don’t forget, Windows remembers lots of passwords in behalf of users.
*   Lots of tools do exist, such as Snadboy's Revelation. Unfortunately, most of them do not work against recent OS.
*   BulletsPassView is one of the remaining tools which still works under Windows 7. There is even a 64 bits version.
*   Anyway, it also does not work under Windows 8.
========================
Stars revelation
========================
Stars revelation
*   Pillaging passwords often provide the keys of the kingdom.
========================
Memory Patching
*   Memory Patching is the first stone to build a Crack or create a Keygen in the Warez world.
*   It basically consists of locating and bypassing binary protections in memory in order to finally implement the trick in the targeted file.
========================
Memory Fuzzing
*   Fuzz Testing, aka Fuzzing, consists in providing invalid, unexpected, or random data to the inputs of a monitored program to detect security issues [among others].
*   General approach to Fuzzers:
========================
Memory Fuzzing
*   Memory-oriented Fuzzing:
========================
Memory Fuzzing
*   Here is an example from dbgHelp4j, a memory fuzzing project under development at High-Tech Bridge:
*   To learn more, read Xavier ROUSSEL’s paper.
*   This short demonstration shows how dbgHelp4j permits to identify rapidly an old buffer overflow in the CWD Command of Easy FTP Server v1.7.0.11.
========================
DLL Injection
*   Another well-known memory abuse consists in injecting arbitrary code into the memory space of another process, for example through a CreateRemoteThread like function.
*   Such an injection permits the attacker to benefit from the rights of the target process, and often to bypass firewalls.
*   This also enable its author to hide himself from most users, as threads are not displayed in Windows Task Manager.
========================
DLL Injection
*   Native task manager does not display current threads within a process.
========================
DLL Injection
*   Here a DLL based Reverse Trojan is injected into IE memory space.
========================
DLL Injection
*   Trojan reaches its C&C Server via HTTP through Internet Explorer [whose behaviour sounds right].
========================
DLL Injection
*   From a Pivoting Attack point of view, DLL Injection is widely used during Privilege Escalation.
*   There are a lot of tools, such as CacheDump, PWDump6, LSADump2 or PWDumpX.
*   Most tools actually inject their nasty code into the Local Security Authority Subsystem (LSASS) to reach hashes.
*   The latter is amazingly efficient and permits a user with administrative privileges to retrieve [either locally or remotely] the domain password cache, password hashes and LSA secrets from a Windows system.
========================
Process Memory Dump
*   Some processes write sensitive data in memory in clear text format, or without relying on heavy encryption.
*   Specific process memory dumps may allow an attacker to grab interesting data.
*   Lots of tools do exist. One of the best ones is probably ProcDump, from Mark Russinovich.
*   It’s a powerful command-line utility which primary purpose is to monitor applications for CPU spikes in order to generate a crash dump with the purpose of helping the developer to debug.
========================
Process Memory Dump
*   It has plenty of amazing features. Anyway, here our goal is simply to dump the memory contents of a process to a file [without stopping the process of course].
*   So lots of tools can also do the job, such as PMDump from NTSecurity.
*   Sometimes we can find very sensitive information, such as usernames, computer names, IP addresses, and even passwords.
*   This is for example the case if you dump the memory of PwSafe. Not all fields are encrypted in memory.
========================
Process Memory Dump
*   For sure, password fields are not stored in memory in plaintext, but unfortunately other fields are. And sysadmin’s notes are often very juicy...
*   There is hope to collect credentials, map network resources, identify services, ports, sudoers account, and so on.
*   Even if the auditor is unlucky and does not grab passwords, he can still create a user list file for further dictionary attacks.
========================
Process Memory Dump
*   Process Memory Dump files are quite light.
*   During a Pivoting Attack in an Internal Penetration Test, it may worth a try to launch a memory dump against sensitive processes.
========================
Process Memory Dump
*   Something as easy as parsing the process memdump for strings may reveal interesting stuff to a pentester.
========================
Process Memory Dump
*   Here the Password Safe application permits an attacker to fingerprint the network, and to collect usernames, IP addresses and ports.
*   Very useful to carry out further attacks.
========================
Process Memory Dump
*   Here the network administration tool mRemote leaks internal path, IP address and TCP port of an SSH enabled server… As well as the username & password of a root account!
========================
Full Memory Dump
*   If you have a good bandwidth and you are not so limited by the time, why not dumping the whole memory?
*   An offline analysis of the whole memory dump may even reveal more important stuff. Even in the case of FDE, users may have opened sensitive TXT documents for example.
*   You may add DumpIt to your toolkit. It is a one-click memory acquisition application for Windows released by MoonSols. It’s a great tool which combines win32dd and win64dd in one executable. It is fast, small, portable, free and ultra easy to use. Just run in to dump the physical memory in the current directory.
========================
Cold Boot Attacks
*   It is a common belief that RAM looses its content as soon as the power is down.
*   This is wrong, RAM is not immediately erased. It may take up to several minutes in a standard environment, even if the RAM is removed from the computer.
*   And it may last much longer if you cool the DRAM chips. With a simple dusty spraying at -50°C, your RAM data can survive more that 10 minutes.
*   If you cool the chips at -196°C with liquid nitrogen, data are hold for several hours without any power.
========================
Cold Boot Attacks
*   It is then possible to plug the RAM in another system to dump their content to carry out an offline analysis.
*   In particular, encryption tools deeply rely on RAM to store their keys. Therefore such attacks are mostly aimed to defeat FDE, such as BitLocker, FileVault, dm-crypt, and TrueCrypt.
*   And even if there is some kinds of degradation in the memory contents, some algorithms can intelligently recover the keys.
*   To know more, read the Princeton University's paper.
========================
DMA based attacks
*   IEEE1394, aka FireWire, is a serial bus interface standard for high-speed communications and isochronous real-time data transfer.
*   According to Wikipedia, it “supports DMA and memory-mapped devices, allowing data transfers to happen without loading the host CPU with interrupts and buffer-copy operations”.
*   In other words, you can read [and write] in the target’s memory through its FireWire interface!
*   This security problem is not new [2004], but still exists today as it relies in IEEE 1394 specifications.
========================
DMA based attacks
*   A few years ago, attackers could use WinLockPwn. Today they have Inception tool, from ntropy.
*   Inception is a physical memory manipulation and hacking tool which nicely exploits IEEE 1394 SBP-2 DMA [Serial Bus Protocol 2].
*   The tool can unlock and escalate privileges to Administrator / Root on almost any powered on machine you have physical access to.
*   The tool works over any interface that expands and can master the PCIe bus, such as FireWire, Thunderbolt, ExpressCard and PCMCIA (PC-Card).
========================
DMA based attacks
*   It is initially made to attack computers that utilize FDE, such as BitLocker, FileVault, TrueCrypt or Pointsec.
*   You just need a Linux / Mac OS X system and a target which provides a FireWire / Thunderbolt interface, or an ExpressCard / PCMCIA expansion port.
*   There are for sure some limitations, such as the 4 GiB RAM bugs or the restrictions on OS X Lion targets [which disables DMA when the user is logged out as well as when the screen is locked if FileVault is enabled], but most often FireWire means P0wned.
========================
DMA based attacks
*   Just a few lines to install on a your BackTrack:
*   The short following demo of Inception exploits the FireWire interface of an up-to-date Windows 7 system to patch the msv1_0.dll file and unlock the running session.
========================
DMA based attacks
*   This kind of DMA based attacks also permit to attack mounted encrypted volumes, such as a TrueCrypt archive.
*   You can for example boot your attacking system with PassWare FireWire Memory Imager from Passware Kit Forensics, and search for AES keys in the target memory through FireWire.
*   You can basically defeat BitLocker, TrueCrypt, FileVault2 & PGP encryption volumes.
*   To know more: http://www.breaknenter.org/projects/inception/ http://support.microsoft.com/kb/2516445
========================
DMA based attacks
*   The following slides illustrate an attack on a TrueCrypt volume created on an 8 Gb memory stick.
*   First step was to backup the encrypted drive.
========================
DMA based attacks
*   Then let’s begin the attack on a mounted volume when the user went.
========================
DMA based attacks
*   Dump the physical memory of the target system through our favourite FireWire interface.
========================
DMA based attacks
*   And attack the key material in memory…
========================
DMA based attacks
*   The attack only last a couple of minutes.
========================
DMA based attacks
*   And you should get an unencrypted raw volume.
========================
DMA based attacks
*   You just have to fill a new memory stick with this raw image…
========================
DMA based attacks
*   And that’s it ! Just plug your new device…
========================
DMA based attacks
*   And enjoy your TrueCrypt less volume.
========================
Table of contents
0x00 - About me
0x01 - About this conference
0x02 - Memory introduction
0x03 - Memory manipulation from an offensive angle
0x04 - Memory manipulation from a defensive angle
0x05 - Conclusion
========================
Circumventing FDE
*   Traditional Forensics approach faces problem with encryption, especially with FDE.
*   If the investigator “pulls the plug” and creates a bit-for-bit image of the physical hard drive, he most probably destroys the best chance of recovering the plaintext data, as well as all common memory artefacts.
*   With FDE, it is usually far better to make a bit-for-bit image of the logical device while the system is still running, even if underlines disk activities are generally not welcome… And even if we rely on an untrusted OS to present what is actually on the disk, therefore prone to anti-forensic techniques.
========================
Circumventing FDE
*   If we begin by capturing the volatile memory, then we can potentially extract the cryptographic keys from the memory image to decrypt and analyse the disk image.
*   The only one challenge usually consists in uniquely identifying key materials among gigabytes of other data.
*   It is usually achieved with a mixed of entropy analysis [limited because of the short length of symmetrical keys and the randomness of other data, such as compressed files] and brute force attack [Known-Plaintext Attack, where the attacker has samples of both the plaintext and the ciphertext].
*   To learn more: “RAM is Key - Extracting Disk Encryption Keys From Volatile Memory", by B. Kaplan and M. Geiger).
========================
Code Analysis via API Hooking
*   A quick way to have an idea of what a binary does is to analyse its API calls.
*   You can do it easily with APISpy32 for example, from Pietrek.
*   You just need to populate a configuration file with the name of all the API [e.g. per a strings] you want to enable Hooking, and you get a nice malcode monitoring tool.
*   Next slide shows common API use in malware.
========================
Code Analysis via API Hooking
Common API
Malware
URLDownloadToFile, FtpGetFile, FtpOpenFile
Dropper
CreateRemoteThread, NtWriteVirtualMemory,
LoadLibrary and similar (LoadLibraryA, LoadLibraryExA, LoadLibraryExW, etc.)
Injection
BeginPaint (to disable local screen changes when a VNC session is activated)
Zeus
Accept, Bind
Backdoor
Connect, CreateNamedPipe, ConnectNamedPipe, DisconnectNamedPipe
Dropper and Reverse Trojan
IsDebuggerPresent, CheckRemoteDebuggerPresent
Anti debugger
========================
Code Analysis via API Hooking
Common API
Malware
CryptCreateHash, CryptEncrypt, CryptGetHashParam
Encryption
DeviceIoControl, NtLoadDriver, NtOpenProcess
Rootkit
HttpOpenRequest, HttpSendRequest, InternetConnect
Exfiltration
ModifyExcuteProtectionSupport, EnableExecuteProtectionSupport, NtExecuteAddFileOptOutList
DEP
SetSfcFileException
Windows File Protection alteration
========================
Memory Forensics
*   It is probably the best way to identify the most hidden evil code, such a Rootkits.
*   And don't forget that some malware can live in memory without ever touching the hard disk. This is for example the case with MSF Meterpreter, which is injected into existing process memory.
*   Stealth malware also work in that manner [mostly in targeted hacking against big companies].
*   Hard disks are amazingly big today. Simply creating a raw image can take very long time... Sometimes several days. Analysing memory is much faster.
========================
Memory Forensics
*   But there are also some minor drawbacks… Indeed, the memory image will only give us information on what was running at a particular time. We will not see the most visible piece of malcode if it was not running when we proceed with the imaging [unless some tracks remain in undeleted structures].
*   And fore sure, to make an image of the memory we first need to run once a specific utility... Which will be loaded in the targeted memory! As a consequence, it is always possible to alter evidence [even if chances are really low with a light utility].
*   Anyway, it definitely worth a try as a fast analysis can help you spot the evidence very quickly. :-]
========================
Memory Forensics
*   Any kind of physical memory abstract could be usable, such as a Memory Dump, a Crash Dump, an hibernation file or a VMEM file for virtual machines.
========================
Memory Forensics
*   Memory Forensics is a very huge project, as memory mappings differ from OS, SP and patch levels, and as vendors usually do not really document their internal memory structures.
*   Nevertheless, it is mature and efficient since a few years. Nowadays, we are not limited anymore to ASCI and Unicode grep, and we can now rely on powerful tools which parse well known memory structures.
========================
Memory Forensics
*   For sure, we are still facing challenging problems, and tools may be limited by Paging and Swapping which can prevent investigators from analysing the whole virtual address space of a specific process [unless they also dig into the pagefile.sys for example]…
*   But it is still really effective for Malware Analysis!
*   Besite commercial tools, free solutions do exist, such as Radare and Volatility. The later simply became impressing.
*   Since last year, Volatility also support MAC systems.
========================
Memory Forensics
*   Shall you need to carry out a Memory Forensics on a Windows, Linux, Mac or Android system, I strongly advise you to have a look on Volatility.
*   It is basically a Python based tool for extracting digital artefacts from volatile memory [RAM] samples which offer an amazing visibility in the runtime state of the system.
*   You can easily identify running processes and their DLL, Virtual Address Descriptor [VAD], System call tables [IDT, GDT, SSDT], environment variables, network connections, open handles to kernel and executive objects, and so on.
========================
Memory Forensics
*   It can even be used to dump LM and NTLM hashes, as well as LSA secrets…
========================
Memory Forensics
*   Well, for French targets there is a little bug [because of accents]... You will have to adapt a little bit the code:
========================
Memory Forensics
*   But beside this, it is really efficient to track malcode. Let’s dig into a real example…
========================
Memory Forensics
*   Heavy malware may be digitally signed by a trusted CA.
========================
Memory Forensics
*   And may be really appear benign to your users.
========================
Memory Forensics
*   Here it was an obfuscated .Net based Dropper.
========================
Memory Forensics
*   Even if you manually find the embedded payload, nearly everything is packed to disturb Reverse Engineers.
========================
Memory Forensics
*   The only one unencrypted payload was a kind of anti-restoring feature, which basically hooks specific API to prevent system administrators to remove the malware [e.g. by killing his task manager].
*   And then? What’s next? We could spend lots of time in a Reverse Engineering phase, or analyse its behaviour in a sandbox [if the code doesn’t detect it]…
*   …And we can simply see what’s happen in memory.
========================
Memory Forensics
*   Just infect voluntarily your VM or your lab workstation.
*   And use one of the good existing tools to dump the whole memory:
*   Memory from Mandiant
*   FTK Imager from AccessData
*   FastDump from HB Gary
*   DumpIt and Win32dd / Win64dd from Moonsols
*   And of course your favourite FireWire interface
*   Before using Volatility to dissect this memory dump.
========================
Memory Forensics
*   Let’s begin to get basic information on our dump file.
========================
Memory Forensics
*   The PSLIST command quickly show processes.
========================
Memory Forensics
*   You can arrange them by tree view.
========================
Memory Forensics
*   This process list can be quickly obtained by parsing a Kernel double chained list. Nevertheless, this list can be altered by malware, such as Rootkits, which therefore hide themselves from common system tools.
*   A deep research can then be achieved, which consist in parsing the whole memory dump to locate EPROCESS structures. These Kernel structures do exist for each process, no matter what the double chained list [known as Process Control Block] is.
*   A process listed in a PSCAN and not in a PSLIST often indicate a threat [mostly permitted via API Hooking].
========================
Memory Forensics
*   The PSCAN is longer but may reveal hidden code.
========================
Memory Forensics
*   Similarly, you can find processes which attempt to hide themselves on various process listings through the PSXVIEW command:
========================
Memory Forensics
*   Several Volatility commands works in this way and offer a SCAN variant to try to recognize specific structures in memory, thus revealing hidden sockets and connections for example.
*   For sure you may have [often quickly identified] false positives, as some process may gave been legitimately closed for example, thus letting some orphan EPROCESS data structures in RAM.
*   Nevertheless, some process may still be really running, and therefore instantaneously reveal a serious security issue.
========================
Memory Forensics
*   Established and recently closed connexions are also quickly revealed.
========================
Memory Forensics
*   And you can also easily explore the registry, which is widely used by malcode writers for various purpose [e.g. to permit their code to survive reboot].
========================
Memory Forensics
*   As well querying loaded drivers [often used by Rootkits].
========================
Memory Forensics
*   You can even parse loaded libraries to detect API Hooking, also widely used by Rootkits. Here a trampoline has been placed in the wbemcomm DLL [to hook certain WMI queries].
========================
Memory Forensics
*   You can extract suspicious file [through PID or offset] from the memory dump to carry out further investigation.
========================
Memory Forensics
*   And quickly identify a Key Logger.
========================
Memory Forensics
*   In fact, you can enumerate all opened files and even loaded DLL within a specific process… And drop them back on disk for investigation.
========================
Memory Forensics
*   The dumped process may not be runable, but would still offer you a quite easy to understand code [at least you don't have anymore to unpack it]. For example: strings dumpedfile | egrep -i 'http|ftp|irc|.exe'
*   Even more powerful, you can rely on the MALFIND command to perform advanced search using Regex, Unicode or ANSI strings...
*   And most importantly, it permits to quickly find hidden or injected code through the VAD tree inspection [very useful in case of DLL which may have been unlinked from the LDR lists by the malcode loader in order to avoid its detection].
========================
Memory Forensics
*   Here the MALFIND command reveals that an arbitrary code was injected into the CRSS.exe system process.
========================
Memory Forensics
*   We can quick parse MALFIND results to bring out running processes which were infected by such code injection.
========================
Memory Forensics
*   Even powerful rootkits quickly draw your attention.
========================
Memory Forensics
*   We can also use the Yara malware identification feature to directly scan for patterns inside a PID or within a specific memory segment. Here we see that an injected code inside the SVCHOST process established a connection to dexter.servequake.com:4444 via HTTP and download the 1234567890.functions resource.
========================
Memory Forensics
*   For sure, the RAT payload is encrypted, but in a few minutes you identified the threat and dig quite deeply into the real problem.
========================
Memory Forensics
*   You can now extract the guilty binary code along with the related memory segments and begin a classical malware analysis.
========================
Memory Forensics
*   And if you like high-level view for your incident report, why not extend Volatility with Graphviz to make something more visual?
========================
Memory Forensics
*   That’s it. I hope I have piqued your interest with one of the most important Forensics innovations of those last few years. The whole demo is attached here.
*   To learn more: SANS Forensics 610 Training Course [GREM] https://www.volatilesystems.com/default/volatility http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html http://www.tenouk.com/visualcplusmfc/visualcplusmfc20.html
========================
Table of contents
0x00 - About me
0x01 - About this conference
0x02 - Memory introduction
0x03 - Memory manipulation from an offensive angle
0x04 - Memory manipulation from a defensive angle
0x05 - Conclusion
========================
Conclusion
*   I hope I have achieved my goal of opening the doors to a fascinating world which could easily allow security analysts to save lots of time during their recurrent duties…
*   …And that you will see your own system [and the ones you asses] from a different angle.
*   …And that you will now have the reflex of dumping the whole memory in case of incident.
*   …And that you will reconsider security when the physical aspect in concerned. :-]

Read the original at: contagioFiled Under: Malware Analysis Tagged With: High-Tech Bridge, memory analysis, Volatility

About

This site aggregates posts from various digital forensics blogs. Feel free to take a look around, and make sure to visit the original sites.

  • Contact
  • Aggregated Sites

Suggest a Site

Know of a site we should add? Enter it below

Sending

Jump to Category

All content is copyright the respective author(s)