https://github.com/Srinivas11789/PcapXray/blob/master/README.md

https://www.hackingarticles.in/forensics-investigation-of-ping-command/

https://pentesttools.net/srum-dump-a-forensics-tool-to-convert-the-data-in-the-windows-srum/

https://github.com/alphaSeclab/awesome-forensics/blob/master/Readme_en.md

https://www.enisa.europa.eu/topics/trainings-for-cybersecurity-specialists/online-training-material/technical-operational#network_forensics

https://aboutdfir.com/

https://www.slideshare.net/NicolasCollery/let-me-pick-your-brain-remote-forensics-in-hardened-environments?trk=v-feed

"Como resultado, as tecnologias que facilitam a busca e análise rápidas de evidências em sistemas 'vivos' começaram a florescer na última década e formaram a base do que é conhecido como mercado de detecção e resposta de endpoint", disse ele. Os produtos EDR normalmente oferecem alguma combinação dos seguintes recursos:

Gravação contínua de telemetria de pontos-chave - como processos executados ou conexões de rede - para fornecer um cronograma prontamente disponível de atividade em um sistema. Isso é análogo a um gravador de caixa preta em um avião, ele disse. O acesso a essa telemetria alivia a necessidade de reconstruir os eventos históricos através das fontes nativas de evidência de um sistema. Pode ser menos útil nos casos em que a tecnologia de investigação é implantada em um ambiente depois que uma violação já ocorreu.

Análise e pesquisa das fontes forenses de evidência de um sistema - isto é, o que é preservado pelo sistema operacional por conta própria durante as operações normais do sistema. Isso inclui a capacidade de executar buscas rápidas e direcionadas para arquivos, processos, entradas de log, artefatos na memória e outras evidências em sistemas em escala. Ele complementa o uso de um gravador de eventos contínuo e pode ser usado para ampliar o escopo de uma investigação e encontrar leads adicionais que de outra forma não poderiam ter sido preservados.

Alerta e detecção. Os produtos podem coletar e analisar proativamente as fontes de dados citadas acima e compará-las com inteligência estruturada de ameaças (como Indicadores de Compromisso), regras ou outras heurísticas destinadas a detectar atividades maliciosas.

Coleta de evidências de hospedeiros individuais. À medida que os investigadores identificam sistemas que necessitam de uma inspecção mais aprofundada, podem conduzir colecções e análises de dados de "mergulho profundo" através da totalidade da telemetria histórica de um sistema sujeito (se presente e gravado), ficheiros no disco e na memória. A maioria das organizações preferem realizar análises remotas e triagem de sistemas ao vivo, em vez de imagens forenses abrangentes sempre que possível, disse ele.
http://www.itworld.com/article/3192348/security/computer-forensics-follows-the-bread-crumbs-left-by-perpetrators.html

OWASP iOSForensic is a python tool to help in forensics analysis on iOS.
It get files, logs, extract sqlite3 databases and uncompress .plist files in xml.

OWASP iOSForensic provides:

• Application's files
• Conversion of .plist files in XML
• Extract all databases
• Conversion of binary cookies
• Application's logs
• A List of all packages
• Extraction multiple packages

Options

• -h --help : show help message
• -a --about : show informations
• -v --verbose : verbose mode
• -i --ip : local ip address of the iOS terminal
• -p --port : ssh port of the iOS terminal (default 22)
• -P --password : root password of the iOS terminal (default alpine)

./iOSForensic.py -i 192.168.1.10 [OPTIONS] APP_NAME.app INCOMPLETE_APP_NAME APP_NAME2_WITHOUT_DOT_APP
./iOSForensic.py -i 192.168.1.10 -p 1337 -P pwd MyApp.app angry MyApp2

Disk tools and data capture

• the kernel extensions
• the system agents and daemons
• the third party's agents and daemons
• the old and deprecated system and third party's startup items
• the users' agents
• the users' downloaded files
• the installed applications

• the users' quarantined files
• the users' Safari history, downloads, topsites, HTML5 databases and localstore
• the users' Firefox cookies, downloads, formhistory, permissions, places and signons
• the users' Chrome history and archives history, cookies, login data, top sites, web data, HTML5 databases and local storage
• the users' social and email accounts
• the WiFi access points the audited system has been connected to (and tries to geolocate them)

• Team Cymru's MHR
• VirusTotal
• Malware.lu
• your own local database

• /var/log (-> /private/var/log)
• /Library/logs
• the user's ~/Library/logs

• rendered as a simple txt log file (so you can cat-pipe-grep in them… or just grep)
• rendered as a HTML log file
• sent to a Syslog server

NetSleuth identifies and fingerprints network devices by silent network monitoring or by processing data from PCAP files.
NetSleuth is an opensource network forensics and analysis tool, designed for triage in incident response situations. It can identify and fingerprint network hosts and devices from pcap files captured from Ethernet or WiFi data (from tools like Kismet).

It also includes a live mode, silently identifying hosts and devices without needing to send any packets or put the network adapters into promiscuous mode ("silent portscanning").

NetSleuth is a free network monitoring, cyber security and network forensics analysis (NFAT) tool that provides the following features:
An easy realtime overview of what devices and what people are connected to any WiFi or Ethernet network.
Free. The tool can be downloaded for free, and the source code is available under the GPL.
Simple and cost effective. No requirement for hardware or reconfiguration of networks.
“Silent portscanning” and undetectable network monitoring on WiFi and wired networks.
Automatic identification of a vast array of device types, including smartphones, tablets, gaming consoles, printers, routers, desktops and more.
Offline analysis of pcap files, from tools like Kismet or tcpdump, to aid in intrusion response and network forensics.

Download NetSleuth -
Requirements
Perform a full installation of Wireshark on your machine.
Specifically the tshark program (this is installed by default).

Unhide is a forensic tool to find hidden processes and TCP/UDP ports by rootkits / LKMs
or by another hiding technique.

Unhide (unhide-linux or unhide-posix)

Features - 
Detecting hidden processes. Implements six main techniques
1- Compare /proc vs /bin/ps output
2- Compare info gathered from /bin/ps with info gathered by walking thru the procfs. ONLY for unhide-linux version
3- Compare info gathered from /bin/ps with info gathered from syscalls (syscall scanning).
4- Full PIDs space ocupation (PIDs bruteforcing). ONLY for unhide-linux version
5- Compare /bin/ps output vs /proc, procfs walking and syscall. ONLY for unhide-linux version
   Reverse search, verify that all thread seen by ps are also seen in the kernel.
6- Quick compare /proc, procfs walking and syscall vs /bin/ps output. ONLY for unhide-linux version
  It's about 20 times faster than tests 1+2+3 but maybe give more false positives.

Unhide_rb

It's a back port in C language of the ruby unhide.rb
As the original unhide.rb, it is roughly equivalent to "unhide-linux quick reverse" :
- it makes three tests less (kill, opendir and chdir),
- it only run /bin/ps once at start and once for the double check,
- also, its tests are less accurate (e.g.. testing return value instead of errno),
- processes are only identified by their exe link (unhide-linux also use cmdline and
  "sleeping kernel process" name),
- there's little protection against failures (failed fopen or popen by example),
- there's no logging capability.
It is very quick, about 80 times quicker than "unhide-linux quick reverse"

Unhide-TCP

Identify TCP/UDP ports that are listening but not listed in sbin/ss or /bin/netstat.
It use two methods: 
- brute force of all TCP/UDP ports availables and compare with SS/netstat output.
- probe of all TCP/UDP ports not reported by netstat.

Files

unhide-linux.c      -- Hidden processes, for Linux >= 2.6
unhide-linux.h

unhide-tcp.c        -- Hidden TCP/UDP Ports
unhide-tcp-fast.c
unhide-tcp.h

unhide-output.c     -- Common routines of unhide tools
unhide-output.h

unhide_rb.c         -- C port of unhide.rb (a very light version of unhide-linux in ruby)

unhide-posix.c      -- Hidden processes, for generic Unix systems (*BSD, Solaris, linux 2.2 / 2.4)
                       It doesn't implement PIDs brute forcing check yet. Needs more testing
                       Warning : This version is somewhat outdated and may generate false positive.
                                 Prefer unhide-linux.c if you can use it.

changelog           -- As the name implied log of the change to unhide
COPYING             -- License file, GNU GPL V3
LEEME.txt           -- Spanish version of this file
LISEZ-MOI.TXT       -- French version of this file
NEWS                -- Release notes
README.txt          -- This file
sanity.sh           -- unhide-linux testsuite file
TODO                -- Evolutions to do (any volunteers ?)
man/unhide.8        -- English man page of unhide
man/unhide-tcp.8    -- English man page of unhide-tcp
man/fr/unhide.8     -- French man page of unhide
man/fr/unhide-tcp.8 -- French man page of unhide-tcp

Compiling
If you ARE using a Linux kernel >= 2.6
      gcc -Wall -O2 --static -pthread unhide-linux*.c unhide-output.c -o unhide-linux
      gcc -Wall -O2 --static unhide_rb.c -o unhide_rb
      gcc -Wall -O2 --static unhide-tcp.c unhide-tcp-fast.c unhide-output.c -o unhide-tcp
      ln -s unhide unhide-linux

Else (Linux < 2.6, *BSD, Solaris and other Unice)
      gcc --static unhide-posix.c -o unhide-posix
      ln -s unhide unhide-posix

Using
You MUST be root to use unhide-linux and unhide-tcp.

Examples:
 # ./unhide-linux  -vo quick reverse
 # ./unhide-linux  -vom procall sys
 # ./unhide_rb

 # ./unhide-tcp  -flov
 # ./unhide-tcp  -flovs

Download -
unhide-20121229.tgz
Download WinUnhide.zip (38.5 kB)


Note that it doesn't work well for kernel processes/threads nor for daemons.
http://sourceforge.net/projects/unhide/
http://www.unhide-forensics.info

Screenshot-

I'll be presenting on "Extending RegRipper" at Brian Carrier's Open Source Digital Forensics Conference on 14 June, along with Cory Altheide, and I wanted to provide a bit of background with regards to what my presentation will cover...

In '98-'99, I was working for Trident Data Systems, Inc., (TDS) conducting vulnerability assessments for organizations.  One of the things we did as part of this work was run ISS’s Internet Scanner (now owned by IBM) against the infrastructure; either a full, broad-brush scan or just very specific segments, depending upon the needs and wants of the organization.  I became very interested in how the scanner worked, and began to note differences in how the scanner would report its findings based on the level of access we had to the systems within the infrastructure.  Something else I noticed was that many of the checks that were scanned were a result of the ISS X-Force vulnerability discovery team.  In short, a couple of very smart folks would discover a vulnerability, add a means of scanning for that vulnerability via the Internet Scanner framework, and roll it out to thousands of customers.  Within fairly short order, this check can be rolled out to hundreds or thousands of analysts, none of whom have any prior knowledge of the vulnerability, nor have had to invest the time to investigate it.  This became even more clear as I started to create an open-source (albeit proprietary) scanner to replace the use of Internet Scanner, due in large part to significant issues with inaccurate checks, and the need to adapt the output.  I could create a check to be run, and give it to an analyst going on-site, and they wouldn't need to have any prior knowledge of the issue, nor would they have to invest time in discovery and analysis, but they could run the check and easily review and understand the results.

Other aspects of information security also benefit from the use of scanners.  Penetration testing and web application assessments benefit from scanners that include frameworks for providing new and updated checks to be run, and many of the analysts running the scanners have no prior knowledge of the checks that are being run.  Nessus (from Tenable) is a very good example of this sort of scanner; the plugins run by the scanner are text-based, providing instructions for the scanner.  These plugins are easy to open and read, and provide a great deal of information regarding how the checks are constructed and run.


Given all of the benefits derived from scanners in other disciplines within information security, it just stands to reason that digital forensic analysis would also benefit from a similar framework.

The forensic scanner is not intended to replace the analyst; rather, it is intended as a framework for documenting and retaining the institutional knowledge of all analysts on the team, and remove the tedium of looking for that "low-hanging fruit" that likely exists in most, if not all, exams.

A number of commercially available forensic analysis applications (EnCase, ProDiscover) have scripting languages and scanner-like functionality; however, in most cases, this functionality is based on proprietary APIs, and in some cases, scripting languages (ProDiscover uses Perl as it's scripting language, but the API for accessing the data is unique to the application). 

A scanner framework is not meant to replace the use of commercial forensic analysis applications; rather, the scanner framework would augment and enhance the use of those applications, by providing an easy and efficient means for educating new analysts, as well as "sweeping up" the "low-hanging fruit", leaving the deeper analysis for the more experienced analysts.

This scanner framework would be based on easily available tools and techniques.  For example, the scanner would be designed to access acquired images mounted read-only via the operating system (Linux mount command) or via freely available applications (Windows - FTK Imager v3.0, ImDisk, vhd/vmdk, etc.); that way, the scanner can make use of currently available APIs (via Perl, Python, etc.) in order to access data within the acquired image, and do so in a "forensically sound manner" (i.e., not making any changes to the original data).

The scanner is not intended to run in isolation; rather, it is intended to be used with other tools (here, here) as part of an overall process.  The purpose of the scanner is to provide a means for retention, efficient deployment, and proliferation of institutional digital forensic knowledge.

Benefits
Some benefits of a forensic scanner framework such as this include, but are not limited to, the following:

1.  Knowledge Retention - None of us knows everything, and we all see new things during examinations.  When an analyst sees or discovers something new, a plugin can be written or updated.  Once this is done, that knowledge exists, regardless of the state of the analyst (she goes on vacation, leaves for another position, etc.).  Enforcing best practice documentation of the plugin ensures that as much knowledge as possible is retained along with the application, providing an excellent educational tool, as well as a ready means for adapting or improving the plugin.

2.  Establish a career progression - When new folks are brought aboard a team, they have to start somewhere.  In most cases, particularly with consulting organizations, skilled/experienced analysts are hired, but as the industry develops, this won't always be the case.  The forensic scanner provides an ancillary framework for developing "home grown" expertise where inexperienced analysts are hired.  Starting the new analysts off in a lab environment and having them begin learning the necessary procedures by acquiring and verifying media puts them in an excellent position to run the scanner.  For example, the analyst either goes on-site and conducts acquisition, or acquires media sent to the lab, and prepares the necessary documentation.  Then, they mount the acquired image and run the scanner, providing the more experienced analyst with the path to the acquired image and the report.

This framework also provides an objective means for personnel assessment; managers can easily track the plugins that are improved or developed by various analysts.

3.  Teamwork - In many environments, development of plugins likely will not occur in a vacuum or in isolation.  Plugins need to be reviewed, and can be improved based on the experience of other analysts.  For example, let's say an analyst runs across a Zeus infection and decides to write a plugin for the artifacts.  When the plugin is reviewed, another analyst mentions that Zeus will load differently based on the permissions of the user upon infection.  The plugin can them be documented and modified to include additional conditions.

New plugins can be introduced and discussed during team meetings or through virtual conferences and collaboration, but regardless of the method, it introduces a very important aspect of forensic analysis...peer review.

4.  Ease of modification - One size does not fit all.  There are times when analysts will not be working with full images, but instead will only have access to selected files from systems.  A properly constructed framework will provide the means necessary for accessing and scanning these limited data sets, as well.  Also, reporting of the scanner can be modified according to the needs of the analyst, or organization.

5.  Flexibility - A scanner framework is not limited to just acquired images.  For example, F-Response provides a means of access to live, remote systems in a manner that is similar to an acquired image (i.e., much of the same API can be used, as with RegRipper), so the framework used to access images can also be used against systems accessed via F-Response.  As the images themselves would be mounted read-only in order to be scanned, Volume Shadow Copies could also be mounted and scanned using the same scanner and same plugins.

Another means of flexibility comes about through the use of "idle" resources.  What I mean by that is that many times, analysts working on-site or actively engaged in analysis may be extremely busy, so running the scanner and providing the output to another, off-site analyst who is not actively engaged frees up the on-site team and provides answers/solutions in a timely and efficient manner.  Or, data can be provided and the off-site analyst can write a plugin based on that data, and that plugin can be run against all other systems/images.  In these instances, entire images do not have to be sent to the off-site analyst, as this takes considerable time and can expose sensitive data.  Instead, only very specific data is sent, making for a much smaller data set (KB as opposed to GB).