Part D
Import the VM provided in enisa-main.ova into Virtual Box. From a terminal, execute the
initialization script “./setup” and follow the instructions. After restarting the VM, all necessary
material to complete this lab will be found in the just created directory
home/enisa/Desktop/Training-Material/Dig_For_and_Handl_Ev. Finally, read about the scenario
(section 3) in the provided document ENISA_Bank_forensic_investigation.pdf.
Reference manual: https:
www.wireshark.org/docs/man-pages/tshark.html
1. Execute the command below. Please note the command provided in the PDF (section 4)
contains two typos, so the wrong character “–” must be changed by “-” for the command
to work with no e
ors. What is the size in bytes of the file where the output was redirected?
tshark -nn -r tcpdump.pcap -T fields -E separator='|' -R 'http.request' -e ip.src -e
frame.time -e http.request.uri -e http.user_agent -e http.cookie > tshark.log
2. The command above has extracted HTTP session information from the network capture.
Check the last line of tshark.log and note each field name (as indicated by the parameter -
e) with the co
esponding value. Capture a screenshot.
3. We are looking for suspicious sessions. Is there any login from a
owser other than Mozilla
or Opera? How did you know?
4. Go to the tips in the section 4 of the PDF regarding the user that made the complaint and
time of the incident. Now that you have the user and time, try to filter all lines for this
specific time. There were too many users with open sessions at the same time. How many
exactly?
5. You could check the localization of each IP address, but we are going to focus on this
specific user instead. Filter all lines in client.csv match client94777. Capture a screenshot
of the actual command executed in the VM.
6. The last field is the session ID, which can be found in other files in the folder, notably
tshark.log and syslog.log. As copying and pasting can be daunting in some cases, you need
to extract both session IDs. To do so, append the following to the command you used, then
capture a screenshot: | awk -F ‘,’ ‘{ print $2 }’
7. Try again and redirect the output to a temporary file sessions.txt in the working directory.
Then, filter all lines in tshark.log and syslog.log that match any of the session IDs in the
file. Use a single command. Show the command and output.
8. What can you observe regarding the timestamps?
9. One of the sessions co
espond to the one opened while the user was on the phone to report
the incident. What is the co
esponding IP address? Where is it located?
10. What is the other IP address and where is it located?
11. Filter this last IP in access.log and explain what the numbers 200 and 291 represent.
12. The command below will give you all suspicious log entries. Capture a screenshot.
grep Mozilla access.log | grep ‘ ru;’ | grep \”\’
13. Now use the tool awk to get the IP addresses (first field) and redirect them to a file called
ips.txt. Capture a screenshot.
14. Finally, create a shell script with a loop that geolocates each IP address in the file. Tip: you
can do it in a single line using for and geoiplookup.
Import the two VMs provided in SEEDUbuntu.ova and Herzing-Ubuntu.ova into Virtual Box. Both
machines will need an interface configured as NAT Network, but this must be previously created
in Virtual Box → File → Preferences → Network.
Part A: Inspect the environment
1. In the Android VM, open the Contacts app. You will be asked to capture the mouse click.
Whenever you need to get out of the VM, just press the Host key (usually the right Ctrl).
In the contacts app, add your name with a fake number. Capture a screenshot of the “All”
view.
2. Check Settings → Apps. What is the only app beginning with L?
3. Open the Terminal Emulator. Some Linux commands can be used. Execute “ls system/etc”
and “ls system/app | grep -i wall”. Capture a screenshot.
4. Check the assigned IP address. Capture a screenshot.
Part B: Repackaging the app
To repackage an app, an attacker needs to disassemble the app, modify it to introduce the malicious
code, then assemble it again and, finally, publish it in the store. In this lab, you will simulate these
steps, without publishing the app anywhere. You will need the PDF document
SEEDAndroid_Repackaging.pdf provided with the lab.
Reference for ADB commands: https:
www.xda-developers.com/install-adb-windows-macos-
linux/
Reference for
oadcasts: https:
developer.android.com/guide/components
oadcasts
5. In the Ubuntu VM, install the packages android-tools-adb and apktool. Then, connect to
Android using the adb command. Capture a screenshot containing “adb devices” and
proving the connection was made.
https:
developer.android.com/guide/components
oadcasts
1. Copy the provided files RepackagingLab.apk and MaliciousCode.smali in Ubuntu. One
contains the app to work on and the other the malicious code to be inserted. Disassemble
the app. What command did you use? Where is the code you need to modify and repackage?
2. Insert the malicious code into the original code as per the instructions in the section 2.3
(Task 3) of the provided PDF. Where did you copy the file?
3. Modify the AndroidManifest.xml file as per the instructions in the PDF. Show how it looks
like.
4. Finally, repackage with “apktool b RepackagingLab”. Capture a screenshot of the
ebuilding and the generated file in RepackagingLa
dist.
Part C: Installation and test
The repackaged app must be signed and installed in Android. All the steps, except the creation of
the private key to sign, will be repeated every time the app is modified and repackaged.
Additionally, you might need to uninstall the app before every try.
5. Sign the code following the instructions of the section 2.4 (Task 4) in the PDF. You might
need to install OpenJDK; choose the last version of the package. What is the full jarsigner
command you used? What warning did you get? Explain it.
6. Install it with “adb install path-to-app/RepackagingLab.apk” and check that it appears in
Android. Prove it.
7. Give permissions to the app over the Contacts. Then, trigger the malicious code. How did
you do it?
8. Prove it worked by checking that the Contacts were wiped out. If it did not work (it might
happen for some Android versions and permissions required that the trigger fails or that the
notification does not reach the app), then explain how it could be exploited by a threat
actor.