As a way to give back to our community, we have reserved a few
complimentary tickets to our From the Source event happening on
Monday, October 20th in Arlington, VA.
If you have not yet seen the incredible speaker lineup for the event,
then please check the event page:
https://volatilityfoundation.org/from-the-source-2025/
If you can attend the event and would like to claim one of the
complimentary “Friend of Volatility” tickets, then please reply to
this email.
Given the limited number of these tickets available, please only reply
if you are 100% sure that you can attend.
We also need to receive all replies by this Friday, October 10th.
We are looking forward to seeing many of you at FTSCon!
-- The Volatility Team
The next in-person offering of our highly popular and technical
Malware and Memory Forensics Training with Volatility will be held in
Arlington, VA from October 21st-24th.
This course has been fully converted to Volatility 3, and all the
material and labs have been updated to cover the latest threats and
analysis techniques.
Details on the course and how to register can be found on the registration page:
https://memoryanalysis.net/courses-malware-memory-forensics/#course-availab…
Registering for the course also gets you a free ticket to our FTSCon
conference taking place the day before the training on the 20th:
https://volatilityfoundation.org/from-the-source-2025/
The full FTSCon speaking lineup will be announced next week so be sure
to check back!
If you missed our announcement of the Volatility 3 Parity Release and
deprecation of Volatility 2 then please read our blog post from
earlier this year:
https://volatilityfoundation.org/announcing-the-official-parity-release-of-…
We are looking forward to seeing many of you in Virginia later this year!
-- The Volatility Team
We were writing to let everyone know that our highly popular and
technical training, "Malware and Memory Forensics with Volatility",
has been fully converted to Volatility 3 as well as significantly
updated.
The updates include many completely new sections, rewrites of existing
ones, and 8 new, in-depth labs.
The course is available online in a self-paced format and will be run
live in Arlington, VA in October.
Full details can be found on the course page:
https://memoryanalysis.net/courses-malware-memory-forensics/
PS: If you previously took the course and want to retake, then please
contact us for a significant alumni discount.
The Volatility Team is very excited to announce the official Parity
Release of Volatility 3!
This release is not only capable of fully replacing all of Volatility
2’s features, but it also incorporates support for all the latest
operating system versions plus all the latest memory forensics
research.
With this release, Volatility 2 is now deprecated, and its GitHub
project has been archived.
Our announcement blog post details the new features, many of the new
plugins, and tells you how to get started with Volatility 3.
https://volatilityfoundation.org/announcing-the-official-parity-release-of-…
Our team is incredibly grateful for the continued support from our
community, and we hope that you all enjoy Volatility 3 for many years
to come.
-- The Volatility Team
We are very excited to announce that we (The Volatility Foundation)
are hosting a week of Volatility events in October in Arlington, VA!
The week will start with our From the Source event on Monday October
21st. FTS is a one-day conference with speakers across two tracks, and
we have chosen speakers from across the industry who have recently
published ground-breaking research in the areas of memory forensics,
malware analysis, threat intelligence, and other related technical
fields. The day will conclude at the International Spy Museum where we
have booked out the entire venue for our attendees to network and
enjoy. All proceeds from this event will be donated to Connect Our
Kids, a 501(c)(3) nonprofit that is pioneering technology to find
families, build connections, and create community for children in the
foster care system.
From Tuesday the 22nd through Friday the 25th, we will be hosting the
first offering of our popular Malware and Memory Forensics with
Volatility training that is focused exclusively on Volatility 3. This
event will allow attendees to be in the first set of students to learn
Volatility 3 directly from the core development team. We have also
significantly updated the course curriculum and created many new labs.
Those who register for this training will receive complimentary access
to FTS.
Full details of both events can be found here:
https://volatilityfoundation.org/from-the-source-memory-forensics-training/
Please let us know if you have any questions, and we are looking
forward to seeing many of our community members in October!
-- The Volatility Team
The 2024 Volatility Plugin Contest is officially open for submissions!
This is your opportunity to directly contribute to the open-source
forensics community and put groundbreaking capabilities into the hands
of digital investigators.
Gain industry-wide visibility for your work, contribute to an
important open-source project, and win cash, swag, and other great
prizes!
The contest is designed to encourage research and development in the
field of memory analysis – a critical field given the prevalence of
memory-only payloads, malware, and rootkits.
Submissions will be accepted until December 31, 2024.
Full details can be found on our announcement page:
https://volatilityfoundation.org/volatility-plugin-contest/
We are looking forward to another year of creative submissions!
-- The Volatility Team
We are very excited that, for the first time, we are hosting an
in-person, public offering of our popular Malware and Memory Forensics
Training focused solely on Volatility 3! This training takes place
October 22–25, 2024, in Arlington, VA.
This course will allow students to learn the latest version of the
Volatility framework directly from members of the core development
team. Students will also be the first to experience many new lecture
sessions and labs that have been incorporated into the course.
As an added bonus, students who register for this in-person training
will receive a complimentary pass to our “From the Source” event
taking place on October 21, 2024.
For full information on the course and From the Source, please see our
recent blog post:
https://volatilityfoundation.org/in-person-malware-and-memory-forensics-tra…
We are looking forward to seeing many of our community members this
October in Arlington!
-- The Volatility Team
In celebration of the 10th anniversary of The Art of Memory Forensics
and our recent push for Volatility 3 feature parity, we are excited to
announce that we are hosting the first Volatility Foundation
conference, From the Source (FTS) , which will be held in Arlington,
VA on October 21, 2024! This event is an intimate one-day summit
offering a unique opportunity to connect in person with pioneering
researchers and practitioners who work on the most advanced digital
investigations. The conference agenda consists of two parallel tracks:
one track is focused on the “makers” who build the open-source tools
relied upon by modern digital investigators; the second track
highlights the “hunters” who have discovered some of the biggest
intrusions of the past year. Unlike most conferences in cybersecurity
these days, we wanted to return the focus to the people who actually
do the technical work! Be sure to follow @Volatility on social media,
as we will be announcing an exciting roster of talks over the next
couple of weeks.
Join industry-leading digital investigators from commercial, academic,
and government organizations from around the world who are looking for
technical content about digital investigations. As a non-profit
charitable event, 100% of the proceeds of the registration fee will be
donated to “Connect Our Kids”, which leverages technology to help
vulnerable children and their families.
As contributors to Volatility and members of the Volatility community,
we wanted to extend an early VIP registration in appreciation of the
years of contributions and support!
- To register for From The Source:
https://events.humanitix.com/from-the-source-hosted-by-the-volatility-found…
- Use access code VOLCOMMUNITY17 to obtain a discounted, early access rate.
- Note that the early registration discount will expire on July 15, 2024.
- There are a limited number of tickets, so register early!
For the remainder of the week following the summit, the Volatility
core development team will also be hosting the first offering of the
Malware & Memory Forensics Training course in person that is focused
exclusively on Volatility 3.
- To register for the Malware & Memory Forensics Training on
Volatility 3: https://events.humanitix.com/malware-and-memory-forensics-training-on-volat….
- It may show it is Sold out; just choose the “Join waitlist” option
to begin the registration process.
- Registration for this in-person training includes a complimentary
pass to the conference.
Please let me know if you have any questions or concerns.. We hope you
will consider attending, and we look forward to seeing you!
-- The Volatility Team
We just published a new blog post that details our effort to recover
raw sockets on Windows 10+ systems.
This included reversing of the Windows network stack, verification of
recovery across all operating system versions, and creation of a new
Volatility 3 plugin that automates the recovery.
https://volatility-labs.blogspot.com/2023/08/memory-forensics-r-d-illustrat…
We hope that you enjoy it!
-- The Volatility Team
We are excited to announce that our Malware and Memory Forensics
training course is headed to Amsterdam in October!
Complete details can be found on our blog post announcing the course:
https://volatility-labs.blogspot.com/2023/06/malware-and-memory-forensics-t…
This course is completely updated to cover the latest malware and
threats against Windows 10 and 11 as well as the latest versions of
Linux and Apple Silicon devices.
If you would like to see an example of the research presented in this
course, then check out our recent blog post on detecting hidden
services in Windows 10+ memory samples:
https://volatility-labs.blogspot.com/2023/03/memory-forensics-r-d-illustrat…
We hope to see many of you October!
PS: We will be in Vegas this summer, so please let us know if you
would like to meet up with some of the developers!
-- The Volatility Team
The Computer Science department at Louisiana State University (LSU) is
currently hiring for many faculty positions related to applied cyber
security. Courses taught inside this department include reverse
engineering, malware analysis, binary exploitation, memory forensics
and other intensive courses related to incident response and offensive
security.
Ideal candidates will have significant experience with deeply
technical areas of cybersecurity. LSU was recently granted the CAE-CO
designation and is one of only 21 schools nation-wide to hold it as it
is the most technical designation granted by NSA and DHS. The
department also runs a large SFS program for cyber security students.
If you are interested in one of these positions, then please see the
following link. I also ask my industry contacts to please spread the
word within academic communities that you have access to:
https://lsu.wd1.myworkdayjobs.com/en-US/LSU/job/3325-Patrick-F-Taylor-Hall/…
The cybersecurity effort at LSU has strong support from the highest
levels of the school and is rapidly expanding – so now is the perfect
time to join.
PS: I am not employed by LSU, but do work very closely with the CS
department to ensure the courses are relevant to industry and rigorous
enough for students to leave with real-world, hands-on experience. If
you have questions related to the position, then please direct them to
Dr. Golden Richard at LSU: https://www.cct.lsu.edu/~golden/
Thanks,
Andrew
We just published a blog post on creating new Volatility 3 plugins to detect hidden services on Windows:
https://volatility-labs.blogspot.com/2023/03/memory-forensics-r-d-illustrat…
The post covers background on how malware abuses services, how services are tracked on a live system, and how we developed our new plugins.
Feedback and comments encouraged!
— The Volatility Team
We are excited to announce that we are resuming our in-person training course!
The first in-person course of 2023 will take place May 8–12 in Reston,
VA. We are also exploring potential venues for a Fall 2023 course in
Europe.
Full information on the course, including the many new updates being
added for 2023, can be found on our blog post here:
https://volatility-labs.blogspot.com/2023/01/the-return-of-in-person-volati…
We are really looking forward to resuming in-person training, and we
hope to see many of you in Reston. Please let us know if you have any
questions.
-- The Volatility Team
Hello All,
We are writing to gauge interest in our team resuming in-person
Malware and Memory Forensics trainings. We have not held one of these
since early 2020 but have started to receive inquiries about when they
would return. To help with our decision making, we have put together a
survey to help shape a potential in-person training in the USA in the
Fall. If you have interest in attending this course, or if would like
to suggest alternative options, then please fill out the survey here:
https://www.memoryanalysis.net/training-2022-survey
The survey will close next Friday on April 29th.
We would like to note that our self-paced, online training will remain
in place even when in-person trainings resume.
https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t…
Please let us know if you have any questions or concerns.
Also, our mailing lists were having issues so we needed to resend this
message. We apologize if you receive it multiple times.
Thanks,
The Volatility Team
Hello All,
We are writing to gauge interest in our team resuming in-person
Malware and Memory Forensics trainings. We have not held one of these
since early 2020 but have started to receive inquiries about when they
would return. To help with our decision making, we have put together a
survey to help shape a potential in-person training in the USA in the
Fall. If you have interest in attending this course, or if would like
to suggest alternative options, then please fill out the survey here:
https://www.memoryanalysis.net/training-2022-survey
The survey will close next Friday on April 29th.
We would like to note that our self-paced, online training will remain
in place even when in-person trainings resume.
https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t…
Please let us know if you have any questions or concerns.
Thanks,
The Volatility Team
The Call for Papers for the 2022 DFRWS USA conference is open!
Since 2005, DFRWS has been one of the main venues for publishing
cutting edge research and techniques related to memory forensics.
It is also a great venue to publish a peer-reviewed paper in an
academic setting that understands the value of memory forensics and
malware analysis.
If you are interested in submitting, then please see this year's CFP:
https://dfrws.org/dfrws-usa-2022-call-for-papers-is-open/
Thanks,
Andrew
We (the Volatility team) are often asked about what the memory forensics R&D process looks like, and how the abuse of an API by malware or a new code injection technique can be successfully uncovered by a Volatility plugin.
To illustrate this process, we just published a blog post that takes you from analyzing a potent target - the Skeleton Key attack of Mimikatz - through developing a new Volatility 3 plugin that can automatically detect it:
https://volatility-labs.blogspot.com/2021/10/memory-forensics-r-illustrated…
Feedback and comments are greatly appreciated.
We hope you enjoy the post!
We are very excited to announce that our malware and memory forensics training course is now available online!
Full information can be found here:
https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t…
This course deeply covers all aspects of memory analysis and ensures that you are ready to take on modern threats.
If you have any questions then please let us know.
- The Volatility Team
We just posted a new writeup on a common analysis task required when investigating real world systems - deciphering hooks placed by AV/EDR vs those placed by malware
The post can be found here:
https://volatility-labs.blogspot.com/2020/05/when-anti-virus-engines-look-l…
Please let us know if you have any questions or comments, and we hope you enjoy the read!
At a recent Volexity Cyber Security Session, Steven Adair gave a presentation on how OceanLotus lures and targets its victims, including malware, fake news websites and organizations, and fake social media campaigns. If you want to see what real nation-state level targeting looks like then check out his talk:
https://www.volexity.com/company/resources/digital-surveillance-and-cyberes…
Windows 10 brought about significant changes in how file system and memory analysis must be performed.
I explore all of these changes in a recorded talk at the last Volexity CyberSecurity Session:
https://www.volexity.com/company/resources/windows-10-dfir-challenges-andre…
There is no signup required to watch or any other marketing nonsense, just the video and the accompanying slides.
Feedback and questions are welcome, and I hope you enjoy!
We at Volexity are looking for a Malware Reverse Engineer to join our team. The ideal candidate will have several years of experience in analyzing real-world malware and attacker toolsets as well as be familiar with the wider threat-intel and DFIR landscapes.
The job description can be found on our website:
https://www.volexity.com/company/careers/malware-reverse-engineer/
Volexity was founded by leading experts in the threat intelligence realm as well as several of the core Volatility developers. This includes Michael Ligh and myself. Our work centers on providing products, services, and training related to memory analysis, incident response, and threat intel. Our main client focus is highly targeted organizations across private industry, government, and NGOs.
Highlights of several of our efforts are on our blog, such as the recent Exchange vulnerability:
https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-e…
Digital targeting of China's minority Uyghur population:
https://www.volexity.com/blog/2019/09/02/digital-crackdown-large-scale-surv…
And attack campaigns related to the 2016 United States election:
https://www.volexity.com/blog/2016/11/09/powerduke-post-election-spear-phis…
If this type of work interests you, then please submit your information on the career page linked above. Please do NOT reply to this email with your resume/application.
We wanted to remind everyone that we are now about two months away from our first public west coast training in several years. This is the timeframe where we start to get many requests so if you want a guaranteed spot then please reach out to us ASAP.
We will be in San Diego the week of March 9th for five days of Malware and Memory Forensics training led by the Volatility Team.
Full information can be found here:
https://volatility-labs.blogspot.com/2019/10/volatility-malware-and-memory-…
If you can’t join us in San Diego then we will also be hosting 3 other public trainings this year:
- April 20-24, Herndon, VA
- September 21-25, Amsterdam, NL
- October 12-16, Herndon, VA
And if you missed some of our last emails, we recently announced the Volatility 3 Public Beta:
https://volatility-labs.blogspot.com/2019/10/announcing-volatility-3-public…
As well as the results of the 2019 Volatility Plugin and Analysis Contests:
https://volatility-labs.blogspot.com/2019/11/results-from-2019-volatility-c…
Please reach out to us if you have any questions, and we look forward to meeting many new students and Volatility users this year!
Two weeks ago, at OSDFCon, we presented the first beta release of Volatility 3, and we are now happy to announce this release officially!
Volatility 3 is a complete rewrite of the framework and enables many new types of analysis.
The first full release is slated for next summer, and we are hoping to inspire many community members to join us in developing, testing, and documenting the framework from now until then.
Full details of the beta release, as well as ongoing and future work, can be found on our blog post:
https://volatility-labs.blogspot.com/2019/10/announcing-volatility-3-public…
Please let us know if you have any questions or comments. You can send those here or on our new Slack server: https://www.volatilityfoundation.org/slack
— The Volatility Team
We are very excited to announce our public training lineup for 2020!
For the first time since 2016, we will be headed to the west coast - San Diego in March!
We will also be running courses in Herndon in April and October and in Europe in September.
Full information on the course, including locations, dates, and how to register can be found on our blog post:
https://volatility-labs.blogspot.com/2019/10/volatility-malware-and-memory-…
We looking forward to meeting many new students this year!
— The Volatility Team
Volatility Contributors,
Many of you may have noticed that in a couple of weeks we will be giving a
talk at OSDFCon titled “Volatility 3 Public Beta: The Insider’s Preview”.
This presentation will be the first public introduction and pre-release of
Volatility 3. A major motivation for this talk was to inspire and engage
those members of the community who want to help us get Volatility 3 ready
for its official launch!
Getting to this initial milestone, while supporting users of the current
stable version, has only been possible because of our amazing community!
We are grateful for the contributions and for your patience over the last
couple of years. As a show of appreciation, Volexity is hosting a special
event on the evening of October 15th for the contributors of the
Volatility Project. If you have contributed to the project at some point
over the last 12 years and are attending OSDFCon or happen to be in the
Northern Virginia area on the evening of October 15, please send me a note
off list. Our goal is to get an initial head count by Tuesday, October
1st.
We look forward to hearing from you!
AAron Walters
The Volatility Foundation
We are very excited to announce the speaker lineup for BSidesNOLA 2019!
This year we will have 15 speakers across 3 tracks.
The topics covered span digital forensics, malware analysis, threat hunting, penetration testing, and more.
Full information on each talk and presenter can be found at:
www.bsidesnola.com
You will also find registration, venue, and sponsorship information there as well.
Please register early, if possible, as it greatly helps us in the planning of the event.
We will be announcing the keynote speaker next week so be sure to look for that!
We hope to see you all on October 26th!
If you are going to be in the Reston, VA area on Sept 25th, then you should consider coming out to our meet up.
I will be presenting my recent talk from BSides Las Vegas, “Windows 10 DFIR Challenges”, and Steven Adair will be giving his RSA talk on “Digital Surveillance and Cyberespionage at Scale”.
Not to mention, many of the Volatility developers will also be hanging out.
It would be great to catch up.
Full information can be found here:
https://www.meetup.com/Volexity-Cyber-Sessions/events/264350470/
Thanks,
Andrew
We are very happy to announce that Security BSidesNOLA 2019 will take place on Saturday, October 26th!
This will be our 7th year, and we are hoping to again break our attendance record.
We have switched venues to a beautiful hotel inside the French Quarter that we believe will allow for our best event yet.
Registration and the CFP are both now open.
Full details can be found at http://www.bsidesnola.org.
We are also actively looking for sponsors. If you or your company are interested, then please email bsidesnola(a)gmail.com for a sponsorship packet.
We are looking forward to seeing you all in October!
— The BSidesNOLA Team
We wanted to send a quick reminder that our final public training offerings for 2019 are rapidly approaching.
The first will be in London during the week of September 9-13th and the second will be in Herndon during the week of October 14-18th.
Please contact us ASAP if you wish to attend either of these classes.
Full information can be found here:
https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t…
- The Volatility Team
If you are interested in learning more about Volatility 3 and getting
access to the first public pre-release, please vote for the Volatility
Development Team’s OSDFCon submission (#26. Volatility 3 Public Beta: The
Insider’s Preview). Voting ends 6/26/2019.
https://www.surveymonkey.com/r/osdfconvoting2019
OSDFCON SUBMISSION DETAILS
Volatility 3 Public Beta: The Insider’s Preview
Since its initial public release over a decade ago, Volatility has
attracted one of the largest and most active communities of users and
developers in the digital forensics industry. As a result of those
contributions, it has become the world’s most advanced and widely used
memory forensics platform. In the digital forensics research community,
Volatility has served as the foundation of a thriving ecosystem that
continues to facilitate the rapid transition of cutting-edge technologies
into the hands of digital investigators across the globe.
During the same period, the industry has continued to evolve the way that
operating systems are developed, deployed, and maintained. Similarly, the
skillsets of memory analysts and their preferred work flows have changed
to meet a world with increasingly large volumes of complex data. To
address these challenges, the Volatility development team has been
actively architecting and developing an entirely new version of the
framework, while simultaneously supporting users of the current stable
version.
This presentation will be the first public introduction and pre-release of
Volatility 3. It will highlight how this new framework compares to
previous versions of Volatility and other Volatility-based tools. The
discussion will also highlight many new features and describe our new
contributor focused license. Finally, we will discuss ways the community
can help contribute to the official launch of Volatility 3!
Thanks,
AAron Walters
The Volatility Foundation
The CFP deadline is tomorrow for the 10th Annual Open Source Digital
Forensics Conference (OSDFCon). The conference will be held on Oct 16,
2019.
There are openings for:
* 10-minute short talks
* 35-minute in-person talks
* 35-minute remote talks
* 3-hour hands on workshops
https://www.osdfcon.org/2019-event/2019-call-for-presentations/
Please submit your ideas about open source tools you've developed, used, or
want to exist. The event is 1-day long with 400+ attendees. It's the
biggest open source digital forensics event and the biggest DFIR event in
the Metro DC region.
All you need to submit is an abstract and then we'll crowd source the
agenda.
thanks,
brian
We wanted to send a reminder that our next Malware and Memory Forensics training offering will be in Reston in April. We are about 8 weeks away now and already have a number of seats filled. Our courses in the Reston/Herndon area generally sell out early so please contact us ASAP if you wish to attend.
Full information can be found here:
https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t…
We are looking forward to meeting many of you there!
We are excited to announce our public Malware and Memory Forensics training offerings for 2019!
We will be headed back to Herndon in the Spring and to Herndon and London in the Fall.
Full details of the training, including a list of newly updated material, can be found on our blog post:
https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t…
We deeply appreciate your continued support for Volatility and our trainings, and we are excited for another great year of open source memory forensics research and development.
-- The Volatility Team
Since there seems to be a renewed interest in LiME and it's format, I think
it's time that we extend the format to include the storage of optional
metadata. Anything that can be collected at acquisition time saves the
need for scanning and other possibly more complex processes during
analysis. Formats like AFF4 are great, but are too complex to implement in
the kernel.
I'd like to crowdsource opinions on how the LiME format should be
extended. When contributing thoughts please keep the following in mind.
- Changes to the format should not break existing parsers
- To minimize the number of future changes, the enhancements should be
as flexible as possible. For example, I've heard rumors that the LiME
format is being used in acquisition tools that target more than just Linux,
so I'd prefer a generic key/value store for metadata rather than any
hardcoded solution.
- Whatever we collect during acquisition time (at least in LiME) must be
easily accessible from a kernel module
What are your thoughts? What metadata should be collected? Obvious
answers that come to mind are DTB, kernel virtual base address, and KASLR
slide, but I'm sure there are more.
We wanted to send a quick note that we will have a sponsor table tomorrow at OSDFCON. Please come by and see us during the day and also during the conference social at night.
If you are a previous training course alumni and/or a past Volatility contributor then please stop by as we will have some special edition swag for you:
https://twitter.com/volatility/status/1052210342577795073
We will also be raffling a free seat for one of our 2019 trainings offerings:
https://twitter.com/volatility/status/1050769125080006658
We are looking forward to seeing many of you tomorrow!
We wanted to send a reminder as the deadline for both the Volatility Analysis Contest AND the Volatility Plugin Contest is approaching:
https://volatility-labs.blogspot.com/2018/05/the-6th-annual-volatility-plug…
The Plugin contest gives you the opportunity to showcase your research and development skills.
The Analysis Contest lets you showcase your memory forensics skills against malware and real-world IR situations.
Both contests have a number of prizes and a bunch of swag ready for the winners.
We hope to see many great submissions, and we look forward to reviewing them all!
Thanks,
The Volatility Team
Hi list,
Apologies for the cross-post.
Has anyone created a Volatility profile for Solaris or AIX that they would
be willing to share?
I am also searching for a way/tool to image RAM from Solaris and AIX
operating systems. If anyone has any experience in this area please get it
touch.
Thanks,
Brent Muir
As members of the Volatility mailing list, you know that memory
acquisition has proven to be one of the most important and precarious
aspects of digital investigations. Over the years, you have seen the
Volatility team spend a lot of time troubleshooting issues that were
ultimately caused by failed or corrupted acquisition attempts. You have
also seen our colleague, George M. Garner, lead spirited debates about the
reliability of proposed acquisition tools and techniques. With George’s
untimely passing last summer, the industry not only lost one of the most
robust Window’s acquisition tools, but it also lost an industry thought
leader who held the forensics community to a higher standard.
Unfortunately, many investigators still blindly trust free and commercial
acquisition tools without understanding the associated risks and
limitations. While these tools may be readily accessible, many are
unsupported or have been effectively abandoned by their original
developers who have moved on to pursue other projects. As an example,
Google’s GRR project recently disabled their memory forensics capabilities
because it was introducing instabilities, and it wasn’t being actively
maintained. A recent empirical study also showed that most open source or
commercial Windows memory acquisition tools either failed to collect or
crashed systems with modern security features enabled. We can also share
countless stories of investigators and law enforcement officers returning
to their labs only to discover that their memory acquisitions had failed.
There is a growing need for a reliable and actively supported memory
acquisition capability across Windows, Linux, and macOS.
If you follow us on twitter (@volatility) or have taken our training
classes within the last couple of years, you have heard about Volexity’s
Surge Collect. Surge Collect provides a reliable and commercially
supported collection capability with flexible storage options. Surge
Collect can also be easily integrated with Tanium, Carbon Black, and other
enterprise software agents. It is currently in use by many of the largest
federal and local law enforcement agencies around the world. Surge
Collect is also actively used by leading incident response firms,
technology companies, telecommunication providers, universities, Fortune
companies, and branches of the military.
If you are looking for a commercially supported acquisition solution with
dedicated development and support teams for Windows, Linux, and macOS, I
recommend you check out Volexity’s Surge Collect. Hopefully, this will
FINALLY give investigators a reliable and flexible acquisition capability
they can depend on and allow the Volatility team to focus more of our time
on developing exciting new memory analysis capabilities!
Thanks,
AAron Walters
Original author of Volatility
Founder of The Volatility Foundation
The next stop for our training course is Amsterdam in September. This will be our only public offering in Europe in 2018.
Historically our courses have sold out around a month in advance, so please contact us ASAP if you wish to attend.
For our US-based students, we will be back in Herndon in October.
Full information on both offerings can be found here:
https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t…
We look forward to meeting many new Volatility users at these events!
We are excited to announce that the 2018 Volatility Plugin Contest and the inaugural Volatility Analysis Contest are now accepting submissions until October 1, 2018. Winners of each contest will receive over $2,500 in cash prizes and the highly coveted Volatility swag (t-shirts, stickers, etc.)!
Full details can be found on our blog post:
https://volatility-labs.blogspot.com/2018/05/the-6th-annual-volatility-plug…
Please let us know if you have any questions, and good luck to all!
I've found several repositories of Yara rules for scanning fie systems,
but so far, none written for scanning memory. Does anyone know of (or
have) a Yara rule collection for memory images?
Thanks!
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
We are very excited to announce that the speaker lineup for BSidesNOLA 2018 is out!
We have some of the best speakers in the industry in order to cover a variety of topics in digital forensics, incident response,
malware analysis, and more.
The full lineup can be found here:
www.bsidesnola.com <http://www.bsidesnola.com/>
Please register ahead of time if you wish to attend ($15), and please spread the word to your coworkers and friends.
— The BSidesNOLA Team
To all concerned,
A coworker and I have authored an ingestion tool for Splunk called
Ta-Volatility, https://splunkbase.splunk.com/app/3919/, that takes json
formatted unified_outputs from volatility. As it stands right now, it can
handle over 160 plugins across windows, linux and mac, and we're adding
more every day. We are adding unified outputs to the standard plugins that
do not have them, github PR #501
<https://github.com/volatilityfoundation/volatility/pull/501>. The app
will support the latest version of volatility (volatilityfoundation or
mutedmouse's fork, https://github.com/mutedmouse/ta-volatility) The app's
setup page describes the required folder structure. The source by default
is "volatility" and the index is main by default, although you can set this
by adding index=<yourindex> in the inputs.conf file.
Below is a sample sankey visualization from an analyzed windows 10 system's
ingested pslist plugin output.
Enjoy and please let us know if there is anything you would like added
(aside from charts and dashboards - those are coming 😀 ).
V/r,
Chris
We are excited to announce our full list of public trainings for 2018!
There will be three offerings this year, including two in Herndon (Spring and Fall) and one in Amsterdam in September.
Full information, including updates to the course for the new year, can be found on our blog post:
https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t… <https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t…>
Our classes tend to sell out early so please contact us as soon as you have interest in a particular offering.
We look forward to meeting many new students this year!
— The Volatility Team
We are pleased to announce that registration and the Call for Papers for BSidesNOLA 2018 are now open!
Full information can be found at: http://www.bsidesnola.com
This will be our 6th year, and we are expecting continued growth in attendance - our goal is to eclipse 250 attendees this year.
We have also changed venues to the world famous Roosevelt Hotel, which is only a 1 minute walk from the French Quarter.
We hope to see everyone at the event, and we are looking forward to many great talk submissions.
If you would like to help spread the event on Twitter, then please RT this announcement:
https://twitter.com/BSidesNOLA/status/956545409589108737
Finally, we are also now seeking sponsors. If your company is interested then please email bsidesnola [AT] gmail.com or reply privately to this email.
Thanks,
The BSidesNOLA Team
We are excited to announce that the results of the 2017 Volatility Plugin Contest are in:
https://volatility-labs.blogspot.com/2017/11/results-from-5th-annual-2017-v…
We had many novel submissions this year across a wide variety of operating systems, malware detection strategies, and userland application artifacts.
Thanks to everyone who submitted and contributed new capabilities to open source memory forensics!
Thanks,
The Volatility Team
We just published a blog post detailing the infrastructure, initial
infection strategies, and payloads of the resurgent OceanLotus threat group:
https://www.volexity.com/blog/2017/11/06/oceanlotus-blossoms-mass-digital-s…
A follow up post detailing the phishing activity and malware
infrastructure is coming soon.
Comments welcome!
--
Thanks,
Andrew (@attrc)
Hi guys,
I'm trying to recover a php script from a suspected system. The file was
stored in a tmpfs filesystem and i cannot recover it. In the php process
(running from cli) i can see references to the script but can't find the
code.
The suspected system in running Debian 8.9: Linux version 3.16.0-4-amd64
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5
(2017-09-19).
I've tried to use linux_tempfs to recover /dev/shm from memory but got some
errors with volatility with no success:
# ~/bin/vol26 --plugins=profiles --profile=LinuxDebian89x64 -d -f
memory.dump linux_tmpfs -S 4 -D dump/
[...]
WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for
dereferencing name as String WARNING : volatility.debug : NoneObject as
string: Invalid offset 0 for dereferencing name as String WARNING :
volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing
name as String WARNING : volatility.debug : NoneObject as string: Invalid
offset 0 for dereferencing name as String WARNING : volatility.debug :
NoneObject as string: Invalid offset 0 for dereferencing name as String
The php process has pid 1234, using volatility linux_dump_map on that
process I see the following strings in dumped file
task.1234.0x7f003ddf3000.vma:
/dev/shm/script.php(1) : eval()'d code0x7f003ddf303f
/dev/shm/script.php(1) : eval()'d code0x7f003ddf8e2e
/dev/shm/script.php(1) : eval()'d code0x7f003ddf952a
/dev/shm/script.php(1) : eval()'d code0x7f003ddfa588
/dev/shm/script.php(1) : eval()'d code0x7f003ddfa7f3
I'm stuck now trying to recover the php eval'd code, any ideas?
Thanks
Valter
We are excited to announce that two of our public trainings for 2018
have now been scheduled!
The first will be in April in Herndon, VA:
https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-…
The second will be in Herndon in October:
https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-…
We are also in the process of scheduling public trainings in Australia
for Q1 2018 and Europe for Q3. We will send out an update when these are
confirmed, but please contact us if you would like to be placed on the
notification list for either course.
To see some of the recent updates to the course, be sure to check out
our blog post:
https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren…
Also, we are continuing to have many repeat students - for which we are
very grateful! If you are a previous student and wish to attend again,
then please inquire with us about the repeat-student discount.
Finally, if you will be around during OSDFCON in a few weeks then let
us know if you would like to meet up as most of the team will be in town.
-- The Volatility Team
Hello vol-users!
I'm working on a forensics case where I have multiple memory scrapes with
strange volatility output. This has down some rabbit holes and I'm at the
point where signs are pointing to anti-forensics. This has led me to dig
into how pool tag scanning works and I've found several articles
referencing a apparently still yet unreleased (mentioned in 2014, and 2016)
Volatility plugin called TCPScan which uses an alternative method (which
uses methods that are not detailed).
You can find references to the plugin here:
https://scudette.blogspot.com/2014/02/anti-forensics-and-
memory-analysis.html
https://findingbad.blogspot.com/2016/09/forensic-analysis-
of-anti-forensic.html
Does anyone have access to or can anyone put me in touch with anyone who
has access to this plugin? Or can anyone talk to the methods that it uses
to scan for connections?
Thanks,
Nate Subra
Hi all,
Hoping somebody can provide some comments re ELF files in memory.
My ultimate question is: How can I find the .bss section of an ELF
file in memory?
But I have a more specific one. Consider the following output from a
Volatility plugin I wrote which aims to parse the segments:
Volatility Foundation Volatility Framework 2.6
# First we grab the proc_maps which are mapped to the process of
interest (in this case, Xorg)...
# This mimics the linux_proc_maps plugin
Parsing proc maps...
/usr/lib/xorg/Xorg r-x start=0x55d4ddda4000 end=0x55d4ddfe0000 length=0x23c000
/usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000
/usr/lib/xorg/Xorg rw- start=0x55d4de1e2000 end=0x55d4de1ef000 length=0xd000
# Not listing anonymous maps for now.
# The we parse the ELF header which is at the start of the first
proc_map shown above
Parsing elf_ehdr...
Container({'e_flags': 0, 'e_shoff': 2401000, 'e_phoff': 64, 'e_shnum':
30, 'e_entry': 270368, 'e_version': 'EV_CURRENT', 'e_machine':
'EM_X86_64', 'e_phnum': 9, 'e_shentsize': 64, 'e_ident':
Container({'EI_DATA': 'ELFDATA2LSB', 'EI_OSABI': 'ELFOSABI_SYSV',
'EI_VERSION': 'EV_CURRENT', 'EI_CLASS': 'ELFCLASS64', 'EI_ABIVERSION':
0, 'EI_MAG': [127, 69, 76, 70]}), 'e_type': 'ET_DYN', 'e_phentsize':
56, 'e_shstrndx': 29, 'e_ehsize': 64})
# This looks sane, so let's go to e_phoff (64) and read the program header
Parsing segments...
0x55d4ddda4040 Segment<p_memsz=0x1f8, p_flags=0x5, p_offset=0x40,
p_type=PT_PHDR, p_align=0x8, p_paddr=0x40, p_filesz=0x1f8,
p_vaddr=0x40>
0x55d4ddda4078 Segment<p_memsz=0x1c, p_flags=0x4, p_offset=0x238,
p_type=PT_INTERP, p_align=0x1, p_paddr=0x238, p_filesz=0x1c,
p_vaddr=0x238>
0x55d4ddda40b0 Segment<p_memsz=0x23bdd4, p_flags=0x5, p_offset=0x0,
p_type=PT_LOAD, p_align=0x200000, p_paddr=0x0, p_filesz=0x23bdd4,
p_vaddr=0x0>
0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6,
p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408,
p_filesz=0xdd98, p_vaddr=0x43c408>
0x55d4ddda4120 Segment<p_memsz=0x2e0, p_flags=0x6, p_offset=0x23dc78,
p_type=PT_DYNAMIC, p_align=0x8, p_paddr=0x43dc78, p_filesz=0x2e0,
p_vaddr=0x43dc78>
0x55d4ddda4158 Segment<p_memsz=0x44, p_flags=0x4, p_offset=0x254,
p_type=PT_NOTE, p_align=0x4, p_paddr=0x254, p_filesz=0x44,
p_vaddr=0x254>
0x55d4ddda4190 Segment<p_memsz=0x9904, p_flags=0x4, p_offset=0x1f2b50,
p_type=PT_GNU_EH_FRAME, p_align=0x4, p_paddr=0x1f2b50,
p_filesz=0x9904, p_vaddr=0x1f2b50>
0x55d4ddda41c8 Segment<p_memsz=0x0, p_flags=0x6, p_offset=0x0,
p_type=PT_GNU_STACK, p_align=0x10, p_paddr=0x0, p_filesz=0x0,
p_vaddr=0x0>
0x55d4ddda4200 Segment<p_memsz=0x1bf8, p_flags=0x4, p_offset=0x23c408,
p_type=PT_GNU_RELRO, p_align=0x1, p_paddr=0x43c408, p_filesz=0x1bf8,
p_vaddr=0x43c408>
# These segments look sane, and in fact the values match what I see
from `readelf --segments` against the Xorg binary on disk.
# I ignore the first PT_LOAD segment because the p_flags and p_vaddr
tell me the .bss isn't going to be in there. (As does the output from
`readelf --segments`)
# And I try to read the data pointed to by the p_vaddr of the second PT_LOAD
Testing PT_LOAD at 0x55d4ddda40e8.
# Let's re-print the segment to remind ourselves:
0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6,
p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408,
p_filesz=0xdd98, p_vaddr=0x43c408>
# So starting at the base address (0x55d4ddda4000) + p_vaddr
(0x43c408) =0x55d4de1e0408, I should be able to read p_memsz (0x1f8f0)
bytes, right?
# Wrong... I can only read 0xebf7 (60,407) bytes before volatility
reports an error
Failed to read offset 0xebf8==60408
Notably, the starting offset, 0x55d4de1e0408, is in:
/usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000
but of course is bigger than the size of the proc_map.
I really do appreciate any comments you might have as to where my
understanding is lacking!
Adam
Hello!
I posted this question already, but i could not find it on the
archive, so I am trying it again.
I am doing some research on RAM extraction and analysis in Android (6
Marshmallow). I succeeded in compiling my own Kernel with enabled
CONFIG_MODULE_LOAD and installing it onto my Nexus 5X. Creating the
LiME module to extract the RAM was also successful, I could get a
memory dump of the device on my computer. In a Hex-editor, I can see
content of the RAM (boot pictures, text messages,…).
I also asked this question at stackoverflow, it is better readable
there due to formatting reasons:
https://stackoverflow.com/questions/44807171/keyerror-int128-unsigned-in-dw…
But now I have problems using Volatility 2.6. My steps so far:
• get volatility
git clone https://github.com/volatilityfoundation/volatility.git
cd volatility/tools/linux
• Adjust Makefile (I also had to uncomment #define RADIX_TREE_MAX_TAGS
2 in the module.o, otherwise I got an error during make)
obj-m += module.o
KDIR := /root/compile/msm/
CCPATH := /root/compile/msm/aarch64-linux-android-4.9/bin
-include version.mk
all: dwarf
dwarf: module.c
$(MAKE) ARCH=arm64 CROSS_COMPILE=$(CCPATH)/aarch64-linux-android-
-C $(KDIR) \
CONFIG_DEBUG_INFO=y M=$(PWD) modules
dwarfdump -di module.ko > module.dwarf
make
• Combine System.map (created during kernel compilation) and
module.dwarf (created during make) and copy the .zip it into the
overlays directory
zip Nexus5X.zip module.dwarf ../../../System.map
cp Nexus5X.zip ../../volatility/plugins/overlays/linux/
• run volatility
python vol.py --profile=LinuxNexus5Xx64 -f
/root/Documents/nexus-ram.dump linux_pslist
The parameters are all correct - the profile exists, the file also and
linux_pslist is a valid command. But even with other commands such as
linux_cpuinfo, I get the following error:
root@kali:~/compile/msm/volatility-2.6# python vol.py
--profile=LinuxNexus5Xx64 -f /root/Documents/nexus-ram.dump linux_pslist
Volatility Foundation Volatility Framework 2.6
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/linux/common.py",
line 64, in execute
commands.Command.execute(self, *args, **kwargs)
File "/root/compile/msm/volatility-2.6/volatility/commands.py",
line 116, in execute
if not self.is_valid_profile(profs[self._config.PROFILE]()):
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 216, in __init__
obj.Profile.__init__(self, *args, **kwargs)
File "/root/compile/msm/volatility-2.6/volatility/obj.py", line
862, in __init__
self.reset()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 227, in reset
self.load_vtypes()
File
"/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py",
line 264, in load_vtypes
vtypesvar = dwarf.DWARFParser(dwarfdata).finalize()
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
71, in __init__
self.feed_line(line)
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
162, in feed_line
self.process_statement(**parsed) #pylint: disable-msg=W0142
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
225, in process_statement
self.id_to_name[statement_id] = [self.base_type_name(data)]
File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line
125, in base_type_name
return self.tp2vol[data['DW_AT_name'].strip('"')]
KeyError: '__int128 unsigned'
Can you help me figuring out the error and how to solve it? Or any
related work which did RAM extraction from Android > 5.0 ?
The string "__int128 unsigned" is inside the module.dwarf two times. I
posted the Module.dwarf here as it would be too big for this mail (it
needs some time until the web page appears):
http://chopapp.com/#b27ludkk
Thanks in advance!
Hi all,
This is a "what don't I know?" question...
I have a very simple C program:
#include <gtk/gtk.h>
#include <stdio.h>
int main(int argc, char **argv)
{
GtkTextBuffer *buffer;
buffer = gtk_text_buffer_new(NULL);
gtk_text_buffer_set_text(buffer, "adam1adam2adam3", 15);
printf("buffer: %p\n", buffer);
getchar();
return 0;
}
Then the following to try and locate the strings in memory:
------------------------------------------------------------
$ strings --radix=d LinuxMint-17.3-Mate-x64-61951b91.vmem | fgrep
adam1adam2adam3 >/tmp/s
------------------------------------------------------------
$ cat /tmp/s
195393652 adam1adam2adam3
204175816 adam1adam2adam3
851998836 adam1adam2adam3
------------------------------------------------------------
$ ~/src/volatility/vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem
--profile LinuxMint173x64 linux_strings -s /tmp/s
Volatility Foundation Volatility Framework 2.6
195393652 [kernel:88000ba57874] adam1adam2adam3
204175816 [kernel:88000c2b79c8] adam1adam2adam3
851998836 [kernel:880032c87874] adam1adam2adam3
------------------------------------------------------------
Why on earth would the string only be located in Kernel space??
I've been digging into Gtk for quite some time now to try and solve this
and think I understand that in Gtk, text is stored as GtkTextLineSegments.
The memory for a GtkTextLineSegment is allocated via g_slice_alloc and the
actual text copied to the allocated space via an ordinary memcpy (See:
https://github.com/GNOME/gtk/blob/406db15066f121c2b9910691f92e58
41b30e0311/gtk/gtktextsegment.c#L190-L210)
I've proved the text really is here by editing the text in the VMEM file in
a hex editor and then resuming the VM - sure enough the text is updated to
reflect the changes.
I could just about understand the text being in Kernel space AND user space
because perhaps its sent to the X server or something, but it appears to
ONLY be in Kernel space.
What don't I know??
Many thanks,
Adam
Hi,
using the current version from GitHub (-> git pull) I can’t analyze Virtualbox memory dump files anymore. I’m using Virtualbox v5.1.22 (current release).
I’m using Cuckoo Sandbox (v2.0 and cuckoo-modified) and vol.py doesn’t recognize the memory.dmp files anymore. Neither within Cuckoo processing nor manually from the command line. My Virtual machine contains Windows 7 SP1 x86 Pro and the memory dumps could be analyzed successfully in the past. This happens when using all Win7 profiles.
See some vol.py messages below. Taken from an older memory.dmp file which could be successfully analyzed by vol.py with cuckoo-modified when it was created in 2016. If needed I can share the memory dump (2,1 GB, zipped ~640 MB).
Thomas
1)
vol.py -f memory.dmp --profile=Win7SP1x86 pslist
Volatility Foundation Volatility Framework 2.6
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
Win10AMD64PagedMemory: No base Address Space
WindowsAMD64PagedMemory: No base Address Space
LinuxAMD64PagedMemory: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment with VBCORE
VMWareAddressSpace: Invalid VMware signature: 0x464c457f
QemuCoreDumpElf: ELF error: did not find any PT_NOTE segment with CORE
WindowsCrashDumpSpace32: Header signature invalid
Win10AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
WindowsAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
LinuxAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
OSXPmemELF: No PT_LOAD segments found
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Profile does not have valid Address Space check
2)
vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 (Instantiated with Win7SP1x86)
AS Layer1 : FileAddressSpace (/daten/cuckoo-modified/storage/analyses/44/memory.dmp)
PAE type : No PAE
DTB : 0x185000L
KDBG : 0x293c504L
Number of Processors : 0
Image Type (Service Pack) : 0
KUSER_SHARED_DATA : 0xffdf0000L
3)
vol.py -f memory.dmp kdbgscan
Volatility Foundation Volatility Framework 2.6
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86_23418
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP0x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
4)
vol.py -f memory.dmp --profile=Win7SP1x86 vboxinfo
Volatility Foundation Volatility Framework 2.6
ERROR : volatility.debug : Memory Image could not be identified as ['VirtualBoxCoreDumpElf64']
5)
file memory.dmp
memory.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)
As we enter summer, we wanted to let everyone know that we only have two
remaining public training classes for 2017. Full details of these
classes, including all the newly updated material, can be found on our
recent blog post:
https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren…
Our classes have been selling out a good bit in advance so please let us
know ASAP if you wish to attend.
We are very excited to announce that our 5th annual Volatility Plugin
Contest is now live, and we are accepting submissions until October 1st,
2017. We are giving away over $2,000 in prizes and swag - so get coding!!!
Full details on our blog post:
https://volatility-labs.blogspot.com/2017/04/the-5th-annual-2017-volatility…
Please let us know if you have any questions and good luck to all!
Hey All,
We will be in the Reston/Herndon area next week for a training, and
wanted to see if any Volatility users were interested in a meetup.
We will be hanging out in Herndon on Wednesday (the 5th) late
afternoon/night and Reston on Thursday. These will be informal meetups
at a bar or similar type place.
If you are interested in the specifics for a particular night then let
us know and we can pass them along information.
Hope to see some of you around!
--
Thanks,
Andrew (@attrc)
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
This release improves support for Windows 10 and adds support for
Windows Server 2016, Mac OS Sierra 10.12, and Linux with KASLR kernels.
A lot of bug fixes went into this release as well as performance
enhancements (especially related to page table parsing and virtual
address space scanning).
Here's the TL;DR:
The release page, with standalone binary downloads for 64-bit Windows,
Linux, and Mac:
http://www.volatilityfoundation.org/26
Information on new Volatility 2.6 profiles:
https://github.com/volatilityfoundation/volatility/wiki/2.6-Win-Profiles
Python source code packages:
https://github.com/volatilityfoundation/volatility/releases
We look forward to working with you all in the new year!
The Volatility Team
Hello All,
We are excited to announce that the date for BSidesNOLA 2017 is set and
that the CFP is live.
BSidesNOLA will take place on April 1st, 2017 in downtown New Orleans.
This will be our 5th year running, and we are expecting another sell out
crowd. If you have never been before, it is a day full of infosec talks,
networking, and contests along with plenty of local New Orleans food and
drinks - all for $15.
If you plan to submit to the CFP then please take your time in crafting
your submission. We don't review the submissions until after the
deadline ends so there is no benefit to submitting early. We also have a
highly competitive CFP, and every year we have to reject 15 or more
talks. Give us your best so this doesn't happen to you!
Full information, including venue, how to register ($15 for all day),
and the CFP details can be found at:
http://www.securitybsides.com/w/page/113990746/BSidesNOLA
If you have any questions then please contact us at bsidesnola [@@@]
gmail.com.
Thanks,
The BSidesNOLA Team
Our next public training in April in Reston is on pace to sell out
pretty quickly. Please contact us ASAP if you wish to attend:
http://www.memoryanalysis.net/memory-forensics-training
Also, our private training slots for next year are filling fast as well.
These are a great way to raise the skillset of your entire team up at
once. We also have several add-ons that previous private training
clients chose and found great value in - such as customization of
content as well us building labs around memory samples from your own
previous internal investigations (NDAs expected for this). Please
contact us off list if interested in a private training.
--
Thanks,
Andrew (@attrc)
We are excited to announce that the results of the 2016 Volatility
Plugin Contest are in:
https://volatility-labs.blogspot.com/2016/12/results-from-2016-volatility-p…
We received a record number of submissions this year, and we are looking
forward to seeing these plugins be adopted in the field.
Be sure to congratulate the winners on Twitter and LinkedIn and when you
see them at conferences and trainings.
We also wanted to thank Airbnb again for their donation of $999 to the
prize pool. It is great to see organizations supporting open source
research in the digital forensics and incident response fields.
Thanks,
The Volatility Team
In case you don’t follow us on twitter (@volatility), we wanted to send a
quick reminder that the 2016 Volatility Plugin Contest will be ending on
October 1, 2016. This is your chance to win over $3200 in cash and prizes!
http://www.volatilityfoundation.org/2016
A special thanks to Airbnb (@airbnb) and Volexity (@volexity) for
sponsoring this year’s contest!
Thanks,
AAron Walters
The Volatility Foundation
Hi all,
Because the universe hates me, I've been given an E01 of a RAM dump (from
Win7SP1x64) and I have to use Windows to run Volatility.
I have p99 of tAoMF in front of me.
I tried the "Mount in FTK Imager and point to Z:\unallocated space" thing,
but pslist showed only 1 entry which looked very corrupt.
I don't have access to EnCase to mount it from there.
So I'd like to use libewf. But can I even use it on Windows?? If I compile
the library, how do I tell Volatility about the libewf.dll?
Basically, how do I use Volatility with libewf on Windows?
Thank you,
Adam
Bridgey,
I haven't been in this EWF situation for memory yet but I'd probably try
imagecopy first:
vol.exe -f image.e01 --profile=<yourprofile> -O image.raw
If that didn't work, I'd use Tom's #2 and load the .E01 in FTK imager and
image that mounted volume.
If that didn't work I'd try load the evidence into encase 7.x - right click
on the evidence --> evidence --> device --> share --> Mount as Emulated
Disk and then use FTK imager to image that mounted volume to .raw
JG
On Tue, Aug 16, 2016 at 11:03 AM, Tom Yarrish <tom(a)yarrish.com> wrote:
> IIRC volatility should be able to handle an E01 file natively now (unless
> that's a *nix only thing). But another option would be either 1) Arsenal
> Image Mounter (which works much better than FTK, EnCase, etc IMO) or 2) Use
> FTK to covert the E01 image to a RAW image file and then just run that
> through volatility.
>
> Thanks,
> Tom
>
>
> PGP Key ID - B32585D0
>
> On Tue, Aug 16, 2016 at 2:39 PM, Bridgey theGeek <bridgeythegeek(a)gmail.com
> > wrote:
>
>> Hi all,
>>
>> Because the universe hates me, I've been given an E01 of a RAM dump (from
>> Win7SP1x64) and I have to use Windows to run Volatility.
>>
>> I have p99 of tAoMF in front of me.
>>
>> I tried the "Mount in FTK Imager and point to Z:\unallocated space"
>> thing, but pslist showed only 1 entry which looked very corrupt.
>>
>> I don't have access to EnCase to mount it from there.
>>
>> So I'd like to use libewf. But can I even use it on Windows?? If I
>> compile the library, how do I tell Volatility about the libewf.dll?
>>
>>
>> Basically, how do I use Volatility with libewf on Windows?
>>
>> Thank you,
>> Adam
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
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
On Donnerstag, 23. Juni 2016, 13:49:58 wrote Klaus Möller:
> Hi,
>
> I've a problem with an image from a Microsoft Surface tablet.
> I've verified that the OS is Windows 10 Pro 64Bit,
After a few more hours, here's the "output" from netscan:
$ vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem
--kdbg=0xf8033ca31a14 netscan
Volatility Foundation Volatility Framework 2.5
Offset(P) Proto Local Address Foreign Address State Pid
Owner Created
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
0xe0008817c4c0 UDPv4 0.0.0.0:0 *:* 980
?j? 2016-06-15 08:13:14 CEST+0200
0xe0008817c4c0 UDPv6 :::0 *:* 980
?j? 2016-06-15 08:13:14 CEST+0200
0xe00088d67c90 UDPv6 ::1:16528 *:* 1168
??q? 2016-06-15 14:19:21 CEST+0200
0xe00089d8f330 UDPv4 0.0.0.0:0 *:* 980
?j? 2016-06-16 12:32:29 CEST+0200
0xe00089d8f330 UDPv6 :::0 *:* 980
?j? 2016-06-16 12:32:29 CEST+0200
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
same problems here: the command takes hours to complete and the output
strings are garbled.
Best regards,
Klaus Möller, DFN-CERT
--
Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team)
Phone: +49 40 808077-555, Fax: +49 40 808077-556
DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de
Hi,
I've a problem with an image from a Microsoft Surface tablet.
I've verified that the OS is Windows 10 Pro 64Bit, and "imageinfo" confirms
that:
Suggested Profile(s) : Win10x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/srv/evidence/memdump.mem)
PAE type : No PAE
DTB : 0x1ab000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2016-06-16 12:52:11 CEST+0200
Image local date and time : 2016-06-16 12:52:11 +0200
However, all comands take hours to complete, imageinfo took about an hour,
kdbgscan was closer to 10 hours (I let it run through the night).
$ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence//memdump.mem kdbgscan
Volatility Foundation Volatility Framework 2.5
**************************************************
Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) : 0xf8033cb38a60
Offset (P) : 0x268d38a60
KdCopyDataBlock (V) : 0xf8033c9965d0
Block encoded : Yes
Wait never : 0x1d323b0baac9580
Wait always : 0xf0e3591e003a646a
KDBG owner tag check : False
Profile suggestion (KDBGHeader): Win10x64
Service Pack (CmNtCSDVersion) : -
Build string (NtBuildLab) : -
PsActiveProcessHead : 0xb276fbddbd63c845 (0 processes)
PsLoadedModuleList : 0xf249d7ddbd63c805 (0 modules)
KernelBase : 0xfe52e3ddbd63c885 (Matches MZ: False)
Major (OptionalHeader) : -
Minor (OptionalHeader) : -
**************************************************
Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) : 0xf8033cb38a60
Offset (P) : 0x268d38a60
KdCopyDataBlock (V) : 0xf8033ca31a14
Block encoded : Yes
Wait never : 0xf0e3591e003a646a
Wait always : 0x1d323b0baac9580
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win10x64
Version64 : 0xf8033cb38dc0 (Major: 15, Minor: 10586)
Service Pack (CmNtCSDVersion) : 0
Build string (NtBuildLab) : 10586.306.amd64fre.th2_release_s
PsActiveProcessHead : 0xfffff8033cb4d160 (91 processes)
PsLoadedModuleList : 0xfffff8033cb52cd0 (202 modules)
KernelBase : 0xfffff8033c874000 (Matches MZ: True)
Major (OptionalHeader) : 10
Minor (OptionalHeader) : 0
KPCR : 0xfffff8033cb91000 (CPU 0)
KPCR : 0xffffd001cc54a000 (CPU 1)
KPCR : 0xffffd001cc5c9000 (CPU 2)
KPCR : 0xffffd001cc648000 (CPU 3)
I think the later part is the right one, but when I run pslist with the value
for
KdCopyDataBlock, I get something like this, using other options/values simply
gives
empty output.
$ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem
--kdbg=0xf8033ca31a14 psscan
Volatility Foundation Volatility Framework 2.5
Offset(P) Name PID PPID PDB Time
created Time exited
------------------ ---------------- ------ ------ ------------------
------------------------------ ------------------------------
0x0000c001edeb7bce 42...2 23...8 0x6b76ffffffd80000
5914-08-12 10:20:02 CET+0100
0x0000c001eed47b6e o 42...2 57...7 0x2b30fffffff00000
9767-04-28 16:32:54 CET+0100
0x0000e00087491680 4 0 0x00000000001ab000
2016-06-06 18:03:31 CEST+0200
0x0000e0008765d7c0 0?? 3600 3524 0x000000017ccc3000 2016-06-06
18:03:44 CEST+0200
0x0000e000876657c0 ??e? 3608 3600 0x000000017ccf8000
2016-06-06 18:03:44 CEST+0200
0x0000e00087f73080 7200 4812 0x00000001cbc8e000
2016-06-07 23:07:21 CEST+0200
0x0000e000897597c0 ??s? 372 4 0x0000000250219000
2016-06-06 18:03:31 CEST+0200
0x0000e0008a27f7c0 6012 5208 0x0000000200ad7000
2016-06-06 18:13:22 CEST+0200
0x0000e0008a2c45c0 ?;? 6088 700 0x00000001f4eeb000
2016-06-06 18:10:22 CEST+0200
0x0000e0008a3067c0 4260 6572 0x00000001edf60000
2016-06-06 23:16:37 CEST+0200
0x0000e0008cbc67c0 P??? 2564 700 0x0000000173299000
2016-06-06 18:03:41 CEST+0200
0x0000e0008cf997c0 ??|? 2780 700 0x000000013a0e0000
2016-06-06 18:03:41 CEST+0200
I can't say wether the addresses and pids (the first two ones look bad) are
correct, but the process name field surely does not look good. Any ideas?
Best regards,
Klaus Möller, DFN-CERT
--
Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team)
Phone: +49 40 808077-555, Fax: +49 40 808077-556
DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de
Has anyone encountered DEST records in index.dat files? I looked at the
source code and docs of open source tools that parse index.dat/MSHIST
files and I don't see any reference to DEST records...
I ask as I was digging around a memory sample that I generated to look
at IE records, and saw this:
0x04517313 a7 c2 cf 11 bf f4 44 45 53 54 00 00 16 00 08 00
......DEST......
0x04517323 66 63 03 00 00 00 da 00 68 63 28 00 01 00 82 00
fc......hc(.....
0x04517333 00 00 c2 c5 41 6e 03 c7 d1 01 c2 cd 17 57 2d c7
....An.......W-.
0x04517343 d1 01 01 00 00 00 00 00 00 00 00 00 00 00 3a 00
..............:.
0x04517353 32 00 30 00 31 00 36 00 30 00 36 00 31 00 35 00
2.0.1.6.0.6.1.5.
0x04517363 32 00 30 00 31 00 36 00 30 00 36 00 31 00 36 00
2.0.1.6.0.6.1.6.
0x04517373 3a 00 20 00 56 00 61 00 41 00 41 00 41 00 40 00
:...S.a.l.t.r.@.
0x04517383 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 77 00
h.t.t.p.:././.w.
0x04517393 77 00 77 00 2e 00 6e 00 62 00 63 00 2e 00 63 00
w.w...n.b.c...c.
0x045173a3 6f 00 6d 00 2f 00 00 00 4e 00 42 00 43 00 20 00
o.m./...N.B.C...
0x045173b3 54 00 56 00 20 00 4e 00 65 00 74 00 77 00 6f 00
T.V...N.e.t.w.o.
0x045173c3 72 00 6b 00 20 00 2d 00 20 00 53 00 68 00 6f 00
r.k...-...S.h.o.
0x045173d3 77 00 73 00 2c 00 20 00 45 00 70 00 69 00 73 00
w.s.,...E.p.i.s.
0x045173e3 6f 00 64 00 65 00 73 00 2c 00 20 00 53 00 63 00
o.d.e.s.,...S.c.
0x045173f3 68 00 65 00 64 00 75 00 6c 00 65 00 00 00 00 00
h.e.d.u.l.e.....
The strings are in unicode, but you can see the DEST marker followed by
binary timestamps, followed by the traditional hist format of
DATEDATE:machine@URL ....
If DEST records don't appear on disk, then maybe they are a memory-only
data structure? I would like to convert carving for these into a
Volatility plugin, but I want to make sure I understand any prior work
on them first.
--
Thanks,
Andrew (@attrc)
I'm analyzing a Vista SP2 system that was compromised via a Remote Desktop
login (somehow the culprit had access to correct login credentials).
Security.evtx only contains information about this single illegal login
(and there is no indications that the eventlog was cleared)
The strange thing is that carving though memory for network packets (using
CapLoader) I find packets showing RDP traffic to additional IPs, not only
the one found in Security.evtx
Any help in trying to put some contex around these additional IPs found in
memory, using volatility, or traditional disk forensics is highly
appreciated!
(The machine had only been running for about a week before the intrusion,
so anything found in memory should in theory be backed up by information in
eventlog)
Jarle Thorsen
All,
I have a hibernation file from a Windows 7 machine that when I run hibinfo against it, I get the output below. Has anyone seen this before? I'm using the latest version of volatility from github, as of today. The command I used was vol.py -f hiberfil.sys --profile==Win7SP1x86 hibinfo. Other plugins fail as well. Converting the file to raw format using imagecopy and using other plugins didn't work either.
Thanks for the help!Kevin
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VMWareMetaAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64BitMap: Header signature invalid
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VMWareMetaAddressSpace: VMware metadata file is not available
VirtualBoxCoreDumpElf64: ELF Header signature invalid
VMWareAddressSpace: Invalid VMware signature: 0x0
QemuCoreDumpElf: ELF Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
IA32PagedMemoryPae: No valid DTB found
IA32PagedMemory: No valid DTB found
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: No valid DTB found
Hi,
I've recently used linux_netstat with different Linux memory images
and noticed that the destination port for established outgoing connections
is always shown as "0".
The source port for incoming connections is shown correctly.
Any way to fix this and get the correct destination port for outgoing
connections?
Thanks,
Thomas
Hello list,
I’m trying to use Volatility on an OSX memory dump. I was unable to download mac memory reader as the site is offline. I’ve used osxpmem from recall.
The commands I used to perform the dump were:
sudo kextutil MacPmem.kext
sudo ./osxpmem --format elf -o ./ram.dump
I then moved ram.dump into my volatility directory
To check my downloaded profile is included I’ve run the command
./volatility_2.5_mac --plugins=./mac —imageinfo
and then I ran
./volatility_2.5_mac --plugins=./mac --profile=MacElCapitan_10_11_4_15E65x64 -f ../ram.dump mac_pslist
and got
Volatility Foundation Volatility Framework 2.5
Offset Name Pid Uid Gid PGID Bits DTB Start Time
------------------ -------------------- -------- -------- -------- -------- ------------ ------------------ ----------
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
QemuCoreDumpElf: No base Address Space
VMWareAddressSpace: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF Header signature invalid
QemuCoreDumpElf: ELF Header signature invalid
VMWareAddressSpace: Invalid VMware signature: 0x4034b50
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Failed valid Address Space check
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
Apparently my OSXPmemElf signature is invalid. What can I do to dump memory with a valid signature? Or does my problem lie elsewhere?
Regards,
Rob
Dear list,
Is it possible to extend the built in profiles for the standalone mac version of volatility with extra ones?
I’ve downloaded the linux and mac profiles from github and tried putting them in a subdirectory as with the source code version on Linux i.e. volatility_2.5.mac.standalone/volatility/plugins/overlays/mac
However they don’t show up in the profile list when I run volatility_2.5.mac.standalone —info
Regards,
Rob
Hi,
thanks to your suggestion, I make great progresses but I still not get
the target: localize the master password of an android app.
I run the app and set a password as "mypassword2016". With yarascan I
was able to see that this password is store in memory in unicode (I run
"python vol.py linux_yarascan -W -A -Y "mypassword2016"").
Then, I would like to see if there some "signature" that helps me to
locate the password. So I decide to use volshell and see around the
passwod, but I have no luck (see the attachment, where I showed that
there is before and after of the two occurrences of the password
"mypassword2016").
Of course I've repeated the same workflow for other two passwords, but I
did not get anything that helps me to figure out if there is way to
locate where the password is store.
Do you have any suggestion, please?
Thanks in advance,
Massimo
Hi Laurent,
Not necessarily. You're assuming that everything once in memory stays in
memory...which isn't the case. If you have an IP and you pass it to
ws2_32.connect() and then free or overwrite the memory containing the
IP...the connection stays up and running just fine. It could also be
swapped to the page file.
MHL
On 5/17/16 5:14 AM, Laurent LF wrote:
> Thanks Michael,
>
> What I don't understand is that yarascan on the "IP to integer" value on
> the full mem dump gives a result in the svchost process only and not
> anywhere else. I should have at least two occurences, one in the svchost
> process and one other in the System process, right ?
>
> Thanks,
>
> Laurent
>
>
> On 2016-05-12 23:18, Michael Ligh wrote:
>> I can't speak to whether its "normal" but its not surprising. The System
>> process is the default home for threads that start in kernel mode. Thus
>> any kernel driver using the winsock APIs for networking will make it
>> appear as if the System process is responsible. Now combine that with a
>> DLL that's implementing a particular service (and running inside
>> svchost.exe process) who wants to communicate with its corresponding
>> driver...it could send an IOCTL and say "go connect to this x.x.x.x IP
>> address." In that case you could easily end up with a reference to the
>> IP in svchost.exe.
>>
>> MHL
>>
>> On 5/10/16 2:34 PM, Laurent LF wrote:
>>> Hi,
>>>
>>> I have progressed a bit on this.
>>> I was first limiting my IP addresses searches on the process returned by
>>> "netscan", which was "System" with pid=4. As I was convinced I should
>>> have got some results within "System", I supposed I was wrong with the
>>> syntax or the IP representation and made several other tries (IP as
>>> string, little indian ordering as suggested by Andrew,...), still with
>>> pid=4. I also made a few tries on the whole memory dump but with no
>>> luck. It looks like I was doing something wrong because today I made
>>> some tries again on full memory dump and finally found the IPs (Big
>>> Indian ordering) in ... a "svchost" process.
>>>
>>> I still need to go deeper in the analysis (as far as my little knowledge
>>> will allow me to go :-) ) but is it normal behavior to have netscan
>>> reporting some connections linked with "System" when IP search with
>>> yarascan on given IPs returns only a "svchost" process ?
>>> Also, I was expecting to find references to the IPs in several memory
>>> locations but only one occurence in this case, in the given svchost
>>> process...
>>>
>>> Thanks,
>>> Laurent
>>>
>>>
>>> Le 10/05/2016 17:14, Michael Ligh a écrit :
>>>> Also note yarascan only accesses available pages. The IP could be in a
>>>> page that's swapped to the pagefile or in a page that's been
>>>> freed/deallocated and is no longer referenced from any page
>>>> table(s). In
>>>> the later case, you could find it by extracting strings from the memory
>>>> dump or by scanning with yara signatures across the memory dump file
>>>> (i.e. not caring about virtual address spaces)...however if you find it
>>>> in either of two methods, there's no way to trace the page back to its
>>>> owner.
>>>>
>>>> MHL
>>>>
>>>> On 5/10/16 7:56 AM, Andrew Case wrote:
>>>>> Hey,
>>>>>
>>>>> Did you try the IP hex value in reverse? It is likely that the IP
>>>>> address is stored as little endian in memory.
>>>>>
>>>>> Thanks,
>>>>> Andrew (@attrc)
>>>>>
>>>>> On 05/10/2016 05:15 AM, tech(a)nisteo.fr wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am starting to play with Volatility (2.5) and I am currently
>>>>>> working
>>>>>> on a Win2008R2 image (memory dump with winpmem). I would like to
>>>>>> understand what is causing some network connections initiated by the
>>>>>> "System" process.
>>>>>> netscan shows those connections and I would like to be able to find
>>>>>> references to the IP addresses in the memory dump. I have tried
>>>>>> "yarascan -Y" plugin with the IP string, with the IP to integer value
>>>>>> (converted to Hex) but no luck finding IPs that , however, I can
>>>>>> see in
>>>>>> the netscan result...
>>>>>> Either I am wrong with the yarascan syntax or there is something I
>>>>>> don't
>>>>>> know regarding how Win2008 stores IP...
>>>>>>
>>>>>> Any hints ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Laurent
>>>>>> _______________________________________________
>>>>>> Vol-users mailing list
>>>>>> Vol-users(a)volatilityfoundation.org
>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>> _______________________________________________
>>>>> Vol-users mailing list
>>>>> Vol-users(a)volatilityfoundation.org
>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>
>>>
>>>
>
>
Hi all,
Wondering if anybody's come across this scenario...
I want to read an address from my_offset:
my_address = obj.Object('address', offset=my_offset, vm=task_vm)
However, for Wow64 the address should only be 4 bytes, but because we're
analysing with a 64-bit profile, 'address' will cause 8 bytes to be parsed
(right?).
Do I need to replace it with something like:
if profile_is_32bit or process_is_wow64:
my_address = obj.Object('unsigned long', offset=my_offset, vm=task_vm)
else:
my_address = obj.Object('unsigned long long', offset=my_offset,
vm=task_vm)
Or do I need to start manually unpacking structs?
Thanks,
Adam
