12.15.2017

Bad information

I recently found some blogs about various anonymous functions online which appear to be seeding bad information. Either by being wrong, misleading, or inadequate. To start with, here's one I saw that people were sharing in a forensics group.

https://vallejo.cc/2017/11/11/using-gathering-information-tools-through-tor-network/

Yes you can totally do an nmap scan over tor with proxychains, yes these particular copypasta scans can work. However lets discuss why a bit further. Yes, there are limitations on scanning capabilities on what can/will go through socks, there is also limitations on what scans can do what functions. As a test, I used tcpdump on the server being attacked with a monitor of my own ip address. If there was even a single packet to or from my attacking ip, it was a complete failure.


nmap attempt Results (did it hide our ip)
proxychains nmap -Pn -sT -sV -O -p80 {MY HOST} Failed when added os detection (+O)
proxychains nmap -Pn -sT -sV -T5 -p80 {MY HOST} Success, despite T5 being known to have issues hiding
proxychains nmap -Pn -sV -p80 {MY HOST} Failed when -sT was removed
proxychains nmap -Pn -sS -sV -p80 {MY HOST} sS fails
proxychains nmap -Pn -sA -sV -p80 {MY HOST} sA fails
proxychains nmap -Pn -sW -sV -p80 {MY HOST} sW fails
proxychains nmap -Pn -sM -sV -p80 {MY HOST} sM succeeds
proxychains nmap -Pn -sM -T5 -sV -p80 {MY HOST} Still succeeds despite issues with T5
proxychains nmap -Pn -sM -O -sV -p80 {MY HOST} os detection fails again
proxychains nmap -Pn -sM -T5 -f -sV -p80 {MY HOST} Success despite issues with -f
proxychains nmap -Pn -sM -T5 -f -D 127.0.0.1 -sV -p80 {MY HOST} success despite issues with decoys
 proxychains nmap -Pn -sT -T5 -D 127.0.0.1 -sV -p80 {MY HOST} success
proxychains nmap -P0 -T5 -D 127.0.0.1 -sV -p80 {MY HOST} Failed despite claims of functional equivilence of PNnand P0. 
proxychains nmap -P0 -T5 -D 127.0.0.1 -sV -p443 --script ssl-enum-ciphers {MY HOST} Failed. Despite options, common nmap scripts will fail because they are not geared to work in a socks environment.


The setup for a tor proxy as a wireless ap, the reasons why it didn't work from what I've tested seems to be because the tutorial they used mentions to create the prerouting setup but nothing else... like.. idk... forwarding? You also see on that tutorial they used that their output of iptables -L is actually not matching their saved file.

Edit: a worthy mention about segfaults:
- Scanning more than one or two ports seems to end in seg faults for various reasons, gdb or strace that it looks like it's getting hung up waiting. I think there is an option for that in nmap because of the delay times. Haven't tested on my end to see if it's useful. This also coincides with refresh times for tor, so it may be that because nmap doesn't directly deal with tor, the connections are timing out and dying along with that.
- Example of segfaults during run scanning all ports on a single host similar happens with too many hosts for my scan:


Other ways to do what they were attempting:
- Scapy: using torsocks or proxychains to a scapy scanning script works even for os detection, syn, and ack scans. I'm sure there are some ways that escape it, such as atm traffic and protocols of that sort maybe, haven't enumerated all possibilities of scapy by any means. As best I can figure from looking into this, it works while other scripts don't because the way scapy handles packet creation isn't the same way a standard C program (library requirements?) would, generating the entire packet as capable to load into sock5 chain (can we do a test development of a socks proxy exploit using scapy maybe? maybe?).
- Script your own scanners? massscan? etc... you get my point.
- USING A FUCKING VM: People seem to have no idea how important vms can be do this type of work. I'll explain more in my next rant.
- Modding/compiling your own copy of torsocks: tor socks actually does have a known correction public that isn't part of it's standard code source that will properly bind interfaces instead of crashing, and also utilizes proper dns queries. (for the record, my host was a sub host for my domain, and the ns server is on the same system, making this evident that using proxychains didn't leak ip info when doing dns lookups)


Now that's not to harass that person for their post or bug out about them in any way, this is more just something I noticed because it seems there was a chain of bad/lacking information that they got their info from to have created that post. Because of this, there is a distinct lack of information for those who want to do it in the future.

I leave information out of my own posts too and sometimes it seems it's not worth it, other times it seems legality may step in somewhere. Either way, this is a catastrophic problem in our world. Its good people share, but we should all make an effort to test information first as well as explore other options.

Example 2:

So, there was another example on a forum (leaving out due to having posted in the forum's post), where a self proclaimed hacker was boasting their setup and their tool sets. Needless to say this is a bad idea for anyone who wants to claim to be a hacker, but lets dive into why.
  1. They detailed that people should use one vm and route the traffic through their tor socket on their host machine. 
    1. pushing into a socket on a different kernel isn't necessary
    2. The entire purpose is supposed to be anonymity, they're saying everyone should do this for attacking via c2 infrastructure
    3. they clearly don't understand what their own infrastructure is
    4. they don't understand anonymity. 
  2. They detailed that using metasploit was a "real hacker" thing more than using paid malware was. 
    1. metasploit has a paid version
    2. metasploit is a toolkit, not really hacker versus non more of a research versus real attacker automation tools. Which most will create themselves leveraging everything from paid malware to metasploit.
    3. Again shows a lack of information or understanding about attacker landscape
    4. again doesn't seem to understand anonymity, or for that matter, disassociative properties. 
So, my founding principle for this is an argument of lets have attacker versus attacker. Lets act like rules don't mean anything, since they don't anyway, and have one on one attacks. The attacks would be based on information of our c2 found in the a launched sample. This would make us attacker v. attacker on the battle grounds of infrastructure versus infrastructure. I've been making allusions to this in many comments online but it's pretty easy to note this isn't a new thing for hackers to do and yet so few of them are willing to do this. It's almost sad actually that it's avoided so much. But then researchers are all liek "blah blah blah white hat blah blah we can't be using hack back infrastructures blah blah." So, lets bring this to light a little in a scenario designed to specifically mock their own infrastructure. 
  1. Using two vms, one with ubuntu and tor, the other with windows and comodo (you'll see why). With docker also on the ubuntu box and the docker cli on the windows one. 
    1. Setup the ubuntu one as the default route (via host only adapter) of the windows one. 
    2. Setup tor and appropriated routing (google it) for ebtables and iptables (yes, it's important). Hell setup i2p too for shits and giggles and helping out the cause. 
    3. On windows, load any generic, free, easily detected piece of shit malware using comodo's sandbox feature and generate a few thousand samples. (docker for this task? why not. ;), keep the c2 panel up on that system ) 
    4. Setup your network as (ubuntu box <- ssh tunnel with remote side listening (you can use tor to proxy this too)-> public host you spin up {no no, no need to pay just grab a valid card number anywhere and move along}, this creates your public connection) <-> php script to proxy ports on various servers to the domain and port you're listening on for your public host. Now your public infrastructure is running, you just need to setup that domain. So rush on over to hijack someone's domain creds (brute? free leak? whatever it doesn't matter)  and use their ns to spin up several hundred subdomains you change to various ips at random remotely based on a remote connection saying (see my rant about domain ip rotations), or alternatively use ddns services (theres plenty of them). 
      1. This is a lot so basically it's from the c2 side: c2 panel::windows <-> ubuntu <-> tor || reverse proxy (i mention this as || (or) because if the proxy were to fail or something along the chain does fail (including panel itself accidentally having exploitable features), we want any secondary traffic or altered traffic to not leak our ip so we can just revert state and move forward again) <-> the public ip we do actually control (we want to be able to ditch this too at a moments notice, so we can all agree to use cloud providers, they're good for this) <-> php proxies scattered around the net <-> payload/stub/malware::infected host. 
    5. Now that we have our structure setup, go spin up some more malware with the correct hosts in place, and go ahead and start your sending scripts wherever you have those hosted, clearly not on your vm host you dumb piece of shit.  #justsayin. 
    6. Since there is very little protections in this structure yet, you could spend the time to make antiforensics tools, drive and system wipes, remote databases for exfiltrated information, really whatever you'd want. 
  2. Spin up another windows box with no connections and your favorite decompiler to identify and attack their scripts. 
    1. You will need to be able to identify anything they launch and the pattern of encoding/decoding over the net. 
    2. You will need to be able to find common abuse traits, such as when you see the host request information but the request data may not be validated, check it. test it from somewhere, like maybe your ubuntu box? scapy/tcpreplay/etc... is your friend. 
  3. make sure they know which ones are yours and how they can get a copy, and get theirs for your own. 
  4. Laugh uncontrollably when you find their real ip by trashing their socks connection. 
    1. WHAT?
      1. Well, you see, why do you think some scans work and some don't? Different packet data responds differently. 
      2. Sometimes, this means you will adjust the windowing on your side and watch their responses from a public host magically correlate with where they're from. 
    2. What if they used a vpn?
      1. looooooooooool
        1. People rely on vpns a lot but when push comes to shove, you can smash a vpn provider's connections and have them time out, so if they try to attack yours or respond to yours, it's going to come from the right place. ;) 
  5. be sure to leave a friendly reminder about how stupid their structure is on the way out. 
This is attacker versus attacker architecture planning, or as many may call it, attack back architecture. Now, I might like this plan of action and have referenced portions of this in several ways before, this is just play things. This is a toy architecture in this scenario. 

My purpose in bitching about this is pretty simple: This person was given really bad information and reflected is as boasting their own knowledge of the way things work. Because of this, when it comes to them posting their malware anywhere or someone stumbling across is, they're prone for attacks from various entities including governments and other attackers. On both sides, from whitehat nonsense to self proclaimed blackhat kiddies, information spreads under the guise of "don't bother looking for the correct way" and I just wanted to throw it out there that we should say it under the guidance of "I tried to study this, this is what I found," or alternatively "I've been recently finding..."

Now some error codes to make this page have a picture on it. People say the picture makes people want to look at your page. hehe.



-Ferasdour
https://keybase.io/ferasdour

No comments:

Post a Comment

2am rant