Now and again, the question comes up about writing technical forensic examination reports. Often in some forums, you'll see someone say that they feel that folks should publish their report formats...most often without doing so themselves. Funny how that works, eh?
Here's a link to a recent DFI article that describes what a report should contain.
Not long ago, John H. Sawyer wrote a nice article for DarkReading that mentioned my name...very cool, and a very nice reference. Thanks, John!
From the sausage factory, there's a great blog post about Windows Photo Gallery artifacts. IMHO, for the most part, we don't see enough of these kinds of posts...great work! Here's another, similar post from the ThinkTankForensics blog.
This past week, I had an opportunity to be around and talk to some really smart people, and had some really interesting thoughts about WiFi geolocation data extracted from acquired images. Okay, it's not quite as simple as that, per se, but I do think that for some folks (in particular, law enforcement), this sort of data exploitation will be extremely useful.
Ran across a reference to the Digital Forensic Framework last week, and thought I'd take a look...yes, Virginia, there is a Windows version! I'll have to read a bit more about it and give it a run.
Speaking of frameworks, ProDiscover version 6 is available! Thanks to Chris Brown's generosity, I've been using PD since version 3, and have written several ProScripts, which is the Perl scripting interface into ProDiscover. Some of the updates in version 6 are very, very welcome, including the ability to conduct regular expression raw mode searches. Very cool! I also ran across some comments in various lists that version 6 also supports access to Vista Volume Shadow Copy files...this is something I definitely need to check out. One of the things I've always loved about ProDiscover is the cleaner interface than some other tools, and I really like the Perl scripting capability!
John McCash recently posted an interesting article to the SANS Forensic blog on decoding the binary Scheduled Task .job file format (John's article referred to tasks created using at.exe).
So, this is a good start. I've had engagements where analysis of the Scheduled Tasks log file proved to be critical, so I can see how being able to get details from the .job file might also be important. Also, as John pointed out, information about the binary structure of .job files may assist you if you find indications of deleted .job files in unallocated space. If you get a hit and are able to backtrack a bit, you may find enough information in unallocated space to be able to decipher the header fields.
As a side note, I did find some minor issues with how the MS documentation identifies some of the fields in the structures; for example, the documentation shows a total of 9 2-byte fields for the UUID, but UUIDs are defined as being 128-bits long (ie, 8 bytes); this threw my initial parsing code off by 2 bytes. Interestingly enough, this applies to Windows XP systems, and the last run time for the job is maintained in the header as a 128-bit wide field; here I was thinking that the new date format was only part of Vista and Windows 7! Eesh!
The F-Response Enterprise installation package now includes a partial implementation of the F-Response Enterprise Management Console in a language neutral fully scriptable COM object. This object will allow a technical user of F-Response Enterprise to script actions typically initiated manually in the FEMC.
Sweet! What this technical jargon amounts to is that F-Response EE can now be scripted through Perl! Imagine automating collection of system names from the network, pushing out F-Response EE, collecting information, disconnecting and moving on to the next system!
Here's an analysis tip that I picked up based on a question posted to one of the forums...when posting a question about time stamp oddities (in particular) on Windows systems, it helps to specify which version of Windows you're working with. For example, if you have a last modified date that is three days after the last accessed date on a file, and the system is Vista, then you may have encountered an artifact that has to do with the fact that by default, Vista does not update last access times on files. If the system is XP or Win2K3, you may want to check the NtfsDisableLastAccessUpdate value. Even variations within the same version of Windows (XP Professional vs. Home) can be important...and yes, you can use RegRipper to get this information for you.
Lee posted an excellent write-up regarding issues of MSOffice document metadata, along with an interesting example that many of us have likely run across. This is an issue that's been around for some time, and even though MS's updated the application itself, this is still something that can be very important during an examination, as Chris found out recently.
Are you tired of using RegRipper? Mark Woan has created RegExtract, which according to Mark, is based completely on RegRipper, and implements most of the plugins that are currently publicly available (I currently have 118, a few of which are proof-of-concept and for testing purposes only...) with RegRipper. I downloaded and installed RegExtract and took a look at it. It requires .NET 3.5, and it only runs on Windows (unless you can get .NET 3.5 installed on wine), but if you need a better looking UI and perhaps slightly faster processing, you should take a look at this. A couple of things I found with RegExtract is that while it can run all plugins designed for the NTUSER.DAT hive (or any other hive type) against that hive file, it doesn't appear to be able to automagically determine the hive type, or allow you to run only specific plugins in a predetermined order against the hive file. The results of the plugins are sent to a text field in the UI, and the user doesn't appear to have the ability...at least not obviously...to save the results to a file, for inclusion in a report (directly into the report, or an appendix). You can, however, select what you want from the text field, copy it to the Clipboard, and then paste it into a report or text file.
Finally, something else to consider...the plugins are compiled DLLs, and are not open. RegRipper's plugins are essentially text files that can be opened in Notepad or an editor of your choice (much like Nessus's plugins), so if you ever have any questions about what the plugin does or why it doesn't work, you can just open the plugin up and have a look-see.
Speaking of RegRipper, Rob posted the results of his updated research on USB devices to the SANS Forensic blog yesterday. This is an excellent bit of work that Rob's done and really taken the original work that Cory and I did oh, lo those many years ago to new levels. Drop by and check out the handouts Rob's put together. Based on an IM exchange with Rob, I've updated mountdev.pl a bit to pull out the sector offset information for the partitions, so that there's less confusion when you see two volumes or drive letters with the same disk signature or MBR disk identity (they're the same thing...the 4 bytes found at offset 0x01B8). The plugin now returns the same information seen when you open the image in FTK Imager and look at the start sector for the partition. With this new information, I need to clean up the plugin a bit to make the output a bit easier to understand.
Finally, Matthieu's been busy, it seems, working away on win32dd (now referred to as "windd") and looking for beta testers (ignore the "2008" in the changelog info...it's 2009). Take a look!
A recent thread over on ForensicFocus got me to thinking about the issue of tool verification. In that thread, there is discussion of verifying the results produced by RegRipper. Chris picked up on this and posted to his blog, as well.
First off, I'm a proponent of verification, but I also think that we, as a community and a profession, shouldn't be blindly running on autopilot when it comes to tool verification. Specifically, what is "tool verification"?
One way to look at this is that you'd like to verify that a tool does what it's supposed to do correctly. For example, if one tool (ie, AccessData's FTK Imager) generates an MD5 hash of an acquired image, you might want to verify that the algorithm used to generate that hash was done implemented correctly, so you'd use another tool (one that you trust as being correct...perhaps Jesse Kornblum's md5deep) to confirm that the MD5 hash is, indeed, correctly implemented. The implication here is that if both tools produce the same output, then the implementation employed by FTK Imager is correct and verified.
A similar way to look at this is with respect to a tool such as RegRipper, but how would you verify the results? For one, what other tools do what RegRipper does...besides RegExtract, which is, according to the author, based on RegRipper?
Well, similar to Nessus, RegRipper implements its actions based on plugins that are text-based. So if you want to determine what a plugin does (ie, what keys, values or data it extracts, and how it extracts or parses that data), all you need to do is open the plugin in Notepad or an editor. I know that a lot of folks will look at the Perl code and slip in to a coma, but for the most part, the data extraction and parsing logic is right there...in some cases, it's easy to see: read the binary data into a variable/Perl scalar, go to this offset within the data, read this many bytes, and translate it based on this table of values. Easy.
If you're not sure that what a plugin does is correct, I try to make sure that I include either descriptions in the comments of the plugin (lines that start with "#") or references to credible sources about the structure or use of the key, value, or data being parsed. In most cases, much like WFA 2/e, these references consist of MS KB articles. If there's some question about the data and how it is or should be interpreted...well, that's what I provide the references for, and as many of you know, I've tried to answer more than a few questions along those lines.
So, how do you verify what a tool like RegRipper does? One way is to use another tool that does what RegRipper does...but outside of RegExtract, there are no other tools that do what RegRipper does. You can open the hive file in a Registry viewer...some of the plugins present information in a manner similar to the way a viewer would, and you can always write your own plugins to do this. But what about parsing/interpreting binary data? Or "decrypting" ROT-13 value names? At that point, the only way to verify what RegRipper does is to sit down with the hive file open in a hex editor and do it all by hand.
Again, I'm not saying that tool verification isn't important...because it is. But so is understanding what a tool does. Blindly saying that I need a tool verify my findings against another tool is really pointless unless I understand what both tools do, and how they do it. I mean, the same holds true in other areas, such as live response. If I run two tools that both use to the same API calls to show me the active process list or the network connections, have I verified anything? No, I haven't. However, if I run two tools that use disparate APIs (and don't converge until somewhere very low in the API stack) then I have verified the tools and the findings...but only to the point where they ultimately converge somewhere down the API stack.
So, before discussing tool verification, we need to have an understand of the purpose and use of the tool, as well as an understanding of how the tool functions.
I posted something similar to the RegRipper forums, but I'll do the same here...I'm looking to consolidate a RegRipper wishlist, so I can see what folks are looking for in RegRipper, see what is most/least looked for, and then prioritize the creation/update of features.
So...please, comment here, or email me. Thanks!
A while ago, I posted on mounting DD images, and I wanted to provide an updated list of some of the tools that you can use to do just that on a Windows systems.
When would you need to use such tools? I like to use tools such as these as in most cases, you can do your analysis whilst goin' commando (sans dongle, as it were), and in many cases, do a great deal more deep analysis than you could using one of the commercial forensic analysis suites. In most cases, it's as simple as mounting the image and using your tools, many of which are CLI and can be run via a batch file. Mounting the image gives you access to most (be cognizant of permissions issues) of the files in the file system without that system being live and without requiring a password to log into the system (as with LiveView), simply because you're not actually booting the system, you're just reading the file structure.
I won't got into any particular detail about these tools, as I want to simply provide them here as a means of identifying those that are available.
VDKWin (free) - Excellent UI for VDK.
SMARTMount (pay) - Andy Rosen's superb mounting utility; requires a dongle, mounts raw, SMART, EWF, SAW, VMWare virtual disk format images, and detects a wide variety of file systems.
P2Explorer (free, requires registration) - Lots of cool features, mounts a variety of formats.
Captain Nemo (pay) - Mounts raw and RAID Reconstructor images from Linux, MS, and Novell systems.
For those of you doing live response, the guys over at CommandLineKungFu posted a great blog on determining information about mounted drives and shares. Some of the tools I've written and provided on the DVD that accompanies WFA 2/e implements similar functionality as the wmic commands that Ed posted, but in most cases going just a bit further.
Richard Bejtlich posted his review of WFA 2/e on Amazon...thanks, RB! It's validating to see luminaries in the security industry picking up, reading, and commenting on books like mine, particularly because Richard is so well known for NSM, something my book doesn't really cover.
Thanks to a recent comment to one of my blog posts, I was led to the Eating Security blog...always nice to get different perspectives on topics. I like some of the recent posts about IR teams and documentation, as well as the "does it make sense" test. I've done considerable work over the years with respect to CSIRP development and IR team testing, and I like to see how others approach the problem. While each customer brings a unique perspective to the problem through their own infrastructure and team organization, it's always interesting to see the thoughts that others have...most often due to the fact that developing a new IR team with a customer doesn't allow for a great deal of feedback beyond, "wow...okay...this is new."
Speaking of CSIRP development, here's an interesting blog post that I picked up a while back. Interesting how information on "crisis management" so easily maps to a CSIRP.
The guys over at cmdLabs had a nice post on SQLite for forensics nerds that has some good information...something to read, maybe play around with a bit, and bookmark.
Claus had an excellent forensic roundup post recently...he really can cover a LOT of stuff. I'm still sifting through this one. Claus and I read each other's blogs pretty regularly, so you see not only crosslinks but comments, as well...but Claus never ceases to amaze me with the breadth of useful information he's able to come up with. He's got a couple of links for pcap visualization that I need to take a look at.
All in all, not a bad catch this time around.
ForensicInnovations had an interesting blog, and the post that initially got my attention was Push for Live Forensics. I started into the post expecting yet another argument for developing a live response process, and got some of that...but the post ends with an announcement for a data profiler product that appears to provide a list of various file types found on the system. I'm not entirely sure how I'd use such a product, as rather than "show me all of the file types" I might take the approach of just "show me all graphics images", or something a bit more directed (based on the goals of my response).
I also found Simple Techniques that Fool Forensics Tools in the archive, as well as a couple of other posts. There's mention of NTFS Alternate Data Streams in this post, something I've been writing about for years, and oddly enough, is still something that is an effective hiding place for data, as many sysadmins and forensic analysts still do not understand how ADSs are used by the OS, let alone by the bad guys.
Also, I found a link to this CyberCrime blog that has some interesting stuff to read.
In a memory-dumping attack, the attacker reads the unencrypted transaction or other information that sits in memory before it goes to the actual application. The hotel attack included several pieces of malware, including code that dumps the contents of the memory onto the attacker's machine, and another that performs data parsing. "One piece installs itself as a service so the malware can come back when it needs to boot up," Ilyas says.
I'd run into the same malware myself during an exam, and one of our team members had seen an earlier version a year so prior to that. This shows how pervasive this stuff can get! In the instances I'm aware of, the intruder gained access to the internal network and then gained domain admin access...most often due to weak passwords...and then targeted very specific systems, and installed the software mentioned in the article.
Also, if you're going to the conference, be sure to check out Chris Pogue's Sniper Forensics presentation.
On the topic of visualization, check out the VizSec2009 conference. This looks really interesting, as visualizing malware program flow, for example, can be extremely helpful. One of the things I've been struggling with is to understand how to graphically represent timeline data so that an analyst can use that to determine what happened and when; however, there's just potentially so much data that I've been having a very difficult time trying to come up with some way to represent what happened. Right now, its a manual process to sift through the data looking for the smoking gun(s), and representing the findings can be done with a table or an Excel spreadsheet.
It looks like I'll be attending HackerHalted in Miami later this month, and Syngress is not only a sponsor but will have books available. I'll try to be available to sign books...if I'm not at the booth, just grab me (beer's always welcome!!).
And finally, for the VMI alumni in the readership, I picked up follower number 89 today!


With these challenges in mind we are kicking off 2018 with a can't-miss Meetup, Jumpstart Your Move to the Cloud – Gov Edition, on Wednesday, Jan. 31 starting at 6 p.m. at 1776 in Washington, DC.
Be sure to RSVP and join us for this month's Meetup featuring a speaker lineup of cloud experts who will help you figure out where to begin and what valuable resources are available. You will also get insight to government use cases and best practices for cloud onboarding success.
This event is free and open to the public. Please help spread the word by inviting your colleagues and connections – and be sure to RSVP and reserve your spot today!


In the instructions sent by email to you after you signed up there may be more than one combination of username and password that you can use to log in. When the popup appears requiring your username and password be sure to use one or the other combination but not to mix them up.
Also, be sure not to add anything onto the back end of your member name. For example, if your member name is "jacksonsupply" then that's all you type in for your username.
Both your member name and password must be entered exactly as it appears in your email instructions including any use of upper and lower case letters. For example: Supposing your password is "Johnson" then "johnson" won't work and neither will "JOHNSON". Because you can't actually see what you are typing in as your password (all you see are the ***** characters) be careful that you do not have your caplocks key on if your member name or password contain lower case letters.
If your username and/or password are already filled in for you and you proceed by clicking OK but the log in fails then you'll need to make absolutely sure what is in there is correct. Delete out both the username and the password, type them in again per the instructions in your Welcome email, and then click OK to try again.
If you have forgotten your member name or password please write to rob@robshelp.com and a reminder will be sent.


text:
Q: Why is binary file bigger? I created a compressor for my online course project using huffman algorithm. Problem is that the output file in binary (10101010011..) is bigger than the original files.
Teachers on the course don't know the answer.
I use this, where ciph_text is a string of 0s and 1s.
with open(full_name,'w') as temp:
    temp.write(ciph_text)

Any idea?
I can post more code if requested.

A: int(x, 2) is your friend:
>>> a="00001010000101000001111000101000"
>>> for b in range(0, len(a), 8):
...   print a[b:b+8], int(a[b:b+8], 2)
...
00001010 10
00010100 20
00011110 30
00101000 40

redpajama_set_name: RedPajamaStackExchange


text:
Buddhist Ladies' College is a private girls' primary and secondary school in Colombo, Sri Lanka. The school was established by Mohandas De Mel on May 20, 1954. It is one of the leading government-approved schools in Colombo. The first principal of the school was Clara Motwani. The current principal is Padmaseeli Lyanage.

History
The Buddhist Ladies' College is a popular school situated in Town Hall, Kurunduwatta, Colombo. It was first established as a private school before being transferred to the government. It became a private Buddhist girls' school in 2018. The school's motto is: The Utmost for the Highest. It was previously part of the same school as Vishaka College, but the schools were later separated.

Achievements
Buddhist Ladies' College was the first school whose students used to jump through a fire ring at the gymnastics display.

The Buddhist Ladies' College choir achieved All Island first place in a competition in 2017 (open category), and successfully advanced to the semifinals of the Ananda College Vocalize generation five competitions in 2019.

Alumni

References

External links

1954 establishments in Ceylon
Buddhist schools in Sri Lanka
Educational institutions established in 1954
Girls' schools in Sri Lanka
Private schools in Sri Lanka
Schools in Colombo

redpajama_set_name: RedPajamaWikipedia