Archive for the pentest Category

Thoughts on APT28

Posted in pentest, Security on 2015/11/22 by mram

I just went through the slides of Stefano Maccaglia on his research on APT Group 28. APT28 is also known as ‘Sofacy’ or ‘ Sednit’ and thought to be a Russian (semi) state sponsored group.

Stefano’s sheets are good to read as a write-up of his past and still ongoing research on this topic. The sheets can be found here (note: RSA seem to have removed the sheets from their website, here is a Google cache version, of course lacking pictures I found a copy on github here).

Here are a few items I think stand out from his slides and can be usable for us red teamers / defenders:

  • Once again its spear phishing that give the attackers the initial access.
  • The first round of phishing email did not provide much success. Main reason was that outgoing data for some several compromised systems was blocked due to filtering of outgoing data. Ive been saying this for years to my clients: filtering and logging of outgoing data is just as important as incoming.
  • Its not entirely clear from the sheets but it seems that external access to email (Microsoft OWA) with some compromised accounts was possible using just username and password. Using this and due to the wonderfully AD-integrated info of OWA the attackers could do some proper internal intelligence gathering and gain info for new phishing attacks.
  • This one is important: all servers where properly patched, except one server because of some legacy reasons (don’t you just hate / love exceptions). The patch they were missing was MS14-068: a major issue for AD domains. The bigger issue here that many people forget is that domain segmentation in a larger forest does not isolate domain compromises. In this case the DCs of a sub domain lead to full forest compromise. Ouch. So much effort put into proper patching of 99,9% of the systems, and just one missing patch lead to full forest compromise.
  • The defenders made a typical defensive error upon the first recognition of the compromise: they wiped the desktops and reinstalled. Of course the attackers noticed and stayed low for a while (20 days), but still had access via other compromised systems. It was only due to an unrelated investigation that they detected another way that the attackers still had access. Take away: understand your attackers and observe their modus operandi to hit them at the right level in the pyramid of pain. Hard, but so so important.
  • Even the real bad guys just loooove mimikatz.
  • Log analyses of Windows Active Directory remains a big challenge. You need to dive into tiny details of the logs and make correlations in order to detect lateral movement and some more advanced attacks on AD. Microsoft, please give us a better way of interacting with Windows logs!
  • The attackers used Windows mailslot for communication within the network. Mailslot is a form of IPC any modern Windows versions has. Not to be confused with named pipes.
  • The APT28 tools used – although some were relatively advanced –¬† follow the same stages of other know malware, namely downloader, persistent access stager, internal info gathering and some modular platform for target specific functionality.
  • Stefano tries to coin the term ‘actionable IOCs’. I agree not all IOCs are that usable and I like his term.

Go read the full slide deck of you are more interested in all the details.

 

Advertisements

WiFi Pineapple and Mac OS X Internet Sharing

Posted in Notes to myself, pentest, Security on 2014/10/03 by mram

Important: this approach does not seem to work since Mac OS X 10.10 Yosemite.

This one is for you Mac users out there that want to share¬†your Mac’s WiFi internet connection via the LAN cable to the WiFi Pineapple. Using the out of the box Internet sharing option of your Mac doesn’t work with the WiFi Pineapple. I had experienced it again, but never gave it any good look and switched to Linux. Today I it frustrated me and I looked into it.

The problem with the setup is twofold: 1) The Pineapple expects the 172.16.42.0 subnet, while OS X uses 192.168.2.0 when enabling internet sharing, and 2) the Pineapple expects the default gateway on 172.16.42.42 which is not a very logical address for a gateway. Now, we could change all these settings on the Pineapple to match the Mac’s. But sometimes your situation may require different. I couldn’t find any manual on the internet. So here are the steps you need to do:

  1. Disconnect cables from Mac’s LAN to Pineapple.
  2. On the Mac go to Internet Sharing and share your WiFi adapter to the LAN interfaces. Once enabled, disable it again and close the System Preference program. We need this step to write a default config file that we can alter.
  3. The config file that we need to alter is /Library/Preferences/SystemConfiguration/com.apple.nat.plist We need to add an option “SharingNetworkNumberStart 172.16.42.0”. You can manually add this as a dict at the end of the file, or you can use the command “sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.nat NAT -dict-add SharingNetworkNumberStart 172.16.42.0″. This makes sure that 172.16.42.0/24 is now used as the subnet for the sharing interface, and as such fixes our first problem.
  4. Use the GUI again to start Internet Sharing.
  5. Manually change the IP address used by the Mac’s LAN interface with the command “ifconfig bridge100 172.16.42.42 netmask 255.255.255.0 up”.
  6. Now we need to change some DHCP options, because by default the DHCP server tells the clients to use gateway 172.16.42.1. We do this by altering file /etc/bootpd.plist. There are two mentions of 172.16.42.1 that we need to change into 172.16.42.42. We also need to adjust the pool range. Look for the <key>net_range</key> section. Alter the starting address to 172.16.42.43.
  7. Find the PID of the bootpd process and give it a kill -HUP to reread its config file.

That’s it. Now you can connect the LAN cable and enjoy internet from your Pineapple.

SSLsplit on WiFi Pineapple

Posted in Notes to myself, pentest, Security on 2014/07/26 by mram

Update: after this blogpost somebody made an Infusion for SSLSplit on the WiFi Pineapple. That’s great! You can still use the howto below, but the easier way is to install the Infusion via the Pineapple bar.

Recently I was asked by a client to do a penetration test on one of their mobile apps. Fun stuff. One of the things I always test is security of the communication channel. Often SSL over HTTP is used for that. The WiFi Pineapple is a great companion for this as it provides an easy way for setting up a wireless access point with some attacks on the communication, leaving your own pentest machine free for other attacks.

Default approach to analyze traffic is to become Man-in-the-middle between App and server it communicates with. This is easily done by configuring the mobile device with a proxy (if the App communicates via a proxy aware protocol and if it accepts the system proxy settings) or to redirect traffic using iptables on the Pineapple. Than have Burp or any other proxy tool run to intercept and modify the traffic. Nothing new here.

But what was special at this specific engagement was that Burp (or any other proxy tool I know) was unable to interpreter the traffic. Yes, the iptables redirection was working, yes the SSL-mitm worked without a prob. Burp showed the initial request, and wireshark showed the traffic being forwarded to the actual server the App wanted to communicate with. But nothing was happening after that. No data, nothing. After some tinkering the hypothesis was formed that the App used non HTTP traffic over SSL and our proxy tools don’t understand it.

This is where I learned about this great tool SSLsplit. Its a proxy tool able to do full SSL certificate forging, full HTTPS decode, but also able to just show the decoded TCP and SSL traffic if it cant decode it into HTTP. Exactly what I needed! I had some compiling issues getting it to run on my Kali pentest machine. Im sure these could be fixed but I just tried installing it directly on the Pineapple. Turned out it works like a charm. Here is what you need to do:

  • SSH to your Pinapple and update the packages using opkg update
  • Get the OpenWRT libevent2 packages (all 5) from the official mirror at http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages/
  • Download the unofficial OpenWRT build of SSLsplit for OpenWRT at project Ghost on Github: https://github.com/ShaPOC/ProjectGhost/blob/master/software/sslsplit/bin/sslsplit
  • generate the SSL certificate authority and key for SSLsplit to use.
    • openssl genrsa -out certificate.key 4096
    • openssl req -new -x509 -days 365 -key certificate.key -out certificate.crt
    • Depending on the config of the mobile App you may need to import the newly generated certificate.crt onto the device.
  • Know what non intuitive parameters SSLsplit requires:
    • mkdir /tmp/sslsplit (make a working directory)
    • mkdir /tmp/sslsplit/contentlog (make a directory for session logs inside the working directory)
    • ./sslsplit -k certificate.key -c certificate.crt -D -l connections.log -S /tmp/sslsplit/ -L contentlog ssl 0.0.0.0 8888
    • This starts sslsplit with:
      • using the cert authority we just created, used for certificate forging
      • debug output to the main screen (I found this useful, you may not)
      • working dir /tmp/sslsplit, duping the actual content of the connections to /tmp/sslsplit/contentlog/
      • decoding traffic that comes in a port 8888 as ssl
  • Redirect the traffic we want to analyze to port 8888, with a simple iptables script
    • root@Pineapple:~# cat pineburp_split.sh
      #!/bin/sh
      echo ‘1’ > /proc/sys/net/ipv4/ip_forward
      iptables -X
      iptables -F
      iptables -t nat -F
      iptables -P INPUT ACCEPT
      iptables -P FORWARD ACCEPT
      iptables -P OUTPUT ACCEPT
      iptables -t nat -A PREROUTING -p tcp -d @@SPECIFIC_DEST_IP@@ –dport 443 -j REDIRECT –to-ports 8888 (watch it, parameters –dport and –to-ports are double dashes but for some reason WordPress displays them as one).
      iptables -t nat -A POSTROUTING -j MASQUERADE
  • Start your app and see if it accepts the SSL certificate. In my case it did (bad for the App, good for the pentester) and the content was dumped on the pineapple in /tmp/sslsplit/contenlog with a file per TCP sessions.

Full SSL decode. Awesome!