We are pleased to announce that Michael Ligh (MHL) will be delivering a
two day version of our Malware and Memory Forensics training at this
year's NorthSec conference in Montreal:
https://www.nsec.io/2017/01/malware-and-memory-forensics-training/
This will be our first public training of any kind in Canada, and the
class is already quickly filling.
If you have any questions please see the URL above or let me or MHL know.
Vol-users,
All mailing list services have been restored. If you have any questions
or experience any issues, please let me know. We apologize for any
inconvenience and thank you for your patience.
As a quick reminder, the new email address for the list will be: vol-users
[at] lists [dot] volatilityfoundation [dot] org. You can manage your
membership settings at the following URL:
https://lists.volatilityfoundation.org.
Thanks,
AAron Walters
The Volatility Foundation
Hi vol-users,
After 10 years, it is finally time to move the Volatility mailing lists to
their new home at the Volatility Foundation,
lists.volatilityfoundation.org. The official cutover is currently
scheduled for Friday, 3/10/2017, at 1100 EST. As a part of this process,
we’re also performing a number of infrastructure and security upgrades. We
anticipate this planned outage will take less than 12 hours.
With the dramatic increase in spam over the last 10 years, we have relied
heavily on automated classification and manual review to make sure none of
those messages burden your inbox. Unfortunately, there have been
circumstances where some users’ emails have been inadvertently filtered.
In order to reduce the likelihood of this happening in the future, the
list will now be configured to only accept messages from email addresses
that are registered as members of the list.
During the move, we will handle migrating existing users to the new
systems. Once the move is complete, we will send an email notification
that will also serve as a test message on the new platform. If you do not
receive the notification email, please send me a note and we will work on
getting the issue resolved! We appreciate your patience as we make this
transition.
The new email address for the list will be: vol-users [at] lists [dot]
volatilityfoundation [dot] org.
As a part of this transition, we have also decided to sunset the
Volatility Developers mailing list (Vol-dev). Currently, almost all of
the development conversations and issues are handled within the Volatility
project page on Github:
https://github.com/volatilityfoundation/volatility. We will be maintaining
the Vol-dev mailing list archives for historical purposes.
A special thanks to the Volexity team and our official training partner,
memoryanalysis.net, for sponsoring the new infrastructure.
Thanks,
AAron Walters
The Volatility Foundation
Dear All,
I'm a beginner in Memory Forensics, I want to develop volatility plugin
that searches a memory dumps to find records which inserted via C++
program. I'm created VType for the struct that used in the program but how
to access the records in memory dump using volatility.
thanks
regards,
Ahmad
Hi list,
I have a couple of questions that might be stupid but I am pretty new to
memory forensics.
-Is there a specific reason why the windows operating system would need a
page to be marked Execute and Read/write?
-IS DKOM used only in Windows OSs?
Thanks!
We wanted to send a quick note that our upcoming training in Herndon is
likely going to sell out in the next week. Please contact us ASAP if you
wish to attend:
https://www.memoryanalysis.net/memory-forensics-training
If you can't make this training, we also have public trainings later
this year in London and back in Herndon. Both of these currently have
spots available.
We also have 1 (or possibly 2 depending on the week) private training
slots left for 2017. Again, contact us ASAP if your organization would
like a private training as the slots go pretty fast.
If you have any questions then please let us know.
--
Thanks,
Andrew (@attrc)
Hello All,
We are excited to announce the keynote and speaker lineup for BSidesNOLA
2017!
http://www.bsidesnola.com
This all-day event will take place on April 1st in the New Orleans CBD.
It is a great time for learning, networking, and enjoying great food and
drinks.
It is $15 to attend, and this includes refreshments and a t-shirt.
We had around 215 people attend last year, and expect more this year.
If you have any questions then please let me know.
--
Thanks,
Andrew (@attrc)
Hi all,
I know in an ideal world I'd submit this as a pull request to the github
project, but you'll see why I haven't.
With the Win81U1x64 profile, the `windows` plugin is able to correctly
report the associated PID:
Window Handle: #20074 at 0xfffff90140819cf0, Name: Untitled - Notepad
ClassAtom: 0xc12c, Class: -
SuperClassAtom: 0xc12c, SuperClass: -
pti: 0xfffff9014225b9b0, Tid: 2532 at 0xffffe00001dbe600
ppi: 0xfffff90140747010, Process: notepad.exe, Pid: 2528
However, using the Win10x64 profile it cannot, because tagWND.head.pti.ppi
is 0x0.
Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad
ClassAtom: 0xc16d, Class: -
SuperClassAtom: 0xc16d, SuperClass: -
pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380
ppi: 0x0, Process: -, Pid: -
I'm pretty sure I've traced this to being that in tagWND.head.pti the
offset to ppi is wrong.
$ python vol.py -f Win10x64.vmem --profile Win10x64 volshell
--SNIP--
>>> dt('tagTHREADINFO')
'tagTHREADINFO' (936 bytes)
0x0 : pEThread ['pointer64', ['_ETHREAD']]
0x8 : RefCount ['unsigned long']
--SNIP--
0x168 : spklActive ['pointer64', ['tagKL']]
0x170 : pcti ['pointer64',
['tagCLIENTTHREADINFO']]
0x170 : ppi ['pointer', ['tagPROCESSINFO']]
0x178 : rpdesk ['pointer64', ['tagDESKTOP']]
--SNIP--
You can see that `ppi`, the pointer to `tagPROCESSINFO`, is at 0x170 - the
same as `pcti`.
The pointer to the tagPROCESSINFO structure is actually at 0x178 -
currently shown as `rpdesk`.
If I modify `volatility/plugins/gui/vtypes/win8.py`, at line 197 from:
'ppi': [0x170, ['pointer', ['tagPROCESSINFO']]],
to:
'ppi': [0x178, ['pointer', ['tagPROCESSINFO']]],
the `windows` plugin now behaves itself:
Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad
ClassAtom: 0xc16d, Class: -
SuperClassAtom: 0xc16d, SuperClass: -
pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380
ppi: 0xfffff90141fa5c10, Process: notepad.exe, Pid: 3692
And it's at this point where my understanding of the Volatility code breaks
down and why I'm not comfortable submitting a pull request. I don't know
how to implement an overlay for Win10 and what knock-on effect it might
have.
My *guess* would be that Microsoft has added an extra value to the
tagTHREADINFO structure between Windows 8 and Windows 10 meaning the offset
(within the tagTHREADINFO structure) has moved along 8 bytes (0x170 ->
0x178), but I don't know the rest of the structure well enough to
confidently validate this theory.
Perhaps one of the Volatility core developers does?
Thanks,
Adam
All,
My Forensic team is hiring two paid Forensic Interns for the summer of 2017
in the Northern Virginia area. We are charged with directly supporting
Sony's global SOC, which ends up touching many core facets of digital
forensics and incident response including:
memory analysis
disk analysis
mobile device forensics
timeline investigations
research and development projects
data analytics
If you are interested please feel free to apply directly on the job listing
below. If you have any questions you can reach out to me directly.
https://careers.sony.com/sony/?_3x3524903Z2U14Kdf8024bc-fbd2-4d8e-96d7-d7a5…
I'll also be doing some recruiting at BSides New Orleans
<http://www.securitybsides.com/w/page/113990746/BSidesNOLA%202017> on 4/1
where i'll be talking about a case study on Andromeda malware.
Best Regards,
Jared Greenhill (@jared703)
Hi all,
I feel like I'm missing something obvious. Consider the following from
volshell.
Profile is Win10x64 in case it matters; I'd already imported messagehooks
(mh).
>>> sc()
Current context: System @ 0xffffe00012a61840, pid=4, ppid=0 DTB=0x1aa000
>>> for winsta, atom_tables in mh.calculate():
... for desktop in winsta.desktops():
... for wnd, _level in desktop.windows(desktop.DeskInfo.spwnd):
... if wnd.cbwndExtra == 8:
... break
>>> wnd
[tagWND spwndNext] @ 0xFFFFF90140A04AD0
>>> dt(wnd)
[tagWND spwndNext] @ 0xFFFFF90140A04AD0
0x0 : head 18446736382507371216
0x28 : bActiveFrame 0
0x28 : bAnsiCreator 0
--SNIP--
0x120 : bLinked 1
0x120 : bRedirectedForPrint 0
0x120 : bVerticallyMaximizedLeft 0
0x120 : bVerticallyMaximizedRight 0
>>> dt('tagWND', wnd.v())
ERROR: could not instantiate object
Reason: Invalid Address 0xFFFFF90140A04AD0, instantiating tagWND
>>> hex(wnd.v())
'0xfffff90140a04ad0L'
>>> db(wnd.v())
Memory unreadable at fffff90140a04ad0
Why is the memory address unreadable? Is my error in assuming that object
'wnd' is made up of bytes located at 0xFFFFF90140A04AD0?
Given the address is in Kernel space, I should be able to access it right?
Any pointers appreciated! (Pardon the pun.)
Adam
