Konni's New Vector: Abusing KakaoTalk to Spread EndRAT
Hey team,
Just caught the latest report from Genians regarding the Konni group (often associated with APT-37). They are pivoting from standard payload delivery and are now actively leveraging the KakaoTalk desktop client to propagate EndRAT.
The attack flow is particularly insidious because it abuses social trust:
- Initial Access: Spear-phishing emails disguised as government policy documents.
- Compromise: Execution of EndRAT on the victim's machine.
- Propagation: The malware accesses the local KakaoTalk application to send malicious payloads to the victim's existing contacts.
Receiving a malicious file from a trusted contact on a platform you use daily significantly lowers defenses. Since the specific hashes may change rapidly, we need to focus on behavioral detection.
I've thrown together a quick KQL query for Sentinel/Defender to hunt for suspicious child processes spawned by the chat client:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "KakaoTalk.exe"
| where ProcessFileName in~ ("powershell.exe", "cmd.exe", "cscript.exe", "wscript.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
For those on the blue team side, how are you handling "trusted application" abuse in your environments? Are you blocking niche chat apps, or do you rely on EDR alerting on child process anomalies?
This mirrors the abuse we saw with Slack and Teams payloads last year. The 'Trusted Parent Process' is a classic LOLBIN-style evasion that works surprisingly well.
We implemented a Sigma rule to catch this specific behavior across all IM clients. It helps to correlate the network traffic as well—KakaoTalk shouldn't be reaching out to unknown IPs immediately after spawning a shell.
detection:
selection:
ParentImage|endswith: '\KakaoTalk.exe'
Image|endswith:
- '\powershell.exe'
- '\cmd.exe'
condition: selection
Expect some noise during updates, but it's better than missing the C2 beacon.
Solid advice. From a sysadmin perspective, if KakaoTalk isn't business critical, the best control is software restriction policies via AppLocker.
We have a strict whitelist. If an app isn't in the C:\Program Files\Approved directory, it doesn't run. It stops these niche malware vectors dead in their tracks without needing to tune SIEM rules constantly.
The psychological angle here is fascinating. Konni knows that if I get a file from my boss on KakaoTalk, I'm 100x more likely to open it than if it came from a random email address.
During our last phishing sim, we tested a similar vector using a simulated internal IM message. The click rate was astronomical compared to standard email templates. User awareness training really needs to evolve beyond 'Don't click email links.'
Excellent points, everyone. Beyond AppLocker, hunting for unexpected module injections within the chat client is crucial.
I've found success checking for suspicious paths like Temp folders loading into the process space. You can run this quick PowerShell one-liner on suspect machines:
Get-Process -Name KakaoTalk -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Modules | Where-Object {$_.FileName -like '*Temp*'}
Catching these anomalies often flags the injection before the lateral movement kicks in.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access