Open ojensen5115 opened 10 months ago
I've worked around the problem for myself by modifying nameserver.go
to read a dns_records.yaml
file on startup, and then basically added the following to the switch in handleRequest
case dns.TypeTXT:
log.Debug("DNS TXT: " + fqdn)
if txtRecords, ok := o.txtMap[fqdn]; ok {
for _, txtData := range txtRecords {
rr := &dns.TXT{
Hdr: dns.RR_Header{Name: fqdn, Rrtype: dns.TypeTXT, Class: dns.ClassINET, Ttl: 300},
Txt: []string{txtData},
}
m.Answer = append(m.Answer, rr)
}
}
I'm not making a pull request because this isn't an ideal solution -- ideally you'd manage this via the internal prompt or somesuch -- but as a quick-and-dirty workaround it solves my problem. I hope someone else may find it useful too.
Full patch is attached nameserver.patch
Thanks for the patch!
For me, the DNS resolution represents at least 50% of evilginx greatness. Having a config file to control records is 👌
@TwistedSim and I added CNAME and MX records to your patch.
We think the next step would be to integrate this in the global config.json file and in the menu.
For now here's the new patch:
dns_records.yaml:
TXT:
nitbx.xyz.: ["blah blah blah"]
CNAME:
lost.nitbx.xyz.: "perdu.com."
MX:
nitbx.xyz.:
- preference: 10
exchange: mail.ca.
This is great! Thanks for the patch! I will definitely be using it as reference when implementing this feature in upcoming patches.
Great job!
@nitbx , I tried your above yaml, after I made your suggested code updates, and it errors as seen below. " [17:55:19] [err] Failed to unmarshal yaml: yaml: unmarshal errors: line 2: cannot unmarshal !!map into []string line 4: cannot unmarshal !!map into []string line 6: cannot unmarshal !!map into []string " I cannot understand your yaml example. Can you explain it?
@bogdan-dt my best guess based on your error is that you're trying to use my patch and nitbx's yaml. If you want to use nitbx's yaml you will need to use nitbx's patch.
SPF and DKIM both require TXT records set on the relevant domain or subdomain. Assuming evilginx is being used as intended, and any phishlets' domains have their nameservers configured to point to the box itself, then as best as I can tell it becomes impossible for emails from these domains to support these standard authentication mechanisms.
This could be resolved by allowing the user to configure custom DNS records. Back in 2018, someone suggested this feature though this issue was closed in May.