quick question where did you get the bits of code you were talking about in your opening post
Printable View
quick question where did you get the bits of code you were talking about in your opening post
TH13: After the attacker successfully install his bot, why use a https session anyway?
since https traffic is 10% of traffic (got here at my client) why botter to use a small traffic to "cover" your activity?
The bot can use a regular http session to do that. Its pretty common http tunnels (including source) on internet. for free. To establish a C&C base, attacker can use a "normal" http session to comunicate with bot, since it will be hard to monitor (and analyze) each piece of http passing thru firewall.
Maybe a traffic behavior analysis can get those guys (since that is pretty uncommon to see a very long session on http/https) but if its a 1 minute surf it will be tough to see.
Here we are trying to do that (to capture http tunneling) but we are not been succesfull most of the time.
For example, im one of the "testers" (some of us from tech support were asked to start and do http tunneling from time to time) and until now (3 months) they didnt caught me :)
And im using a free sw (httport) with default server. Its really hard when you have a T3 connection to internet and its is been used up to the top.
cacosapo:
I can write Snort rules for HTTP traffic because it is in clear. The SSL connection is encrypted so I can't predict the patterns to match.
I noticed that, TS; however, we couldnt identify a pattern on some traffic that made it diferent from a normal one. What should i look for on http packets?Quote:
Originally posted here by Tiger Shark
cacosapo:
I can write Snort rules for HTTP traffic because it is in clear. The SSL connection is encrypted so I can't predict the patterns to match.
what we already tried (and failed):
destination host
long sessions (in my case i start the tunnel, start mirc, send a couple of msg for about 1 minute and disconnect)
http command and text. (they didnd realized that they can trace /join or other cmds, but its only valid for a irc. a bot can use other protocols to talk, even acessing some pages to xfer info as a covert channel)
There are bleeding snort rules for this. Also, like Tiger mentioned, we can spot unencrypted sessions a mile away. The botnet operators know that hiding traffic using widely used protocols such as SSL and SSH will make it difficult to spot them. They are also taking measures so that network devices will miss the traffic, thus, creating a 100% covert operation (or very close to it).
Sorry, I cannot reveal this.Quote:
quick question where did you get the bits of code you were talking about in your opening post
He wrote them.... ;)Quote:
Sorry, I cannot reveal this.
cacosapo: This will be one of those "wait and see" things. We can't write the rules to match a pattern in a packet until we see the packet streams and determine what the constants are in an "in clear" datastream. In an encrypted stream there won't be any constants which makes it impossible to write a rule to match a pattern in a data stream.
It's going to be a problem.
There are security applications that store hashes of known programs via local database and vendor supplied database. For instance winword.exe with the familiar icon association has a nice recorded hash. If I change the icon association (nice common antvirus avoidance mechanism) or rename or copy winword.exe the hash changes and therefore a rule that says any uncategorized exe com or whatever will never be executed will alarm security eyes and prevent the infection in the first place. In addition ssh traffic patterns can be monitored for increase and location of infection machines when traversing the firewall or web filtering appliance.
Baselining this will be a pain too. I know one of our sister agencies has an app that posts via SSL over the net. The problem is that the damned app opens about 15-20 SSL streams every time they work on it. Then there's all the users who are just getting into internet banking and so the baseline changes regularly as they go online. It won't be fun chasing these down every week and often the SSL server is an unresolvable host forcing more in-depth investigation. Don't try asking the user "Where you banking or shopping at 10:00am today" because they know that it is against policy but, apparently, their mommies omitted to tell them that lying is a bad thing... :rolleyes:Quote:
In addition ssh traffic patterns can be monitored for increase and location of infection machines when traversing the firewall or web filtering appliance.
In that case I would rely on application based filtering. You use websense Tiger. Client Policy Manager can lock down application infection not even antivirus and firwalls can stop. :D And if you run into that one critical application that gets locked because it was updated without your knowledge then it can be restored on the fly. Before that I used the web filter to track my spyware and find those pesky internal mail hosts spamming away because they clicked "do you want to stop pop ups?"
Now, here's my problem.... I don't use websense.... ;)
I use SurfControl.... But I really don't want to have to start discovering and entering all the valid apps..... Please, don't make me do it.... :(