var unreadAlerts = '1';
You have one unread private message from dkota titled Welcome to the Forum!

C2 server implementation of info-stealer ?
#1
If I am developing a stealer that focus on "hit and run" but not persistence,
like once after the exploit and data extraction the malware has been done, it will completely delete itself and been wipe off from disk.
the only communication needed is to report the extracted data from the client back to the operator.

In this case, how can I implement the C2 server,
by bot API service like Telegram or use a VPS as C2 would be more appropriate ?
which one of implementation will be more hard to be trace back or be better in OPSEC and be more secure for the malware operator ?

Any ideas or suggestions ?
Bad things comes to those who waits......
Report
#2
If you know how to create actually anonymous Telegram accounts, then it will probably be easier to set up securely since you already have a platform that's doing a lot of the handling of data. + it's probably easier to code since you only have to mess with the client. If you need a more custom solution then get a vps once you have your c2 code tested ssh to it over proxy drop the files and run your program.
s t a r d u s t   c o l l e c t i v e
- * . *✦٭。 ⋆⚜⋆。 ٭✦* . * -
Jabber: stardust@jabb.im [OTR]
stardust00@mail2tor.com

Reply Quote // Report
#3
Make the C2 a simple HTTP server and log all POST requests as extracted data

Host the C2 on an anonymous VPS which you paid for with crypto and ssh'd over Tor
Reply Quote // Report
#4
Quote:If I am developing a stealer that focus on "hit and run" but not persistence,
like once after the exploit and data extraction the malware has been done, it will completely delete itself and been wipe off from disk.
the only communication needed is to report the extracted data from the client back to the operator.

In this case, how can I implement the C2 server,
by bot API service like Telegram or use a VPS as C2 would be more appropriate ?
which one of implementation will be more hard to be trace back or be better in OPSEC and be more secure for the malware operator ?

Any ideas or suggestions ?

Funny. I am doing the same thing. I can share some ideas:

- The best option is to control your own hosting, but if that isn't available, search for a hosting provider that accepts Bitcoin.
- You can use third-party services like Pastebin, Github, whatever to send commands and that gives many benefits (e.g. packet output is limited to the malware sending a HTTP query to pastebin.com). The main downside to this is that it exposes your communication protocol to outsiders. You can sort of remedy this by encrypting and encoding communication in plaintext (e.g. encrypt text in RC4 then encode with Base64 then upload command to X site), but you are better off serving your own clients because IPs might get banned elsewhere.
Reply Quote // Report
#5
as others have said, can use existing services or put up your own server.
to slightly expand on others answers:
if you are using some public service, be it telegram api, discord webhook, pastebin, smtp, slack or whatever. you should use public key cryptography to make sure only you can decrypt the loot together with some secure encryption like aes, not just rely on a static rc4 key that one can reverse out of your binary.

for hosting own server, if you are cheap and dont want to spend too much, and servers dont need to remain active for long. many cheap VPSes come with pretty high bandwidth, but not much disk space. if you hook up your http server or whatever you use to take in the loot, you can hook up rclone to upload the loot to google drive or other storage service encrypted and save on disk space of the server. letting you take in gigabytes of loot with ease with 3$ a month budget.

but in general terms:
using public 3rd party services:
+ cheap, if not free.
+ already trusted domains and IPs
- easily shut down
- if badly implemented can reveal loot and other info to others
- needs custom code most often
- various platform limitations
- platforms may collect private info
+ but many platforms work well with anonymous users too

hosting own server:
+ full control of the data and processes
+ longevity with correct hosting provider
- costs money
- need to provide some contact info and payment details
+ very few check legitimacy of info and many take crypto as payment

use whatever suits you best. both can work great. both can have issues. both have own limitations.

if i were in your position, id opt in for 3rd party services, since 2 way communication isnt needed. and you can safe a lot on costs by abusing free services. however id also make sure that if one reverses some encryption keys or api keys out of the stealer, it coudnt come back to me, steal the loot or that they coudnt use it to actively monitor anything. if you have something cooking feel free to PM me and see if i can help with making sure whatever you pick is secure.
Reply Quote // Report
#6
phosphate Wrote: as others have said, can use existing services or put up your own server.
to slightly expand on others answers:
if you are using some public service, be it telegram api, discord webhook, pastebin, smtp, slack or whatever. you should use public key cryptography to make sure only you can decrypt the loot together with some secure encryption like aes, not just rely on a static rc4 key that one can reverse out of your binary.

for hosting own server, if you are cheap and dont want to spend too much, and servers dont need to remain active for long. many cheap VPSes come with pretty high bandwidth, but not much disk space. if you hook up your http server or whatever you use to take in the loot, you can hook up rclone to upload the loot to google drive or other storage service encrypted and save on disk space of the server. letting you take in gigabytes of loot with ease with 3$ a month budget.

but in general terms:
using public 3rd party services:
+ cheap, if not free.
+ already trusted domains and IPs
- easily shut down
- if badly implemented can reveal loot and other info to others
- needs custom code most often
- various platform limitations
- platforms may collect private info
+ but many platforms work well with anonymous users too

hosting own server:
+ full control of the data and processes
+ longevity with correct hosting provider
- costs money
- need to provide some contact info and payment details
+ very few check legitimacy of info and many take crypto as payment

use whatever suits you best. both can work great. both can have issues. both have own limitations.

if i were in your position, id opt in for 3rd party services, since 2 way communication isnt needed. and you can safe a lot on costs by abusing free services. however id also make sure that if one reverses some encryption keys or api keys out of the stealer, it coudnt come back to me, steal the loot or that they coudnt use it to actively monitor anything. if you have something cooking feel free to PM me and see if i can help with making sure whatever you pick is secure.

you're right, a static key for rc4, xtea, etc. can be reversed given enough time even if youre creative. do you have any advice on how to implement public key cryptography for communication over http?
Reply Quote // Report
#7
ColdReloaded Wrote: you're right, a static key for rc4, xtea, etc. can be reversed given enough time even if youre creative. do you have any advice on how to implement public key cryptography for communication over http?

you can probably just search some RSA implementation and examples for your language and it gives a working example for encrypting data and then decrypting some data.

most often public key crypto is implemented by generating a random aes key. encrypting the main content with that aes key. then encrypting the aes key with the public key and appending it into the content. on receiving end decrypt the aes key with the private key, then decrypt the content with the decrypted aes key. in the end its the same as any data regarding http. you can transmit the bytes as they are, encode them with base64 or whatever you usually do to transmit the data.

you can replace aes with any other symmetric cipher of your choice if wanted. the general premise stays the same. generate key. encrypt with key. encrypt the key. send on.

if you need any help feel free to PM me. generally its pretty foolproof as long as you make sure you use both algos, the asymmetric and symmetric, correctly and dont leak the private key anywhere.
Reply Quote // Report


Quick Reply
Message
Type your reply to this message here.





Users browsing this thread: purely_cabbage
var thread_deleted = "0"; if(thread_deleted == "1") { $("#quick_reply_form, .new_reply_button, .thread_tools, .inline_rating").hide(); $("#moderator_options_selector option.option_mirage").attr("disabled","disabled"); }