17 September 2014

Repost: Three new videos showcasing Volatility 2.4 features

The Volatility team have published three videos showing off new
features in the recently released Volatility 2.4 version. These videos
were originally shown at Black Hat Arsenal this past summer.

The first video shows how to locate and extract rootkit components from
process and kernel memory and then gather context for IDA:

http://www.youtube.com/watch?v=LVJ5mpZZdY4

The second shows how to uncover a number of artifacts of OS X user activity:

http://www.youtube.com/watch?v=1pZkNRdjWHQ

The last shows how to defeat True Crypt no matter how the user
configures the volumes or settings:

http://www.youtube.com/watch?v=A2d2OFGSnKU


13 September 2014

Firefox Forensics


The most prevalent software applications in use today are probably Web browsers. They are used for viewing, retrieving, traversing, and presenting information resources obtained from the Web. Although browsers are complex software applications, they have common functionality regarding their main components. A simplified overview of their high level structure is as follows:
  • User Interface - the entire browser display except for its main window.
  • Browser Engine - takes the marked up content (XML, HTML, etc.) and formatting information (CSS, XSL, etc.) and displays it on the monitor’s screen.
  • Rendering Engine - responsible for displaying the requested content.
  • Networking - used for network calls (HTTP, etc.).
  • UI Backend - used for drawing widgets such as windows and combo boxes.
  • JavaScript Interpreter - software which interprets/executes JavaScript.
  • Data Storage - a persistence layer consisting of the data that the browser stores on the computer hard drive.
When a URL is entered into the address bar, the browser communicates with a name server to resolve it into an IP address. This allows the browser to connect to the appropriate Web server using HTTP. Once connected, HTTP commands then direct the Web server to retrieve and transmit data back to the browser. The browser reads the HTML and displays the information resources (HTML document, a .pdf file, an image, a video, etc.) which were identified by a Unified Resource Identifier (URI). The browser then saves the Web documents in its cache using Web caching technology. Caching of Web objects reduces the bandwidth usage and server load and allows the browser to retrieve the same Web page much faster when it is visited at a later time. It also allows recently viewed Web pages to be viewed offline and copied although some of the features such as Flash animations and “real time” objects found on the Web page may not function.

Web browser is an essential application program for accessing the Internet. If a suspect uses the Internet as a source of information, the evidence related to the crime would be saved in the log file of the Web browser. Therefore, the forensics examiner need to investigate the Web browser’s log file. However, the impediment of web browser forensics in the future is many of the artifacts of forensics interest probably will continue to change with each release and it will present a difficult technical challenges. 
 
Although the version changes, there remain several constants which facilitate the investigators. Due to the majority of the forensic information pertaining to the different versions of browser which normally resides in two directories which locate in the individual user accounts. 
 
In Firefox, the information reside in the following directories: 
 
Windows XP:
C:\Documents and Settings\[User]\Application Data\Mozilla\ Firefox\Profiles\xxxxxxxx.default\
C:\Documents and Settingd\[user]\Local Settings\Application Data\ Firefox\Profiles\xxxxxxxx.default\Cache\


Windows Vista, Windows 7, and Windows 8:
C:\Users\[User]\AppData]Local\Mozilla\Firefox\Profiles\xxxxxxxx.default\Cache\
C:\Users\[User]\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default\


Linux:
~/.mozilla/firefox/xxxxxx.default/
~/.cache/mozilla/firefox/xxxxxx.default/Cache/

Mac OS X:
~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/
~/Library/Application Support/Mozilla/Extensions
~/Library/Caches/Firefox/Profiles/xxxxxxxx.default/Cache/


Cache Location:

The Firefox cache contains both information about the various cache entries(metadata) and the cached items themselves (data) which can be of immense forensic importance. 
 
Windows Vista 7 and 8:
C:\Users\[User]\AppData\Local\Mozilla\Firefox\Profiles\xxxxxxxx.default\Cache
• C:\Users\[User]\AppData\Local\Mozilla\Firefox\Profiles\xxxxxxxx.default\jumplistCache
• C:\Users\[User]\AppData\Local\Mozilla\Firefox\Profiles\xxxxxxxx.default\OfflineCache
• C:\Users\[User]\AppData\Local\Mozilla\Firefox\Profiles\xxxxxxxx.default\startupCache


Windows XP:
C:\Documents and Settings\%USERNAME%\Local Settings\Application Data\Mozilla\Firefox\Profiles\%PROFILE%.default\Cache\
 
Linux:
~/.cache/mozilla/firefox/xxxxxx.default/Cache
~/.cache/mozilla/firefox/xxxxxx.default/OfflineCache
~/.cache/mozilla/firefox/xxxxxx.default/safebrowsing
~/.cache/mozilla/firefox/xxxxxx.default/startupCache
~/.cache/mozilla/firefox/xxxxxx.default/thumbnails

Mac:
~/Library/Caches/Firefox/Profiles/xxxxxxxx.default/Cache/

There are four primary internal files beside the cache directory:
  • _CACHE_001_ : stores small metadata and data entries in 512-byte blocks.
  • _CACHE_002_ :stores medium-sized metadata and data items in 1024-byte blocks.
  • _CACHE_003_ : stores large metadata and data items in 4096-byte blocks.
  • _CACHE_MAP_ : contains the index to both the metadata and the data and links them together.  

Additionally, there may be any number of external directories/files which are used to store very large metadata items or data.

Viewing the Cache:
With the Firefox browser running, entering “about:cache” into the address field and pressing the Enter key on the keyboard will load the “Information about the Cache Service” screen. Information concerning the memory cache device, disk cache device, and offline cache device will be displayed and appear as follows:

 

Both “List Cache Entries” are hyperlinks. Clicking on either one will cause the cached files or objects to be displayed along with their original link location URLs. For instance, clicking on the link under “memory cache device” will display information regarding the key, data size, fetch count, last modified, and expires that is stored in memory. The information is searchable. Clicking on any of the entries will display the “Cache entry information” screen for that entry and provide a wealth of potential forensic information such as:
  • Key - the URL.
  • Fetch count – number of times accessed.
  • Last fetched – yyyy-mm-dd-hh:mm:ss.
  • Last modified – yyyy-mm-dd-hh:mm:ss.
  • Expires – yyyy-mm-dd-hh:mm:ss.
  • Data size – size of the file.
  • File on disk – none.
  • Security - document does not have any security information associated with it.
  • Client – HTTP.
  • Request method – GET (may or may not be present)
  • Response head – HTTP, server information, etc. (may or may not be present).
  • Charset - (may or may not be present).
  • Charset source - (may or may not be present).
Likewise, clicking on the link under “Disk cache device” and clicking on any of its entries will provide similar information. Clicking on one of the key entries should open the URL or provide other pertinent information. Note that the “File on disk” may point to the directory where it is stored on the hard drive!
The free Firefox add-on, CacheViewer, provides a GUI front end instead of having to use “about:cache.” In addition to providing a searching capability for both memory and disk cache files, it includes a sorting functionality to sort the key, size, MIME type, device, and last fetched columns. An additional feature is a preview pane for images and the ability to copy them for later examination. For instance, searching for “.jpg” will provide a list of all the URLs that contain a .jpg and clicking on one of the “key” URLs will display that .jpg image in the preview pane. Right clicking on the key URL will also provide “Open in Browser” and “Save as” functionalities for that .jpg. Alternately, the free standalone utility MozillaCacheView can be used to read the cache folder on a live system or pointed to the location of an external cache. It provides forensic information such as the URL, Content Type, Fetch Count, Last Fetched, Cache Name, Server Name, Server Time, and so forth. The information can be exported to a CSV/Tab-Delimited File or viewed as an HTML Report.
 
The majority of potential forensic information stores the SQLite Relational Database Management System (RDMS). Firefox typically includes a lot of SQLite databases, each of which performs a different function such as storing bookmarks, cookies, places visited, searches, and so forth. The database files are as follows:

1. addons.sqlite
There are six tables in the file. They are addon, sqlite-sequence, developer, schreenshot, compatibility_override and icon. The addon table cointains information such as the name of each add-on, version, creator, creatorURL, descriptions, fullDescriptions, developer comments, eula, homepageURL, supportURL, contributionURL, contributionAmount, averageRating, reviewCount, reviewURL, totalDownloads, weeklyDownloads, dailyUsers, sourceURL, repositoryStatus, size and updateDate. 


2. content-prefs.sqlite
There are three tables in the file, “groups,” “prefs,” and “settings.” A User can set site-specific preferences for browsers and content settings (page style, text zoom, etc.). Those preferences can remain persistent across browsing sessions and page visits. Along with browser history, this is an indicator of intentionally visited sites and not accidental or casual visits. The sites visited are maintained in the “groups” table.

3. cookies.sqlite
.When a user try to remove the cookies sometimes the cookies may and may not all be deleted. The alternative cookies storage location, the persistence and process of cookies can have an effect upon whether a cookie is deleted or not. The moz_cookies is the only tables in the cookies.sqlite. Therefore, data which useful can be found in the “baseDomain,” “host,” “lastAccessed,” and “creationTime” columns.
4. downloads.sqlite
Firefox stores a list of all files downloaded in the “moz_downloads” table which is used to populate the popup download queue. They remain in the table as long as the User does not clear the queue. Valuable forensic information can be found in the table. The names of all the files downloaded, their source, downloaded destination, and the start and end times of the download are all recorded. If the data in the “currBytes” and “maxBytes” columns is the same, that is indicative that the download completed successfully.

5. extensions.sqlite

The file stores data about installed extensions :
 
6. formhistory.sqlite
It contains all the historical data for every form that a user ever filled out while online is maintained in the file. 
7. permissions.sqlite
Permissions.sqlite contains a history of the permissions that are assigned to various sites. The data is stored in the file’s only table, “moz_hosts” and the sites are listed in the “host” column.
8. Places.sqlite
Places.sqlite contains a list of all Web sites visited, bookmarks, and attributes for those sites. Forensically, it is probably the most important file for investigators to examine. A User’s entire Web history, including all bookmarks, their properties, and favorite icons are maintained in the file. This information can be linked to the cookies.sqlite, formhistory.sqlite, and permissions.sqlite files to provide an overall view of a User’s Internet activity. The file contains thirteen tables:
  • moz_anno_attributes
  • moz_annos
  • moz_bookmarks
  • moz_bookmarks_roots
  • moz_favicons
  • moz_historyvisits
  • moz_hosts
  • moz_inputhistory
  • moz_items_annos
  • moz_keywords
  • moz_places
  • sqlite_sequence
  • sqlite_stat1
All bookmarks are stored in the “moz_bookmarks” table. The “title” column contains the name of the bookmark and the “dateAdded” column contains the timestamp information. Bookmarks can be linked to the URLs in the “moz_places” table since the “fk” column in “moz_bookmarks” contains the same values as those in the “id” column in the “moz_places” table.
Each time a User visits a Web page, an entry is recorded in the “moz_historyvisits” table. The date of the visit is recorded in the “history_date” column and how the User arrived at the site is recorded in the “visit_type” column. Values in this column can be very important forensically:
  • 1” the User followed a link.
  • 2” the User typed/allowed the autocomplete feature to complete the URL.
  • 3” indicates that the User clicked on an existing bookmark.
  • 4” an embedded URL.
  • 5” a permanent redirect.
  • 6” a temporary redirect.
URLs are maintained in the “moz_places” table under the “url” column. The “visit_count” column records the number of times each site was visited and the timestamp information for a site is recorded in the “last_visit_date” column. If the User typed the URL in the address bar, a value of “1” is noted in the “typed” column.

9. signons.sqlite
The file contains three tables: moz_deleted_logins, moz_disabledHosts, and moz_logins. The moz_logins table is the repository for all the sites that a User has entered and saved their username and password. The information is usually persistent since many Users do not want to continually reenter their username and password each time they revisit the same site. The URLs are recorded in the hostname column. Although usernames and passwords are encrypted and maintained in the encryptedUsername and encryptedPassword columns respectively, they may be viewable in plain text in Firefox if no Master Password has been set. The table can be imported into an existing Firefox User’s profile on a forensic machine and the username and password possibly viewed by selecting edit → security-> Saved passwords . When the saved passwords dialog box appears, selecting show passwords the selecting Yes to confirm, then it should display the password and username as the following:
 
Time stamp information regarding when the username and password was created, last used, and last changed is stored in the “timeCreated,” “timeLastUsed,” and “timePasswordChanged” columns respectively. The number of times each site was visited is maintained in the “timesUsed” column.
 
 
10. webappsstore.sqlite
The file only contains one table, “webappstore2.” Firefox uses the table for storing its Web storage objects (software methodology/protocols used for storing data in a Web browser). Web storage types consist of local and session storage (somewhat analogous to persistent and session cookies respectively). Data is usually persistent and removing history, cookies, or form information may or may not remove the data.
 11. healthreport.sqlite


Some Caveats 

Much of this discussion and any potential forensic information contained in the Firefox database files are predicated upon the fact that the User did not change certain defaults in Firefox. For instance, Firefox automatically records browsing history. However, a User can browse the Internet and prevent Firefox from storing certain information by selecting the “Start Private Browsing” option from the main drop down menu. For that session, no additional data will be recorded in the history menu, no new passwords will be saved, no downloaded files will be listed in the downloads window, no data from forms filled out on-line will be saved, no cookies will be stored, any files opened in external applications will be cleared from the temporary folder, and no cached files will be saved. Any new bookmarks created, however, will remain. Most of this information would normally be stored in the various database files previously discussed. (Note: selecting this feature does not make a User anonymous. The sites visited and/or the IP provider can still track User activity). Selecting the “Stop Private Browsing” option from the main drop down menu will cause Firefox to begin recording any further browsing activity during that session.
Alternately, a User can permanently prevent Firefox from recording browsing history by selecting “Options” from Firefox’s main drop down menu and selecting the “Privacy” tab. The default is to “Remember history” and options are provided to manually “clear your recent history” and “remove individual cookies.” If the User selects the second option, “Never remember history,” Firefox will no longer record site visits and provides the User with the option to “clear all current history.” Additionally, a User can select a third option, “Use custom settings for history,” and then check “Always use private browsing mode” to prevent Firefox from tracking browsing history.
If the User manually chooses to clear all browsing history, then potentially valuable forensic information may be lost from many of the previously discussed database files. Fortunately for investigators, for convenience purposes, the overwhelming numbers of Users do not select the “Start Private Browsing” or the “Never remember history” options. Nor do they clear their history or cookies. If they did, then they would have to continually reenter their usernames and passwords, refill out on-line forms, and so forth each time they revisited the same site(s).


Source:
http://www.forensicmag.com/
http://www.dfinews.com
http://www.forensicswiki.org/wiki/Mozilla_Firefox 
http://www.symantec.com/connect/articles/web-browser-forensics-part-2
http://kb.mozillazine.org/Profile_folder_-_Firefox
http://kb.mozillazine.org/About_protocol_links
http://www.journals.elsevier.com/digital-investigation

12 September 2014

Dementia : Defeating Windows memory forensics


Mostly, when the analysis forensic or investigators do the seizure of electronic evidence in the crime scene they have to search the live systems then doing triage forensics which help the investigators to find the computer-related crime. One of the triage forensics process is RAM Imaging. The Random Access Memory stores a lot of information of all the process and applications which are running on the system.

Besides RAM imaging, the forensic analysis and investigators also can obtain a lot of data on the live system. They can obtain the content of encrypted files, browser history, open files, recent files, contents searching, network connections, RAM mapping, USB history, password and etc.

Due to the sophisticated computer-related crimes and security measures that grow up, come up the softwares which preclude the investigators and forensics analysis to obtain the computer-related crimes data. One of the sophisticated software which precludes to reveal the data of RAM imaging is dementia-forensics.

Dementia is a proof of concept memory anti-forensic toolkit designed for hiding various artifacts inside the memory dump during memory acquisition on Microsoft Windows operating system.

By exploiting memory acquisition tools and hiding operating system artifacts (eg. processes, threads, etc.) from the analysis application, such as Volatility, Memoryze and others. Because of the flaws in some of the memory acquisition tools, Dementia can also hide operating system objects from the analysis tools completely from the user-mode.

Features:
 
Architectures
    32-bit
    64-bit - note: 64-bit support has not been tested as widely as 32-bit, so bugs should be expected

Operating systems:
Dementia has been tested and known to work on the following operating systems: 

Microsoft Windows XP
        without SP
        SP1
        SP2
        SP3 
Microsoft Windows Vista
        without SP
        SP1
    Microsoft Windows 7
        without SP

Memory acquisition applications


Dementia is able to hide artifacts inside the memory image produced by the following memory acquisition applications:

    Mandiant Memoryze
    Winpmem
    Mantech MDD
    Moonsols Windows Memory Toolkit
    FTK Imager

Dump formats


    Raw dump format
    Crash dump format (as created by Moonsols Win32dd) 

Hiding methods and supported artifacts

  • User-mode hiding method (supports Mandiant Memoryze only)
    • Process hiding
      • Pro allocation deletion
      • _EPROCESS unlinking from the list of active processes
    • Thread hiding
      • Thr allocation deletion
      • _ETHREAD unlinking from the list of active threads
    • Connection hiding
      • _TCP_LISTENER allocation deletion
      • _TCP_ENDPOINT allocation deletion
      • _UDP_ENDPOINT allocation deletion
  • Kernel-mode hiding based on hooks
  • Kernel-mode hiding based on file system mini-filter driver
    • Process hiding
      • Pro allocation deletion
      • _EPROCESS unlinking from the list of active processes
      • _EPROCESS unlinking from the appropriate session list
    • Thread hiding
      • Thr allocation deletion
    • Memory allocations hiding
      • Vad/VadS/VadM allocation deletion
      • Deletion of the entire memory region if it is private for the target process or if it represents process EXE image
      • Deletion of the entire memory region if it is a shared section which is opened exclusively by the target process
        • Deletion of mapped files, if used (Fil allocation deletion)
    • Handle hiding
      • Obtb allocation deletion (process handle table)
      • _HANDLE_TABLE unlinking from the list of handle tables
      • Deletion of handles/objects opened exclusively by the target object
        • _HANDLE_TABLE_ENTRY deletion
        • Object allocation deletion
      • Decrementing handle counters for objects not opened exclusively by the target process
        • _HANDLE_TABLE_ENTRY deletion
      • Removing thread handle from the PspCidTable
      • Removing process handle from the PspCidTable
      • Removing process handle from the csrss.exe handle table
    • File objects hiding
      • Fil allocation deletion
    • Driver hiding
      • MmLd allocation deletion (_LDR_DATA_TABLE_ENTRY)
      • LDR_DATA_TABLE_ENTRY unlinking from the loaded modules list
      • Deletion of driver image in memory
For further details about Dementia, check the 29c3 presentation PDF or video below)


Sources: 
https://code.google.com/p/dementia-forensics/
https://www.youtube.com

 

06 September 2014

AUTOPSY Forensic Browser

AUTOPSY is an essential tools for Linux forensics investigations and can be used to analyze Windows images.

1. Make sure autopsy and sleuthkit have installed. If not yet, let's install it now:
apt-get install autopsy sleuthkit

2. Start the Autopsy.

3. Open browser the input  http://localhost:9999/autopsy.
To Start new case
Click New Case. This will add a new case folder to the system and allow us to begin adding evidence.

4.  Enter the Case Name, Description and Investigators Names


After the case file created, we will see the message as displayed in step 5.

5. Note about the evidence directory is located.
It displays where the evidence is located on the system  and the case name is korupsaun

6.Add a host to the Case.

Click "Add Host" and we will be presented with a screen (above) that allows us to add the host and a description. As it states, the Timezone and skew can be configured. Also, we can add and use a list of known good or known bad hashes. This can be as complex as the NSRL lists or as simple as a hashed list of our own organizations "known good" files. Lists of known rootkits and other Malware can be added as a known bad list.
Where a time skew is known, can can also add this in advance.

7. Note the location of the host.
Next, add the disk image by pressing the Add Image button

8. Add an Image to Analyze

The "Add Image" screen allows us to import the image that we are going to analyze in Autospy.

9. Select the location of the Image to Analyze
This will allow us to import an image into our evidence locker. Rather than working on the original image, can can select the move option to copy the image to the analysis host and have a separate copy of the image for use in Autopsy.

10. Image file Details

 11. The Case Gallery

12. File analysis
 13. Keyword Search





14. Deleted File Recovery Mode

15. Anallocated(JPG file)

 16. Not Allocate(PDF File) 

 17. Image Details:
We can use foremost to recovery deleted files  #foremost -v -i /root/Forensics/usb1.dd


The Evidence Analysis Techniques in Autopsy
The primary modes and functions of the Autopsy Forensic Browser are to act as a graphical front end to the Sleuth Kit and other related tools in order to provide the capabilities of analysis, search and case management in a simple but comprehensive package. This collection of tools creates a simple, yet powerful forensic analysis platform.

Analysis Modes in Autopsy

A dead analysis occurs when a dedicated analysis system is used to examine the data from a suspect system. When this occurs, Autopsy and The Sleuth Kit are run in a trusted environment, typically in a lab. Autopsy and TSK provides support for raw, Expert Witness, and AFF file formats.

A live analysis occurs when the suspect system is being analyzed while it is running. In this case, Autopsy and The Sleuth Kit are run from a CD in an untrusted environment. This is frequently used during incident response while the incident is being confirmed. Following confirmation, the system is acquired and a dead analysis performed.

Evidence Search Techniques
The Autopsy Browser provides the following evidence search functionality:

  • File Listing: Analyze the files and directories, including the names of deleted files and files with Unicode-based names.
  • File Content: The contents of files can be viewed in raw, hex, or the ASCII strings can be extracted. When data is interpreted, Autopsy sanitizes it to prevent damage to the local analysis system. Autopsy does not use any client-side scripting languages.
  • Hash Databases: Lookup unknown files in a hash database to quickly identify it as good or bad. Autopsy uses the NIST National Software Reference Library (NSRL) and user created databases of known good and known bad files.
  • File Type Sorting: Sort the files based on their internal signatures to identify files of a known type. Autopsy can also extract only graphic images (including thumbnails). The extension of the file will also be compared to the file type to identify files that may have had their extension changed to hide them.
  • Timeline of File Activity: A timeline of file activity can help identify areas of a file system that may contain evidence. Autopsy can create timelines that contain entries for the Modified, Access, and Change (MAC) times of both allocated and unallocated files.
  • Keyword Search: Keyword searches of the file system image can be performed using ASCII strings and grep regular expressions. Searches can be performed on either the full file system image or just the unallocated space. An index file can be created for faster searches. Strings that are frequently searched for can be easily configured into Autopsy for automated searching.
  • Meta Data Analysis: Meta Data structures contain the details about files and directories. Autopsy allows us to view the details of any meta data structure in the file system. This is useful for recovering deleted content. Autopsy will search the directories to identify the full path of the file that has allocated the structure.
  • Data Unit Analysis: Data Units are where the file content is stored. Autopsy allows us to view the contents of any data unit in a variety of formats including ASCII, hexdump, and strings. The file type is also given and Autopsy will search the meta data structures to identify which has allocated the data unit.

  • Image Details: File system details can be viewed, including on-disk layout and times of activity. This mode provides information that is useful during data recovery.
Case Management Autopsy provides a number of functions that aid in case management. In particular, investigations started within autopsy are organized by cases, which can contain one or more hosts. Each host is configured to have its own time zone setting and clock skew so that the times shown are the same as the original user would have seen. Each host can contain one or more file system images to analyze. The following functions within Autopsy are specifically designed aid in case management:

  • Event Sequencer: Time-based events can be added from file activity or IDS and firewall logs. Autopsy sorts the events so that the sequence of incident associated with an event can be easily determined.
  • Notes: Notes can be saved on a per-host and per-investigator basis. These allow the investigator to make quick notes about files and structures. The original location can be easily recalled with the click of a button when the notes are later reviewed. All notes are stored in an ASCII file.
  • Image Integrity: Being that one of the most crucial aspects of a forensics investigation involves ensuring that data is not modified during analysis; Autopsy will generate an MD5 value for all files that are imported or created by default. The integrity of any file that Autopsy uses can be validated at any time.
  • Reports: Autopsy can create ASCII reports for files and other file system structures. This enables investigator to promptly make consistent data sheets during the course of the investigation.
  • Logging: Audit logs are created on a case, host, and investigator level so that all actions can be easily retrieved. The entire Sleuth Kit commands are logged exactly as they are executed on the system.

Source: http://digital-forensics.sans.org

WPA2 Cracking

WiFI Protected Access(WPA):

1. WPA was designed to replace WEP security method.

2. WPA uses algorithms RC4 + TKIP (Temporal Key Integrity Protocol) which able to dynamically change after 10,000 data packets transmitted.

3. TKIP protocol takes the primary key as a starting point then regular changing so there is no encryption key used twice

4. The background process is automatically carried out without being noticed by the user

5. Radius: RC4 + TKIP (Temporal Key Integrity Protocol) + 802.1x + better ICV (MIC).

WPA2 (Robust Security Network/RSN 802.11I):

1. Using AES and TKIP algorithms for encryption.

2. WPA/WPA2 is divided into 2 :

WPA/WPA2-Personal and WPA/WPA2-Enterprise

@Personal using Pre-Shared Key as the "Password"
@Enterprise using 802.1x with the protocol EAP (Ie: EAP-TLS, EAP-TTLS, EAP-PEAP)

Cracking steps:
1. airmon-ng start interface

2. airodump-ng interface

3. airodump-ng -c [channel AP] --bssid [MacAddress AP] -w [path where the capturing data will be saved] interface

4. aireplay-ng --deauth 0 -a [mac AP] -c [Mac client] interface

5. aircrack-ng -w [path wordlist] -b [mac AP] [location of capturing file] 5.a. john --stdout --incremental:all | aircrack-ng -b [mac AP] -w - [location of capturing file]

If successful then you will see the results as follows


You can download my slide here. This slide I prepared for a workshop in my University when I was invited as a speaker.

05 September 2014

Network Monitoring with NAGIOS

Nagios is an open source tools which useful for network monitoring. This tools has a lof of features that facilitate its use in Nagios. Nagios is modular, easy to use, and have high scalability. The modules on this tools are very simple we can even make it to complement the Nagios checking system according to our needs.

Here are the advantages of Nagios:
a. It can monitor network services(http , smtp, ping  and etc)
b. It can monitor host resources (disk usage , processor load and etc)
c. Autoatic log rotation file
d. Nagios can be developed in terms of notification, ie: can maintenace via email, pager or userdifined method)

Nagios Installation:

1. I used two machines for this experiments.

Descriptions:
Computer A:
Hostname : debian
IP : 192.168.1.11

Komputer B:
Hostname : deft
IP : 192.168.1.12

2. Install Nagios on the computer that will become host Nagios(Computer A).
apt-get install nagios3 nagios-plugins nagios-nrpe-plugin

3. Install nagios-nrpe-server nagios-plugins on computer B
apt-get install nagios-nrpe-server nagios-plugins

4. Set the user password for Host Nagios (Computer A).
To access the Nagios configuration page, we need to set a password for the user.
htpasswd -c /etc/nagios3/htpasswd.users abrao
If this steps has been done, we can login to http://192.168.1.11/nagios3/
with the username abrao and the password that on-set just now.

5. Install web server on Computer B.
apt-get install apache2

6. Create a config file in the Nagios host (Computer A). Because of this implementation on Debian,  therefore create a config file in /etc/nagios3/conf.d
vim /etc/nagios3/conf.d/server1_nagios3.cfg

The computer B will be like the following:

7. Restart Nagios.
8 Prepare NRPE client on computer B to submit more data to the Nagios host (Computer A)
vim /etc/nagios/nrpe.cfg
Change allowed_hosts = 127.0.0.1 into allowed_hosts = 192.168.1.11

9. Restart nagios-nrpe-server on Computer B.
/etc/init.d/nagios-nrpe-server restart

10. Check nrpe-service on Computer A.
debian:~# cd /usr/lib/nagios/plugins/
debian:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.1.12 -c check_users

11. Access Nagios via browser
http://192.168.1.11/nagios3/

12. After successful login, the result will look like the following:

Reference: http://www.howtoforge.com

03 September 2014

USB Imaging

A disk image is a copy of the entire contents of a storage device, such as a hard drive, DVD, or CD. The disk image represents the content exactly as it is on the original storage device, including both data and structure information.
The similarity can be ascertained through the hashing process is applied to the disk image and the original disk. If the hash values ​​between imaging results with the digital evidence is the same, it is certain that the two are identical, and the result is a forensic imaging, which means it is scientifically and legally, for subsequent imaging results can be used for further inspection and analysis. Conversely, if the two hash values ​​are different, then the forensic imaging process should  be repeated until we get the same hash value.

The implementation of imaging process on a 2GB of Transcend JetFlash flash (scsi).

1. List out the block device (partitions and storage media).



Based on the information above, shows that the disk that will be cloned on /dev/sdc1.

2. Prior do the image of the disk, we have to know the hash value of original disk which will be used to compare with the results of cloning file.

md5sum /dev/sdc

Output:
6c03a23f98a5e2bc0c1e5fdc27783823  /dev/sdc

3. Then need to know how many sectors are there in the original disk.
hdparm /dev/sdc

Output:
/dev/sdc:
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 0a 00 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 multcount     =  0 (off)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 1009/63/62, sectors = 3944448, start = 0

4. Using dcfldd utility to perform the imaging on the disk.
dcfldd if=/dev/sdc of=/media/DATA/usb.dd hash=md5 hashlog=/media/DATA/hashlog.txt

Output:
61440 blocks (1920Mb) written.
61632+0 records in
61632+0 records out

5. Comparing the original disk and cloned image file:
md5sum /media/DATA/usb.dd /dev/sdc

Output:
6c03a23f98a5e2bc0c1e5fdc27783823  /media/DATA/usb.dd
6c03a23f98a5e2bc0c1e5fdc27783823  /dev/sdc

The comparison shows that the hash value of the original disk and the cloning image is the same.