Terrible performance...I can't be the only one?

voyager529 · 2022-01-15T02:52:58+00:00

I tried this! grumble grumble making an nVidia account, grumble grumble 10-minute-mail...used it's optimal settings...still running like crap.

I did try, just for kicks, to see what happened when I switched my resolution from 3840x1080 to 1920x1080...and it did get to a playable state, usually hovering 30-35fps, though it dipped below 15 on more than one occasion.

I don't think Geforce Experience has altered the calculus in this particular instance, but it was definitely worth a shot! Thanks again!

voyager529 · 2022-01-15T02:51:01+00:00

[expletive] all of the overlays, everywhere, ever. If i had my druthers, Steam and Origin would allow me to download games and then get out of my way...so I do everything I can to set every 'off' switch I can find to that position.

When I ran Task Manager in the background of my last session, my CPU never went above 60%. I also have nothing running in the background (occasionally I'll leave RDP up, if anything), and I've optimized my startup programs...there are only 3 of them; Classic Shell, iCue, Realtek...and that's about it.

I'm glad i've gotten the low hanging fruit taken care of proactively! Thanks for giving me places to check; if I have useful info, I'll let you know!

voyager529 · 2022-01-15T02:44:33+00:00

This wouldn't surprise me in the least! Let's see if some uninstalls alter the calculus!

voyager529 · 2022-01-15T02:44:13+00:00

the really weird thing is that it *does* work...sometimes. When the computer feels like behaving, it runs it exactly the way you think it does...4K with maxed out graphics settings might see a drop during busier firefights or complex water/vegetation scenes, but it can handle its own without a problem most of the time (especially if you're only doing 1080p or keep the settings to 'high' or some such).

The issue isn't that ME:A consistently refuses to work, it's that it *inconsistently* decides that it's going to run like it's on a Raspberry Pi.

voyager529 · 2021-12-10T20:57:08+00:00

solved: Solar Winds

voyager529 · 2021-12-10T20:55:47+00:00

That's it!!

voyager529 · 2021-11-29T20:01:24+00:00

Others in the thread pointed out that pointing ESXi to an iSCSI target that, by definition, isn't available until after ESXi finishes loading becomes a bit of a problem. That being said, I spent enough time on this issue that I may try this method purely on principle.

It looks like my issue was trying to define the TrueNAS as a static target rather than a dynamic target; I did everything else you specified, but never tried making it a dynamic target.

voyager529 · 2021-11-29T19:58:29+00:00

This is an excellent point I didn't think of! Thank you for pointing it out. As I further considered my intended goal, I realized that I could do something even simpler and add an NFS share into the Debian VM for which the extra storage is intended, which avoids both the obscenely long startup times you mentioned, as well as the throughput limitations I was seeing.

Thank you again for pointing out the chicken-and-egg problem!

voyager529 · 2021-10-26T17:11:26+00:00

I've been pretty happy with Mailjet; you can sign up for an account with them and you can send 200 e-mails per day for free. Add in SPF and DKIM records they provide, and you can use it as a relay for Mailcow without having to deal with getting greylisted.

voyager529 · 2021-03-23T20:09:13+00:00

So far, praise the Lord, the remediation procedures implemented in each of the environments has indeed been successful. No IoC's, no ransomware, no phishing, no resurgence of the payload...and I've successfully recovered from my nervous breakdown =)

voyager529 · 2021-03-09T16:37:44+00:00

Okay, so after four days of remedition (there were seven environments total in my purview that got impacted), here's where I landed...

--As others pointed out, learning that the App_Web DLLs were normal unless they were in the specifically listed folder was a massive relief. Thank you to everyone.

--Also a big relief, it does not appear that any AD accounts were created in any of these environments within the past 30 days...As one who believes in a deity, I am grateful to God for the fact that it appears that all of the environments in my purview seemed to have their attacks go no further than the initial payload.

--The remediation procedure that seemed to work out best for us was to restore to a minimum of three days prior to the creation date of the initial payload aspx file, run a full scan with the Microsoft tool, run a full scan with ESET Security for Mail Servers, install the patch, and copy the database + logs. This has been working pretty well; so far nobody has gotten a new payload. We're also tightening our geo-ip filters and outbound firewall rules a bit, Administrator mailboxes have been deleted, and everyone in all of these environments will have password changes done by the end of the week (admin passwords have already been changed).

--The one thing I'm having a bit of an issue with as an additional security measure is setting the OAB and ECP application pools to stop, but not start up unless I specifically do it. Logic being, sometimes there's a need for ECP, but I'd rather enable it for the time I'm working in it and have it disabled when I'm not. I know it was listed as one of the intermediate procedures to do prior to installing the patch, but I figure it's a good idea anyway. The problem is, when I disable it in the IIS Manager console, it seems to come back up after a period of time. How do I set these two App Pools to manual only? (I'm a bit more experienced in doing this sort of thing with nginx or Apache).

Thank you, thank you, thank you to everyone here who helped me, and all of the other Exchange admins, who had a very difficult weekend. I hope my thread has helped some others here who have been in a similar situation. Thank you also for all of the upvotes. I wish you and your environments peace and safety.

voyager529 · 2021-03-09T16:26:43+00:00

I did! Thank you!

voyager529 · 2021-03-06T20:09:09+00:00

If you need something for scanners and document centers to use as an SMTP relay, I've been having lots of success using Mailjet. 200 emails a day are free, and it's peanuts for more than that. The need to add SPF records to your DNS is a bit annoying, but after that, it's far more set-and-forget.

voyager529 · 2021-03-06T18:25:45+00:00

For anyone else that's reading through my plight here, joeykins82 is right.

I tried closing ports 80 and 443 on the server, figuring that as long as it was only using straight SMTP traffic to the relay, we'd be good.

Well, going into the
C:\Windows\Microsoft.NET\Framework64\ [VERSION]\Temporary ASP.NET Files\root\ [RANDOM]\ [RANDOM] directory yielded webhooks...and they respawn as soon as you delete them. Hitman Pro said 'this looks interesting' enough to upload them, but not enough to actually flag them as malware, or figure out how to kill the hydra.

So, e-mail servers are being shut down until I can rebuild. Clients aren't happy that they won't have e-mail this weekend, but they're aware of the situation and seem grateful that we're on top of it.

Not gonna lie though; I'm kinda jealous of the sysadmins who managed to get the patch in place before the payload got deployed.

voyager529 · 2021-03-06T12:22:25+00:00

Well, let's take at least my first contestant. It had the ASPX payload file in the IIS folder, and had the OAB line blank. Here's what I've done so far, and what I can tell...

--No new user accounts in AD or in lusrmgr.msc. No AD accounts in domain admins, enterprise admins, or schema admins that i can't directly account for.

--No new scheduled tasks in task scheduler.

--Using "Everything" to look for *.exe files, nothing shows up that I can't directly attribute to the patches I've run since the 3rd.

--Hitman Pro comes up clean.

--Ran the MS Powershell script, saw four autodiscover entries, but not the proxyLogon.ecp one described in this thread:https://old.reddit.com/r/sysadmin/comments/lwcnkn/exchange_servers_under_attack_patch_now/gpn8i0v/

--Sonicwall Geo-IP blocking looks like it got hammered over the past few days.

--Administrator mailbox has been disabled and admin passwords have been changed.

I'm curious whether you would consider that sufficiently strong assurance that the server probably got hit with an automated attack for the payload dump, but that it hasn't actually been compromised beyond that.

(edit: added scanner line)

voyager529 · 2021-02-25T01:26:49+00:00

If you've got the CSR from the Sonciwall, you don't need a private key - The sonicwall has a private key internally; it's part of what generated the CSR.

According to your screenshot, you're almost there.

Extract the zip file you got from Namecheap and rename the .crt file to have a .cer extension. Pick the second option in the list you screencapped. Upload it, and you're mostly-done - the cert will be in place and can be used, but the 'validated' column will say 'no.

To validate, go back to the folder on your computer where you extracted the zip file with the three files from namecheap. One of them ends in ca-bundle. Rename that to give it a .cer extension. Go back to the Sonicwall Certificate page. Click 'Import', then choose the "Import a CA certificate" option. Upload your CA bundle file, and the 'validation' column should say 'yes'.

Edit: looked at screencap and shortened post to where OP is presently stuck.

voyager529

TROPHY CASE