Quantcast
Channel: Forensic Focus Forums - Recent Topics
Viewing all 20109 articles
Browse latest View live

Education and Training: A Survey On Digital Forensics Research

$
0
0
Hi! We are an independent team of UX Researchers working with a client to improve the usability of their digital forensics website. We’re looking for a small number of people to fill out a short survey about their purchase journey and pain points. There will be no attempt to sell you anything now or later, it is strictly for research purposes only. To show our appreciation, we’re offering a $50 Visa gift card to all selected participants. Spots are limited, so please sign up at your earliest convenience. If you are selected, we will get in contact with you. Given the confidentiality required for those in this industry, all survey answers will remain anonymous and will not be shared publicly. We are only collecting email addresses in order to send out the rewards. We’d love to hear from you if: •You are from one of the following backgrounds: Law Enforcement, Cyber Security, Information Security, Digital Forensics •You are interested in using or have previously used digital forensics software •You are ok with sharing details about the software you use Interested in participating? To see if you’re eligible, click the link below to complete our form. These questions are designed to determine your eligibility for our study. If you have any colleagues who would also be interested in participating, please send them this form. https://goo.gl/forms/fdt2G4O4rLwsb6nB2 If chosen, you’ll receive a link to download your $50 Visa gift card after completing the survey. Thank you and we hope to hear from you!

General Discussion: X-ways - Steganography tools

$
0
0
Hello, Can X-ways detect the use of steganography tools ? Can X-ways detect text files, zip files, other pictures in a picture when steganography tools are used? Kind regards, Dimi

General Discussion: what else other than memory dump

$
0
0
Quote:: I'm trying to use memory dumps to investigate malware detections on some computer from the company I work So far I am able to match the creation time date of the file with the time the detection was triggered in the AV but I'm not able to know how the file get in to the machine. - d4n13l4 Quote:: as a side note: as a threat hunter in a malware investigation, he probably doesn't need to follow forensic principles of creating a full image, or even a write-blocked image. What I would be pushing is documentation. Document what you've done, and what you've found. -randomaccess What randomaccess suggests is very appropriate and what you use to document would pretty much depend upon how he wishes to document and which tools. It would make the task somewhat easier or much more time consuming. Since this is a Windows system, anyone have any tools to suggest ? I would guess that this is more of a Blue Team type situation ? But wouldn't you not want to at some point, just-in-case, want to have the collected evidence ready for a possible court use besides stopping this attack and making secure corrections and protections ? What has been your policies and experiences ? To just stop and correct the attack and move on or to potentially provide your experience and evidence to a prosecutor ? This would be interesting to know, too ....

General Discussion: How did the suspect hide these folders?

$
0
0
If the file system is FAT32 that greatly narrows the possible ways this could be done. All of the possibilities below "abuse" the FAT specification in some way: 1. Overwrite proceeding directory entry with 0 In most implementations this causes the directory parsing to stop. However, the subsequent directory entries remain and critically so do the allocated data clusters. If the "hidden" entry contains a sub-directory it and all child folders will also be hidden. In this case, it isn't even necessary to overwrite the whole directory entry, simply replacing the first character of the filename with 0 is sufficient. You can re-create this scenario easily by: a. Create a new small FAT volume b. Create 3 small files c. List the directory. All three files should be visible d. Overwrite the first character of the middle file with 0 e. List the directory again. Only the first file remains This situation would show up in your Hex editor like this: http://www.binarymarkup.com/ForensicFocus/badfat.jpg 2. Create a new "root" directory Unlike FAT12/16, FAT32 allows the root directory to be in any data cluster. The root directory is specified in the VBR. A user could create this scenario by: a. Create sub-folder called "Root" b. Populate this folder with harmless content c. Modify VBR to point to the new root 3. Modify attribute bits FAT uses a single byte in the directory entry to describe the attributes of the file/directory. Changing a single bit in this can change a sub-directory to apparently become a 0 byte file. This will have the effect of hiding the contents of the sub-directory from a casual observer. 4. Use non-standard characters in filename I haven't tested this scenario but the specification reserves certain characters. It is possible that replacing the first character of the filename with such a character would confuse the directory parsing. I wouldn't be surprised that there are other methods I haven't thought of and look forward to hearing about them shortly... Jim www.binarymarkup.com

General Discussion: How did the suspect hide these folders?

$
0
0
@athulin: I don't think this is a bug. The FAT spec says the directory "ends" when when the first directory record starting with 00 is encountered. This behavior is by design and isn't a bug. FTK is no doubt wise to this trick and keeps parsing. @jaclaz: You are correct that you can effectivly ignore a FAT table by moving the offset in the VBR and changing the number of FAT tables accordingly. This could be used to "hide" the allocation of clusters in a "private" FAT. However, this technique wouldn't itself hide a directory entry. I think this can probably only be done by abusing the 32-byte directory entry itself. As noted already, the main candidates are the first byte of the filename, the attribute byte or the file size (see below). To expand on this further, I would suggest the following subtle variations to my original post: 3b. Modify attribute bits - Remove directory flag (0x10) Removing the directory flag (0x10) from the attribute byte (offset 0x0b) converts the directory to a zero byte file. This file would still be visible in a directory listing but access to the sub-directory and it's contents would no longer be available. This would show up as an error with CHKDSK. 3c. As above, but also change size to 1 byte This would make the file "valid" and casually looking at the file would reveal it contained as single "." character. I made a screenshot of this here: http://www.binarymarkup.com/ForensicFocus/badfat2.jpg This would make quite a good competition - To find the best way to hide a file on a FAT drive that still passed CHKDSK... Jim www.binarymarkup.com

General Discussion: X-ways - Steganography tools

$
0
0
Dimi wrote: Can X-ways detect the use of steganography tools ? Can X-ways detect text files, zip files, other pictures in a picture when steganography tools are used? Well, depending on the OS and version you're examining, you can use any tool to pull out the info you need. For example, was there a stego tool installed? Was a stego tool used on the system (i.e., check JumpLists, UserAssist, Prefectch if Win7, all that and AmCache/BAM key if Win10...)?

General Discussion: The secret Office 365 logging ...

$
0
0
... is not secret anymore: https://lmgsecurity.com/exposing-the-secret-office-365-forensics-tool/ https://www.crowdstrike.com/blog/hiding-in-plain-sight-using-the-office-365-activities-api-to-investigate-business-email-compromises/ jaclaz

Mobile Phone Forensics: Android Logs - Actually Useful

$
0
0
In all the classes I've taken for mobile forensics we've never discussed the logs that are available in the Android Recovery Menu. I've been working on a device for quite some time and decided to peer through the logs. There's actually a lot of useful information in there! I was able to find the chipset running on the device and the last security patch that was installed. Definitely helped me to think of some alternatives for the device.

General Discussion: Drone Forensics Gets a Boost With New Data on NIST Website

$
0
0
NIST maintains a library of “forensic images” that forensic experts can practice on before trying to extract data from real devices. These are freely available for download as part of NIST's effort to support the digital forensics community. We just added a slew of forensic images from drones which should help investigators solve drone-related crimes. More info here... Drone Forensics Gets a Boost With New Data on NIST Website

General Discussion: How did the suspect hide these folders?

$
0
0
anucci wrote: While using FTK Imager to inspect the "Documents" folder, I get a message from FTK saying "cached_drive_image:read_blocks:index out of bounds". Not sure if this has anything to do with it but figured I would mention it. Unless someone else here knows what that is, you need to ask Access Data for the exact meaning ... or perhaps look in the AD knowledgebase/equivalent for discussion of it. (I hope you're using the latest version of the software?) My guess would be that a directory entry somewhere (which?) references a disk cluster that is not found within the image. That could mean: ... that the image or the volume is truncated. When that happened is not clear -- it might be that the device you're looking at earlier was the destination for a block copy that eventually failed. It might be that the image of the device was truncated at some later point, and what you have is only the 'first half' of a FAT32 file system. (Should be easy to test: the FAT bitmap size should tell you.) ... or that the cluster calculations are messed up: FTK Imager does it one way, while the software that created the volume did it another way. The FATGEN103 document identifies this problem as known, and provides The True Algorithm, but until you know what software created the volume, you can't say for certain that it was used. There is, for example, an ISO standard for a subset of FAT that is slightly different. (I would think this would be less likely, though.) ... or something else. The fact that you get an error message is significant, as it affects interpretation. You must report it. This very probably changes the question: you are no longer looking at a sound file system. That means that all interpretations ('how did X hide these files?') are off until you know exactly to what extent the file system is sound. As far as I can see, you can't even say that the files were hidden at this point, only that they seem to have been deleted at some point. You almost certainly want to use some tool with better diagnostic capability in order to get a better idea of the extent of the problems. Quote:: By looking at the Hex of the root directory I can only see a lot of files that show as "previously deleted in FTK" and then the single "Documents" folder. I then navigate to this folder and get the above referenced message from FTK. The only way I can think of to explain that seems to be that you do have a 0x00 situation, but that it applies to an previous directory entry than 'Documents', as the first character of the directory name has not been overwritten. You can't rely on further interpretation until you know what the error message refers to, and how it affects the operation of FTK Imager. Does FTK Imager manage to read the directory contents? or does it read only part of it? or perhaps none of it, and what you see is consequence of poor error recovery? (You have to find out.) On the assumptions that some part of it is read ... Quote:: Within the "Documents" directory, I can see all the files and folders listed as expected, but I did not note any "0" in front of the directory names for the hidden folders, or anything similar. In fact they have an "A" appended to the name... The 0x00-conventions applies to deletion of a subset of directory entries (I think). When an entire directory is deleted (such as by CMD-line X:>\RMDIR /S DOCUMENTS) I would not expect such details.

General Discussion: Drone Forensics Gets a Boost With New Data on NIST Website

$
0
0
Thanks. <img src="images/smiles/icon_smile.gif" alt="Smile" title="Smile" /> Off-topic and surely not a new observation, but having a name like Richard Press and a nickname of richpress for someone that deals with publication of material for an organization is one of the best examples ofnomen est omenI have ever seen: https://en.wiktionary.org/wiki/nomen_est_omen <img src="images/smiles/icon_biggrin.gif" alt="Very Happy" title="Very Happy" /> jaclaz

General Discussion: How did the suspect hide these folders?

$
0
0
I don't want to teach anyone to suck eggs. A simple answer may be that the folders have been tagged as "Hidden" on a previous windows machine. The examination computer folder options are set not to show hidden files and folders Therefore Windows File explorer will not show the folders or the contents as hidden but ftk will show them

Digital Forensics Job Vacancies: Digital Forensic Investigator - 6 month contract

$
0
0
A leading Government Body in Central London is seeking a Digital Forensic Investigator to help them at a time of heightened activity for a 6 month contract. Due to expansion of their department they are looking for multiple individuals to join them. The organisation are processing a substantial amount of digital evidence in accordance with ACPO guidelines. The focus of the role will be to work on a substantial amount of phone based evidence. You will require experience working within a similar post with forensic tools such as EnCase and Nuix. A lot of this evidence is on mobile phones so experience working with Cellebrite or XRY would be highly beneficial. The role is paying around £400 per day for the duration of the contract. They are looking for someone who can start ASAP. Please contact me on danielrichards@morgan-law.com or call me on 0207 747 4921 for more information.

General Discussion: How did the suspect hide these folders?

$
0
0
Hello Everyone, A few more details.... The suspect , while no longer working in the Computer Science field, he used to be a programmer in the 90's. So there is a potential that he was familiar with FAT32 and used his knowledge to hide these files. *As a side note... I am attempting to obtain a forensic image from a 128GB thumb drive for this same case... and I am running into issues also... it could be coincidence... or that every piece of evidence seized will be a challenge and not your regular "I save everything into cataloged folders on my desktop" type of case... To answer the question about the FTK error... I will be reaching out to AD to confirm. When I navigate to the Documents folder, I get the error, but the directory is still displayed. I can still see the data contained within, which includes CP. However, I cannot say whether that is all the data, or not. Also... to answer a previous question, I see FAT1 and FAT2 among the tables. Along with VBR. I will review all of these suggestions in more detail and see what else I can come up with. Maybe I'll be able to post some of the HEX I see on the root and VBR in the upcoming days. Thanks Again.

General Discussion: Drone Forensics Gets a Boost With New Data on NIST Website

$
0
0
Actually, this is a new observation. I've gotten many comments on my name, but I had never heard this phrase. Thanks for sharing!

Classifieds: Encase v6 Dongle, Fastbloc 1 &2, EnCase v6 DVD for Sale

$
0
0
i want to buy encase dongle is it still available

Mobile Phone Forensics: Decrpyt gatekeeper.password.key - android 7.0

$
0
0
Hello, I have a mobile phone SM-G935F (version android 7.0). I have full memory dump, but I need to know the access password. In device_policies.xml, the password length is 4 characters - 4 digits. Is there a possibility to decrypt a password? Mobile phone has a gatekeeper.password.key file. Thank you for answer.

Mobile Phone Forensics: Android Logs - Actually Useful

$
0
0
It would be great if you could write up your findings in a blogpost somewhere!

Mobile Phone Forensics: recovery image quest

$
0
0
MOBILedit Forensic Express has an HTC rooting capability leveraging HiSuite. I have not tested this feature.

Classifieds: Encase v6 Dongle, Fastbloc 1 &2, EnCase v6 DVD for Sale

$
0
0
I also have a Encase 6 dongle that I could sell if You are interested - $ 600
Viewing all 20109 articles
Browse latest View live