Worm_agent.ad


 
Thread Tools Search this Thread
Special Forums Cybersecurity Malware Advisories (RSS) Worm_agent.ad
# 1  
Old 05-01-2008
Worm_agent.ad

This worm may be dropped by other malware.
It may be downloaded unknowingly by a user when visiting malicious Web site(s).
This worm registers itself as a system service to ensure its automatic execution at every system startup. It does this by creating registry key(s)/entry(ies).
It also creates other registry key(s)/entry(ies) as part of its installation routine.
This worm drops copies of itself in all physical and removable drives.
It drops an AUTORUN.INF file to automatically execute dropped copies when the drives are accessed.

It drops component file(s), including TROJ_AGENT.OTJ. A certain dropped file replaces the legitimate file of the same name in the Windows system folder.
It connects to a Web site to download a text file. The downloaded text file contains a list of malware download sites. As a result, the routines of the downloaded files may be exhibited on the system.

More...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question
FS(4)							     Kernel Interfaces Manual							     FS(4)

NAME
fs - file server, dump SYNOPSIS
none DESCRIPTION
The file server is the main file system for Plan 9. It is a stand-alone system that runs on a separate computer. It serves the Plan 9 protocol on a variety of networks including Datakit/URP, Ethernet IL/IP and Cyclone fiber direct connections. The name of the main file server at Murray Hill is bootes. The file server normally requires all users except to provide authentication tickets on each attach(5). This can be disabled using the noauth configuration command (see fsconfig(8)). The user none is always allowed to attach to bootes without authentication but has minimal permissions. Bootes maintains three file systems on a combination of disks and write-once-read-many (WORM) magneto-optical disks. other is a simple disk-based file system similar to kfs(4). main is a worm-based file system with a disk-based look-aside cache. The disk cache holds modified worm blocks to overcome the write- once property of the worm. The cache also holds recently accessed non-modified blocks to speed up the effective access time of the worm. Occasionally (usually daily at 5AM) the modified blocks in the disk cache are dumped. At this time, traffic to the file sys- tem is halted and the modified blocks are relabeled to the unwritten portion of the worm. After the dump, the file system traffic is continued and the relabeled blocks are copied to the worm by a background process. dump Each time the main file system is dumped, its root is appended to a subdirectory of the dump file system. Since the dump file sys- tem is not mirrored with a disk cache, it is read-only. The name of the newly added root is created from the date of the dump: /yyyy/mmdds. Here yyyy is the full year, mm is the month number, dd is the day number and s is a sequence number if more than one dump is done in a day. For the first dump, s is null. For the subsequent dumps s is 1, 2, 3, etc. The root of the main file system that is frozen on the first dump of March 1, 1992 will be named /1992/0301/ in the dump file sys- tem. EXAMPLES
Place the root of the dump file system on /n/dump and show the modified times of the MIPS C compiler over all dumps in February, 1992: 9fs dump ls -l /n/dump/1992/02??/mips/bin/vc To get only one line of output for each version of the compiler: ls -lp /n/dump/1992/02??/mips/bin/vc | uniq Make the other file system available in directory /n/bootesother: mount -c /srv/boot /n/bootesother other SOURCE
/sys/src/fs SEE ALSO
yesterday(1), srv(4), fs(8) Sean Quinlan, ``A Cached WORM File System'', Software - Practice and Experience, December, 1991 FS(4)