We were recently able to sinkhole a CARBERP command and control (C&C) server, similar to the way in which we sinkholed a ZeuS C&C in March of this year. This post will explain our findings during the said activity.
The results have basically led us to conclude that CARBERP has proven once more that malware creators are getting better at hiding and establishing their creation’s covert communications, and that today’s establishments are ill-prepared to deal with issues such as when a previously undetected botnet exposes private information.
This botnet is purported to have been deployed since early 2010, but managed to avoid attention until September of last year. Malware Intelligence reported in February 2010 that new CAB files were added specifically targeting the theft of certificates, keys, and banking credentials. Trust Defender reported in October of last year that CARBERP was able to control Internet traffic by hooking the export table of WININET.dll and USER32.dll. Seculert.com reported at the beginning of February 2011, how uniquely generated RC4 keys encrypt subsequent exchanges and compromised data.
Easier to Not Ask for Permission
The CARBERP C&C represents a repository of plugins designed to compromise various applications running in a version of Windows. After the first logging, CARBERP bots offer the currently running processes by posting a “/set/first.html” and then request plugins by posting a “/set/plugs.html” or acquire a task by “/set/task.html.”
CARBERP is also able to operate within user privileges and not make registry or system file changes. It takes advantage of file system features to hide its presence. CARBERP also adds a startup link, as do many applications, and is able to spoof websites, do key-logging, and establish covert communications using encoded messages. CARBERP may be revealed by processes not associated with a visible file.
Findings of C&C Traffic
A Command & Control server for the CARBERP botnet was replaced with a server that only logged connections, but did not prompt for subsequent data exchanges. The dummy CARBERP C&C also was not assigned IPv6 addresses, which may have been a mistake. There was a large disparity with some victims attempting to resolve this server using IPv6 addresses versus IPv4 by more than two orders of magnitude. Subsequent HTTP connections were also minimal. From this it seems communications carrying sensitive information may have been relayed elsewhere, blocked by network policies, or prevented because of incomplete C&C exchanges.
|Victim Sectors||Victim Domains|
Why These Targets?
We contacted identifiable hosts that may have been affected by CARBERP infections monitored by the particular C&C. Without details of the information that may have been compromised, it would be conjecture as to why these particular victims were the focus of the C&C.
Leave a reply