14

Always wondered how it would be possible to see what data is being transmitted back and forth with an application that calls home.

Let's say we emulate the server via host file redirect. Would it be possible to see what requests are being made by the application?

Also is it possible at all to intercept the response(and view data) from the real server before it reaches the application?

  • Everything here seems to be HTTP inspection related. For more custom protocols, you could hook ws32.recv and ws32.send respectively as well. I don't think it's a full on answer, but it's an option that bears noting I think. – RobotHumans Apr 6 '13 at 15:13
  • @CallmeV I don't see anything HTTP-specific in the question or answers. – Jonathon Reinhart Apr 9 '13 at 4:37
  • @JonathonReinhart - clarification: many of the answers refer to mostly web proxies – RobotHumans Apr 9 '13 at 6:01
19

You may capture the traffic with packet sniffer to capture all the communications of client\server application, or You may use reverse proxy to intercept and alter data in real time.

In simple words, network sniffers allow You to see data flow between client and server, analyse it and reverse the protocol communications Reverse proxy intercept communication between client and server, allow alter the requests and re-send them, manipulate and examine in real time.

Network sniffers:

WireShark

tcpdump

WinDump

Reverse Proxy:

ZAP (OWASP Project)

Vulture

Burp Proxy

Fiddler (most recommended for Web\malware analysis)

You may see samples of successful use of such technique here:

Intercepting Blackberry Application Traffic

Intercepting SSL traffic using WebScarab

iOS data interception

7

There are a couple of ways that come to mind. The first would be to use a network packet analyzer on the actual client running the application. Some well known packet analyzers are Wireshark, tcpdump, and even Microsoft Network Monitor.

Another alternative would be to intercept the traffic via man-in-the-middle (M. The easiest way to do this (if you control the client) is to turn your Linux based laptop into a wireless access point, and intercept the client's traffic, analyze it, and route it to the internet. This will require 2 network cards, at least one of them being a wireless card.

Here's a tutorial to get you started on performing a mitm attack in this manner: http://www.backtrack-linux.org/forums/showthread.php?t=1939

Or mitmproxy is another great tool to accomplish this (and they support SSL), and have lots of examples on their website.

5

Just before posting this answer I realized he's asking how to do this on windows and my answers is for Mac. I'm posting it regardless because I believe it might be useful for others trying to perform the same thing but then using a Mac

If you're using a Mac, then it's really easy by the combination of a Remote Virtual Interface (rvi) and Wireshark. Note that this does not work if your application uses HTTP/SSL, in that case do what @MickGrove suggests and perform a MITM.

Assume you do have a mac, try this:

  1. Connect your phone/ipad/ipod via USB
  2. Go to system information (use Spotlight or via Apple Logo -> about this mac) and under hardware->USB find your iphone and copy the Serial Number (it's a long hex number)
  3. Open a terminal and type rvictl -s <serialnumber> This will create a network interface called rvi0.
  4. Open wireshark and start sniffing on rvi0
  5. Once done type rvictl -x <serialnumber> to remove the interface
5

If the network traffic is in "plain text" (not encrypted) then a network sniffer such as Wireshark is ideal.

If the network traffic is encrypted via SSL but you have the private key (or if the client application does not validate the server's public key) then you can use a proxy such as Burp.

If the network traffic is encrypted via SSL and you don't have the private key readily available and the client validates the server's public key then you can use a program such as Echo Mirage, which hooks Winsock's send and receive functions, thus giving you access to the plain text before it's encrypted and after it's decrypted.

Alternatively, if network traffic is encrypted using something other than SSL then you'd need to reverse engineer the client software to determine how the encryption and decryption are performed. Your best bet would be to find cross-references to Winsock's send and receive functions and determine how the client encrypts the data before sending it and decrypts it after receiving it.

4

Another option that's pointed out in the comments above by @CallMeV is to use hooking. On Windows you may look at using EasyHook.

1

You can add the HTTP proxy Fiddler to the list if they use a HTTP protocol

0

Well, do you know what is the IP address or domain which the malware is trying to call home? If you do, you can try changing the hosts file located at %systemroot%\system32\drivers\etc\. That way, it won't be able to call home.

Then use Wireshark to sniff the traffic. Once you know the IP address and the port number, you can use the filters to make it more appeasing to the eyes and easier to find the information that you require.

  • A better method would be a transparent proxy which also intercepts the DNS queries. I am aware of such systems that have been used at the anti-malware company for which I work. It was proprietary, however. – 0xC0000022L Apr 6 '13 at 20:07
  • I wouldn't do this with malware: you aren't preventing it from phoning home unless you're absolutely sure it won't contact other hosts than the one you blocked (and if it tries IP addresses, changing hosts won't help a bit). And this isn't a very useful approach anyway, since preventing the application from phoning home is likely to inhibit the interesting behaviors you're trying to observe — if it can't initiate the connection, there won't be any traffic to sniff. – Gilles 'SO- stop being evil' Apr 6 '13 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.