-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Standard Config XOR Key #22
Comments
通过爆破方式确定config xor key会有个问题,config xor key的变化会导致encrypted_beacon_config的特征发生变化,虽然config xor key只有一个字节,可以进行爆破,但是没法解决定位encrypted_beacon_config的问题 The problem with determining the config xor key by brute force is that changing the config xor key will cause encrypted_beacon_config characteristics to change. Although the config xor key has only one byte, it can be brute force. This does not solve the problem of locating encrypted_beacon_config beacon sample: GeoB.zip |
That Beacon has a {
"BeaconType": [
"HTTPS"
],
"Port": 8902,
"SleepTime": 60000,
"MaxGetSize": 1048576,
"Jitter": 0,
"MaxDNS": "Not Found",
"PublicKey": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDohWpPN9dK5Iaq3j5MARwhwXxMD+LZJY92SEg755tH3cbGJDwjAjae+Cq14PUO5w33EpPbdmLoEfwZmXv2Zz/AYj0O8mNmRw35sEPhPXGKj1Snqz4qS1EVBYgJOSMLEUCg7LBwHQtvsGnoZjszjkVqf9Hi9INcnBF8qLyh4JrKQIDAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==",
"PublicKey_MD5": "5f82233e80427147f9f7ec6eff252049",
"C2Server": "38.6.179[.]130,/fwlink",
"UserAgent": "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; BOIE9;ENUS)",
"HttpPostUri": "/submit.php",
"Malleable_C2_Instructions": [],
"HttpGet_Metadata": {
"ConstHeaders": [],
"ConstParams": [],
"Metadata": [
"base64",
"header \"Cookie\""
],
"SessionId": [],
"Output": []
},
"HttpPost_Metadata": {
"ConstHeaders": [
"Content-Type: application/octet-stream"
],
"ConstParams": [],
"Metadata": [],
"SessionId": [
"parameter \"id\""
],
"Output": [
"print"
]
},
"SpawnTo": "AAAAAAAAAAAAAAAAAAAAAA==",
"PipeName": "Not Found",
"DNS_Idle": "Not Found",
"DNS_Sleep": "Not Found",
"SSH_Host": "Not Found",
"SSH_Port": "Not Found",
"SSH_Username": "Not Found",
"SSH_Password_Plaintext": "Not Found",
"SSH_Password_Pubkey": "Not Found",
"SSH_Banner": "",
"HttpGet_Verb": "GET",
"HttpPost_Verb": "POST",
"HttpPostChunk": 0,
"Spawnto_x86": "%windir%\\syswow64\\rundll32.exe",
"Spawnto_x64": "%windir%\\sysnative\\rundll32.exe",
"CryptoScheme": 0,
"Proxy_Config": "Not Found",
"Proxy_User": "Not Found",
"Proxy_Password": "Not Found",
"Proxy_Behavior": "Use IE settings",
"Watermark_Hash": "BeudtKgqnlm0Ruvf+VYxuw==",
"Watermark": 100000,
"bStageCleanup": "False",
"bCFGCaution": "False",
"KillDate": 0,
"bProcInject_StartRWX": "True",
"bProcInject_UseRWX": "True",
"bProcInject_MinAllocSize": 0,
"ProcInject_PrependAppend_x86": "Empty",
"ProcInject_PrependAppend_x64": "Empty",
"ProcInject_Execute": [
"CreateThread",
"SetThreadContext",
"CreateRemoteThread",
"RtlCreateUserThread"
],
"ProcInject_AllocationMethod": "VirtualAllocEx",
"ProcInject_Stub_hash": "5547675d56441b15c132ad856621eb22",
"ProcInject_Stub": "VUdnXVZEGxXBMq2FZiHrIg==",
"bUsesCookies": "True",
"HostHeader": "",
"smbFrameHeader": "AAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"tcpFrameHeader": "AAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"headersToRemove": "Not Found",
"DNS_Beaconing": "Not Found",
"DNS_get_TypeA": "Not Found",
"DNS_get_TypeAAAA": "Not Found",
"DNS_get_TypeTXT": "Not Found",
"DNS_put_metadata": "Not Found",
"DNS_put_output": "Not Found",
"DNS_resolver": "Not Found",
"DNS_strategy": "round-robin",
"DNS_strategy_rotate_seconds": -1,
"DNS_strategy_fail_x": -1,
"DNS_strategy_fail_seconds": -1,
"Retry_Max_Attempts": 0,
"Retry_Increase_Attempts": 0,
"Retry_Duration": 0
}
|
Recently came across a number of stager payloads that are not using the standard (0x69, 0x2e) XOR configuration key. Given that it's a single byte key a simple brute force check works. Not sure if you want to consider implementing that into your code.
At the same time, also came across one version that along with changing the key, also changed the type markers in the configuration by multiplying them by two. So SHORT moves from 0x01 to 0x02, INT from 0x02 to 0x04 and STR from 0x03 to 0x06, I don't think this will be as easier a fix or option to factor in. Sample currently at https://8[.]218[.]28[.]246:8443/
The text was updated successfully, but these errors were encountered: