rwboyer

IE… I am assuming everything else depends on ‘jquery’ and tablepress depends on ‘jquery-core’ or something along those lines??

thanks,

problem sorted but still curious why nothing else re-loads jquery but tablepress?

RB

Figured out the issue:

Hidden columns via the plugin editor are not counted/visible at all to the JS so my numbering was wonky.

Sorry/Thanks

also tried a different version that was posted here that was even older same results:

“aoColumnDefs”: [ { “bVisible”: false, “aTargets”: [ 6 ] } ]

@kirkpete –

Just trying to get a handle on why you are having such a hard time with wordpress.

I just looked at your hosting provider, if you have a virtual server it should be a walk in the park with nothing really in the way. What kind of account do you have? Windows? LInux?

RB

@kirkpete

actually you can just download a copy of the new wordpress into a new directory, change the wordpress config file to setup connectivity to your database, copy your wp-content directory to the new tree, fire it up and go. If there are db changes required wp will know and do them.

RB

ps. this is roughly what I do using automated tools and db/filesystem snapshots and test virtual machines prior to cutting over to new versions.

@dyske –

yes you can – I only present to people that actually read things.

Go down to the bottom and hit login or just go to the login url directly

https://photo.rwboyer.com/wp-login.php?loggedout=true

You can try to hack one small blog that I own and is not a clients that was affected this morning – I have tried the entire sequence a few times and it seems to be ok now.

I did temporarily disable both options-permalink and xmlrpc until I have a full picture this week.

https://photo.rwboyer.com/

RB

@dyske=

my investigation also confirms your last couple of posts as factual.

My second post in this thread appears at this point to be the entire attack sequence minus the post data (which is not really anything special) the critical info is already posted elsewhere in the thread by someone that detailed the code sequence buried in the username.

One more time for those that have not actually read the thread the options-permalink AND xmlrpc are required for this hack to work the real damage is done via the xmlrpc after the permalinks are changed.

RB

@kirk

what system are you running wordpress on?

can you look at your webserver access logs?

can you do any kind of advanced file search based on change dates or content?

RB

@cyberws

Violent agreement – hence why I keep a pristine code base laying around for deployment. The only thing I took from my active backups are my database and my image files. Everything else in that VirtualServer tree is history. Even checked my database for entries made over the last couple of days, users that shouldn’t be there etc.

RB

@cyberws

I guess my previous life causes me to be extra extra careful – I look at finding the signature as just a validation the system was compromised rather than the ONLY compromise.

RB

For instance I can tell you that 72.167.131.221 looks like it is running an apache server. Not real common on hacked windoze systems

@marc

“tracking fool down”

Sometimes it is good to have a pool of IP addresses used for the attack, even if they are botnets/compromised systems sometimes you can get assistance from the owner of the compromised system to search deeper. Sometimes the fools are dumb enough to use local systems in their office, neighbors, etc.

RB

@cyberws-

I would recommend looking at modification dates and visually examining the files considering I don’t think any of us are absolutely sure exactly what is done on all systems after the XMLRPC.php hack.

I archived my entire compromised directory trees for all effected sites and hope to have an analysis today but that won’t prove a whole lot except verify a trend. Better off looking at all files modified during and after the XMLRPC.php hack signature that I uploaded earlier.

RB