Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suggestion: using the olevba API or mraptor #3

Open
decalage2 opened this issue May 23, 2019 · 3 comments
Open

suggestion: using the olevba API or mraptor #3

decalage2 opened this issue May 23, 2019 · 3 comments

Comments

@decalage2
Copy link

Hi, I see that olefy is calling olevba as an external script, and capturing its output + exit code. I think this is error prone and may lead to issues if we change the display or behaviour of olevba.

I would advise to import olevba and to use its python API instead:
https://github.com/decalage2/oletools/wiki/olevba#how-to-use-olevba-in-python-applications

Moreover, olevba is meant for malware analysts to look at the details of a file when they know it's suspicious or malicious.
If your goal is to decide (automatically) if a file is innocuous or suspicious, I would suggest to try mraptor instead. It is built on top of olevba, but applies a simple algorithm to detect suspicious keywords, and returns a clear result:
https://github.com/decalage2/oletools/wiki/mraptor

For example, it is used in the project MacroMilter for sendmail/postfix:
https://github.com/sbidy/MacroMilter

I have not yet documented the mraptor API, so for now you need to look at the code. But it's not a complex API.

@c-rosenberg
Copy link
Member

Hey, thanks for your suggestions. This initial implementation was a quick shot while the Emotet wave last December. We have started using mraptor, but found olevba is returning more details . We have added an extended mode to Rspamd to be able to add symbols to any reported macro function. So you are able to just take action to e.g. Workbook_Open and Shell combinations.
We gave the direct integration a quick try, but was faster to use the json output of the command line tools.

Nevertheless, we are currently thinking about to move to persistent http connection on the Rspamd side, so we maybe reimplement the complete script and use oletools directly.

Thanks for your great work.

@jonmoesli
Copy link

Sadly the performance is not optimal forking olevba. Is there a plan to use native API from oletools or the project was just a POC?

Thank you for your work!

@c-rosenberg
Copy link
Member

We are working on a new more generic daemon for oletools and other tools, but it is not ready yet. The olefy tool will stay as is, also because we would need to also change the protocol in Rspamd.

The new damon uses oletools native API and scans in memory. You are right, it's much faster :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants