Webex-ploitation

Hey there, my fellow geese. Today, we’re going to dive into Webex forensics with you on an insider threat scenario involving unauthorized remote access including using Webex as a keylogger (wait, what?), and a few other fun discoveries.

DPRK IT workers and worker fraud is running rampant in remote workforces. You’ve probably done a great job locking down RMM tooling and detecting KVM over IP devices, but have you looked at your collaboration tools? Are you like me and wonder if Webex can be used to facilitate fraud? If that answer is yes, you’re in the right place.

Note: Everything referenced below is with the latest, free version of Webex. Some of this may not pertain to an enterprise-managed version of Webex, but most of it should still apply.

Logging

As a blue teamers, the first question we love to ask is, “where are the logs?”

Turns out, logging for both the Windows and Mac Webex client are fairly verbose (maybe a little.. too verbose? 👀) and have some interesting insights. First, where to find them:

Windows

%LOCALAPPDATA%\CiscoSpark\current_log.txt
%LOCALAPPDATA%\CiscoSpark\last_run_current_log.txt
%LOCALAPPDATA%\CiscoSpark\logArchive_*

Mac

~/Library/Logs/SparkMacDesktop/current_log.txt
~/Library/Logs/SparkMacDesktop/last_run_current_log.txt
~/Library/Logs/SparkMacDesktop/logArchive_*

Did you know Webex used to be called Cisco Spark?

None of this is officially documented, but here is how we understand they break down:

current_log.txt Log of the current/most recent Webex session. Sometimes there’s a current_log1.txt? No idea why.

last_run_current_log.txt Log of the previous Webex session.

**logArchive_*** Logs roll off into these .zip files. How far back the logs go will vary depending how how much Webex is utilized. The most we’ve seen is the previous 5 Webex sessions, but depending on session length and use, it could be less.

These logs have some juicy insights for insider threat investigations. The most interesting for this audience, is detecting when a remote control session is established. That can be found by searching for any of the following terms (this works on both Mac and Windows logs):

isRemoteControlSessionEstablished 1 Detects when a remote control session is established

Example:

2026-03-21T01:46:54.593Z <Debug> [3228:0x16a4][]ShareViewModel.cpp:1737 commonHead::viewModels::ShareViewModel::updateLocalShareInfo::[LocalShare] - mLocalShare:state LocalShareStateSharing, isRemoteControlSessionEstablished 1

RemoteControlMouseEvent Indicates mouse movement via a remote session (in the lines following this one, you can even see where on screen the mouse clicks, neat!)

Example:

2026-03-21T01:46:57.399Z <Debug> [3228:0x1ba4][]RemoteControlViewModel.cpp:290 commonHead::viewModels::RemoteControlViewModel::onRemoteControlEvent::onRemoteControlEvent:RemoteControlMouseEvent

RemoteControlKeyboardEvent Indicates keystrokes being pressed via a remote session

Example:

2026-03-21T01:47:14.341Z <Debug> [3228:0x1614][]ShareViewModel.cpp:1103 commonHead::viewModels::ShareViewModel::onRemoteControlEvent::onRemoteControlEvent:RemoteControlKeyboardEvent

Presence of these terms in Webex logs indicate that ‘someone’ has taken remote control of the machine. There is no immediate way to know who that ‘someone’ is, as we don’t get the IP or account of the remote connection; but we may be able to get some clues.

These logs also contain the meeting invite link/room used for the Webex meeting. The following string shows the meeting room URI, with some information redacted.

uriFromMeetingInfo

Example:

2026-03-21T01:46:17.716Z <Debug> [3228:0xccc][]RequestJoinMeetingUtils.cpp:525 RequestJoinMeetingUtils::getUriFromCall::uriFromMeetingInfo: https://meet1585.webex.com/meet1585/j.php?MTID=m9*****************************4d

Unfortunately the specific room ID is redacted (so you can’t barge into someone else’s meeting), however we can still use the meeting room site name/URI for pivoting.

From what we can tell, URIs like “meet123” can and are re-used, and you may see this across multiple users. However, if the same user is using the same room regularly, and there’s remote control indications, that could be cause to investigate further.

Especially if it’s a custom room. Rooms like “grumpygoose.webex.com” come from a paid subscription. If you’re abusing this to commit fraud, you’ll need that because a free Webex account limits meetings to 40 minutes, whereas the paid tier extends a meeting timeout to 24 hours.

Now that we have a meeting URI, we can pivot to our SIEM/network logging to see if there’s any reoccurrence or pattern tied to it. Was it a one time thing? Do they join it every day at a specific time? Are they selling their job to ‘Bill’ in Pakistan and giving control of their workstation via Webex every day while they go chill on the beach? Let your imagination run wild!

Scripting!

Why do all this manually when you can script it? Here’s a PowerShell script that can automatically parse Webex logs from a Windows machine and let you know if remote sessions have taken place.

[embed]

Thanks AI!

Meeting Invites

Another pivot point to investigate is the Webex meeting invites themselves. While you can join a Webex meeting manually by inputting the meeting ID in the client or visiting the URL in your browser; you can also use the Webex client to send a meeting invite to another account directly. This sends an automated email to the invitee that can be hunted on.

Important business

Subject(s): “<Name> is inviting you to a Webex meeting in progress.” “Join me now in my Personal Room”

Sender: messenger@webex.com

Reply-to: <Sending accounts Webex email>

Using this information, we can hunt email logs for reply-to email addresses that look similar to our end users, or repeat meeting invites from the same email address (most likely free email providers like Gmail, Outlook, etc).

This sample Splunk query will look for Webex email invites where the reply-to email address closely matches the recipient address.

index=your_email_index sourcetype=your_email_sourcetype sender="messenger@webex.com" subject IN ("*is inviting you to a Webex meeting in progress.", "Join me now in my Personal Room")
| eval 
    recipient_email=lower(recipient), 
    reply_to_email=lower(reply_to)

/* 1. Extract the aliases and domains */
| rex field=recipient_email "^(?<work_alias>[^@]+)@(?<work_domain>.+)$"
| rex field=reply_to_email "^(?<personal_alias>[^@]+)@(?<personal_domain>.+)$"

/* 2. Exclude internal-to-internal invites */
| where work_domain != personal_domain

/* 3. Strip out numbers, dots, dashes, and underscores, replacing them with spaces */
| eval clean_work = replace(work_alias, "[^a-z]", " ")
| eval clean_personal = replace(personal_alias, "[^a-z]", " ")

/* 4. Split the cleaned aliases into multi-value fields (chunks of names) */
| eval work_parts = split(clean_work, " ")
| eval personal_parts = split(clean_personal, " ")

/* 5. Check if any Work chunk (>= 3 chars) is inside the Personal alias */
| eval matched_from_work = mvfilter(len(work_parts) >= 3 AND like(personal_alias, "%".work_parts."%"))

/* 6. Check if any Personal chunk (>= 3 chars) is inside the Work alias */
| eval matched_from_personal = mvfilter(len(personal_parts) >= 3 AND like(work_alias, "%".personal_parts."%"))

/* 7. Keep the event if EITHER of those checks found a match */
| where (isnotnull(matched_from_work) AND mvcount(matched_from_work) > 0) 
     OR (isnotnull(matched_from_personal) AND mvcount(matched_from_personal) > 0)

/* 8. Combine the matches so you can see exactly what triggered the alert */
| eval overlapping_name_strings = mvappend(matched_from_work, matched_from_personal)
| eval overlapping_name_strings = mvdedup(overlapping_name_strings)

/* Output the final results */
| table _time, subject, reply_to_email, recipient_email, overlapping_name_strings
| sort - _time

This search tries to find strings in the recipient email that match strings in the reply-to/sending email. This isn’t an ‘end all be all’ search, but it’s a starting point.

Another idea is to look at the frequency at which a reply-to emails and a recipient emails invite each other to these meetings. Then, check if those sessions have remote control indicators in the logs.

index=your_email_index sourcetype=your_email_sourcetype sender="messenger@webex.com" subject IN ("*is inviting you to a Webex meeting in progress.", "Join me now in my Personal Room")
| stats 
    count 
    min(_time) as first_seen 
    max(_time) as last_seen 
    by reply_to, recipient
| convert ctime(*_seen)
| sort - count

Remote Control Hunting on the Network

Local logs and Splunkin’ for emails is good and all, but how can we find this with 🪄network traffic🪄?

Using a combination of the below network IOCs will give you a pretty good idea of who may be using this feature. You’ll want to be looking for large volumes to these endpoints over a long period of time to develop a trend.

Again, absolutely none of this is documented by Cisco. Some of these endpoints/APIs may be used for the myriad of other features Webex provides. Thus, you should always double check this with the Webex logs above!

In Windows, the below connections have the user agent sparkwindows/<version>

Screen Sharing Initiated:

PUT https://locus-r.wbx2.com/locus/api/v1/loci/<GUID>/mediashares/<GUID>

Remote Control Session Initiated:

PUT https://locus-r.wbx2.com//locus/api/v1/loci/<GUID>/participant/<GUID>/rdc/sessions/<GUID>

Followed immediately by:

POST https://encryption-r.wbx2.com/encryption/api/v1/kms/messages

Prevention

So now that we’ve got you super paranoid about the insider threats in your org abusing Webex remote control to farm our their job, how can you prevent this?

Webex allows blocking of remote control, but only if you own an enterprise license, have a Webex Control Hub configured, and your Webex clients are configured to point to it.

If you do, you can follow the instructions here. You can also set this on individual meetings that you control, however that isn’t much help in this context.

If you don’t own Webex Control Hub.. well..

If someone has found a way to block this on unmanaged Webex endpoints let me know!

Now… lets get to the really fun stuff.

Didn’t you mention something about a Keylogger?

During analysis of the Webex logs, something interesting caught our eye. While we were typing in a remote control session and tailing the logs, we noticed keystrokes were being… logged?

For reasons we can only speculate, it appears that Webex was logging every keystroke typed, through the remote control session, into the local client log, in Decimal encoded format!

Note: For some reason there are different flag values for some key presses. We’re not exactly sure why, but this did make some key presses show up twice in the logs. If you’re a Webex dev, we’d love to know why! :)

These logs could be decoded many ways. Scripting is probably the easiest, but we decided to make a CyberChef recipe, because, why not?

Recipe linkFind_/Replace(%7B'option':'Regex','string':'.*%20keyboardEvent:%20'%7D,'',true,false,true,false)Find/_Replace(%7B'option':'Regex','string':'%20flags:%208'%7D,',',true,false,true,false)Remove_whitespace(true,true,true,true,true,false)FromDecimal('Comma',false)Find/Replace(%7B'option':'Regex','string':'(%5Cu0010%7C%5Cu0014)'%7D,'',true,false,true,false)Find/_Replace(%7B'option':'Regex','string':'%C2%BE'%7D,'.',true,false,true,false)) — takes a current.log file as input!

This could have been abused in a multitude of different ways. Namely, Infostealers, or tricking your friendly IT admin to control your box and log into something/provide admin creds. The possibilities are endless! Yes, this even logged credentials typed into password fields!

We talk about the issue in past tense because this was reported to Cisco’s PSIRT team on January 14th 2026 and fixed on March 4th 2026 in Webex client version 46.3.0.34324 (consider prior versions vulnerable).

Props to Cisco taking this issue seriously and addressing it in a timely manor, but why not add it to your release notes?

Until this goose comes out of hibernation again, happy hunting!

Zoom next?