GitBook: [master] 4 pages and one asset modified

This commit is contained in:
CPol 2021-08-01 22:39:35 +00:00 committed by gitbook-bot
parent 1fa4bfa885
commit 76100d0b06
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
5 changed files with 79 additions and 9 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 71 KiB

View file

@ -1,10 +1,10 @@
# Office file analysis
From: [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)
## Introduction
Microsoft has created dozens of office document file formats, many of which are popular for the distribution of phishing attacks and malware because of their ability to include macros \(VBA scripts\). Microsoft Office document forensic analysis is not too different from PDF document forensics, and just as relevant to real-world incident response.
Microsoft has created **dozens of office document file formats**, many of which are popular for the distribution of phishing attacks and malware because of their ability to **include macros** \(VBA scripts\).
Broadly speaking, there are two generations of Office file format: the OLE formats \(file extensions like RTF, DOC, XLS, PPT\), and the "Office Open XML" formats \(file extensions that include DOCX, XLSX, PPTX\). Both formats are structured, compound file binary formats that enable Linked or Embedded content \(Objects\). OOXML files are actually zip file containers \(see the section above on archive files\), meaning that one of the easiest ways to check for hidden data is to simply `unzip` the document:
Broadly speaking, there are two generations of Office file format: the **OLE formats** \(file extensions like RTF, DOC, XLS, PPT\), and the "**Office Open XML**" formats \(file extensions that include DOCX, XLSX, PPTX\). **Both** formats are structured, compound file binary formats that **enable Linked or Embedded content** \(Objects\). OOXML files are actually zip file containers, meaning that one of the easiest ways to check for hidden data is to simply `unzip` the document:
```text
$ unzip example.docx
@ -49,11 +49,26 @@ $ tree
As you can see, some of the structure is created by the file and folder hierarchy. The rest is specified inside the XML files. [_New Steganographic Techniques for the OOXML File Format_, 2011](http://download.springer.com/static/pdf/713/chp%253A10.1007%252F978-3-642-23300-5_27.pdf?originUrl=http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F978-3-642-23300-5_27&token2=exp=1497911340~acl=%2Fstatic%2Fpdf%2F713%2Fchp%25253A10.1007%25252F978-3-642-23300-5_27.pdf%3ForiginUrl%3Dhttp%253A%252F%252Flink.springer.com%252Fchapter%252F10.1007%252F978-3-642-23300-5_27*~hmac=aca7e2655354b656ca7d699e8e68ceb19a95bcf64e1ac67354d8bca04146fd3d) details some ideas for data hiding techniques, but CTF challenge authors will always be coming up with new ones.
Once again, a Python toolset exists for the examination and analysis of OLE and OOXML documents: [oletools](http://www.decalage.info/python/oletools). For OOXML documents in particular, [OfficeDissector](https://www.officedissector.com/) is a very powerful analysis framework \(and Python library\). The latter includes a [quick guide to its usage](https://github.com/grierforensics/officedissector/blob/master/doc/html/_sources/txt/ANALYZING_OOXML.txt).
Once again, a Python toolset exists for the examination and **analysis of OLE and OOXML documents**: [oletools](http://www.decalage.info/python/oletools). For OOXML documents in particular, [OfficeDissector](https://www.officedissector.com/) is a very powerful analysis framework \(and Python library\). The latter includes a [quick guide to its usage](https://github.com/grierforensics/officedissector/blob/master/doc/html/_sources/txt/ANALYZING_OOXML.txt).
Sometimes the challenge is not to find hidden static data, but to analyze a VBA macro to determine its behavior. This is a more realistic scenario, and one that analysts in the field perform every day. The aforementioned dissector tools can indicate whether a macro is present, and probably extract it for you. A typical VBA macro in an Office document, on Windows, will download a PowerShell script to %TEMP% and attempt to execute it, in which case you now have a PowerShell script analysis task too. But malicious VBA macros are rarely complicated, since VBA is [typically just used as a jumping-off platform to bootstrap code execution](https://www.lastline.com/labsblog/party-like-its-1999-comeback-of-vba-malware-downloaders-part-3/). In the case where you do need to understand a complicated VBA macro, or if the macro is obfuscated and has an unpacker routine, you don't need to own a license to Microsoft Office to debug this. You can use [Libre Office](http://libreoffice.org/): [its interface](http://www.debugpoint.com/2014/09/debugging-libreoffice-macro-basic-using-breakpoint-and-watch/) will be familiar to anyone who has debugged a program; you can set breakpoints and create watch variables and capture values after they have been unpacked but before whatever payload behavior has executed. You can even start a macro of a specific document from a command line:
Sometimes the challenge is not to find hidden static data, but to **analyze a VBA macro** to determine its behavior. This is a more realistic scenario, and one that analysts in the field perform every day. The aforementioned dissector tools can indicate whether a macro is present, and probably extract it for you. A typical VBA macro in an Office document, on Windows, will download a PowerShell script to %TEMP% and attempt to execute it, in which case you now have a PowerShell script analysis task too. But malicious VBA macros are rarely complicated, since VBA is [typically just used as a jumping-off platform to bootstrap code execution](https://www.lastline.com/labsblog/party-like-its-1999-comeback-of-vba-malware-downloaders-part-3/). In the case where you do need to understand a complicated VBA macro, or if the macro is obfuscated and has an unpacker routine, you don't need to own a license to Microsoft Office to debug this. You can use [Libre Office](http://libreoffice.org/): [its interface](http://www.debugpoint.com/2014/09/debugging-libreoffice-macro-basic-using-breakpoint-and-watch/) will be familiar to anyone who has debugged a program; you can set breakpoints and create watch variables and capture values after they have been unpacked but before whatever payload behavior has executed. You can even start a macro of a specific document from a command line:
```text
$ soffice path/to/test.docx macro://./standard.module1.mymacro
```
## [oletools](https://github.com/decalage2/oletools)
```bash
sudo pip3 install -U oletools
olevba -c /path/to/document #Extract macros
```
## Automatic Execution
Macro functions like `AutoOpen`, `AutoExec` or `Document_Open` will be **automatically** **executed**.
## References
* [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)

View file

@ -734,6 +734,35 @@ The possible categories include the following:
* **LSRiskCategoryUnsafeExecutable**: **Triggers** a **warning** “This file is an application...”
* **LSRiskCategoryMayContainUnsafeExecutable**: This is for things like archives that contain an executable. It **triggers a warning unless Safari can determine all the contents are safe or neutral**.
## Apple Scripts
It's a scripting language used for task automation **interacting with remote processes**. It makes pretty easy to **ask other processes to perform some actions**. **Malware** may abuse these features to abuse functions exported by other processes.
For example, a malware could **inject arbitrary JS code in browser opened pages**. Or **auto click** some allow permissions requested to the user;
```bash
tell window 1 of process “SecurityAgent”
click button “Always Allow” of group 1
end tell
```
Here you have some examples: [https://github.com/abbeycode/AppleScripts](https://github.com/abbeycode/AppleScripts)
Find more info about malware using applescripts [**here**](https://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/).
Apple scripts may be easily "**compiled**". These versions can be easily "**decompiled**" with `osadecompile`
However, this scripts can also be **exported as "Read only"** \(via the "Export..." option\):
![](../../.gitbook/assets/image%20%28535%29.png)
```bash
file mal.scpt
mal.scpt: AppleScript compiled
```
and tin this case the content cannot be decompiled even with `osadecompile`
However, there are still some tools that can be used to understand this kind of executables, [**read this research for more info**](https://labs.sentinelone.com/fade-dead-adventures-in-reversing-malicious-run-only-applescripts/)\). The tool [**applescript-disassembler**](https://github.com/Jinmo/applescript-disassembler) with [**aevt\_decompile**](https://github.com/SentineLabs/aevt_decompile) will be very useful to understand how the script works.
## Specific MacOS Enumeration
```bash

View file

@ -139,11 +139,37 @@ Basically, a bundle is a **directory structure** within the file system. Interes
ls -lR /Applications/Safari.app/Contents
```
* The **MacOS** **folder** contains the executable of the application
* The **Resources** **folder** contains the resources of the app \(icons, images...\)
* **Plist** **files** contains configuration information. You can find find information about the meaning of they plist keys in [https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)
* `Contents/_CodeSignature`
Contains **code-signing information** about the application \(i.e., hashes, etc.\).
* `Contents/MacOS`
Contains the **applications binary** \(which is executed when the user double-clicks the application icon in the UI\).
* `Contents/Resources`
Contains **UI elements of the application**, such as images, documents, and nib/xib files \(that describe various user interfaces\).
* `Contents/Info.plist` ****The applications main “**configuration file.**” Apple notes that “the system relies on the presence of this file to identify relevant information about \[the\] application and any related files”.
* **Plist** **files** contains configuration information. You can find find information about the meaning of they plist keys in [https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)
* Pairs that may be of interest when analyzing an application include:
* **CFBundleExecutable**
Contains the **name of the applications binary** \(found in Contents/MacOS\).
* **CFBundleIdentifier**
Contains the applications bundle identifier \(often used by the system to **globally** **identify** the application\).
* **LSMinimumSystemVersion**
Contains the **oldest** **version** of **macOS** that the application is compatible with.
## References
* \*\*\*\*[**The Mac Hacker's Handbook**](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=)\*\*\*\*
* \*\*\*\*[**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)\*\*\*\*

View file

@ -56,7 +56,7 @@ sudo apt-get install libsaxonb-java
Execute:
```bash
```markup
$ saxonb-xslt -xsl:xsl.xsl xml.xml
Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl: