Copyright 1998-2002 by Robert Graham (firewall-seen@robertgraham.com.
All rights reserved. This document may only be reproduced (whole or in part) for non-commercial purposes. All reproductions must contain this copyright notice and must not be altered, except by permission of the author.

Special thanks to Alan J. Rosenthal (maintainer of FAQs himself) for some really good input.

1. What does destination port number ZZZZ mean?

PORT GUIDE  | source-ports | many-to-one | trojans | DNS | dial-up | IRC | remapping | still can't figure it out

2. What does this ICMP info mean?

0 (echo reply) | 3 (unreachable) | 4 (source quench) | 8 (ping) | 11 (ttl exceeded) 12 (problem)

3. What do these IP addresses indicate?

source-routing | 255.255.255.255 | track owner | 10.x.x.x | known IP addresses | 0.0.0.0 | directed-broadcasts | 169.254.x.x

4. Stuff doesn't work

slow connections

5. What are some typical signatures of well-known programs?

traceroute | sscan | proxy scanners | smurf | fraggle

7. What do these other logs mean?

DNS | HTTP | RPC | SMTP | identd

8. How do I configure filters?

ICMP filters | split DNS

9. Packet Zen

IP ID | TTL | Resources

10. What's the deal with NetBIOS (UDP port 137)?

What? | Why? | But I'm not Win? | Statistics | Signature | Get rid of them? | Attacks

A. Appendix

You'll note that some sections are missing. This is an evolving document; when sections are removed (because the info is moved into other sections), I don't renumber the document.

Forensics and protocol analysis can be used to track down who this is. For example, if you ping each of the systems, you can match up the TTL fields in those responses with the connection attempts. This will at least point a finger at a decoy scan. (The TTLs should match; if not, then they are being spoofed). [Newer versions of scanner now randomize the attackers own TTL, making it harder to weed them out].

You can also attempt to go back further in your logs, looking for all the decoy addresses or people from the same subnets. You will often see that the attacker has actually connected to you recently, while the decoyed addresses haven't.

Q: My filters reject incoming packets with source ports below 1024, so the DNS lookups are failing.
A: Don't filter that way. Lots of firewalls have similar rules, but this is somewhat "misguided" since hackers/crackers can forge whatever ports they want.

Q: Are these NAT firewalls doing it incorrectly?
A: Not in theory, but in practice it will result in failures. The "correct" way would be more strictly control DNS traffic in any case (such as essentially "proxying" DNS and forcing out through port 53).

Q: I thought DNS lookup was supposed to use a random source port above 1024?
A: In practice, your average DNS client will use a non-reserved port. However, a lot of implementations use a source port of 53. In any case, the NAT issue is completely separate because it completely changes the entire 'socket' (IP address + port combo).

Therefore, both servers and clients are implementing measures to stop "anonymous" use of chatrooms. In particular, they check people entering chatrooms in order to see if they are "proxying" through some other connection. The most popular of such probes is SOCKS. The assumption is that if the IP address of where you are coming from supports SOCKS, then it is possible that you have a completely separate machine and are only going through the indicated machine in order to hide your true identity. Undernet's policy on this can be found at http://help.undernet.org/proxyscan.

At the same time, crackers/hackers will scan people's machines in order to determine if they are running some sort of server that can be bounced through. Again, by checking for SOCKS, the attacker hopes to find somebody that has left SOCKS open, such as a home user implementing connection sharing using SOCKS, but accidentally configured it so that anybody on the Internet has access to it.

Remapping is done under the theory that making the port harder to find will make it more difficult for a hacker to exploit. Instead of simply exploiting a well-known service at a well-known port, the hacker will have to port scan the machine.

Most port remapping is done at some variation of the original port. Therefore, most HTTP ports are based upon a variation of the theme "80": 81, 88, 8000, 8080, 8888, and so forth. POP, which is originally at port 110 can often be found at port 1100.

There are other statistically significant chosen numbers, like 12345, 23456, 34567, etc. Many people also choose numbers that are well known for other reasons; 42, 69, 666, 31337, and so on. The recent proliferation of Remote Access Trojans (RATs) has resulted in hackers/crackers choosing the same defaults for their programs. For example, NetBus defaults to port 12345.

Blake R. Swopes points out that remapping is also done because on UNIX machines, your server needs root privileges to listen on ports below 1024. If you don't have root level access and want to run a web service, you will need to install it on a high-numbered port. Likewise, some ISPs might firewall low-numbered ports, forcing you to remap even when you own the entire machine.

Someone's ping that person

Somebody behind the firewall is sending pings to the target.

Automated ping

Lots of applications use pings for various purposes, such as to see if their communication partner is alive, or to measure the response time. A big cause of this is VitalSign's Net.Medic, which sends pings of various sizes in order to measure link speed.

Decoy Ping Sweep

Somebody is using your IP address as a decoy in a ping sweep, so you are seeing the responses.

Covert-channel communications

Most network managers block incoming pings (type=8), but allow ping responses (type=0). Therefore, hackers have begun using ping replies as ways of bypassing firewalls. For example, in the massive DDoS attacks against Internet sites, commands could be imbedded in ping responses, and floods of responses were directed against the sites in order to clog their Internet connections.

Lots of network management "scanners" will precede a scan using a special ping packet. These include ISS scanner, WhatsUp monitor, and others. This will be visible in the payload of the scanner. Most firewalls don't log this payload, so you may need to use some sort of sniffer to capture them or some time of Intrusion Detection System to flag them.

Note that blocking incoming PINGs does not mean a hacker can't scan the network. There are many other ways of doing this. For example, TCP ACK scanning becoming popular -- they usually get through the firewall, and they illicit a response from the target system.

Pings sent to broadcast IP addresses like x.x.x.0 or x.x.x.255 are probably attempts to use your network as a smurf amplifier.

 

2.11.0 Type = 11, Code = 0 (TTL Exceeded In Transit)

This can be caused by a number of things. If somebody from your site is doing traceroutes out to the Internet, you will see lots of TTL exceeded responses from routers. This is how traceroute works: forces the routers to generate TTL exceeded messages in order to find them.

Another common reason firewall administrators see this is due to routing loops developing in the Internet. Route flapping (constant route changes) is a common problem, and will often briefly result in a loop. This means that while a IP packet is heading towards it destination, the packet gets misrouted to a router that it previously visited it. The packet then gets routed in a circle infinitely -- or it would be, if the routers didn't decrement the TTL field each time and discard the packet once that value hit zero.

Another cause of this is distance. Many machines start with a default TTL of 127 (Windows) or even lower. Routers will often decrement the TTL more than by one in order to reflect slow lines like dialups or transcontinental links. Therefore, a site might not be reachable with a low initial TTL. In addition, some hackers/crackers like to make their site unreachable through this method.

 

2.11.1 Type = 11, Code = 1 (Fragment Reassembly Time Exceeded)

When sending fragmented IP datagrams, the sender of this message never received all the fragments. Normally, most TCP/IP traffic shouldn't even be fragmented. You will only see this if the traffic is both fragmented AND there congestion somewhere between you and the target.

There are a couple of network management uses of this packet, such as testing to see if two computers can talk to each other. A network manager at point A may send a packet to B through point C. This tells A if B & C can talk to each other.

The same technique can be used to evade firewalls, subvert trust relationships, and communicate with machines using "private" address (10.x.x.x, 192.168.x.x, 172.[16-31].x.x).

Let's say you are a hacker/cracker on the Internet and you want to talk to some machines behind a firewall who use 10.x.x.x as their IP addresses. Since the routers on the Internet do not know where this subnet is located, they will drop your packets. However, you put a loose source route option in the IP packet and tell all the Internet routers to first forward to the firewall. Since the firewall straddles both the Internet and the private network, it will know how to forward the packet appropriately. Thus, you can carry on a conversation with the victim by bouncing all packets through the firewall.

This can be used with IP spoofing. You pretend to be a router (like the firewall mentioned above) and pretend that somebody else is bouncing packets through you. Thus, pick some random machine on the Internet (ALICE) as the spoofee, then send packets from ALICE to your victim BOB. BOB will think the packets are coming from ALICE, but in reality they are coming from you. This masks the real source of the attack.

This is even better if you know that BOB trusts ALICE. IP addresses are often used as part of authentication. Let's say the firewall has a rule allowing all traffic from ALICE into the network. By forging all IP packets to be from ALICE (but being source routed through your own machine), then you get free access to the victim network.

More and more core Internet routers are disabling source routed packets. They slow down routing anyway, but they are a huge security risk. There is also no real need for them. Managers should do the same and disable source routing everywhere: on firewalls, on routers, and even on end-nodes so that they won't even accept incoming source routed packets.

See Microsoft Knowledge Base article Q217336 for setting the "DisableIPSourceRouting" on WinNT SP5 systems

You must remember that such packets MUST be local. Routers (generally) refuse to forward packets with the IP address of 255.255.255.255. This address is known as a "local broadcast" for this reason: it never travels past the local segment (or these days, the local "virtual" segment).

What are these packets for?

Check the list of ports at the top of this document. If it is not listed there, then the only way to figure this out is to capture them with a sniffer and view their contents.

For example, a common service that runs with a random port number is CORBA IIOP packets. Many services run at port 535, but it is frequently reconfigured to broadcast on other ports. If you look at the hex dump in the sniffer, you will see the letters "IIOP" somewhere in the contents.

In any case, this is rarely something to be concerned about. In fact, it advertises something about the person sending the traffic that can be used to hack them. Hackers rarely attack their own neighborhoods (because it is easy to detect), so it probably is accidental, not malicious.

It should be noted that with today's ATM networks, the source of the broadcast may not even be in the same state as you are; they may be hundreds of miles away. The word "local" means in terms of the network topology, not distance.

I've been seeing these in three cases:

traceroutes

Core routers on the Internet are increasingly being assigned IP address in this range. There is really no need for a router to be reached from the Internet. The "forwarding" function really is independent from "sending/receiving" packets. When a router drops a packet and sends back a "ICMP TTL Exceeded" message, it will use the private address. Note that some routers are multi-homed with both private and non-private addresses. Other routers have only private addresses.

cable-modem, DSL

Most cable-modem and DSL connections are on virtual LANs over ATM. You will often see broadcast packets from neighboring machines with these private addresses.

hackers

Very rarely, you may see an address from a hackers who are spoofing addresses in this range.

Doubleclick

Sends echos to people in order to redirect them to a nearer server for their advertising.

http://www.cyveillance.com/

Scans websites looking for illegal activities, such as copyrighted items.

Therefore, each router decrements (subtracts 1) from the TTL field. When each reaches zero, the router who currently has the packet will simply "drop" it (not forward it on). When a router drops a packet, it sends a message back to the sender informing for this. This message is called an ICMP "TLL Exceeded in Transit".

The nifty thing about this is that the router uses its own IP address as the source address of the ICMP message. Therefore, if you send a packet to a target but with a TTL of only 1, the first router will receive the packet, decrement the field to 0, drop it, then send back the ICMP notification. This informs you of the first router along the route (which you probably knew anyway).

The same goes for an initial TTL of 2. The first router gets it, decrements to 1, then forwards to the second router along the route. This router then decrements to 0, drops the packet, and sends back and error ICMP message.

By continuing this process, you eventually end up with the list of routers between yourself and the target.

Versions of traceroute

There are various versions of the traceroute program. In particular, the Windows program "tracert.exe" uses pings as the packet it sends to the target. Therefore, you might see ICMP Echoes on your firewall.

The most popular "traceroute" program for UNIX programs sends UDP datagrams to port 33434 for the first packet sent, then increases this port number by one for each successive packet. This means that you will never see port 33434 on your firewall, but you will start to see successive ones starting at higher port numbers. Traceroute programs typically send 3 packets for each hop (in case some get dropped). Therefore, if somebody is 10 hops away, the first port you will see is 33434 + 3*10 = 33464.

Symptoms

Firewall administrators should learn the symptoms of traceroute activity.

port scans in 33434-33600

A brief sequential "port scan" in this range usually indicates a traceroute for a UNIX machine, as explained in this section.

incoming TTL exceeded

If someone inside the network is attempting a traceroute, then you'll see these incoming packets. Many admins allow these through the firewall.

outgoing TTL exceeded

This indicates that somebody is tracerouting you. This doesn't necessarily indicate hostile activity, but somebody is scanning you. These should be blocked by the firewall.

outgoing ICMP port unreachable

When a traceroute successfully hits a target, it will generate back-to-back "ICMP port unreachable" messages (probably 3 in a row).

Other

Some traceroutes are designed to bypass firewalls. See http://www.packetfactory.net/Projects/Firewalk/firewalk-final.html for more information.

A sscan goes through several phases:

TCP ACK pings

The program will attempt to see if the host is reachable by scanning for the most common services, namely ports 23/telnet, 25/smtp, 110/pop3, 143/imap4, 80/http. This phase is easily detected because both the source and destination port are the same.

connection attempts

Connection attempts are made to several services in order to see if they are available. This is highly configurable. Typically configured probes are those above, as well as 111/rpc, 6000/x-windows, 79/finger, 53/dns, 31337/elite, 139/netbios,smb, 21/ftp, 1114/msql, 1/tcpmux

OS fingerprint

sscan contains a basic OS fingerprinting technique, easily detected because it uses source ports 1-5. The fingerprinting is not as complete as the techniques used by Queso or nmap.

vulnerability assessment

It then looks at the ports that are open and checks the banners that might indicate a vulnerable version of one of the services. It also scans for a range of known vulnerable CGI scripts.

script execution

Depending upon what it finds, it can further launch configured scripts against the system.

Example

The following is a record pulled from an intrusion detection system.

ports=1 22 23 25 53 79 110 111 143 1114 2766 6000 31337

Unfortunately, the system consolidates alerts, discards duplicates, and keeps the port numbers in sort order. In a real scan, several of the ports would have duplicate connection attempts, and port 1/tcpmux would be one of the last probes, not one of the first.

More info

[IN-99-01]

In late summer of 1999, probes for ports 80/8080/3128 were particularly noticed. These came from all over the Internet and were fairly disjoint. These came from a Trojan Horse called "Ring0" (RingZero). It would infect PCs, then scan random IP addresses for proxy servers. The SANS Institute (a security training/conference organization) coordinated an effort to track down exactly what was happening from reports from many of their customers. A common symptom of this Trojan is 3 probes spaced within a minute from the same IP address from this Trojan. More information can be found at: http://www.sans.org/newlook/resources/ringzero.htm. A news article by CMP can be found at: http://www.techweb.com/wire/story/TWB19991013S0018

A list of open proxies can be found at: http://freebooks.hypermart.net/proxy/proxies.htm

Ports with variations of the "80" them (81, 88, 8000, 8080, 8888, etc) are most commonly used for proxies. In addition, a popular free proxy server called "squid" runs at port 3128.

As always, these attempts are usually from scans against thousands/millions of machines rather than against you in particular. Every few months, a new exploit script is published for Linux or Solaris services, and script kiddies start scanning the Internet for that service. Most of the vulnerabilities in the services listed are buffer overflows.

Note that on Sun Solaris machines, these services usually have port numbers in the range starting at port 32770. Many other times, RPC services will have ports below 1024, on the assumption that it provides a little better security because

More info on RPC can be found in RFC1833.txt.

The problem is that many administrators simply install servers without taking these simple precautions. Spammers take advantage of this fact. They give a single e-mail to the mail server and a recipient list containing hundreds of unrelated recipients. This allows them to send huge quantities of e-mail using a slow dialup connection. This is important because once the ISPs get enough complaints, they will terminate the user's account, so they must continual get new dialup connections. It also has the effect of partially hiding the true source of the spam.

If you get error messages about relaying, that is a good thing: you've configured your server correctly. If you don't get such messages, this is a bad thing. This means that you are probably not rejecting relayed messages. Has your server seemed slow lately?

Not only do spammers hunt for open relays, anti-spam organizations do the same in an attempt to "blacklist" open relays. Some of the good guys are:

IMC

The Internet Mail Consortium reports that in 1999, roughly 17% of e-mail systems had open relays.

MAPS RBL

The MAPS RBL (Realtime Blackhole List) allows you to configure your e-mail server to blackball known open relays that send out bulk spam. It is used by a huge percentage of e-mail servers on the Internet.

ORBS

Scans the Internet looking for open relays. ORBS uses relay tests from New Zealand (e.g. manawatu.co.nz).

Not only do you receive relay attempts from spammers, you also get attempts from anti-spam organizations. There are several organizations that regularly scan the Internet looking for open relays. The most common is from "manawatu.co.nz"; don't get too upset -- they

If you do the command "VRFY root", you might be able to find out the postmaster's e-mail address. This is good reconnaissance technique.

By doing a "VRFY decode" or "VRFY uudecode", you might be able to find out some security holes in the system related to these subsystems. Other commonly scanned user names are "bbs", "lp", "demo", "guest", and "debug".

Some systems have buffer overflows in this command, either in the command itself or in the logging system behind the command. You might see entries for very long strings like "xxxxxxxxxxxxxxxxxxxxxxxx".

If you see a bunch of these in a row, you are probably being scanned by a vulnerability scanner (ISS/CyberCop/Nessus). They will generate a bunch of other junk in your logs as well.

The absolute minimum ICMP traffic to allow is the packets dealing with TCP path MTU discovery. Fragmenting a stream is more efficient at the TCP layer rather than the IP layer, so the TCP layer will try to discover when IP packets are being inadvertently fragmented. They do this by setting the "DF" (Don't Fragment) on all outgoing packets. When a router cannot forward the packet because it is too big, rather than fragmenting it, it sends back a "fragmentation needed" ICMP packet (type=3/code=4). The TCP stack then starts sending smaller IP packets, segmenting the data at the TCP layer rather than allow routers to fragment at the IP layer. Therefore, firewalls must be configured to allow incoming ICMP type=3, code=4 packets.

Another issue is Host unreachable and Destination Unreachable packets. Allowing these to come in through your firewall will allow connections to timeout faster, but they can also be used as a denial of service attack (by disconnecting clients from servers).

Users will constantly ask for the ability to ping and traceroute machines on the Internet. Most firewall adminsitrators will eventually give into these demands. Nobody really needs to ping/traceroute, but they really want to. It should be remembered, however, that ICMP ping responses are often used as a covert-cahnnel. (The massive DDoS attacks against Internet portals used this as a covert channel).

For more information on this, you may want to consult "Protect and Survive Using IBM Firewall 3.1 for AIX", IBM publication SG24-2577-02. See http://www.redbooks.ibm.com for more info. I disagree with it, though.

Another good document is http://www.worldgate.com/~marcs/mtu/.

It also means that you can tell how far away a person is from the TTL field, and sometimes what kind of platform they are running. Most Windows machines send packets with a starting TTL of 128. This means that if your firewall log shows a TTL=112, then you can make the guess that the sender is 16 hops away, and that they are using a Windows machine.

Conversely, UNIX machines typically choose 64 as the starting TTL, so a packet when the TTL is 51, then it probably isn't Windows, but it is probably 13 hops away.

This technique was once used to find the source of nmap decoy scans. The decoys where given random TTLs, but the real scans were give normal TTLs. This allowed the astute observer the ability to sift through the incoming decoys and find the real scan. The nmap program was soon fixed to randomize the TTL of the real scan as well.

Max Vision's "Passive Host Fingerprinting"

http://dev.whitehats.com/papers/passive/index.html

Lanz Spitzner's "Passive Fingerprinting"

http://www.enteract.com/~lspitz/finger.html

The discussion of these NetBIOS packets crops up over and over again on firewall/incident mailing lists. In this section, I've tried to come up with the "definitive" answer to this question.

Note that you will see NetBIOS scans, such as from hackers running the Legion NetBIOS scanner or other scanners. In this case, you'll likely see a scan of your entire address range. The important thing to remember is that few NetBIOS packets are from hostile intent.

We call DNS a directory service, where the word directory has the same meaning as in phone networks. In the U.S., we can dial directory assistance at 411 rather than looking up a name in the phone book. Either way, the goal is to lookup a name, and receive a number.

In a similar manner, sometimes you have a number, and you want to find the name. Let's say that you have caller ID and somebody calls you with the phone number (212) 555-1038. This doesn't tell you who this is, so you want to do the reverse lookup and discover the person's name.

In much the same fashion, the Internet provides a number of capabilities to resolve an IP address into a name.

The process is simply that a program requests the name for an IP address, and sends this request to all the protocol stacks. If the NetBIOS stack receives such a request, it always sends a NetBIOS query to the IP address. It doesn't matter if you have (or haven't) an existing NetBIOS connection to the machine.

In other words, the only requirement necessary in order to receive such packets is that you have an IP address.

ping.exe

If the user executes a ping -a 192.0.2.168, then Windows will attempt to find the name for that address. This doesn't happen so often.

tracert.exe

The traceroute program finds all the hops between the client and the server. Users sometimes do this from the command-line. The most common source of this is from programs that automatically traceroute the servers the user visits. Note that if they are tracing through several hops, you will get separate queries for each hop.

Microsoft's IIS web server

Microsoft's webserver has the option to log the machine name of the client accessing the web site. Each time one of your users behind your firewall browses an IIS-based server, you'll get a query for the name of the user's machine.

Logfile analyzers

Even if name resolution is disabled on the webserver, the site administrator may run the webserver logfiles through a reporting tool like Webtrends. Most of these tools have the ability to resolve IP addresses to names. At this stage, you will see a flury of port 137 packets from the address the tool is run from (which may be different from the original webserver). This is especially a problem because they request such a huge amount of DNS PTR queries that they overwhelm the DNS server. Thus, even though DNS queries would normally be resolved, they might fail during analysis of a log file, thereby generating NetBIOS queries. Since these logfiles analyzers are often run on a scheduled (i.e. nightly) basis, you may see such activity from the same host during the same period of the day.

Client apps

Beyond web browsing, reverse IP name resolution is a fixture in many Windows client apps like IRC, ICQ, and so forth.

Personal firewalls

Personal firewalls will attempt reverse resolution of the IP addresses. The "auto-learning" personal firewalls that prompt the user for each outgoing connection can be particular offenders in this regard. If BlackICE Defender sees an intrusions attempt, it may also do its own NetBIOS lookups independently from the underlying Windows system.

Note that starting in late 1999, desktop security tools like personal firewalls have exploded. This means that the number of NetBIOS queries have dramatically risen.

Also, see section 10.6 for an explanation of how a simple configuration error in DNS can cause you to be suddenly flooded with such requests.

The thing to remember is that A and PTR queries are unrelated.

When you register your domain name (example.com) you go to the owner of .com (Network Solutions) and purchase the address. As part of your registration, you tell Network Solutions something to effect "Please pass any DNS queries for the domain example.com to my DNS server ns1.example.com which is located at the IP address 192.0.2.168".

Thus, when resolving www.example.com, you first ask .com for the DNS server for example.com, which is ns1.example.com/192.0.2.168. You then ask that server for the A record for www.

Now going the reverse direction is a bit tougher. When trying to figure out who owns the IP address 192.0.2.3, you've got a problem. What is the first step? The solution was to query for a PTR record with the pseudo-name that looks something like "3.2.0.192.in-addr.arpa". Like the .com domain, the .arpa domain is run by a special company. It forwards the requests to the backbone ISPs, which then forward the request to the smaller ISPs and customers.

This forwarding mechanism is easily broken due to CIDR addresses. An ISP may assign 192.0.2.[0.127] to one customer, and 192.0.2.[128-255] to another customer. In order to fix this issue, the ISP must support special CNAME records that delegate lookups. For the network 192.0.2.128/25, then the CNAME record would look like 128/25.0.2.192.IN-ADDR.ARPA. This is kinda complex, easy to get wrong, and the administrators at ISPs often don't know how to do it right.

Please see CNAME -> PTR indirection described in RFC 2317 for more details on this. Also see http://www.dns.net/dnsrd/ for extensive DNS resources.

Conclusion

The upshot is that you probably have a CIDR allocation that breaks PTR queries causing NetBIOS queries. Harangue your ISP until they fix this.

Legion scans

There are numerous tools that scan for open shares. The first popular tool for this was called "Legion" from Rhino9. Since then, numerous other tools have been created. Some of these tools will do a lookup on port 137 before connecting to TCP port 139.

NetBIOS worms

Starting in 1999, numerous NetBIOS worms have been seen. These include ExploreZip virus/worm, Network.VBS VisualBasic script, and the 911 worm (which also calls 911 out your modem). All of these worms will attempt connection to you machine.

NetBIOS scans

Sometimes people just scan the Internet looking for people's names. Since most people leave port 137 open, it is pretty fun.

http://www.cert.org/tech_tips/intruder_detection_checklist.html

CERT's Intruder Detection Checklist. If you believe you've been compromised, this document describes how to go through your UNIX system and find signs of this intrusion.

http://www.usdoj.gov/criminal/cybercrime/reporting.htm

If you have evidence of a cybercrime that you believe warrants the attention of the FBI, this is a good place to start. Note that you can't simply hand it off to them and say "you take care of it". They are only willing to take part of you are willing to spend the necessary time in gathering evidence. For example, you may have to ship your compromised machine to them.