[Snort-sigs] Re: [Packet-ninjas-syn-k1ck] Re: [Infragard-discussion] Port 17300 traffic

daniel.clemens daniel_clemens at ...842...
Sat Feb 22 16:28:08 EST 2003

I have put together a few snort sigs for the Kuang2 Virus/Trojan.
For those that didn't catch the first part of this thread please read the
message below that Gary Warner wrote up giving more detail on why we
performed the inital research on the Kuang2 Trojan.

For now here are some sigs.

alert tcp any 17300 -> any any \
(msg:"to client Generic Kuang2 Infection"; \
content:"YOK2"; \
depth: 50; \

alert tcp any any -> any 17300 \
content:"QUIT"; \
depth: 4; \

// these two i have not validated, but just eyeball'd em.

alert tcp any any -> any 17300 \
(msg:"Remote File Infector -Kuang2 TROJAN"; \
content:"Kuang2 Infector.exe <10k>"; \
depth: 45; \

alert tcp 17300 any -> any any \
(msg:"Successful Remote Infection -Kuang2 TROJAN"; \
content:"DONE"; \
depth: 4; \

Msg. for Snort crew.
For the Snort-Sigs crew I will post the packet captures later next week
when I have time.

For a more complete reference listing, and this should give people a
place to run their own validation on these rules because I might have
messed something up.

Brian, Chris - please feel free to give me any pointers on things that
might need to be cleaned up or implemented in a different way. I don't
live and breath this stuff like you guys, so you might have things to
change like the 'Msg' etc.

I fill properly fill out the form on the snort website once I get things
posted on our website and we put all the information we have on this
trojan/virus into a pdf or txt file.

Hope this helps everyone... or someone.

-Daniel Uriah Clemens

On Wed, 19 Feb 2003, Gary Warner wrote:

> Birmingham Infragard's "Packet Ninjas" club met last night (until almost
> 2 o'clock this morning) and built a Kuang2 Lab.  Our host, Daniel
> Clemens, and member Thomas Torgeson and myself (and 1 non-member who I
> believe wants to remain nameless) were in attendance and geeked out for
> about 6 hours.
> Here is the quickee version of what we think is going on.  We have an
> enormous amount of data to analyze from last night, and that might
> change my assessment, but this is first thoughts.
> (Hopefully we will be releasing specific snort signatures that will
> differentiate between a "probe" and an "active exploitation"  Dan and
> Thomas were both running full captures of everything in the lab and we
> have a LOT of work to do!).
> This is a *THEORY* based on the assumption that this traffic may
> actually be the original Kuang2.  The next phase of our project is to
> compare OUR capture streams from the lab with what is going on in the
> wild.  If you have tcpdumps or other captures of active "wild" 17300
> traffic, please let me know so we can use your data to help shape our
> findings.
> === Theory ===
> Kuang2 was a no big deal virus in 1999.  Basically, if you execute a
> Kuang2 infected executable, it will infect every .exe on your box that
> is capable of a "PE Insertion" infection.  The code is very tight with
> regards to knowing what it can safely infect and what it can't, so the
> infected files, although larger by nearly 12k, still function in every
> way the same as the original.
> The problem with Kuang2, as compared to the email mass-mailers of today,
> was that it had very limited propagation.  There was no way to spread it
> from machine to machine built in to the system.
> Enter Kaazaa and other Peer-to-Peer file sharing systems.
> Now a mal-ist can place a Kuang2 infected program in his kaazaa shares
> directory, and it can actually be a Very Hot Warez title.  Perhaps it
> really is a copy of COmmand and Conquer Generals, or some other "hot
> game".  Kaazaa folks tend to reshare their warez, so whoever acquires
> the program, when they run it (if they are not anti-virused) will infect
> every possible .EXE on their box.  (Including all of the .EXE files in
> their kaazaa shares directory.)  Every person who retrieves those files
> and runs them will have a listener on 17300.
> We tested the "old" Kuang2 on Windows 98, NT 4, and 2000 last night in
> our lab.  An infected .EXE created on any of those platforms and shared
> to any of the other platforms WILL INFECT.  It is not windows version
> dependent.  (Windows 2000 did alert us on reboot that critical system
> files had been changed.  I'm sure XP would do the same).
> The Kuang2 Virus/Trojan has three components:
> An "Infector"
> A "Virus Block"
> A "Client"
> Using the Infector, the mal-ist chooses a popular .exe file and infects
> it by inserting the block of virus code into the .exe.  The .exe must
> then be executed by a target.  Once that is done, the Client is launched
> by the mal-ist.  The Client is a GUI that lists all files on the hard
> drive of the target in "explorer style" tree format.  One can navigate
> the files, "Upload" "Download" or execute "Remote Command" from the
> GUI.  There is also an "Antivirus" button in the GUI, which will remove
> all traces of the infection from the infected machine.
> So, our theory is that what we are seeing is a version of Kuang2 that
> actually has a means of spreading, but unlike the original Kuang2, where
> one emailed an intended victim and then checked to see if his machine
> was infected, the new spread method allows much wider propagation
> causing the mal-ist to have to do wide-spread searches for infected
> machines that he can remote control with the Kuang2 Client.
> Where a single 17300 query bounces off a non-listening port, there is no
> problem.  What concerns me is where there is an extended session.  Both
> the listening and the sending port of a Kuang2 session are 17300.  If
> there is two way traffic, someone is actively using a trojan interface
> to this box.
> Looking at the Incidents.Org information, it is apparent that
> exploitation is actually occurring.
> When numbers of "Targets" and "Records" are similar in number, we can
> assume that a probe knocked on an IP addresses door, and was turned away
> because no one was listening.
> (Examples:
>    Feb 3 -- 82 targets returned 121 records
>    Feb 4 -- 214 targets returned 314 records
> )
> When the number of "Records" greatly exceeds the number of "Targets",
> then the assumption is that a connection has been established and files
> have been transferred.
>  (Examples:
>    Feb 10 -- 1491 targets returned 18,557 records
>    Feb 12 -- 3988 targets returned 71,997 records
> )
> ============
> *IF* the theory is correct, then we would do well to be Very Very
> Alarmed.  Because, in this theory, the number of "Sources" indicates the
> sum of "Client Machines" and "Infected AND EXPLOITED Machines".  Since
> both the client and the server are using port 17300, the fact that there
> are 995 sources listed on Feb 19 (SO FAR TODAY!!!!) can indicate either
> that a small number of mal-ists have successfully connected to a large
> number of targets -- (5 mal-ists could have established sessions to 990
> infected machines).  OR that we have a large and growing number of
> mal-ists.  (The number COULD mean that 200 mal-ists hit a total of 795
> infected machines.)
> Couple more scary facts:
>   On Feb 15 there were 232,153 records from incidents.org's database
> related to this.
>   On Feb 17 there were 1425 sources!
> The Birmingham InfraGard Packet Ninjas will provide updates as our
> analysis continues.  In the meantime, if you would like to participate,
> please join the mailing list:
>        http://birmingham-infragard.org/mailman/listinfo/packet-ninjas
> OR just contact myself (Gary Warner - gar at ...1314...) or Daniel Clemens,
> our Resident Packet Ninja (daniel_clemens at ...729...).  We
> really need to see some "in the wild" packet captures to add to our
> information.
> _-_
> gary warner
> birmingham infragard
> _______________________________________________
> Packet-ninjas mailing list
> Packet-ninjas at ...729...
> http://birmingham-infragard.org/mailman/listinfo/packet-ninjas

-Daniel Uriah Clemens
Esse quam videra
    		(to be, rather than to appear)
http://www.birmingham-infragard.org   | 2053284200 | 877.806.8928

More information about the Snort-sigs mailing list