. I definitely learned a few things on this one. The
last time I had a Mac at work it was Snow Leopard, so the versions issue for #2
was all new, and pretty cool to know about. I look forward to reading the
winning answers for these questions. I am glad to have gotten to the end,
held my own, and learn a few things along the way. It started off
innocently enough with Stage 1 and the VSCS question. By the end I felt like I
was watching the end of War Games "The only way to win is not to
play".
1. Two of the OSX systems have the same MAC address, the
attacker may have cloned his to fool any possible attempts at detection. Only
one of them however connected to the wifi hotspot on the Android phone you
identified in Stage 4. How can you determine which system connected to the wifi
network.
If there are two Macs with the same MAC, then you might
assume that the person who spoofed their MAC is the bad actor. You can
check the true MAC address of a MAC by removing a few screws (how many depends
on the year model of the Mac). The wireless MAC and Ethernet MAC
addresses are generally under the battery area where you will also find the
serial number for the Mac. You can then narrow your search to start
examining the most likely Mac to begin with (the one whose Ethernet MAC from
the battery label is not the one that shows up on ifconfig output).
At path “private/var/log” The file “system.log” is a Mac’s
catch all log for most system activities. Along with many other things
this file can be checked for the name of the SSID and MAC of the Android phone
that it connected to when it was set up as a wireless hotspot. There will be a
timestamp for the date and time of any connections to the hotspot as well as
the IP address that was assigned to this computer, which can be checked against
the records on the Android phone for assigning the DHCP lease.
A plist at path:
“Library/Preferences/SystemConfiguration/com.apple.network.identification.plist”
has historical IP assignments with a timestamp for those assignments that can
be checked for this issue as well.
2. Once you've identified which system was used you need
to determine if they accessed the ex-filtrated data. There is a text file that
appears to named the same as on you found accessed from the victim system but
it now has 0 bytes. How can you determine what its prior contents were.
From the way this question is worded I assume that it the
file was never deleted, and that it was a text file that was modified to remove
the content to make it currently 0 bytes.
If there is no time machine backup for this machine, then I
would want to attempt to obtain the previous version of the file by using the
“versions” functionality present in Macintosh since Lion version 10.7.
There are databases that Mac uses to track changes to files so that previous
versions (I just can’t shake my Windowsness enough to not call them previous
versions) can be rolled back to.
At path “/.DocumentRevisions-V100/db-V1/db.sqlite” is a
database that tracks file names, paths, and inode for files that have previous
versions saved. That database uses a primary key of “row_id” for file
changes to a file. There is another table that stores information in that
database for the change number because OSX is only storing incremental changes
and not entire autosaved versions like Time Machine does.
The actual data for the changes of files/previous versions
of files is stored at “/.DocumentRevisions-V100/.cs/ChunkStoreDatabase”. If the
text file was less than 32KB, then the entire file would be stored as one chunk
in the database. The chunks will have to be pieced together from the separate
chunks in the database if it is a large file.
Alternatively if the data for the previous version of the
file cannot be resolved from the two databases at “/.DocumentRevisions-V100”
you can clone the Mac hard drive to another computer then boot it, open the 0
byte file, drop down the arrow next to the file name when it is open and choose
to “browse all versions”. You can then open any previous version of the file,
and choose to restore any previous version. You may want to double check your
work with that method anyhow.
3. Both of the owners of the systems have stated they
are innocent, how can your prove that their system wasn't hijacked by malware.
I would start off by examining some log files at
“private/var/log”
“Install.log” will show the date, time and name of packages
installed on the computer, including OS upgrades, software updates, and new
package installations. It can be checked for the installation of any
suspicious binaries.
“System.log” is again our savior for this case as a catch
all of things that have been done on the computer. It can be examined for
error messages, remote connections to and from the computer for various
application, and activities in the terminal. I would unpack all of the
archived “system.log” files on the computer to put them with the active log
then GREP for the terms “sudo” and “USER=root” for starters on seeing lines
where an attacker might have dropped into a terminal shell to commit
activities. Older “System.log” files are Gzipped and can be unpacked to
be examined if the timeframe of the attack was not in the active “System.log.”
The last 500 entries are stored for terminal usage in the
“.bash_history” file at the base of each user’s home directory.
In “System.log” if there is an application on the user’s
computer that is making a remote connection to an attacker, then it will be
logged for the date, time, and IP address as well as the application making the
remote connection out.
Since we know the time of the attack, we can just look
through every line of these logs for any activity during that time to determine
any remote connections, or suspicious activity.
We can also check to see if the malware was set as an
autorun on user login by checking the users
“Library/Preferences/com.applie.loginitem.plist” or in the main system we can
check for items set to run on system launch as “System/Library/LaunchAgents”.
For the launch agents we will have to know a good baseline for normal launch
agents and look for suspicious items.
4. In searching for a bank account number you find a
fragment of a file but not the file it came from. How can you re-associate the
fragment to the file it originally came from.
I
would take a note of what cluster number the fragment was found in, then use
the TSK tool ifind to find the metadata address (node)for that cluster I would
then be able to go to that inode record to determine the file that the data
came from. Icat would then be able to be used to view the contents of all data
from the file of that node. Istat would be employed to determine information
about the file from the node record such as file name, size, type, and
CNID.
If
there is trouble with finding what is needed using The Sleuthkit you can always
get a bit more manual with the following 6 steps:
1.
1. Take note of the cluster number where the file
fragment of interest resides
2.
2. Go to the Catalog file for the file system and
search for the “HFSPlusExtentDescriptor” that contains the value “UInt32 –
{cluster number where the file fragment of interest was found}”.
3.
3. Back out one level from that
HFSPlusExtentDescriptor to view the “HFSPlusForkData record to see the total
blocks for the file, and all the other extents for the other file fragments of
the file as well as the total size of the file.
4.
4. Back out one more level from this total file record
in the catalog file to view the Catalog Node ID(CNID), Create, Modified, and
Access dates for the file as well as other information about the file.
5.
5. The CNID can be used to locate more information
about the file in the “file thread record” area of the Catalog File.
There the CNID can be looked up, and the name of the file as well as the CNID
of the parent directory will be available.
6.
6. You could just go nuts and use the
“HFSPlusForkData” and “HFSPlusExtentDescriptor” sections to go to all the other
fragments of the file to view the contents as well.