Notes about release 1.66:

After a long time I have added new entries to BSA.DAT.

I added new malware behaviors: DLL registration at COM, execution of a Windows Script, ...

I fixed and improved reports a bit.

I fixed and improved "Dump Executable Processes" feature. I added the use of MDmp tool by Vlad-Ioan Topan. Now the feature is able to dump certain processes that before was not possible.

Released Buster Sandbox Analyzer 1.67.

Changes:

+ Improved “[File_Strings]” section at BSA.DAT
+ Added “[Custom_LogAPI_Entries”] section to BSA.DAT
+ Added support for wildcards in RegistryExclude.TXT
+ Added support for Hexacorn´s HexDive tool
+ Added new malware behaviours
+ Included new malware behaviours at “Risk Evaluation Ratings”
+ Added LOG_API support for 64-bit applications

Comments about version 1.67 release:

Improved “[File_Strings]” section at BSA.DAT

Now it is possible to assign a description (it is optional, not mandatory) to the strings. So if we define this:



in REPORT.TXT we would get something like this:



And in ANALYSIS.TXT we would get something like this:



As you can see, the information is more clear in both the report and the analysis files.


Added “[Custom_LogAPI_Entries”] section to BSA.DAT

Similar to previous feature, I created a new entry in BSA.DAT to define strings that may appear in LOG_API.TXT file.

In the section we can define a string to look for and a description for it. Like this:



Coincidences will appear in ANALYSIS.TXT only as this:




Added support for wildcards in RegistryExclude.TXT

This gives more flexibility to discard registry keys.


Added support for Hexacorn´s HexDive tool

You can find a description of the tool here: http://www.hexacorn.com/blog/


Added LOG_API support for 64-bit applications

BSA had been lacking of a LOG_API version compatible with 64-bit applications. From this version is already available.

I made some tests and the Sandboxie hiding capabilities in 64-bit OSs are not good. I do not know why but meanwhile 32-bit version of LOG_API is able to hide SbieDll.dll, the 64-bit can not.

Keep that in mind if you analyze malware in a 64-bit environment.

I forgot to mention in the changes, but as usual I fixed several bugs:

+ "Fixed" a problem with Exeinfo crashing on certain files.
+ Fixed a bug related to API logging in manual mode.
+ Fixed a problem when generating additional information on certain files.
...

I made little testing of LOG_API for 64-bit applications: I tested it with 64-bit versions of Notepad and TaskManager and it worked fine.

I compiled an application in 64-bit and the program crashed. I noticed the problem was the injected DLL.

Resuming: at the moment don´t use LOG_API 64-bit version.

Hi Buster

Haven't been here for a while but testet your latetest version and it is running very good here - Thank you for your hard work !!!
Hey, would it be possible to get the URL-Analyzer integrated into the Command Line Option? I'm thinking of something like:


Would be good to check out a list of URLs in Automatic Mode...
Can you please explain what BSA is doing if the URL is a webpage (w*w.1.com/a.html) that might contain a link to a file and if the URL is directly to a file (w*w.1.com/a.exe)?


And another question:
Is there a way to define a custom CSS for the HTML report rather then having the CSS defined in the HTML directly? That way content (report) and design (CSS) are separate and easy to adjust in the future and the report could be integrated into a existing (Honeypot-)website.

Is there an option planed to let the user specific what information he wants in the HTML reports? Like program option for MD5 & SHA1 are ticked but User wants in HTML Report only MD5 should come up + Fileinfo and PE-Imports.


Thanks,
Scrapie

Thanks!



I will add this to my feature request list.



If the URL is an .HTML file, BSA launches IE and loads the URL. If there is not any exploit that loads a link to a file that the URL might contain, then nothing happens. BSA is not a link crawler so if things do not get executed automatically, IE will just load the URL normally.

If the URL is directly a file and the file is executable (.exe), in that case BSA downloads the file and executes it locally for analysis.



I suggest you create your custom HTML reports from the data contained in REPORT.TXT.



No, I will not do something like that.

If you want personalized HTML reports I suggest again you create them from the data contained in REPORT.TXT.

You must understand I can not implement custom reports for HTML, JSON, XML, PDF or any other formats I may add when it´s much more simple that if someone wants customized reports he builds them.

Hi Buster,

thanks for your fast reply
Thanks also for adding the URLs to your request list !

With the reports:
Fair enough. It's not a big deal to write a little tool that goes through the various txt's and generates a html which uses a external CSS. I'm thinking of writting something like a little Report-Builder for BSA that gives users more flexibility handeling the various reports. Would such a program be usefull?

While going through the html & the txt one thing came to my attention. If a program opens a URL, this is not shown in the HTML-Report under "Network services". Not sure if that is okay or a bug. Example of Report.txt:

In Report.html the last point (Opens next URLs:) is missing.


A total different question now - the logged APIs:
That feature is great but to keep the amount of information low, is there a list of suspicious / harmfull calls? I'm thinking of only logging these calls rather then log the whole lot. Sorry, I'm not really into API-Calls so I don't know if that is a stupid idea or not...


Thanks,
Scrapie

I am satisfied with actual HTML format and so far nobody but you talked about doing something like that. If you are interested do it for you and when it´s finished, offer it publicly. That will not harm.



I will take a look. Thanks for the feedback!



You usually get many "GetModuleHandle" in API log, and around 97-99% of the time are harmless calls, but in the other 1-3% you may get a "GetModuleHandle(sbiedll.dll)" which is a clear indication of suspicious activity.

You could filter "FreeLibrary" API i.e. as it´s not used for any malicious behavior. "ExitProcess" could be discarded too.

You will have to dig in this issue and exclude stuff based in your experience.

What would be a smart way to end FakeNet (send CTRL+C to cmd) after every program in sandbox is terminated but before BSA is doing it's Virustotal-Check in Auto-Mode? Because if FakeNet is still running at this stage, BSA wont be able to go out and check ...


Cheers,
Scrapie

There was a mistypo in the code that caused that opened URLs were not being showed in HTML and XML reports.

This bug will be fixed in next version.

Added support to analyze URLS from command line.

Command line format: BSA -s or -m time -url URL or file

Example:

BSA -s 120 -url http://www.sandboxie.com

BSA -m 2 -url c:\test\urls.txt

Hmmmm... this gives me an idea!

I will do some research and if I get something out of this, I will come back here to comment.

Sending CTRL+C to FakeNet´s cmd window was not a simple task at all. When I had a working method I noticed that only works when the window is visible, but not when it´s hidden. As I plan running FakeNet in a hidden window, I had to start again looking for other methods to do the task.

After several hours googling I finally found a working method to do it!

FakeNet´s integration with BSA is very advanced. I just miss processing the logs created with FakeNet.

As soon as I have something working I will send you a beta for testing.

Very good !!!

Send you an email about the latest beta.
Looking forward to test BSA with FakeNet


Scrapie

Released Buster Sandbox Analyzer 1.68.

Changes:

+ Added support to analyze URLs from command line
+ Added support for FakeNet
+ Updated ssdeep tool to version 2.8
+ Updated BSA.DAT
+ Updated LOG_API
+ Fixed several bugs