Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


SteveYates last won the day on September 14

SteveYates had the most liked content!

Community Reputation

18 Good

My Information

  • Agent Count
    < 500 Agents

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. CW has duplicated the large file issue...the files are named .jpg but are actually BMP format according to Firefox. Future patch, may be a few months, etc. CW hasn't duplicated the double screenshots, but we found that super-admin is irrelevant, the issue was actually that PCs on our office LAN only generate one file, and PCs out of our office 99% of the time generate 2 files. lterrors.txt logs "Send ScreenShot Error ERR Microsoft.VisualBasic The process cannot access the file 'C:\WINDOWS\Temp\ltss-0.jpg' because it is being used by another process.:::". I suspect the large file size is causing the upload to be slow enough that it is retrying. Maybe when they fix the size/format this will go away also. I figure somewhere there’s someone with 5000 agents whose techs like screenshots and they are generating quite a bit of disk usage…
  2. https://www.samba.org/samba/security/CVE-2020-1472.html "...since version 4.8 (released in March 2018), the default behaviour of Samba has been to insist on a secure netlogon channel, which is a sufficient fix against the known exploits. This default is equivalent to having 'server schannel = yes' in the smb.conf. Therefore versions 4.8 and above are not vulnerable unless they have the smb.conf lines 'server schannel = no' or 'server schannel = auto'. Samba versions 4.7 and below are vulnerable unless they have 'server schannel = yes' in the smb.conf."
  3. You're probably running the script as the default agent user which runs as localsystem. To get into the logged in user's directory you'd have to use the "console execute" or similar script commands to run as a user (it runs the program through the tray icon). Along the lines of what Wesley said, run "set" at the remote command prompt: %windir%\system32> set ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Windows\system32\config\systemprofile\AppData\Roaming ... LOCALAPPDATA=C:\Windows\system32\config\systemprofile\AppData\Local ... Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps ... PUBLIC=C:\Users\Public ... TEMP=C:\Windows\TEMP TMP=C:\Windows\TEMP ... USERNAME=PCNAMEHERE$ USERPROFILE=C:\Windows\system32\config\systemprofile
  4. I created a monitor: table: eventlogs field: EventID InSet (5827,5828,5829,5830,5831) ID field: Concat(eventlogs.`TimeGen`,': ', Replace(Replace(eventlogs.`message`,'\'', ''), '\n', '')) AS loggedEvent add'l condition: eventlogs.logname='system' and timegen > DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) We have found zero events so far. From posts on the patchmanagement.org list, it seems that past-EOL Windows 7 is only blocked if the default security settings have been lowered Installing the patch is sufficient to block the attack from Windows computers The concern would be other devices (e.g. NAS joined to the domain? Old Macs maybe?) As for when a specific patch was installed, the Patch History tab will show that so it's presumably somewhere in the database. However that gets pruned out eventually. Windows itself tends to replace its own history for superseded patches, like when a new monthly CU installs. Or, Win10 feature updates erase Windows' own history. We have a search for missing KBs, but note it has issues such as different Win10 FUs tend to have different KB numbers, and this KB will be "missing" once the next monthly CU installs:
  5. I'm pretty sure you have to limit the SQL. You could try logging the computername to test.
  6. I was just looking at permissions for my CW ticket from the screenshots issues from 2020.8 (which we are still on). I saw this was unchecked for our users. Not sure if it's new, can you check yours?
  7. Have you tried dating the batch file? ShadowTest20200911.bat for example? That may be seen as new if the remote monitor is saved. Or, have you tried saving the remote monitor again after changing the batch file? Maybe that "rereads" the batch file? What I was trying to suggest is to run a different script that downloads the batch file every week or whatever, so changes are pushed out regularly.
  8. If it was a script it should detect changes when downloading a file, but there is a "force download" option in scripts, as I recall. In cases similar to this we just add a line to our "regularly scheduled script" script that would download updates for the file every week or two, whenever that script runs.
  9. If it helps alleviate your concerns about the users saving, saving changes is the default. There are many things in the UI I find silly (besides the long history of spelling errors that have slowly been fixed over the past 10 years). One is that in Dataviews, Options->List Settings has Save Settings on Close checked by default. Note there is also an option for Clear Custom Settings on Close that can also be checked. If both are checked at the same time, I don't know, maybe a black hole is created or something.
  10. You're not wrong, mine doesn't scale very well. That's why I suggested having pfSense email the notification. For our uses, we have one client on DHCP where we need to use the IP in a firewall rule, and one client that doesn't have a pfSense. I'm pretty sure I did look at the hardware change tables at a time, a few years ago, and didn't find the IP there.
  11. If you just want to know if the client's WAN IP changes (failover happened) that can be done in an internal monitor, though it's a bit manual and requires one monitor per client. Make a group "IP address changes" and add the server at each client to monitor (servers rarely leave the office). Target the monitor to this group. table: computers field: RouterAddress NotEquals result: 'ip.address' <-- primary WAN IP identity: RouterAddress condition: Clients.Name = 'clientname' If the PC's IP changes (how it connects to CWA), the monitor alerts.
  12. Functionally it's been OK. We noticed two issues with screenshots this week. 1) screenshots are duplicated by non-super-admin users (one request, two pictures received), and 2) screenshots are around 4-15 MB depending on screen resolution, whereas they used to be 100-200 KB or so, and the largest (2560x1440) can't display (ltclient logs an out of memory error). They can be opened from L:\Screenshots fine.
  13. Possibly you could write a script to find the file/version and track it in an Extra Data Field?
  14. In theory, it's more complicated than that, see: However that said, as I mentioned in that thread we deleted the Windows Defender 10 virus config to bypass the incorrect detections that still occurred.
  15. An internal monitor can have that info in the Identity field, but be aware anything too unique (e.g. timestamp) will trigger a new alert when that info changes. Our event monitors have: substr(concat(eventlogs.logname,'/', eventlogs.eventid,' - ', replace(replace(replace(replace(replace(replace(eventlogs.message,'\'', ''),'\"', ''),'\\', ''), '\t', ''), '\r', ''), '\n', '')), 1, 99) The replacing and 99 char limit was something CWA made us do several years back, not sure if it's still a thing. Then the alert text has it in %fieldname%: A monitor detected a STOP error/bugcheck event on %CLIENTNAME%\%COMPUTERNAME% at %LOCATIONNAME%. The Event occurred in log/ID: %FIELDNAME%.
  • Create New...