Sunday, November 24, 2013

We usually need to create an executive report when we are involved in an incident handling. In these cases, a good option could be to include in it a world map with the connections which were established in the incident. Maybe we are interested in showing on a map where the command an control servers are hosted or for example to show which countries the distributed denial of service came from...

To achieve this purpose I am going to show you how to create a map using Wireshark. The last Wireshark version 1.10.2 will be used in this guide.

The first thing we need to do is to  download the GeoIP database: GeoLite City, Country, and ASNum from the link below: http://geolite.maxmind.com/download/geoip/database/ (free download).



Then, we need to put into a folder the files contained in the downloads above, for example "C:\Geoip".


Now, we need to tell Wireshark where the GeoIP files are. To achieve this, we need to open Wireshark and go to Edit -> Preferences - > Name Resolution and click on Edit in the "GeoIP database directories" section...


... and create a New path where the files were saved, in this case "C:\Geoip".


It is necessary to restart Wireshark in order to apply the changes. Now, we only need to load a PCAP file or create a new traffic capture. When we have all the traffic captured and we want to create the map with the connection involved in the incident, we need to go to Statistics -> Endpoints...


... select the IPv4 tab and click on the map bottom. Notice that if for example you have set a filter in Wireshark only with the UDP connections which are related to the malware, you can select "Limit to display filter" in order to only print these connections on the map. Then you click on map.


Finally, we have a dynamic map complete connections on the map. In this case, I've used the PCAP file related to the attack to php.net which can be downloaded from the Barracuda website here.




Posted on Sunday, November 24, 2013 by Javier Nieto

3 comments

Sunday, November 17, 2013

The RFC 1945 says in the 10.15 section:

"The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. Although it is not required, user agents should include this field with requests."

We know that the infected hosts which belong to a botnet make callbacks to the command and control (C&C) server usually through the port 80 which is commonly open in the majority of the networks. Currently the  network security  administrators have "next generation firewalls" which are able to detect if a connection crossing by this port is an standard HTTP connection or not (like a shell on tcp/80 port) in order to allow or drop it. For this reason, some malware developers create malicious binaries with HTTP capabilities and sometimes they use the User-Agent field to send information to the C&C server to achieve their goals. (Notice that if the malware is implementing SSL the next generation firewall administrator would need to configure a SSL decryption in their firewalls if they want to look into these connections)

In this post, I am going to show you some examples which use the User-Agent to transmit information in this HTTP field.

Malware Sample 1

In this example, the malware creates a visual basic script which will be running to connect with the C&C server. We talked about it in the last post Decoding the code encoded. In this case, I could edit the the visual basic in order to change the C&C domain name by the localhost 127.0.0.1 address where I have a netcat listening in the port 80. Netcat will receive the malware connections instead of the C&C server. In the picture below, we can see the result.


  1. This line corresponds to Netcat running in the computer where the malware is being analyzed. It is listening "-l" in the 80/tcp port "-p 80".
  2. We can see the connection executes a POST request.
  3. The malware is sending information about the compromised host in the User-Agent field with no more data in the HTTP body. This is the information which is being send to the C&C server:

    User-Agent: {DiskVolumeSerial}<|>{Hostname}<|>{Username}<|>{OS}<|>underworld final<|>{AVProductInstalled or nan-av}<|>{USBSpread: true or false}

Malware Sample 2

I sent a malware sample to my Cuckoo Sandbox to analyze its behavior and I got a traffic capture. If we use Wireshark to see the connections in the traffic capture, we can filter by "http.user_agent" to show only the information about the requests made by the malware which contains  this field  in the HTTP connections. You can see these connections in the picture below.


Right-clicking in each HTTP request, we can select "Follow TCP Stream" in order to see the data in like the application layer sees it. In the picture below, we can see the Follow TCP Stream of the first connection.

  1. A GET petition including the MAC address of the infected host has been made. Normally the malware sends information with POST connections, but in this case, the malware request a URL with contains the infected computer's  MAC address to send this information to the C&C server in a different way... The MAC address will be register in the remote HTTP server logs.
  2. The User-Agent its the same that the name of the malicious executable. Maybe the malware developer has the same malmare hosted in different servers and he wants to trace them or maybe wants to know the malicious program version.
  3. In the GET connection, the infected host receives three codes: 1,1,0. We would need to dig on it making a reversing engineer to try to figure out what the malware exactly does with these codes.
The next petition the compromised host does, is to make another GET request to the C&C server.

  1. We can see another GET request including the MAC address. Now, the HTTP petition has tree fields: "v1", "v2" and "v3".
  2. The connection continues using the same User-Agent.
  3. Now, the the host receive the "0" code.
In the picture below, we can see that in the next request made by the malware, the User-Agent has changed.

  1. The malware visit "/version" path.
  2. The User-Agent has changed. With this name, we can figure out that the malware is trying to check if it has connection to the Internet but it does not make sense, because the malware has received two codes before in two different petitions...
  3. We can see four different executables separated by @date| . Maybe it is the date when they were compiled.
The next connections are related with the last request which I have described above. We can see how the malware request the same executables it received before. The question here is why it download them twice each binary.



The malware downloads the four executables and changes its User-Agent again when it is requesting them.

  1. The URL path where the malware is hosted.
  2. User-Agent is changed to "installer-agent".
  3. The executable download.
The last connection the malware does is the same that the second one.


 This malware seems to use the User-Agent like it were a radio announcer.

Malware Sample 3

This example came from the Fireye blog and belongs to the well-know Flamer malware.

In the picture below, which has been taken from the blog mentioned above, we can see that the .NET version used by this malware is NET CLR 1.1.2150. This version has not been released by Microsoft ever. It is really difficult to know what these numbers want to say... It may be the malware version...


Malware Sample 4

This example came from the Fireye blog too.

In the picture below (taken from the Fireye blog) we can see that the User-Agent contains the strings "sleep 300000" and a date"ct:Mon Feb 25 23:11:58 2013". It could be possible that the zombie computer is telling the C&C how much time the malware has been sleeping and from what day or maybe it informs to the C&C sever that it received the sleep command.



Conclusion

In this post we have seen how the malware exchanges information with the command and control servers using the User-Agent and the importance of this HTTP field. Many of them do not modify its User-Agent or implements  a well-known User-Agent to try to be undetectable, but if it changes you can create a custom signature for you IDS (Snort, Suricata...) in order to locate more infected hosts in your network which are making connections with the User-Agent customized by the malware.


Posted on Sunday, November 17, 2013 by Javier Nieto

2 comments

Sunday, November 10, 2013

This post is the continuation of the last one: http://www.behindthefirewalls.com/2013/11/hacklu-capturing-flag-v10.html


Remember that in the last post, we obtained the first password "r0b0RUlez!" for the challenge offered by Hack.lu. In this post, I am going to show you how to get the first and the second password using IDA Pro instead of OllyDbg. Ok, let's go...

In order to get the first password we can do a similar thing to we did in the previous post. (I am going to explain this swiftly because it was explained in the previous one).

If we set a breakpoint at "call strcnp" at 0x00401B6C, when the program is being debugged it will be stopped when it is comparing two strings, our password and the real one. After setting the breakpoint, press F9 in order to debug the program.



The program is open and we just need to type a password. In this case, "behindthefirewalls".


If we go to the Stack...


... we can see the the picture below.


  1. Our attempt to figure out the password
  2. The real password which the first one is being compared to.
  3. We are not sure about this string... Could it be the second password?
  4. String which will ask for the second password...
It seems too easy... We type the first password "r0b0RUlez!" which we already know is correct, and we try "u1nnf2lg" as second password...


But it does not work... The next step we can take is to set a breakpoint at "u1nnf2lg" "0x0023FDFC" in the stack, in order to stop the program at this address when it is being debugged and look at the code there... Just press F2 over the string to set the breakpoint.


After pressing OK, you will see a red line where the program will be stoped.


We debug the program again by pressing F9. It is necessary to type the first password again and then, the program will be stopped. But...


... the program has been debugged at, "0x0040161F" instead of "0x0023FDFC" where we set a breakpoint... What is happening? If we look at the assemble code in the picture below, we can see "int 3"... It seems that the software developer is trying to thwart our attempts to make a reverse engineer setting a breakpoint in its executable code source...


Don't worry, the pop up below appears. We need to click on "Change exception definition"...


... tick the "Pass to application"...


... and press OK and Yes and press F9 again.

After that the second password is required. We type for example "behindthefirewalls" and press F9 one more time.


Now, the program is stops at the right address, "0x0023FDFC".


If we look at the assemble code of the stack in a graphic, we can see the picture below where we can check that the program has been stopped at "cmp al, 2". We can see that there is a loop and a "xor eax, 2" instruction...


We can check that the EAX value is equal at 75 in hexadecimal which in ASCII is equal to "u" (the first character of "u1nnf2lg") and then it will be XOR with 0x02. 75 + 2 = 77 in hexadecimal is "w"... We can suppose the first character of the password could be "w"...


What would happen if we XORED with 0x02 the string "u1nnf2lg" which was found at the beginning of our post?

python -c "print ''.join([chr(ord(c) ^ 0x2) for c in 'u1nnf2lg'])"


We have the string "w3lld0ne" which seems to be the second password...


... and Yes!! We win!!!

If we analyze the loop we can say that it XOR with 0x02 character by character the string "u1nnf2lg" and the result is compared character by character with the typed password. If the first XORed character is the same as the first character typed by the user, then continue with the second one and so on... If not, the game is over...


Posted on Sunday, November 10, 2013 by Javier Nieto

1 comment

Sunday, November 03, 2013

Last 22-24 October 2013 hack.lu was celebrated in Luxemburgo. Hack.lu is an open a security convention where usually there is a CTF (capture the flag) competition.

This year the competitors need to get two passwords of a program called RoboAuth.exe which can be downloaded here:


The flag to pass the test is: password1_password2

Ok. Let's go to try to get the first one. To achieve this purpose, we are going to use OllyDbg. Just open the file with this program and click on the play button  to run the program.


We can see a MS-DOS windows which requests us the first Password.


One of the first things I usually do in these cases is to look at "All referenced test strings" in order to find something which draws my attention.


In this case, we can see the string "You passed level1!". We can suppose that just before that, the assemble code will compare our password with the real one.


To go to this string in the assemble code, we right-click on this line and select "Follow in Disassembler".


Now we can see the string mentioned above in the assemble code. Two lines before that, we can see the function "TEST EAX, EAX" wich will make a comparison between our password and the real one. Depending on the result, the program will make a decision. If the password is correct, we will pass the test, if not, the program will be closed.


We can set a breaking point at this point in order to stop the program just when the program is comparing the passwords in order to see the good one in the Stack. To do that, just right click on the line which contains "TEST EAX, EAX", select Breakpoint and select for example, "Memory, on access".


The next step is to write a password and wait until the program stops in the breakpoint.


In the end, we just need to see the Stack window which shows the state of the stack in memory for the thread being debugged. This window is at the bottom right. In the picture below you can see our password "COMPARE..." followed by other string "r0b0RUlez!". It seems to be the password.


If we go to our program and type the password "r0b0RUlez!" on the program, you can check that "You passed level1!".


I've spent some time trying to resolve the second Password but it is more complicated than the previous one. When I have some spare time, I will try it again and I will write a post with the solution.


Posted on Sunday, November 03, 2013 by Javier Nieto

No comments