Don't Connect Back - Beaconing Malware
#1
Welcome bois and girls to what is in essence a little word of advice. I'm no expert on coding malware and I don't even consider myself a hardcore programmer. What I do know the most about (which is not much relative to some people) is networks and network security. So with these things in mind, I'm going to talk about a malware concept called beaconing. If you think about it for a minute you might guess what this means. So let's get to the meat of it.

  To understand beaconing, you have to understand how malware communicates with its' master. In the old days, malware would start listening on a victim machine's port much like a web server or email server. The malware owner would connect to this service and do whatever they wanted. This isn't used as much today with NAT being commonplace, halfway decent firewalls preventing incoming connections, and the fact that it's easy to see if a new service pops up on your box. So hackers being hackers, they adapted and started having malware connect back to them instead. It's fairly rare for a box to have any kind of egress filtering that will be good enough to prevent a connection back to a C&C server. It can be done of course, but that's typical for highly secure places like critical infrastructure of governments and companies. So this is the default today. Connect back malware. So that was a boring history of malware. Why does it matter?
  Let's look at an example of connect back malware.
Code:
C&C          Victim

 __            __
|  | <------- |##|
----          ----

This is all fine, but there's at least one critical issue. The connection can be seen by a wily sysadmin or user and they could potentially determine it's malicious. Connections can be seen via netstat and other utilities, because the C&C and malware are maintaining a connection all the time. They may not realize it's bad of course, but we don't want to take that chance. The answer is beaconing. Beaconing is when the malware connects back to its' C&C periodically to get instructions. Powershell Empire is a good example that you can google and read about. Go check out its' source code too. The chances of your malware's communications getting spotted are a lot less. The sysadmin or user would have to be watching at the exact time that the malware was calling back or see the tiny amount of traffic in logs of some form. This may not be a big issue if you're putting malware on your mom's laptop, but in corporate environments or governments this can mean the difference between getting caught or not. Companies will have firewalls, IDS, IPS, EDR, etc. If you have a ton of traffic generated by that constant connection, you're more likely to get seen. Beaconing is very hard to pick out of the massive amount of traffic flowing over the wire in big networks. Especially if the traffic is well disguised to look just like all the other traffic.
  Hope you enjoyed this thread. It was kind of short and a basic concept, but it'll help you if you're new. Peace out Wink
Reply
#2
That's an excellent idea. I've thought about this before too, but I always overcomplicate it in my head. How you explain it is pretty simple. Didn't know this was a known concept.

I'll definetly try this in my next PoC Malware... I like to experiement and play around. See how much AV I can evade etc, never use it anywhere.

I think a good idea in addition to this would maybe to either randomize the beacons. So no patterns are made. Pad the packets with random size, so there's no common denominator there. And maybe even take the business week in consideration, for example prefer beacon on saturdays/sundays where's not likely any sysadmin working. Or maybe at least limit major operations like file exfiltration those days..

Maybe also take timezone in considerations and try to beacon at night? Might not be effective if sysadmin is outsourced to india or something... which I've experienced with some companies during my work.

But on the other hand, this might make the packets stand out more. If we do it during busy business hours, it might hide it in plain sight better.

Interesting thoughts.. I'll have to think more about this Smile
Reply
#3
(02-09-2021, 06:49 PM)Insider Wrote: That's an excellent idea. I've thought about this before too, but I always overcomplicate it in my head. How you explain it is pretty simple. Didn't know this was a known concept.

I'll definetly try this in my next PoC Malware... I like to experiement and play around. See how much AV I can evade etc, never use it anywhere.

I think a good idea in addition to this would maybe to either randomize the beacons. So no patterns are made. Pad the packets with random size, so there's no common denominator there. And maybe even take the business week in consideration, for example prefer beacon on saturdays/sundays where's not likely any sysadmin working. Or maybe at least limit major operations like file exfiltration those days..

Maybe also take timezone in considerations and try to beacon at night? Might not be effective if sysadmin is outsourced to india or something... which I've experienced with some companies during my work.

But on the other hand, this might make the packets stand out more. If we do it during busy business hours, it might hide it in plain sight better.

Interesting thoughts.. I'll have to think more about this Smile

Good thoughts. Randomizing the callback times is a good idea. It seems less suspicious. Powershell empire is the golden child as far as beaconing goes. It can do all the things we're talking about. As far as the timezone thing I personally wouldn't have the malware operate when nobody is around. You'd think it would blend in better, but can actually have the opposite effect (depending on your target). A lot of times, it's more suspicious if a "user" (your malware) is browsing the internet when nobody is supposed to be in the office. There's nothing for the traffic to blend in with. Just my thoughts though. I appreciate the response Smile
Reply
#4
(02-09-2021, 07:50 PM)deviant Wrote:
(02-09-2021, 06:49 PM)Insider Wrote: That's an excellent idea. I've thought about this before too, but I always overcomplicate it in my head. How you explain it is pretty simple. Didn't know this was a known concept.

I'll definetly try this in my next PoC Malware... I like to experiement and play around. See how much AV I can evade etc, never use it anywhere.

I think a good idea in addition to this would maybe to either randomize the beacons. So no patterns are made. Pad the packets with random size, so there's no common denominator there. And maybe even take the business week in consideration, for example prefer beacon on saturdays/sundays where's not likely any sysadmin working. Or maybe at least limit major operations like file exfiltration those days..

Maybe also take timezone in considerations and try to beacon at night? Might not be effective if sysadmin is outsourced to india or something... which I've experienced with some companies during my work.

But on the other hand, this might make the packets stand out more. If we do it during busy business hours, it might hide it in plain sight better.

Interesting thoughts.. I'll have to think more about this Smile

Good thoughts. Randomizing the callback times is a good idea. It seems less suspicious. Powershell empire is the golden child as far as beaconing goes. It can do all the things we're talking about. As far as the timezone thing I personally wouldn't have the malware operate when nobody is around. You'd think it would blend in better, but can actually have the opposite effect (depending on your target). A lot of times, it's more suspicious if a "user" (your malware) is browsing the internet when nobody is supposed to be in the office. There's nothing for the traffic to blend in with. Just my thoughts though. I appreciate the response Smile

True, now that you mention it. Might be better to blend in and connect during normal hours. I'll see if I can come up with some cool POC-malware this weekend. For fun and profit. I will post source here Smile
Reply
#5
Hello guys! 

You're right about revers connect or command control servers but I just want to point out that this has been in practice for some time.

PI - 2005
Bifrost - 2004

**Zeusbot or any other bot that connects to some webform and gets commands without making a direct connection - 2007
Reply
#6
Thank for sharing that dude. I heart that some technics more abpout chaging just firewall, and to create a backdoor in config, and just connect in ssh or something..
Reply
#7
(07-24-2021, 04:38 PM)s3ckt0r Wrote: Hello guys! 

You're right about revers connect or command control servers but I just want to point out that this has been in practice for some time.

PI - 2005
Bifrost - 2004

**Zeusbot or any other bot that connects to some webform and gets commands without making a direct connection - 2007

Correct. For any sort of C2 that needs to work with data provided by the clients connecting to it; having the clients connect over HTTPS to the C2 may be your best bet. Provided you are using DNS Fast Flux in order to protect the integrity of your C2 infrastructure.

A benefit of using SSL/TLS is that it makes it harder to see what the traffic is all about, though not impossible of course. Encoding the data before you send it over SSL/TLS to the C2 server adds another layer of protection. Spoofing the process name and/or PID, to make it appear as though Windows Update or telemetry operations are being run takes a lot of the suspicion away in terms communicating during all hours of the day.


Realistically there is only one time a good ransomware ought to be in contact with C2, that time would be when sending over the file list, checksums, dynamically generated keys, and confirmation that all operations went smoothly or if errors prevented some of the operations from being performed or not.

Additionally, all checks can be done on target first instead, for minimal communications. If you must have a systems and status overview, you could save that output locally, have a different set of crypto routines to encode that data and ask the target to send a copy of it in addition to and/or as a condition for becoming eligible for the decrypting PE, when payment in crypto is made in full.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  The Malware Mega Thread. Vector 70 159,918 09-21-2021, 02:31 AM
Last Post: Vector
  I am interested in making malware... shmoeke 9 5,904 09-06-2021, 01:40 PM
Last Post: Vector
  I want to be a Malware Developer. TheCodeGirl 3 2,937 09-06-2021, 12:45 AM
Last Post: neftis
  experimental malware neftis 0 2,681 08-22-2021, 08:26 PM
Last Post: neftis