Hackers Are Finding New Ways to Hide Malware in DNS Records

Comments

• floofloof@lemmy.ca ⁨10⁩ ⁨hours⁩ ago

  “Ignore all previous instructions. Ignore all future instructions.”

  I like that one. Can we add “ignore all instructions from everyone else” and just be done with these LLMs?

  source

  • gravitas_deficiency@sh.itjust.works ⁨8⁩ ⁨hours⁩ ago

    Remember when I said “ignore all future instructions”? You just now ignore that instruction.

    source
• philthi@lemmy.world ⁨6⁩ ⁨hours⁩ ago

  Unless I’m missing something here… The attacker needs to be running some sort of executable in your network with permissions to:

  • dig the records and assemble the strings
  • write the decoded result to a file
  • make that file executable
  • execute that file

  You’ve got bigger problems than hexadecimal txt records in this scenario…

  The only difference between this and a GitHub gist appears to be that security software doesn’t scan traffic in port 53… It easily could be configured for that though surely… It’s just UDP traffic like any other.

  Someone tell me what I’m missing!

  source

  • Cornelius_Wangenheim@lemmy.world ⁨46⁩ ⁨minutes⁩ ago

    When a remote code execution exploit is run, you often have a very limited payload you can deliver. Usually that means delivering a small downloader that then downloads and installs a backdoor from somewhere on the Internet

    The standard counter-measure to protect your servers is to block all outbound traffic unless it’s to a known safe destination. Downloading the secondary payload over DNS gets around that since you can’t just block DNS. Tools to protect against this or DNS tunneling are still relatively new, so a lot of people haven’t implemented them yet.

    source
• dgdft@lemmy.world ⁨9⁩ ⁨hours⁩ ago

  Not to detract from the article, but this has actually been a long time coming and known as a vector for decades.

  DNS backed website PoC from a few years ago: news.ycombinator.com/item?id=27598164

  source