Re: detecting "trinity v3 by self" DDoS agent

[Max <max0r () digitalsamurai org>]

I have had first hand experience with the "trinity ddos tool".
Trinity is probably the most sophisticated DDoS tool I have ever seen.
It uses standard UDP datagrams between the master and the server,
as for encryption, the version I took a look at did not use encrypted
client-server communication.

When connecting to the master port for trinity, it will spit garbage out
at you, waiting for a password. If the password is correct, it will
present you with a menu. The astethic properites of trinity are very
similar to alot of the public DDoS tools, but the devestation caused by
the attacks is unparalled by anything I've encountered.

I no longer have the source code for trinity, it's currently private.
I do however, have source code for several of the attacks it uses.
If anyone is interested in taking a look at these attacks, drop me an
email.



Matt Power wrote:

> On August 16 at approximately 19:20 GMT, a DDoS agent named "trinity
> v3 by self" was installed on about 20 Linux machines on a university
> network, by way of an rpc.statd exploit. (These DDoS agents were, as
> far as I know, all located and removed without them having been used
> for any attack.) I don't know whether the trinity DDoS agent is
> installed at multiple sites, but in case it is, it may be worthwhile
> to scan your network for hosts that accept tcp connections on ports
> 33270 or 39168. Any hosts found (especially Linux hosts that may have
> been running rpc.statd) can be checked for any of the following:
>
>   -- lsof output reporting that a program named /usr/lib/idle.so is
>      listening on tcp port 39168 (this is the DDoS agent itself)
>
>   -- lsof output reporting that a program named /var/spool/uucp/uucico
>      is listening on tcp port 33270
>
>   -- possibly other tcp or udp ports in use by the /usr/lib/idle.so
>      and /var/spool/uucp/uucico programs
>
>   -- modified copies of /bin/ps and /usr/sbin/inetd
>
>   -- new files named /usr/lib/inetd and /usr/lib/libsup.a
>
>   -- a log entry in one of the /var/log/messages* files containing
>      the text "rpc.statd[###]: gethostbyname error for" followed by
>      many more characters including many non-printing characters
>
> The idle.so program contains strings including "udpflood started",
> "synflood started", "rstflood started", "ackflood started", and
> "fragmentflood started", suggesting that it may support a variety of
> DoS methods. The program is able to join an IRC channel and it might
> be the case that trinity uses IRC as the primary communication
> protocol between the attacker and the agents. (This is not necessarily
> the only way for an attacker to communicate with the trinity agents.)
>
> The use of IRC begins with the program selecting the IP address of an
> IRC server, apparently at random, from a list of 11 possible IP
> addresses. It will try to connect to that IRC server using tcp port
> 6667. Upon (at least some types of) connection failure, the program
> will sleep for 5 seconds, then again choose one of the IP addresses at
> random and try to connect. If none of the IRC servers are reachable,
> this loop apparently continues indefinitely.
>
> Watching for outgoing tcp connections on port 6667 thus might be
> another possible way to detect trinity, although I'd suspect that for
> most sites, scanning your own network for the open tcp ports 33270 and
> 39168 would be more efficient. Please feel free to send me e-mail
> about any successful detection of trinity on your network.
>
> Two final comments: (1) I have not seen the trinity source code; (2) I
> did read http://www.sans.org/y2k/082200.htm which mentions a recently
> found DDoS program named MyServer, but I don't yet have any reason to
> suspect that MyServer is related to trinity.
>
> Matt Power
> mhpower () mit edu

--
[FCS] Yea, We Regulate [FCS]