Archive for November, 2008

10+ things you should know about rootkits


By Michael Kassner, Techrepublic

Malware-based rootkits fuel a multibillion dollar spyware industry by stealing individual or corporate financial information. If that weren’t bad enough, rootkit-based botnets generate untold amounts of spam. Here’s a look at what rootkits are and what to do about them.

Rootkits are complex and ever changing, which makes it difficult to understand exactly what you’re dealing with. Even so, I’d like to take a stab at explaining them, so that you’ll have a fighting chance if you’re confronted with one.

#1: What is a rootkit?

Breaking the term rootkit into the two component words, root and kit, is a useful way to define it. Root is a UNIX/Linux term that’s the equivalent of Administrator in Windows. The word kit denotes programs that allow someone to obtain root/admin-level access to the computer by executing the programs in the kit — all of which is done without end-user consent or knowledge.


#2: Why use a rootkit?

Rootkits have two primary functions: remote command/control (back door) and software eavesdropping. Rootkits allow someone, legitimate or otherwise, to administratively control a computer. This means executing files, accessing logs, monitoring user activity, and even changing the computer’s configuration. Therefore, in the strictest sense, even versions of VNC are rootkits. This surprises most people, as they consider rootkits to be solely malware, but in of themselves they aren’t malicious at all.

One famous (or infamous, depending on your viewpoint) example of rootkit use was Sony BMG’s attempt to prevent copyright violations. Sony BMG didn’t tell anyone that it placed DRM software on home computers when certain CDs were played. On a scary note, the rootkit hiding technique Sony used was so good not one antivirus or anti-spyware application detected it.

#3: How do rootkits propagate?

Rootkits can’t propagate by themselves, and that fact has precipitated a great deal of confusion. In reality, rootkits are just one component of what is called a blended threat. Blended threats typically consist of three snippets of code: a dropper, loader, and rootkit.

The dropper is the code that gets the rootkit’s installation started. Activating the dropper program usually entails human intervention, such as clicking on a malicious email link. Once initiated, the dropper launches the loader program and then deletes itself. Once active, the loader typically causes a buffer overflow, which loads the rootkit into memory.

Blended threat malware gets its foot in the door through social engineering, exploiting known vulnerabilities, or even brute force. Here are two examples of some current and successful exploits:

* Instant Messenger (IM) — One approach requires computers with IM installed (not that much of a stretch). If the appropriate blended threat gains a foothold on just one computer using IM, it takes over the IM client, sending out messages containing malicious links to everyone on the contact list. When the recipient clicks on the link (social engineering, as it’s from a friend), that computer becomes infected and has a rootkit on it as well.
* Rich content — The newest approach is to insert the blended threat malware into rich-content files, such as PDF documents. Just opening a malicious PDF file will execute the dropper code, and it’s all over.

#4: User-mode rootkits

There are several types of rootkits, but we’ll start with the simplest one. User-mode rootkits run on a computer with administrative privileges. This allows user-mode rootkits to alter security and hide processes, files, system drivers, network ports, and even system services. User-mode rootkits remain installed on the infected computer by copying required files to the computer’s hard drive, automatically launching with every system boot.

Sadly, user-mode rootkits are the only type that antivirus or anti-spyware applications even have a chance of detecting. One example of a user-mode rootkit is Hacker Defender. It’s an old rootkit, but it has an illustrious history. If you read the link about Hacker Defender, you will learn about Mark Russinovich, his rootkit detection tool called Rootkit Revealer, and his cat-and-mouse struggle with the developer of Hacker Defender.

#5: Kernel-mode rootkit

Malware developers are a savvy bunch. Realising that rootkits running in user-mode can be found by rootkit detection software running in kernel-mode, they developed kernel-mode rootkits, placing the rootkit on the same level as the operating system and rootkit detection software. Simply put, the OS can no longer be trusted. One kernel-mode rootkit that’s getting lots of attention is the Da IOS rootkit, developed by Sebastian Muniz and aimed at Cisco’s IOS operating system.

Instability is the one downfall of a kernel-mode rootkit. If you notice that your computer is blue-screening for other than the normal reasons, it just might be a kernel-mode rootkit.

#6: User-mode/kernel-mode hybrid rootkit

Rootkit developers, wanting the best of both worlds, developed a hybrid rootkit that combines user-mode characteristics (easy to use and stable) with kernel-mode characteristics (stealthy). The hybrid approach is very successful and the most popular rootkit at this time.

#7: Firmware rootkits

Firmware rootkits are the next step in sophistication. This type of rootkit can be any of the other types with an added twist; the rootkit can hide in firmware when the computer is shut down. Restart the computer, and the rootkit reinstalls itself. The altered firmware could be anything from microprocessor code to PCI expansion card firmware. Even if a removal program finds and eliminates the firmware rootkit, the next time the computer starts, the firmware rootkit is right back in business. John Heasman has a great paper called “Implementing and Detecting a PCI Rootkit” (PDF).

#8: Virtual rootkits

Virtual rootkits are a fairly new and innovative approach. The virtual rootkit acts like a software implementation of hardware sets in a manner similar to that used by VMware. This technology has elicited a great deal of apprehension, as virtual rootkits are almost invisible. The Blue Pill is one example of this type of rootkit. To the best of my knowledge, researchers haven’t found virtual rootkits in the wild. Ironically, this is because virtual rootkits are complex and other types are working so well.

#9: Generic symptoms of rootkit infestation

Rootkits are frustrating. By design, it’s difficult to know if they are installed on a computer. Even experts have a hard time but hint that installed rootkits should get the same consideration as other possible reasons for any decrease in operating efficiency. Sorry for being vague, but that’s the nature of the beast. Here’s a list of noteworthy symptoms:

* If the computer locks up or fails to respond to any kind of input from the mouse or keyboard, it could be due to an installed kernel-mode rootkit.
* Settings in Windows change without permission. Examples of this could be the screensaver changing or the taskbar hiding itself.
* Web pages or network activities appear to be intermittent or function improperly due to excessive network traffic.

If the rootkit is working correctly, most of these symptoms aren’t going to be noticeable. By definition, good rootkits are stealthy. The last symptom (network slowdown) should be the one that raises a flag. Rootkits can’t hide traffic increases, especially if the computer is acting as a spam relay or participating in a DDoS attack.

#10: Polymorphism

I debated whether to include polymorphism as a topic, since it’s not specific to rootkits. But it’s amazing technology that makes rootkits difficult to find. Polymorphism techniques allow malware such as rootkits to rewrite core assembly code, which makes using antivirus/anti-spyware signature-based defences useless. Polymorphism even gives behavioural-based (heuristic) defences a great deal of trouble. The only hope of finding rootkits that use polymorphism is technology that looks deep into the operating system and then compares the results to a known good baseline of the system.

#11: Detection and removal

You all know the drill, but it’s worth repeating. Be sure to keep antivirus/anti-spyware software (and in fact, every software component of the computer) up-to-date. That will go a long way toward keeping malware away. Keeping everything current is hard, but a tool such as Secunia’s Vulnerability Scanning program can help.

Detection and removal depends on the sophistication of the rootkit. If the rootkit is of the user-mode variety, any one of the following rootkit removal tools will most likely work:

* F-Secure Blacklight
* RootkitRevealer
* Windows Malicious Software Removal Tool
* ProcessGuard
* Rootkit Hunter (Linux and BSD)

The problem with these tools is that you can’t be sure they’ve removed the rootkit. Albeit more labour-intensive, using a bootable CD, such as BartPE, with an antivirus scanner will increase the chances of detecting a rootkit, simply because rootkits can’t obscure their tracks when they aren’t running. I’m afraid that the only way to know for sure is to have a clean computer, take a baseline, and then use an application like EnCase to check for any additional code.

Final thoughts

Opinions vary when it comes to rootkit removal, as discussed in the NetworkWorld article “Experts divided over rootkit detection and removal”. Although the article is two years old, the information is still relevant. There’s some hope, though: Intel’s Trusted Platform Module (TPM) has been cited as a possible solution to malware infestation. The problem with TPM is that it’s somewhat controversial. Besides, it will take years before sufficient numbers of computers have processors with TPM.

If you’re looking for additional information, I recommend the book ROOTKITS: Subverting the Windows Kernel, by Gary Hoglund and James Butler, of HPGary.


Samurai Web Testing Framework – Web Application Security LiveCD


Most penetration tests are focused on either network attacks or web application attacks. Given this separation, many pen testers themselves have understandably followed suit, specializing in one type of test or the other. While such specialization is a sign of a vibrant, healthy penetration testing industry, tests focused on only one of these aspects of a target environment often miss the real business risks of vulnerabilities discovered and exploited by determined and skilled attackers. By combining web app attacks such as SQL injection, Cross-Site Scripting, and Remote File Includes with network attacks such as port scanning, service compromise, and client-side exploitation, the bad guys are significantly more lethal. Penetration testers and the enterprises who use their services need to understand these blended attacks and how to measure whether they are vulnerable to them. This session provides practical examples of penetration tests that combine such attack vectors, and real-world advice for conducting such tests against your own organization.

The Samurai project team is happy to announce the release of a development version of the Samurai Web Testing Framework. This release is currently a fully functional linux environment that has a number of the tools pre-installed. Our hope is that people who are interested in making this the best live CD for web testing will provide feedback for what they would like to see included on the CD.

The Samurai Web Testing Framework is a live linux environment that has been pre-configured to function as a web pen-testing environment. The CD contains the best of the open source and free tools that focus on testing and attacking websites. In developing this environment, we have based our tool selection on the tools we use in our security practice. We have included the tools used in all four steps of a web pen-test.

Starting with reconnaissance, we have included tools such as the Fierce domain scanner and Maltego. For mapping, we have included tools such WebScarab and ratproxy. We then chose tools for discovery. These would include w3af and burp. For exploitation, the final stage, we included BeEF, AJAXShell and much more. This CD also includes a pre-configured wiki, set up to be the central information store during your pen-test.


read more here

or download here

Vista, Routing and NAT. Is that Possible?


today, i found something interesting in Vista Networking. when i used Windows XP Professional i found networking tools called netsh with a lot of functional to configure WinXP as a router (you can make your winbox as tough as *nix). Vista come with its netsh tools but limited to firewall & security, it hasn’t routing facility, but with some trick you’ll get routing capability like on WinXP.

this is the info for the netsh command
C:\Users\User>netsh show helper
Helper GUID DLL Filename Command
————————————– ———— ——-
{02BC1F81-D927-4EC5-8CBC-8DD65E3E38E8} AUTHFWCFG.DLL advfirewall
{FB10CBCA-5430-46CE-B732-079B4E23BE24} AUTHFWCFG.DLL consec
{35342B49-83B4-4FCC-A90D-278533D5BEA2} AUTHFWCFG.DLL firewall
{4D0FEFCB-8C3E-4CDE-B39B-325933727297} AUTHFWCFG.DLL monitor
{00770721-44EA-11D5-93BA-00B0D022DD1F} HNETMON.DLL bridge
{6DC31EC5-3583-4901-9E28-37C28113656A} DHCPCMONITOR.DLL dhcpclient
{8B3A0D7F-1F30-4402-B753-C4B2C7607C97} FWCFG.DLL firewall
{44F3288B-DBFF-4B31-A86E-633F50D706B3} NSHHTTP.DLL http
{0705ECA1-7AAC-11D2-89DC-006008B0E5B9} IFMON.DLL interface
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL 6to4
{725588AC-7A11-4220-A121-C92C915E8B73} NETIOHLP.DLL ipv4
{500F32FD-7064-476B-8FD6-2171EA46428F} NETIOHLP.DLL ipv6
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL 6to4
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL portproxy
{78197B47-2BEF-49CA-ACEB-D8816371BAA8} NETIOHLP.DLL tcp
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL teredo
{F7E0BC27-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL ipsec
{F7E0BC29-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL dynamic
{F7E0BC28-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL static
{1D8240C7-48B9-47CC-9E40-4F7A0A390E71} DOT3CFG.DLL lan
{00B399EA-447F-4B19-8393-F9D71D7760F9} NAPMONTR.DLL nap
{3F8A1180-FF5D-4B5B-934C-D08DFFBC9CBC} NAPMONTR.DLL client
{931852E2-597D-40B9-B927-55FFC81A6104} NETIOHLP.DLL netio
{B7BE4347-E851-4EEC-BC65-B0C0E87B86E3} P2PNETSH.DLL p2p
{9E0D63D7-4644-476B-9DAC-D62F96E08376} P2PNETSH.DLL collab
{6ED05238-F6A3-F801-967A-5CAD6F6CAC56} P2PNETSH.DLL contact
{E35A9D1F-61E8-4CF5-A46C-0F715A9303B8} P2PNETSH.DLL group
{9AA625FC-7E31-4679-B5B5-DFC67A3510AB} P2PNETSH.DLL database
{FBFC037E-D455-4B8D-80A5-B379002DBCAD} P2PNETSH.DLL idmgr
{9E0D63D6-4644-476B-9DAC-D64F96E01376} P2PNETSH.DLL pnrp
{1DD4935A-E587-4D16-AE27-14E40385AB12} P2PNETSH.DLL cloud
{AD1D76C9-434B-48E0-9D2C-31FA93D9635A} P2PNETSH.DLL diagnostics
{6EC05238-F6A3-4801-967A-5C9D6F6CAC50} P2PNETSH.DLL peer
{0705ECA2-7AAC-11D2-89DC-006008B0E5B9} RASMONTR.DLL ras
{42E3CC21-098C-11D3-8C4D-00104BCA495B} RASMONTR.DLL aaaa
{90FE6CFC-B6A2-463B-AA12-25E615EC3C66} RASMONTR.DLL diagnostics
{13D12A78-D0FB-11D2-9B76-00104BCA495B} RASMONTR.DLL ip
{36B3EF76-94C1-460F-BD6F-DF0178D90EAC} RASMONTR.DLL ipv6
{592852F7-5F6F-470B-9097-C5D33B612975} RPCNSH.DLL rpc
{C07E293F-9531-4426-8E5C-D7EBBA50F693} RPCNSH.DLL filter
{0BFDC146-56A3-4311-A7D5-7D9953F8326E} WHHELPER.DLL winhttp
{B2C0EEF4-CCE5-4F55-934E-ABF60F3DCF56} WSHELPER.DLL winsock
{D424E730-1DB7-4287-8C9B-0774F5AD0576} WLANCFG.DLL wlan

{65EC23C0-D1B9-11D2-89E4-006008B0E5B9} IPMONTR.DLL routing
{0705ECA0-7AAC-11D2-89DC-006008B0E5B9} IPMONTR.DLL ip
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL autodhcp
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL dnsproxy
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL igmp
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL nat
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL ospf
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL relay
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL rip
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL routerdiscovery

{65EC23C0-D1B9-11D2-89E4-006008B0E5B9} IPMONTR.DLL routing
{0705ECA0-7AAC-11D2-89DC-006008B0E5B9} IPMONTR.DLL ip
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL autodhcp
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL dnsproxy
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL igmp
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL nat
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL ospf
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL relay
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL rip
{0705ECA3-7AAC-11D2-89DC-006008B0E5B9} IPPROMON.DLL routerdisco

from above, we found that routing capability has removed in vista, but we can take it back, here the tricks :

I got IPMONTR.DLL IPPROMON.DLL from 2003 , it is ok if you got these files from XP.
copy to Vista WINDOWS\SYSTEM32
and run

netsh add helper ipmontr.dll
netsh add helper ippromon.dll

now you can configure Vista routing and remote access.

netsh>routing ip nat
netsh routing ip nat>add interface “Nvidia” full
netsh routing ip nat>add interface “SMC” private

netsh>interf ipv4
netsh interface ipv4>set interface “8″ forwarding=enable
netsh interface ipv4>set interface “10″ forwarding=enable

8 and 10 are interface id of Nvidia and SMC.
You can get interface id by

netsh>interface ipv4 show interfa

now you can do everything with this routing capability, u can look at windows XP netsh help documentation..

best regards,

10 Things you should know about NetSH


NETSH is one of the most powerful tools in the Windows networking toolkit. This list will introduce you to some good uses of NETSH in various scenarios and show you how you can streamline your networking configuration, administration, and documentation.

#1: What is NETSH?

NETSH is one of the most powerful yet least known networking tools included with Windows 2000 and Windows Server 2003. It’s installed by default and is located in the %systemroot%\system32 folder. NETSH is also available on Windows XP.

NETSH enables you to display, modify, import, and export many aspects of the network parameters of a system. It can also connect remotely to other systems with a remote machine parameter (-r).

#2: Contexts for NETSH

Contexts are specific dimensions of the network configuration that can be managed by NETSH. The commands and options within NETSH are context sensitive, and the same command may exist in multiple context areas but have different commands and results in each context. Here are the Windows Server 2003 NETSH context areas:

Context – Description
aaaa -Authentication, authorisation, accounting and auditing
dhcp – DHCP server administration
diag – OS and network service parametres
interface – NIC configuration; includes subcontexts
ipsec – Alternative to IP service parameters
netsh bridge – Network bridging configuration
ras – Remote access server configuration
routing – Routing administration (instead of RRAS)
rpc – subnet and interface settings
wins – Windows Internet Name Service administration

Now, to add to the confusion, a context can have a subcontext. For example, the interface context has three subcontexts, ip, ipv6, and portproxy. NETSH refers to these subcontexts as a context, such as the netsh interface ip context. Note that Windows XP has a different set of contexts. When using the import and export operations in noninteractive mode, you must specify context or subcontext configuration.

#3: Coordinating network change control with NETSH

You can use NETSH to export and import network configurations. A good example of using NETSH with networking change control would be when a system is going to be placed on a different network, but the communication channels need to be maintained to various other systems. A NETSH export will allow all parties to agree on various network settings. For example, here is a portion of a NETSH export of the interface context from a dump operation.

set address name = “Teamed NIC” source = static addr = mask =
set address name = “Teamed NIC” gateway = gwmetric = 1
set dns name = “Teamed NIC” source = static addr =
add dns name = “Teamed NIC” addr =
add dns name = “Teamed NIC” addr =
set wins name = “Teamed NIC” source = static addr =
add wins name = “Teamed NIC” addr =

Reviewing a NETSH export with all parties involved can ensure that the system will be routed correctly, using the correct DNS, WINS, and subnet mask. The best part is that you can then import the entire file into the Windows system after all appropriate entries have been made without any chance of entering the information incorrectly. And this is only for the interface context. The same applies for all other context scripts.

#4: Using NETSH to dynamically change TCP/IP addresses

You can use NETSH to make dynamic IP address changes from a static IP address to DHCP simply by importing a file. NETSH can also bring in the entire Layer-3 configuration (TCP/IP Address, DNS settings, WINS settings, IP aliases, etc.). This can be handy when you’re working on networks without DHCP and have a mobile computer that connects to multiple networks, some of which have DHCP. NETSH shortcuts will far exceed the capabilities of using Windows Automatic Public IP Addressing. Here is an example of running a dynamic update of an IP address:

C:\NETSH -f filename.netsh

In this example, filename.netsh is the NETSH file that contains an interface dump configuration. You can make shortcuts in Windows to a .BAT file that will run that command so you can easily add shortcuts to get a DHCP address and switch to a static IP address for a customer site, DMZ network, or any other static IP network.

#5: Best practice: Using a .NETSH extension

NETSH import and export operations are in a native plain text format and can be read and edited from any text tool. However, NETSH files should be handled as a special file type because they’re used to document network configurations, as well as for the import and export process. A best practice would be to make all export operations refer to a FILE.NETSH, where this file is what has been exported from NETSH. This is especially important because a NETSH export file doesn’t contain the word NETSH in it. This way, even a novice can figure out what the file contains.

The file extension from export (dump) and import (-f) operations are entirely user specified. For convenience, you can associate the .NETSH extension with your Windows installation to allow native double-click editing.

#6: NETSH in interactive mode

NETSH is one of the Windows tools that can be run in either an interactive or a noninteractive environment. Interactive tools (such as nslookup and dnscmd) have effectively different usage scenarios depending on the mode chosen.

Interactive mode also has two submodes, online and offline. Online mode is a direct interaction with the networking components while in interactive mode. Offline mode lets you interactively make changes and then roll them all online instantly by going to online mode.

#7: NETSH in noninteractive mode

In noninteractive mode, you can implement NETSH commands by importing a file. Using noninteractive mode is recommended for file import and export operations. With NETSH in noninteractive mode, you can export key settings from each context as a specific aspect of your system documentation. In addition, if an issue arises and you can trace it back to a specific networking topic for which you have a NETSH script exported from a known working time, you can re-import that NETSH script in noninteractive mode and restore your networking functionality to that point. Please note that NETSH does not back up data within the contexts, such as the WINS database.

#8: Clarifying the scripts

When exchanging NETSH scripts, you can insert comments to solicit feedback. This will allow you to explain an entry or use it as a training tool for others. Simply insert REM in a NETSH exported file to add a comment. Don’t put in too many comments, however; just what is necessary.

#9: NETSH precautions

NETSH is a powerful tool and should be used with caution. Using interactive online mode (the default) for changes on the fly can be more risky than implementing a change in interactive offline mode and going online to commit the changes. However, using noninteractive mode to perform changes is popular as well because the changes can be scripted. Try your hand at NETSH on a virtual machine or test system first.

#10: Navigating NETSH

The large array of features available in NETSH may seem overwhelming at first. It’s helpful to get into NETSH to see the options available and practice using the interface in interactive mode (a little different for those of us used to noninteractive tools). Getting into NETSH in interactive mode is easy: Simply type NETSH at the command prompt. Then, use these guidelines to investigate the command options:

|> To change to another context, type the name of the context. For example, typing interface ip will go immediately to the interface ip context from which ever context you are presently located.
|> To change your mode, type offline or online. Typing offline will send the interactive session offline, so any changes won’t be brought in immediately. Typing online will bring the interactive session online, so changes will immediately be brought into the networking elements of the system.
|> Typing show mode will display the current mode (offline or online). The default mode is online, so be sure to immediately jump offline if you are experimenting.
|> Typing ? or help will show the available commands for your current context location. If you’re in the root of the tool, there is no active context and your interface to the tool will be a netsh> prompt.
|> Global commands, such as online and quit, are those you can use everywhere. Context commands are available only in the current context. For example, from the netsh interface ip> context, you can view the network configuration by running show dns, but this command may not work other contexts or subcontexts.
|> In contexts, running set and show will provide the context-sensitive command options.

Go to Top