Short introduction to Network Forensics and Indicators of Compromise (IoC)

Posted by XoN on June 28th, 2016

Indicator of compromise (IOC) in computer forensics is an artifact observed on a network or in an operating system that with high confidence indicates a computer intrusion. Typical IOCs are virus signatures and IP addresses, MD5 hashes of malware files or URLs or domain names of botnet command and control servers. After IOCs have been identified in a process of incident response and computer forensics, they can be used for early detection of future attack attempts using intrusion detection systems and antivirus software.Wikipedia

Hello w0rld! In this post I am planning to do a brief introduction into network forensics and how network monitoring can be used to identify successful attacks. Network monitoring is essential in order to identify reconnaissance activities such as port scans but also for identifying successful attacks such as planted malware (such as ransomware) or spear-phishing. Generally when doing network forensics the network footprint is of significant importance since it allows us to replicate the timeline of events. With that said, network footprint can still be obscured/hidden by using cryptographic means such as point-2-point encryption. Even if you can’t see the actual traffic because it is encrypted, what you can see is the bandwidth load which might be an IoC.

In incident response the first step is the time that is needed for the attack realization. If the attack is not realized then of course there is no ‘incident response’ (doh!). There is a list of things that the analyst should go over in order to try to identify if an attack was successful. The list is not definite and there are far more things that need to be checked than those discussed here.
Whether an attack is targeted or non-targeted, if it is utilizing the Internet connection in any way it will leave network footprints behind. In targeted attacks we see things like spear-phishing and USB planting that quite often are targeting susceptible individuals with lack of security awareness. Non-targeted attacks might include attack vectors such as malware, ransomware, malicious javascripts, flash exploits, etc. This is not exhausting since flash exploits and malicious javascripts can be used also in a targeted fashion.
By identifying the Indicators of Compromise (IoC), we can have briefly describe each attack vector as follows depending on the network footprint that will have:

  • IP addresses
  • domain names
  • DNS resolve requests/response
  • downloadable malicious content (javascripts, flash, PDF files with embedded scripts, DOCX with Macros enabled)

There are also indicators coming out from behavioural analysis. For example a malware which contacts a Command & Control server will ‘beacon’ in a timely (usually) fashion. This ‘beaconing’ behaviour can be identified by monitoring spikes of specific traffic or bandwidth utilisation of a host. Moreover it can be spotted by monitoring out-of-hours behaviour since a host shouldn’t send data except of X type (which is legit) or shouldn’t be sending any data at all.
Ransomware will encrypt all accessible filesystems/mounted drives and will ask (guess what!?) for money! Most likely it will be downloaded somehow or will be dropped by exploit kits or other malware. Sometimes it is delivered through email attachments (if mail administrator has no clue!). As stand-alone ‘version’ ransomware comes in portable executable (PE file) format. However variants of Cryptolocker are employing even PowerShell for doing so. In order to detect them we need a way to extract the files from the network dump. There are couple of tools that does this such as foremost but it is also possible to do it ‘manually’ through wireshark by exporting the objects. This assumes that the file transfer happened through an unencrypted channel and not under SSL.
Malware might serve many different purposes such as stealing data, utilizing bandwidth for DDoS, or used as a ‘dropper’ where a ransomware is pushed. One of the more concerning is turning a compromised host into a zombie computer. Fast flux malware have numerous IPs associated with a single FQDN whereas domain flux malware have multiple FQDN per single IP. The latter is not ideal for malware authors since this IP will be easily identified and traffic will be dropped (a bit more about ‘sinkhole‘ in the next paragraph!).
Assuming that we are after a fast flux malware that uses a C&C, then there are ways to locate the malware by looking for beaconing. Quite often these malware make use of DGAs (Domain Generation Algorithms) which basically hide the C&C IP behind a series of different domain names. Malware that uses DGA are actively avoiding ‘sinkhole’ which allows ISPs to identify the malicious IP (C&C) and leading to the ‘blackhole’ of the traffic, shunning the communication of the infected system with it.
An infected host will attempt to resolve (through DNS) a series of domain names acquired from the DGAs, This behaviour will lead to lots of ‘Non-Existent’ NX responses from the name server back to the infected machine. Monitoring the number of NX responses might help us identify infected systems. Moreover monitoring the DNS queries should also help.

In a latter post I will publish a small script that I am using for looking for IoC.

Main menu

Script under development 😉

 

Research and Development

Posted by XoN on January 28th, 2016

Hello w0rld. On this post we would like to let you know our areas of research and the research projects that we are working on currently. For 2016 we are planning to develop tools that will be used in our tests. Our areas of interest can be highlighted as:

  • AntiVirus Detection and Evasion techniques (sandbox detection, etc)
  • Packers, anti-debugging, anti-disassembly and binary obfuscation
  • Network packet capture analysis scripts looking for IoC

 

  • FUD Malware (maybe Veil Improvisation)

The initial idea is to find a way to create several different templates on top of Veil. Additionally we can implement several add-ons for Virtual Machine detection or Sandbox Environment detection. This can be either logical-based such as human interaction or can be through technical means like red pills. Even 2-3 assembly instructions can be used for identifying a sandbox environment.
Veil exports a .py file which is quite random. It randomizes variable names and also since it uses encryption it randomizes the key that will be used. Then it encrypts the payload and stores it in a .stub area on the binary. This area will be unfold after the execution and a routine is responsible for decrypting and launching the payload. This doesn’t offer and sandbox detection nor VM detection. It is heavily focused against AVs and specifically it is focused defeating signature-based detection systems.
The idea of having different binaries but still using the same payload (meterpreter) is necessary for pentesters and for generating quickly payloads that will be used in social engineering tasks.
Technically now the most important property is the large keyspace. The larger the key space the more ‘impossible’ to hit the same binary twice. Veil is providing that but still there are issues with the actual binary. My thought is to either break the exported binary and placed it under a new one OR just add several lines of code in the python script that will be used for compilation (through py2exe or pwninstaller). Another possibility is to mess around the pwninstaller and add things there. Another idea is to add randomisation on techniques defeating / escaping sandbox environments.
Things that are looking promising:

  1. Mess with the actual PE Header, things like .STAB areas, add more stab areas add junk data to stab areas or even add other encrypted data that might look interesting (hyperion paper also has a super cool idea…)
  2. Change the file size of the exported binary dynamically. This will happen assuming the above will happen. (Can also be randomized with NOP padding
  3. Change values that will not necessarily mess the execution (maybe the versioning of the PE? or the Entry point of the binary?)
  4. Write a small scale packer for performance and maybe add also VM detection there
  5. Employ sandbox detection and VM detection through several means (this also adds to the 2nd step)
  6. Randomized routines for sandbox detection (if mouse_right_click = %random_value then decrypt else break/sleep)

 

Implementation techniques will include ctypes for sandbox detection and adding loops or other useless things such as calculations. Also using ndisasm or pyelf for messing the binary it is suggested. Red pills can be used in several different techniques.

 

  • Packer

Another idea that JUMPSEC labs have is to develop their own packer. This will have several routines for:

  1. Static analysis obfuscation: Encryption
  2. Dynamic analysis obfuscation: Add noise in program flow/Add randomness to data/runtime
  3. Anti-debugging
  4. Sandbox escape: Detect human interactions

 

  • Network Analysis Scripts

We are developing several scripts for analysing pcap files. The purpose of these scripts is to parse packet captures and to identify whether there are IoC (Indicators of Compromise) by performing statistical analysis of the protocols usage and searching for potential protocol misuse (HTTP requests / responses that arent according to RFC).

 

Covert channels – (Mis)Using ICMP protocol for file transfers with scapy

Posted by XoN on April 24th, 2015

Hello w0rld. In this post I will show how it is possible to (mis)use ICMP protocol for file transfers with scapy.

“In computer security, a covert channel is a type of computer security attack that creates a capability to transfer information objects between processes that are not supposed to be allowed to communicate by the computer security policy.” Source: Wikipedia

I have to give credit to the GhostInTheShellcode 2015 for “borrowing” the idea from the forensics challenge (see my previous post!). It is quite tricky to achieve, but the effort is worth it for the result. Network filtering restricts the traversal of specific packets or all the traffic of a kind. A firewall (pseudo)entry might be similar to “allow src dst http” “allow src dst icmp” and the (invisible usually) implicit deny restrict all other traffic. In cases like this there are 2 solutions; either use the existing “allow” for transferring data or switch to a different protocol which is allowed. ICMP is usually allowed because it was created for network troubleshooting mainly. More over messages like ICMP timestamps are blocked but echo requests/responses are not. A network admin that denies ICMP traffic will have troubleshooting difficulties when problems arise. The idea is not new, and according to the wish list of metasploit we should expect to see ICMP/UDP file transfers add-ons/functionalities to be introduced soon.

My idea can be summarized as the following:

  1. We have 2 ends, sender and receiver (else we can imagine it as attacker/compromised host)
  2. Attacker wants to send a file, let’s say an ELF or a PE file to the compromised host and for a reason he doesn’t want to use the solutions that exist already (meterpreter> upload function for example)
  3. ICMP is connectionless/ and not really stateful as TCP however it keeps track in a timed fashion (it can be considered stateful)
  4. I want to be able to parse a file and break it down to multiple chunks so that I can have different sizes of payloads
  5. Then I will send these chunks
  6. Client will receive these “pings” or more accurately this ICMP echo requests
  7. At the side of compromised host/receiver a file will be created and the payload of these requests will be appended.

For dealing with my ideas, I created 2 python scripts, a sender and a sniffer for grabbing the file. The sender is straightforward. The only thing that I had to add is the way of tearing down a file to multiple chunks and then parse these chunks for sending them. I used an “offset” so that in the future I can change the offset and have my chunks in different sizes. For the screenshot below you need to know that x=1 and y=2. So the seek() will be executed just once for moving the file descriptor “offset” bytes ahead.

offset

Setting the offset for subsequent read

 

After the sender was done the “client” was the next step. I used the sniff() from scapy which I have to admit I didn’t really enjoy. There are several things that I learned out of this process most notable that the count refers to the number of packets that will be received and NOT to the number of packets that will be received from the filter (packets that “hit” the filter!).

Another issue that I had to solve was that I wanted specifically to grab the Type 8echo request” messages. However when I was setting a filter=icmp and then in my callback function an if statement as the following I was getting back duplicate packets.

sniff issue

This didnt work really

 

Because of that I had to use a statement as if raw in downloadlist so that I removed the double entries from my list.

Another funny problem would arise in the case that another machine pings the receiver. In that case the payload of the echo request would be appended on the file. For this I just created an if statement and grab the packets coming from a specific source address.

For testing our scripts in a “real case” scenario we placed the client on the host with IP 192.168.1.56 and the sender on 192.168.1.156. A simple ELF file was created.

elf sent

File used for transfer

Then we launched the client and the sender and…

sending the file

Sender. Sorry for the painful output of the non-printable chars 🙁

 

output_client_kappa

Client receiving the file and.. boom!

 

As you can imagine this PoC does not employ a way of obscuring what was sent. We can see that from what tcpdump spits…

tcpdump_kappa

tcpdump clearly shows that some sort of an executable file that uses libc was transfered!

 

There are multiple limitations and challenges here.

1st  The receiver/compromised host will reply back the payload that will be received; a behavior that is not good

2nd ICMP does not have a “window-size” as TCP; there isn’t any “sliding window” that will allow us to send multiple chunks of a file in a single window. We need to take care of that somehow.

3rd The ordering of data chunks is also a challenge. If the 2nd chunk arrives before the 1st one because of network-related issues (maybe a different route was chosen…) then the receiver/compromised host will reconstruct the file incorrectly

4th Since scapy will be used (for now) we have all the limitations related to its capabilities (root access, installation dependencies, etc).

In order to make it happen we need a small script to behave as a client and another one for the sender. The sender should also take care of the breaking up of the file to chunks of a specific size (must be less than the max_payload_size).

Assuming that the ICMP type 8 messages are permitted then detection of a file transfer happening like that comes down to whether an IDS look for “abnormal” traffic. The type 8/0 messages depending on the OS (*nix/Windows/etc) have a similar payload every time that are getting sent (however it depends on the OS, Windows do not have the same payload with Linux). For finding the actual file though, a reconstruction of the file is necessary. Dealing with avoidance we have the following paths that we can use:

  • Encrypt the payload with a key hardcoded into client/server is obviously the strongest way. This would provide end to end encryption and from the network side it “shouldn’t” be possible to find what was sent.
  • Encrypt the payload with a key that is sent through or a value of a packet. This is less “safe” when compared to method 1. But it is still difficult to reverse it. Even if you have the ciphertext and you can extract which algorithm was used you still need to know the key.
  • Doing transposition/permutation. So imagine that we have an array with bytes where z = 0 and y = position of last element. By just reversing the order in the way transposed[y]=element[z] we can create a sequence that wouldn’t make sense at first place (Keep in mind that we do that per chunk (we can also do it per file but this leads to a smaller obfuscation)… so if we have a chunk size of 50 bytes and we are sending it on the reverse order if a file is big then it wouldn’t be so obvious what it is). This approach is (I guess) a way of performing steganography since we just hide the method that we use and we do not encrypt the actual payload. Still though there would be cases where an image header (or a trailer) sent on the reverse order would give away the fact that this is a header. For example the “.exe” if it is sent in that way it will look as “exe.” and would spoil our technique! Still though from a network forensics standpoint the analyst must find a way to find the start/end of the file and the correct sequences in order to reverse the process and reconstruct the file. There are multiple ways of performing this and only sky is the limit… So another example is to use a matrix x*y with the byte sequence of the payload and then shift the columns and the arrows around (similarly to AES process but without XORing) and then send the new matrix to the client who reverses the process.
  • Use encoding instead. Still though encoding with base 64 can be easily spotted.
  • Use a mixed approach of the the previous 2.

Hiding the message though, doesn’t prove the fact that something sneaky happened. If an IPS monitors the ping requests and realizes that the payload is not the one that it should be then it can just discard the packets. There also firewalls that perform stateful inspection of ICMP.

Covert channels are becoming more and more used. We have seen already steganography been used in videos, music but also in networking protocols. A malware author might use ICMP and/or UDP for dropping his downloader and the necessary protection mechanisms must be therefore deployed for mitigating that risk.

Food for thought:

  • Add also encryption to each chunk by hardcoding a key
  • Porting it to C for making it a Portable Executable (PE-File)
  • Writing it alternatively (still in python) with ctypes
  • Add steganographic ways for obscurity
  • Use other fields for the actual transfer of a file

You can find the sender/client scripts in our github here 

If you are still here, thanks for your time 😉

Blooper Section!

This happened while testing the sender with an offset=3!

trolol

Blooper: When computers decide not to speak human-languages…