They know 100% exactly what is going on, and there have only been two major hacks. Both of these are extremely easy to track once they decided they wanted to do so, and there is absolutely no way that anything else anyone could possibly do would show up as either of them. Both of them involved packet editing, and sending packets that no legitimate program would send to SOE.
This really depends on how they're flagging the hacks though. Packet editing is tricky stuff, and the variations of what can be done are virtually endless. Based on the reports of the GMs statements by polly, I suspect that SoE is simply flagging any malformed packets with specific header types. So a set of packets comes in with a header that indicates that this is positional data, but the data doesn't match correctly, they'll flag that. It's unlikely that they're scanning the data itself for specific patterns since that can vary wildly.
If that's the case, it's quite possible for someone to "accidentally" trigger such a flag, without ever doing anything wrong. Packets do get mangled during delivery sometimes, assembled in the wrong order, bits dropped, etc. Usually this is picked up at the network layer via simple checksum. However, occasionally, a packet will get mangled in such a way that only the data is affected (headers intact), and the data contains the same number of bits as it was sent with. This sort of thing would almost certainly trigger any ghosting flag in their system. It's rare, but when you think about the number of packets being sent by clients into their servers every day, it's a statistical certainty that it'll happen.
It's also possible that a virus/trojan on the client host can trigger this as well. Many hacks out there attempt to take advantage of buffer overflow exploits. It's arguably the most basic hack in the world. You send some data to a port on another computer. The program handling that port can only take X data at a time before its "blows its stack". You make sure the first X data is garbage, and then follow it with Y bits of instruction code. When the buffer overflows the remaining bits will be executed with the permissions of the process that just overflowed. For most port handlers, that's going to be an administrative process, giving you the ability to further hack the system.
Hacks of that sort can be automated (via the "zombie" cluster concept). What you do is create a program that checks network connections. Everytime you send data to another external host, it piggybacks the signal. A typical method to use would be to take whatever data was sent legitimately, and copy it multiple times to fill up to some buffer size, then follow it with code you want and send it. To a server that's properly patched, this will come in as a malformed packet. To someone looking at particular types of data, it'll look almost *exactly* like ghosting since it's the same positional (or whatever) data, but it's going to appear "shuffled around" (cause it's randomly repeating whatever data was sent legitimately).
I could probably think of about a dozen different things that could cause a data stream to arrive from an EQ client to an SOE server that would look on the surface like an attempt to ghost that have nothing to do with actually ghosting. Like you said, ghosting is simply the client sending legitimate packets with the correct application headers, but with wrong information in the data. Any such packet with data that isn't "correct" with regard to the server's records will be virtually indistinguishable from an attempt to ghost. The only way to be sure is if you actually had someone who knew which bits of the data meant what and could determine that the exact bits that were "wrong" were wrong in a way that would make the client appear to be in the wrong spot to the server and not just "randomly wrong".
I'm going to go out on a limb and guess that the average GM does not have the skill to make that determination. Heck. I'm betting almost no one does. Because you'd have to compare what the data is supposed to be to what it actually is, and know not only which bits are significant, but in what way they are significant. Does the fact that this set of 6 bits are wrong indicate random data? Or would those 6 bits make the server react in a way that would help the client in some way? That's incredibly hard to tell, and would be virtually impossible to automate. The best you can do is flag any set of clearly "wrong" data...