I’ve just announced it here.
Check it out:
gem install dorothy2
The Italian chapter of the Honeynet Research Alliance
I’ve just announced it here.
Check it out:
gem install dorothy2
Less than a month ago another student got his degree through the Italian Honeynet Project: congratulation to Andrea Cavenago!
Andrea made a very useful extension for Splunk in order to permit us to better monitor our infrastructure among the logs generated by our JDrones, and provided interesting insights on the data collected.
Good job Andrea, and thanks for your contribution!
During the last months two of our valuable students from the University of Milan (SSRI) have successfully graduated by basing their final project on dorothy2 and honeypots.
Salvatore Gervino did a very good work (ita) while extending dorothy2 in order to allow it to analyse malicious emails.
The produced code allows Dorothy to process emails containing malicious attachments, and determine if they could be categorised as Phishing.
His code will be soon merged to the next release of dorothy2, stay tuned!
Calogero Lupo as well did an outstanding job (ita) by improving the overall project’s honeypot infrastructure. His work aimed at developing an honeynet based on Kippo by leveraging the powerful and flexible Amazon Web Service (AWS).
His work illustrates how any willing researcher/analyst could easily setup a wide honeynet implemented among several countries around the world…for free!
The results collected are really interesting, and pave the way for further research.
Congratulations to both then, and a big THANK YOU for your incredible support!.
The version 1.2.0 of Dorothy has been finally released.
Several issues were fixed, and lot of code improved.
This is a major update because since this version, Dorothy will only run on Ruby 1.9.3. So if you have installed a previous version, please upgrade it because older versions relying on Ruby 1.8.7 won´t be maintained anymore.
Very important new features will be soon introduced with the upcoming versions, like:
-a small Sinatra webfront for interactive analysis resumes (finally!) + some handy API
-VNC connection to the sandbox through the vSphere API during the -m manual mode
-behaviour triggers + escalated analysis (if the indicator X is not found, then run the sample into the VM Y , if it isn’t found neither, go to manual mode)
just to name a few
And last but not least, we have now our bug tracking system, so feel free to create an issue whenever something is not working (or for any new features)
The last version of Dorothy introduces lots of improvements.
As first, a new analysis mode has been inserted: the manual analysis.
If Dorothy is executed with the -m parameter, it will fetch the malware, copy it in the sandbox, start the sniffer and pause the whole execution flow waiting for the analyst next action. This flow-controller allows the analyst to log into the sandbox (through RDP for example), and prepare it for ad-hoc runtime scenarios. Or simply to “watch” the system’s behavior once the malicious binary is executed. When Dorothy is executed in this way, the multi-threading is obviously disabled, so one malware at time. Finally, while manual analysis, an interactive console will be prompted by allowing the analyst to control the other Dorothy’s modules/actions e.g. Take screenshot, Save the running processes, etc.
I found it very handy for ad-hoc scenarios, or simply for malware analysis presentations/demos.
BTW: The next version of Dorothy will spawn a VNC session, and connect to the sandbox via the VMWare VNC port (in this way, the network sniffer wont see usual RDP traffic).
Next, Dorothy is now able to detect new spawned processes. Its approach is completely off-the-box and relies on the very basic forensic technique: compare the processes in execution with the ones taken during a “baseline” analysis.
The “baseline” analysis is the novelty of this version. During the first configuration of Dorothy the analyst is driven to make the “baseline” of his sandboxes (currently, is supposed that all the sandboxes are the same i.e. same OS, running process).
Once completed, the baseline analysis will create a yaml file into the Dorothy’s folder, with all the processes in execution among all their details e.g. Creation date, exit Code, etc.
In the future, Dorothy may use this technique to calculate also the filesystem modifications (there is already a method coded into its libs).
Thus, a new table has been created into Dorothive in order to store all the processes information. So if you are upgrading Dorothy from a past version, be sure to read the UPDATE file.
Another important improvement introduced is the extensions file. In order to instruct the sandbox about how to execute the fetched binaries, the analyst can now edit the extenions.yml file and decide how to manage them – e.g. Open PDF file with certain version of Acrobat, Execute exe with certain parameters, and so on.
Lastly, lot of improvements have been made to the code, and now is more readable and reliable.
That’s all for the moment, hope you will enjoy the new version of Dorothy!
Our student Andrea Valerio has just got his Bachelor degree few weeks ago by presenting his great work on recoding the whole Dorothy WGUI module from scratch.
Well done Andrea!
The code will soon be available on this website, and will be included in the next release of the Dorothy2 gem.
His work is summarized in his youtube video (commented in Italian) :
His Degree’s Final Project is also available here: [pdf]
[..]The recent feature was christened under the name “Dynamic Config,” a technology implemented in Citadel v184.108.40.206 “Rain Edition” enabling botmasters smoother, quicker interactions with the victim through browser injection technology. Today’s fraud happens in real time, so speed is of the essence. This nifty function allows Trojan operators to create web injections and use them on the fly, pushing them to selected bots without the hassle of pushing/downloading an entire new configuration file.
How does this happen? It’s actually quite simple. Citadel-infected machines are going to have an instruction to reach out to the C&C every 2 minutes and update themselves with a predefined file where injection “packs” will be ready to go. The whole system will be managed by a clever distribution mechanism dictating which injections go to which bot or group of bots. The format will be fully “Zeus-compatible,” of course. [..]
Although they did not disclose any specific details about how the so called detection actually works, we could inspect it a bit further. It simply scans through the resources of the currently running processes and looks for specific patterns for instance inside the “CompanyName” field, such like:vmwaresandboxvirtualboxgeswallbufferzonesafespaceNevertheless, the tricky part comes here. When a virtualized environment detected, unlike many other Trojans that stop to work, Citadel will continue to operate, but behaves in a different manner. It will generate a unique-machine dependent domain name obviously fake and tries to connect to this server unsuccessfully, making it to believe that the bot is dead and its command and control server is offline, meanwhile the real C&C domain is kept hidden.