IPv6 in Logs with Bits and Pieces
This Post Covers
In the previous post, we covered the basics of Teamviewer log analysis and confirmed that we have a lot more to delibrate from the basic log, ‘connections_incoming.txt’. We have more information coming right up, tips & details including IPv6 in part 2.
Unlike the ‘connections_incoming.txt’, ‘TeamViewer##_Logfile.log’ has more rich information about remote access. The two digits ‘##’ followed by ‘_Logfile.log’ indicates software version. TeamViewer##_Logfile.log is applied in LocalTime, UTC+9 in here South Korea.
Two log files with the exact same name are saved in different directories. Although they both have the same name, contents are distinct.
➔ Records general information of software operation.
[ Fig 1. %USERPROFILE%\AppData\Roaming\TeamViewer ]
[ Fig 2. Content of TeamViewer15.log ]
2. C:\Program Files(x86)\TeamViewer\TeamViewer##_Logfile.log (install path)
➔ Records detailed information of remote access & connections.
[ Fig 3. Remote Access Log ]
All right, We have two logs illustrated in Fig 3. above, filename is containing version numbers, 14 or 15. This tells us the program was upgraded from 14 to 15 at some point in the past. That aside, the file is automatically separated with the name of ‘TeamViewer##_OLD.log’ as soon as the size of original is over 1MB more or less.
Log Analysis Flow & Tips
Let’s assume that remote access starts from Device A all the way to Device B.
1. Session Start & Encryption Negotiation
As a start point, log begins with Activating Router carrier, followed by encryption negotiation process where using AES-256 encryption algorithm for a symmetric key and RSA for key exchange.
[ Fig 4. Teamviewer Connection Log on Device B ]
If we look at the box highlighted in Fig 4 above, local and remote fingerprints are hashed(SHA256) repectively. Like the TeamViewer ID, each device has a unique fingerprint. The fingerprint is generated on the local TeamViewer client by the machines public key and consists of letters, numbers, and special characters.
[ Fig 5. Local Fingerprint of Device B ]
We know Device A(Remote) and Device B(Local)’s fingerprints from the log that makes us have another chance to match suspect’s fingerprint if we find a PC on the crime scene.
Easy way to distinguish whether a portion of logs belong to Device A or B, is just use the role type number. Support PC(Device A) always has type 6 and role 6 whereas, client PC(Device B) has type 3 and role 3. If this doesn’t ring a bell in the future, remember attacker gets the upperhand, gets stronger position.
- type 6, role 6: Support PC(Device A)
- type 3, role 3: Client PC(Device B)
[ Fig 6. Log type & role by Participants ]
4. IPv4 (Public vs. Private)
In the network world NAT does always matter, specifically for P2P(peer to Peer) communication. Device A and B does not know each other’s public IP, private IP and even so, they cannot directly communicate without NAT Table.
NAT Table in home environment? So we need an intermediate node(Server) that works NAT Translation for each party. We call this technique, UDP hole punching. TeamViewer Server(e.g. KR-SEL-ANX-R019.teamviewer.com in Fig 4.) in the middle, between Deivce A and B works for us. That’s why Device A is able to access Device B without any network device in home environment.
UDP hole punching is a commonly used technique employed in network address translation (NAT) applications for maintaining User Datagram Protocol (UDP) packet streams that traverse the NAT.
- punch received a=Public IP:Port
- punch ignored a=Public IP:Port
[ Fig 7. Public IP Address of Device A ]
If Device A and Device B are in the same network(private), they don’t need to use public IP for communication, they use private IP instead. That’s why sometimes we spot private IP from the logs in a test environment.
- punch received a=Private IP:Port
[ Fig 8. Private IP Address of Device A ]
5. IPv6 (Public)
I haven’t seen any IPv6 in Teamviewer log until I used a couple of mobile phones for testing. To check if you have an IPv6 assigned by service provider, go to website at http://test-ipv6.com
[ Fig 9. IPv6 log ]
That being said, not every phone will create IPv6 log. As far as I’m concerned from the test, it’s matter of your service provider directly gives your device IPv6 so that it gets ready to communicate via IPv6. Just so you know about the service plan, mobile phones used in test all use LTE data plan except one, Galaxy S10 5G.
|No.||Test Mobile||Model||5G Support||Service Provider
|Data Plan||in Log|
|1||iPhone 8||A1906||No||LG U+||LTE||IPv4|
|4||iPhone 12||A2403||Yes||LG U+||LTE||IPv4|
|5||Galaxy S10 5G||SM-G977N||Yes||SKT||5G||IPv6|
|6||Galaxy A Quantum||SM-A716S||Yes||SKT||LTE||IPv6|
Search keyword to filter out IPv6 would be as follows:
- EmergingUdpConnection::AsyncSendTo::Handler Send error system:1231 to Public IPv6:port
Galaxy series leave null for Device A’s display name in the Connections_incomings.txt by default, but we could find model name in TeamViewer15_Logfile.log.
6. Update Log
TeamViewer also leaves software update logs including last update time(in unixtime) as well as version, temp directory for a installation binary to save in. In my test environment, username “incheon” could be another evidence factor that should not be overlooked.
[ Fig 10. Tracking Software Update ]
7. Session End
Remote access ends with the keyword ‘RemoveParticipants’ and RA terminates all related services.
[ Fig 11. Remote Session End ]
Unfortunately in this post series we only focused on the TeamViewer logs. However, we need to walk through other teamviewer artifacts like in %USERPROFILE%\Appdata\local\Teamviewer folder and other artifacts as well, registry, event logs and so on.
The more you know, the greater the chance for a good judgement.
Copyright (CC BY-NC 2.0)