Hello,
I recently posted a message, where I asked how to create a profile which
could be used with ArchLinux, but now I just solved this by having
installed Lubuntu 16.04 (4.4.0-31-generic 64-bit), so that I was able to
analyze my system's dumped memory using the pre-built Ubuntu 16.04 image I
found on GitHub (the image I created by myself couldn't be used by
Volatility, although I definitely followed each step precisely).
The checks I performed confirmed my suspicion that my system would be
compromised, as one can see by taking a look at the results I uploaded on
GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWTnNYWlJRWXpsZUE
E.g.:
linux_check_afinfo
Symbol Name Member
Address
------------------------------------------ ------------------------------
------------------
udplite6_seq_afinfo next
0xffffffff81effcc8
udplite6_seq_afinfo stop
0xffffffff81eff808
udplite4_seq_afinfo next
0xffffffff81efeac8
udplite4_seq_afinfo stop
0xffffffff81efbce8
udp4_seq_afinfo start
0xffffffff81efae00
udp4_seq_afinfo stop
0xffffffff81efa3a0
linux_check_inline_kernel
Name Member Hook Type
Hook Address
------------------------------------------------ ---------------- ---------
------------------
udp4_seq_afinfo stop JMP
0x0000000000000000
[A huge number of hooks shown by linux_check_syscall]
Using the netstat plugin shows no result at all (none of the connections
shown by using the normal Linux netstat command). Neither linux_lsmod nor
linux_hidden_modules give any output as well.
I assume that my system is infected by an ACPI rootkit, which is able to
compromise both Linux and Windows systems. After having submitted the
extracted the ACPI tables' code to malwr.com, where it gets executed on a
Windows sandbox, it shows that the system gets manipulated in the following
way:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It might be interesting that the ACPI code of four different systems being
used by me seems to have been manipulated in the same way, since the
extracted code found on one of the other systems leads to the same result
when submitting it to malwr.com. E.g., the link above shows the result for
the analysis of ACPI code on my AMD 64-bit desktop computer (Asus-M4N68T-M
LE mainboard), while the ACPI code extracted from my Lenovo G710 notebook
leads to the same when executed on a Windows system:
https://malwr.com/analysis/MjZkOGU4Y2ZmMGM5NDQ1Njg5OTc4NTVlOTQ5NThiMmY/
I guess everyone can see that the results show how the Windows system gets
compromised for being able to monitor it and gaining remote access over it,
if you take a look at the file and registry activities (just googling some
of the file names makes that clear).
Since a Linux system running on the same machine gets compromised as well,
it would be reasonable to assume that this also takes place by the ACPI
code's execution. Taking a look at the dmesg output, which I also uploaded
on GoogleDrive, seems to confirm this assumption:
[ 0.225468] ACPI: Added _OSI(Module Device)
[ 0.225470] ACPI: Added _OSI(Processor Device)
[ 0.225471] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.225472] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.227433] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.293448] ACPI: Interpreter enabled
[ 0.293458] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State
[\_S2_] (20150930/hwxface-580)
[ 0.293469] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.293470] ACPI: Using IOAPIC for interrupt routing
[ 0.293491] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.294509] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in
ACPI motherboard resources
[ 0.294522] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[ 0.298938] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.298943] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI]
[ 0.299051] acpi PNP0A03:00: _OSC: platform does not support
[PCIeHotplug PCIeCapability]
[ 0.299099] acpi PNP0A03:00: _OSC: not requesting control; platform does
not support [PCIeCapability]
[ 0.299101] acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug PME AER
PCIeCapability]
[ 0.299103] acpi PNP0A03:00: _OSC: platform willing to grant [PME AER]
[ 0.299104] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM
[ 8.647712] ACPI Warning: SystemIO range
0x0000000000000600-0x000000000000063F conflicts with OpRegion
0x0000000000000600-0x00000000000006FF (\_SB_.PCI0.SBRG.ASOC.SMRG)
(20150930/utaddress-254)
The extracted and disassembled ACPI code of my AMD system can be downloaded
from here:
https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
So I would appreciate it, if anyone would have an idea on how to proceed
with a further analysis. It would be interesting, if one would be able to
see how exactly the ACPI code's execution interacts with the kernel in
order to compromise the system. And of course it would be interesting to
discover where the relevant network traffic gets forwarded to / comes in
from (for remote access), since the checks I already performed showed that
the networking structure got manipulated, so that the usage of Wireshark
etc. won't show anything.
Kind regards and thanks in advance
David
Hello,
I'm using Antergos with the 4.6.4-1 kernel and after dumping my computer's
memory using lime worked without any problems, I went on creating a profile
for my system according to the instructions on
https://github.com/volatilityfoundation/volatility/wiki/Linux#using-the-pro…,
while creating the system.map using "cp /proc/kallsyms
/boot/System.map-4.6.4-1" (because there is no system.map in ArchLinux, as
mentioned on https://github.com/volatilityfoundation/profiles/issues/13)
Unfortunately I experience the same problem as described in the last link,
since volatility gives an error message about this profile saying "***
Failed to import volatility.plugins.overlays.linux.linux (ValueError: too
many values to unpack)".
On the issue thread linked above someone gives the following answer:
"Old issue, but could still be interesting.
This is most likely due to kallsyms giving additional information on
certain lines ([serio] or [kvm] for example), and Volatility on the other
hand only expecting three space separated values:
(str_addr, symbol_type, symbol) = line.strip().split()
That's why before using the output of the kallsyms proc file to build a
profile, some lines must be checked to fit the expected format."
Now this answer doesn't really help me to solve the issue and create a
working profile for my system. Does someone has any idea how I could
proceed in order to do so? As far as I know, nobody was ever able to build
a profile working for Arch, so I think this would be really helpful for
many people.
I uploaded the profile created by myself and the files I used for doing so
on GoogleDrive, in case someone might even be able to create a profile
using those files:
https://drive.google.com/open?id=0B62Y5Qk_rdbWbWlDZ21VUEVrZGc
Many thanks in advance and kind regards
David
Hello everyone,
I apologize if this is not correctly described, but I have been trying to read Para-virtualized (PV) core dump files from a Xen Hypervisor. Now, I have managed to read the core dump when the VM is in HVM mode and read pfn values of a Ubuntu system with this external GitHub project (address space from Xenelf.py file): https://github.com/banne01/xen-core-velocity (after modifying line 126 to show elf_hdr instead of elf64_hdr to solve a weird error message).
However, I cannot seem to figure out how the p2m values are properly read from a PV SUSE Linux Enterprise Server VM. There is a pfn value and a gmfn value in the p2m array of values which I cannot seem to read and interpret properly even if I specifically tell volatility to focus on just the pfn values. In addition, Volatility succeeds in instancing the address space for the SLES coredump but it still errors out after all the other address spaces have been exhausted.
If anyone has any feedback or ways to point me in the right direction, could you let me know?
Thanks, and best regards.
Michael Seborowski
We wanted to send a quick update before heading to Vegas.
If you will be around Black Hat during the pre-conference trainings
and/or briefings, and want to meet up then let us know. Jamie and I will
be around during the pre-conf trainings and then the whole team will be
around for the briefings.
Also, if you are headed to DFRWS, then be sure to check out Dr. Golden's
talk on Analyzing Objective-C malware through memory forensics. This is
some work that we did which will be headed to core Volatility soon after.
And finally - we have upcoming trainings in Amsterdam and Reston that
are quickly filling. If you wish to attend then please contact us ASAP
in order to reserve a seat:
http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n
--
Thanks,
Andrew (@attrc)
Hi Kim,
In this case, its not the overlays. I can tell because details for the
two processes you /do/ see from psscan are all okay. If a bad overlay
was the issue, your results would be all or nothing.
Cheers - I may follow up with you off-list to offer a little other advice.
Thanks,
Michael
On 7/25/16 11:40 AM, Kim Palechek wrote:
> I don’t have access to the machine but I’m sure our Forensics guys do as they were the ones who retrieved the image for us. I’ll discuss with Steve on what he wants to do or if he wants to acquire another image.
>
> Thank you so much for getting back to me so quickly and for your help! I wasn’t sure if it was another issue with the overlays and x64 machines.
>
>
>
>
> Kim Palechek, CISSP, CEH
> IT Security Operations Specialist, (Information Security, Risk and Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com
>
> The absence of evidence is not the evidence of absence.
>
> On 7/25/16, 11:15 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
>
> Hi Kim,
>
> Yes, unfortunately we're only able to enumerate 1 process in the linked
> list. This typically happens when the acquisition tool fails to acquire
> one or more pages of memory containing the necessary puzzle pieces (or
> "links"). In some cases, if its a minor smearing issue, you can still
> salvage some data by using psscan, which does a brute force scan of the
> entire memory dump for processes (even if they aren't linked). However,
> I noticed your psscan results only had 2 entries. This means the
> acquisition tool failed to acquire a whole lot more than just a couple
> pages. In the past, we've seen that happen quite a bit with DumpIt, FTK
> Imager, and Memoryze.
>
> Do you still have access to the suspect machine by any chance?
>
> Thanks,
> Michael
>
> On 7/25/16 11:07 AM, Kim Palechek wrote:
> > Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition.
> >
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win7SP1x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win7SP0x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win2008R2SP1x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win2008R2SP0x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> >
> >
> >
> >
> >
> > Kim Palechek, CISSP, CEH
> > IT Security Operations Specialist, (Information Security, Risk and Compliance)
> > 3M Information Technology
> > 3M Center, Bldg, 0224-04-E-21
> > Phone: 736-6526
> > kspalechek(a)mmm.com
> >
> > The absence of evidence is not the evidence of absence.
> >
> > On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
> >
> > Hi Kim,
> >
> > Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
> > results?
> >
> > Also, do you know what tool was used for acquisition? My gut feeling is
> > this is probably related to a bad capture, but I'll wait on the kdbgscan
> > results to tell for sure.
> >
> > Thanks,
> > Michael
> >
> > On 7/25/16 7:42 AM, Kim Palechek wrote:
> > > I need some assistance with an issue that I recently came across. I am
> > > trying to run volatility plugins against the image Win2008R2SP1x64 and
> > > it doesn’t seem to be providing complete information. Below are a few
> > > examples. Any ideas on the ‘lack of information’?
> > >
> > >
> > >
> > >
> > >
> > > $ *vol.py pstree*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Name Pid PPid
> > > Thds Hnds Time
> > >
> > > -------------------------------------------------- ------ ------ ------
> > > ------ ----
> > >
> > > 0xfffffa8024e15040: 0 0 0
> > > ------ 1970-01-01 00:00:00 UTC+0000
> > >
> > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > $ *vol.py psscan*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Offset(P) Name PID PPID PDB
> > > Time created Time exited
> > >
> > > ------------------ ---------------- ------ ------ ------------------
> > > ------------------------------ ------------------------------
> > >
> > > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> > > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
> > >
> > > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> > > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
> > >
> > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > >
> > >
> > > $ *vol.py pslist*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Offset(V) Name PID PPID Thds Hnds
> > > Sess Wow64 Start Exit
> > >
> > > ------------------ -------------------- ------ ------ ------ --------
> > > ------ ------ ------------------------------ ------------------------------
> > >
> > > 0xfffffa8024e15040 0 0 0 --------
> > > ------ 0
> > >
> > >
> > >
> > >
> > >
> > > */Kim Palechek, CISSP, CEH
> > > /*IT Security Operations Specialist, (Information Security, Risk and
> > > Compliance)
> > > 3M Information Technology
> > > 3M Center, Bldg, 0224-04-E-21
> > > Phone: 736-6526
> > > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
> > >
> > >
> > >
> > > The absence of evidence is not the evidence of absence.
> > >
> >
> > 3M security scanners have not detected any malicious content in this message.
> >
> > To report this email as SPAM, please forward it to spam(a)websense.com
> >
>
> 3M security scanners have not detected any malicious content in this message.
>
> To report this email as SPAM, please forward it to spam(a)websense.com
>
Hi Kim,
Yes, unfortunately we're only able to enumerate 1 process in the linked
list. This typically happens when the acquisition tool fails to acquire
one or more pages of memory containing the necessary puzzle pieces (or
"links"). In some cases, if its a minor smearing issue, you can still
salvage some data by using psscan, which does a brute force scan of the
entire memory dump for processes (even if they aren't linked). However,
I noticed your psscan results only had 2 entries. This means the
acquisition tool failed to acquire a whole lot more than just a couple
pages. In the past, we've seen that happen quite a bit with DumpIt, FTK
Imager, and Memoryze.
Do you still have access to the suspect machine by any chance?
Thanks,
Michael
On 7/25/16 11:07 AM, Kim Palechek wrote:
> Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition.
>
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win7SP1x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win7SP0x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win2008R2SP1x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win2008R2SP0x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
>
>
>
>
>
> Kim Palechek, CISSP, CEH
> IT Security Operations Specialist, (Information Security, Risk and Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com
>
> The absence of evidence is not the evidence of absence.
>
> On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
>
> Hi Kim,
>
> Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
> results?
>
> Also, do you know what tool was used for acquisition? My gut feeling is
> this is probably related to a bad capture, but I'll wait on the kdbgscan
> results to tell for sure.
>
> Thanks,
> Michael
>
> On 7/25/16 7:42 AM, Kim Palechek wrote:
> > I need some assistance with an issue that I recently came across. I am
> > trying to run volatility plugins against the image Win2008R2SP1x64 and
> > it doesn’t seem to be providing complete information. Below are a few
> > examples. Any ideas on the ‘lack of information’?
> >
> >
> >
> >
> >
> > $ *vol.py pstree*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Name Pid PPid
> > Thds Hnds Time
> >
> > -------------------------------------------------- ------ ------ ------
> > ------ ----
> >
> > 0xfffffa8024e15040: 0 0 0
> > ------ 1970-01-01 00:00:00 UTC+0000
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > $ *vol.py psscan*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Offset(P) Name PID PPID PDB
> > Time created Time exited
> >
> > ------------------ ---------------- ------ ------ ------------------
> > ------------------------------ ------------------------------
> >
> > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
> >
> > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> >
> > $ *vol.py pslist*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Offset(V) Name PID PPID Thds Hnds
> > Sess Wow64 Start Exit
> >
> > ------------------ -------------------- ------ ------ ------ --------
> > ------ ------ ------------------------------ ------------------------------
> >
> > 0xfffffa8024e15040 0 0 0 --------
> > ------ 0
> >
> >
> >
> >
> >
> > */Kim Palechek, CISSP, CEH
> > /*IT Security Operations Specialist, (Information Security, Risk and
> > Compliance)
> > 3M Information Technology
> > 3M Center, Bldg, 0224-04-E-21
> > Phone: 736-6526
> > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
> >
> >
> >
> > The absence of evidence is not the evidence of absence.
> >
>
> 3M security scanners have not detected any malicious content in this message.
>
> To report this email as SPAM, please forward it to spam(a)websense.com
>
Hi Kim,
Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
results?
Also, do you know what tool was used for acquisition? My gut feeling is
this is probably related to a bad capture, but I'll wait on the kdbgscan
results to tell for sure.
Thanks,
Michael
On 7/25/16 7:42 AM, Kim Palechek wrote:
> I need some assistance with an issue that I recently came across. I am
> trying to run volatility plugins against the image Win2008R2SP1x64 and
> it doesn’t seem to be providing complete information. Below are a few
> examples. Any ideas on the ‘lack of information’?
>
>
>
>
>
> $ *vol.py pstree*
>
> Volatility Foundation Volatility Framework 2.5
>
> Name Pid PPid
> Thds Hnds Time
>
> -------------------------------------------------- ------ ------ ------
> ------ ----
>
> 0xfffffa8024e15040: 0 0 0
> ------ 1970-01-01 00:00:00 UTC+0000
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> $ *vol.py psscan*
>
> Volatility Foundation Volatility Framework 2.5
>
> Offset(P) Name PID PPID PDB
> Time created Time exited
>
> ------------------ ---------------- ------ ------ ------------------
> ------------------------------ ------------------------------
>
> 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
>
> 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> $ *vol.py pslist*
>
> Volatility Foundation Volatility Framework 2.5
>
> Offset(V) Name PID PPID Thds Hnds
> Sess Wow64 Start Exit
>
> ------------------ -------------------- ------ ------ ------ --------
> ------ ------ ------------------------------ ------------------------------
>
> 0xfffffa8024e15040 0 0 0 --------
> ------ 0
>
>
>
>
>
> */Kim Palechek, CISSP, CEH
> /*IT Security Operations Specialist, (Information Security, Risk and
> Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
>
>
>
> The absence of evidence is not the evidence of absence.
>
Hello all,
I am analyzing a memory dump and looking at execution in a period of known
bad activity, and have been able to gather quite a bit of information using
volatility. For some reason though, shimcache and psscan return no results,
although all the other plugins I've run (and volshell) have worked fine. I
find it hard to believe that psscan for one can find no _EPROCESS
structures, so I'm not sure what's happening. Also, in the results from the
timeliner, I have several entries with blank shimcache entries like
"macb,---------------,0,0,0,"[SHIMCACHE] "" during times I can correlate
with shimcache entries on disk, so I know something is just not being
picked up.
Any ideas on why shimcache/psscan would produce no results? I'm not sure
about the best way to track down the reason.
Thanks!
Erika
