Last Updated: 2013-08-13 02:29:29 UTC
by Bojan Zdrnja (Version: 1)
Couple of days ago, one of our readers, submitted a script he identified as sending some weird traffic to the IP address of 220.127.116.11.
The script in question is a PHP script and was not obfuscated so it was easy to analyze what it does. It also appears that certain details were, unfortunately, missing.
It looks as the submitted script crawls over the xat.com web site to retrieve information about registered accounts. I'm not quite sure what people do on xat.com – it appears that, besides chatting they can also trade some things in "xats" – I'm not quite sure what this is about (if you do know please let me know or post in comments :).
The script uses a local database – unfortunately the file specifying the database connection parameters was missing. It then goes into a loop that is supposed to crawl information about xat.com users. The loop uses curl to do the crawling and the method doing the crawling is supposed to use a different proxy for every request. The list of proxies is stored in a file called proxies.txt – unfortunately that file was missing too.
However, the snippet of code below explains why Haren saw network traffic to 18.104.22.168:
If the script failed to load the list of proxies, the $ip variable that is later used to set the curl proxy is automatically populated with 22.214.171.124 and this will, obviously fail.
What the script really tries to do is retrieve an URL from xat.com (i.e. it request something like http://xat.com/web_gear/chat/auser3.php?t=100000232434, where the t variable is randomly generated).
After retrieving that URL, depending on the results, the script checks the received user’s ID. If the user ID was not found, the script considers it to be a rare user ID and stores it in the database. I’m not sure what this is used for later unfortunately (as I failed to figure out what xat.com really does).
This is another example why it really pays to monitor your outgoing traffic. Our reader in this case had a SIEM product that allowed him to inspect outgoing traffic on port 80 – if you see one of your servers sending traffic to 126.96.36.199 on port 80, this is something that warrants more analysis for sure.
Just as a reminder, I posted two diaries about analyzing outgoing network traffic almost exactly a year ago – check them at https://isc.sans.edu/diary/Analyzing+outgoing+network+traffic/13963 and https://isc.sans.edu/diary/Analyzing+outgoing+network+traffic+%28part+2%29/14002