Malware Authors are Using Uncommon Programming Languages

1 view
Skip to first unread message

Bill Frantz

Jul 28, 2021, 8:40:23 PMJul 28
to Design
From: SANS NewsBites Vol. 23 Num. 058

cheers - Bill

Malware Authors are Using Uncommon Programming Languages
(July 26, 2021)
According to researchers at BlackBerry, malware creators are
increasingly using arcane programming languages to improve the
development process and to evade detection and hinder analysis.
In particular, instances of malware written in Go, Rust, Nim,
and DLang are on the rise.

Editor's Note

Not sure if I would call languages like "Go" uncommon, but
reverse analysis tools and debuggers are only now starting to
support it well. This will give attackers an advantage. But this
is also not new. Go has been reported as an up-and-coming
malware language for a couple years now due to its concurrency
support and ease of supporting network clients and servers.

Too many host-based defensive tools are easily tricked by using
a slight variation of payloads. Attackers recognize this and can
queue up a list of payloads using Rust, Go, Dart, Julia, etc.
Application safe listing isn't perfect, but it's a heck of a lot
more reliable than trying to play catch-up each time a new
payload variant is identified.

Not only might Go and Rust binaries be better for evading
signature detection, but they could also run more stealthily
than PowerShell. PowerShell post-exploitation tools are easy to
write, but also easy to log and reverse engineer. The more
attackers shift from PowerShell to compiled code, the more
difficult it will be to track them.

Pentesters have done the same thing, transitioning through
PowerShell, compiled Python executables, cscript.exe XML files,
etc; now we're on to Golang and Rust. On top of that, we use
wrappers and encoders - all to avoid signature-based detection.
In your environment, what type of *behavioral* detections do you
have? Will you catch additions to admin groups,
inter-workstation communications, and heavy/odd Active Directory requests?

On the other hand, the commonly used languages are vulnerable to
procedures being contaminated by their data (e.g., buffer
overflows.) We really need to move in the direction of strongly
typed object-oriented languages. One more instance where we know
what to do but lack the will to do it.

Read more in:

Bill Frantz | Privacy is dead, get over | Periwinkle
(408)348-7900 | it. | 150 Rivermead
Rd #235 | - Scott McNealy (1999) | Peterborough,
NH 03458

Reply all
Reply to author
0 new messages